gematik und Telematikinfrastruktur: Sicherheit und Zulassung

Problem in der Praxis

In vielen Teams gilt die TI-Zulassung als formaler Abschlussschritt. Das Produkt wird gebaut, und erst danach stellt sich die Frage, welche Nachweise das unabhängige Sicherheitsgutachten verlangt. Dann fehlen Architekturentscheidungen und Belege, die sich im Nachhinein nur schwer rekonstruieren lassen.

Ein zweites Muster: Zero Trust wird als einkaufbares Produkt missverstanden statt als Architekturprinzip. Hinzu kommt die Versionsdynamik: Spezifikationen und Releases der TI 2.0 entwickeln sich weiter, und konkrete Pflicht- und Migrationsfristen sind release- und produkttypabhängig. Wer auf veraltetem Stand plant, riskiert Nacharbeit kurz vor der Zulassung.

CISO-Einordnung

Ein belastbarer Zulassungsweg beantwortet nicht nur die Frage "Erfüllen wir die Spezifikation?", sondern vor allem:

• Welche TI-Rolle bzw. welcher Komponenten-/Diensttyp liegt vor, und welcher Zulassungs- oder Bestätigungspfad gilt dafür?
• Wie ist das Zero-Trust-Prinzip in der Architektur verankert (kein implizites Vertrauen, kontinuierliche Authentifizierung und Autorisierung)?
• Wo entstehen die Sicherheitsnachweise im Betrieb, und wer verantwortet sie?
• Wie ist das Zusammenspiel von gematik (Zulassung), BSI (Benehmen zur Datensicherheit, Prüfung externer Gutachten) und BfDI (Datenschutz) organisiert?

ZETA folgt der Zero-Trust-Logik mit vorgelagertem Zugriffswächter und nachgelagerten Ressourcen; die zugehörigen Spezifikationen sind lizenzsensibel und nur als Referenz zu behandeln. Für die Behördenzuordnung gilt: Zuständig sind gematik, BSI und, für angrenzende Bereiche wie DiGA/DiPA und Medizinprodukte, das BfArM. Die BNetzA ist für den Gesundheitssektor nicht zuständig.

Umsetzungsperspektive

Der Zulassungsweg sollte früh und entlang weniger stabiler Kernpunkte aufgesetzt werden:

• Rolle und Diensttyp klären und daraus den anwendbaren Zulassungs-/Bestätigungspfad ableiten (gegen den aktuellen gematik-Prozess verifizieren).
• Die Zero-Trust-Architektur (ZETA) so entwerfen, dass sie Releasewechsel übersteht und nicht an eine einzelne Spezifikationsfassung gekettet ist.
• Sicherheitsnachweise als Nebenprodukt des Betriebs erzeugen, nicht nachträglich rekonstruieren.
• Das unabhängige Sicherheitsgutachten und die BSI-Bestätigung als feste Abhängigkeit einplanen, nicht als Endabnahme.
• Den anwendbaren Spezifikations- und Releasestand samt Fristen aktiv nachhalten; diese sind versionsabhängig und im Einzelfall zu prüfen.

Bewährt hat sich, die TI-Sicherheitsarbeit auf das bestehende ISMS aufzusetzen statt eine Parallelstruktur zu errichten; das Sicherheitsgutachten stützt sich dann auf Belege, die im Regelbetrieb ohnehin entstehen.

Typische Fehler

1. Die Zulassung wird als Projektendpunkt geplant statt als dauerhafte Nachweispflicht.
2. Zero Trust wird als einkaufbares Produkt verstanden statt als Architekturprinzip.
3. Sicherheitsnachweise werden erst kurz vor dem Gutachten erzeugt.
4. Die Zuständigkeit wird falsch verortet (etwa BNetzA statt gematik/BSI/BfArM).
5. Spezifikations- und Releasestände sowie Fristen werden als fix angenommen, ohne den anwendbaren Stand zu prüfen.

Risiken und Trade-offs

Ein zu enges Festkleben an einem einzelnen ZETA-Release erzeugt Architektur-Lock-in und teure Migrationen; ein zu loses Verhältnis zur Spezifikation gefährdet die Zulassung selbst.

Das unabhängige Sicherheitsgutachten kostet Zeit und Geld, liefert aber externe Glaubwürdigkeit und deckt blinde Flecken auf. Wer es zu spät beauftragt, verschiebt die Marktreife; wer es zu früh auf unfertigem Stand beauftragt, prüft eine Architektur, die sich noch ändert. Schließlich besteht ein Trade-off zwischen operativer Telemetrie und Datenschutz: kontinuierliche Verifikation erzeugt Zugriffs- und Kontextdaten, deren Verarbeitung mit Blick auf den Datenschutz (BfDI-Einbindung) abzuwägen ist.

Entscheidungspunkte

• Welche TI-Rolle und welcher Diensttyp liegen vor, und welcher Zulassungspfad folgt daraus verbindlich?
• Wann wird das unabhängige Sicherheitsgutachten beauftragt, damit es weder zu früh noch zu spät greift?
• Wie wird die Zero-Trust-Architektur so gestaltet, dass sie Releasewechsel der TI 2.0 überlebt?
• Wie werden das Benehmen mit dem BSI und die Einbindung des BfDI organisatorisch verankert?

Praktische Empfehlungen

1. Klären Sie Rolle und Diensttyp und damit den anwendbaren Zulassungsweg, bevor Architekturentscheidungen festgezurrt werden; gleichen Sie dies mit dem aktuellen gematik-Verfahren ab.
2. Entwerfen Sie Zero Trust (ZETA) als Architekturprinzip, nicht als Zusatzkomponente.
3. Machen Sie Sicherheitsnachweise zum Nebenprodukt des laufenden Betriebs.
4. Planen Sie das unabhängige Sicherheitsgutachten und die BSI-Bestätigung als harte Abhängigkeit ein.
5. Verfolgen Sie Spezifikations- und Releasestände sowie Fristen aktiv und als versions-/produktabhängig (im Einzelfall zu prüfen).
6. Verankern Sie die TI-Sicherheitsarbeit im bestehenden ISMS.

Relevante Normreferenzen

• § 306 SGB V und § 311 SGB V: gesetzlicher Auftrag der gematik (TI-Gestaltung/-Betrieb, Spezifikationen, Zulassungs-/Bestätigungsverfahren); § 311 Abs. 2 SGB V regelt die Festlegung technischer Maßnahmen zur Datensicherheit im Benehmen mit dem BSI.
• § 391 SGB V: IT-Sicherheit in Krankenhäusern (Stand der Technik), relevant für angebundene Krankenhäuser; löst den früheren § 75c SGB V ab.
• BSIG in der Fassung des NIS2UmsuCG: Gesundheit als Sektor hoher Kritikalität; die konkrete Paragrafennummerierung (etwa §§ 28/30 ff.) ist gegen den geltenden Gesetzestext zu prüfen.
• gematik-Spezifikationen einschließlich gemSpec_ZETA: nur als Referenz, keine Volltexte oder Anforderungslisten.
• ISO/IEC 27001: methodischer ISMS-Unterbau, nur als Referenz.