Die Telematikinfrastruktur (TI) ist ein Netzwerk, welches verschiedenste Akteure des Gesundheitswesens (Ärzte, Apotheken, Krankenkassen etc.) mithilfe mehrerer TI-Anwendungen (z.B. E-Rezept, elektr. Patientenakte, TI-Messenger) miteinander verbindet, um somit die Digitalisierung des Gesundheitswesens voranzutreiben. Die Grundlagen der TI haben wir bereits in einem vergangenen Blogpost zusammengefasst.
Die Gematik GmbH, welche mit der Spezifizierung und dem teilweisen Betrieb der TI beauftragt ist, arbeitet momentan an einer neuen Version der TI. „TI 2.0“ genannt, soll der Teile dieser grundlegend überarbeiten. Unter anderem soll die Netzwerkarchitektur und deren Vertrauensgrenzen in der TI-2.0 auf ein „Zero Trust“-Modell umgestellt werden. In dieser, im Gegensatz zur alten Architektur, gibt es kein internes Netzwerksegment mehr, dem vertraut wird. Der Quellcode der neuen Softwarekomponenten, wurden nun unter dem Namen „Zero-Trust-Access (ZETA)“ auf GitHub veröffentlicht. Sie sichern zukünftig den Zugang zu den sensiblen TI-Anwendungen.
Netzwerkarchitektur der TI-1.0
Die aktuelle Architektur der TI-1.0 ist ein Virtuelles-Privates-Netzwerk (VPN) zwischen den TI-Nutzern und Anwendungen, welches logisch vom normalen Internet getrennt ist. Die TI-Anwendungen sind dadurch nicht einfach aus dem Internet erreichbar, sondern nur von innerhalb diese VPNs. Um z.B. Arztpraxen den Zugang zu diesem VPN zu ermöglichen, erhalten diese spezielle vom BSI zertifizierte Router, sogenannte Konnektoren, welche vor Ort angeschlossen werden und Anfragen an TI-Anwendungen automatisch in das VPN leiten. Um sich gegenüber einer TI-Anwendung zu identifizieren (z.B. um zu entscheiden auf welche Patientendaten zugegriffen werden darf) besitzen Praxen zusätzlich ein Kartenterminal in dem deren Praxisausweis (SMC-B) und der Heilberufsausweis der Ärztin (eHBA) steckt. Deren Zertifikate werden zusammen mit der Anfrage an die jeweilige TI-Anwendung übermittelt.
Diese Architektur bringt jedoch auch Probleme mit sich. Zum Einen bedeutet der Zugang über zentrale Hardware, dass Nutzer für die Teilnahme an der TI auf die wenigen zertifizierten Konnektor-Hersteller angewiesen sind. Änderungen an den TI-Rahmenbedingungen, wie zum Beispiel das Auslaufen von Konnektor-Zertifikaten oder eine Änderung des verwendeten Verschlüsselungsalgorithmus, können den Kauf eines Ersatzgeräts erzwingen, wie wir in diesem Blogpost berichtet haben. Der Konnektor, der für die Zugangskontrolle verantwortlich ist, vertraut Anfragen von innerhalb des VPNs grundsätzlich. Eine unsachgemäße Installation oder Entsorgung von Konnektoren kann Unberechtigten dadurch schnell Zugang zur TI und somit auch zu sensiblen Patientendaten ermöglichen. In der Vergangenheit wurden z.B. die Netzwerkkabel von Konnektoren falsch herum angeschlossen, wodurch der VPN-Zugang aus dem Internet möglich wurde, oder man konnte gebrauchte Kartenterminals mitsamt eingestecktem Praxis-/Heilberufsausweis auf Ebay kaufen.
Netzwerkarchitektur der TI-2.0
Die Netzwerkarchitektur der neuen TI-2.0 soll diese Probleme teils lösen, indem sie gänzlich auf die Notwendigkeit eines eigenen VPNs mit Konnektoren verzichtet. Im Gegensatz zu einem privaten Netzwerk nur für die TI, soll die Kommunikation zwischen TI-Nutzern und Anwendungen in das normale Internet eingebettet werden. Nutzer können Anfragen also z.B. einfach mit einem Smartphone direkt an die TI-Anwendung schicken ohne den Zwischenschritt über einen Konnektor. Hierfür sollen die TI-Anwendungen eingehende Anfragen zukünftig selbst prüfen, ohne auf die Konnektoren der Nutzer zu vertrauen. Dieser Ansatz wird als „Zero-Trust“ („Null-Vertrauen“) bezeichnet.
und Ablauf der Authentisierung über Internet
Um diese Architektur zu implementieren, orientiert sich die Gematik an der Zero-Trust Referenzarchitektur der amerikanischen Standartisierungsbehöre NIST. Diese sieht zwei abstrakte Hauptkomponenten vor, welche vor der Zielanwendung liegen und Anfragen auf dessen sensiblen Ressourcen prüft:
- Policy-Enforcement-Point (PEP): Fängt Anfragen auf die Ressourcen ab und wartet auf Entscheidung des PDP, um diese weiterzuleiten oder abzulehnen.
- Policy-Decision-Point (PDP): Prüft Anfrage auf Grundlage von Richtlinien (z.B. Gerätetyp, Softwareversion, Standort) und gibt Entscheidung an PEP zurück.
Die Gematik veröffentlichte eine erste konkrete Implementierung von PEP & PDP auf GitHub unter dem Namen „ZETA Guard“ veröffentlicht. Die Rolle des PEP übernimmt dort ein Nginx HTTP-Proxy, die des PDP ein Keycloak Server. Eine Clientimplementation, der „ZETA Client“, ist öffentlich, die die Interaktion mit „ZETA Guard“ geschützten TI-Anwendung ermöglicht.
Nach Angaben der Gematik soll ZETA erstmalig Mitte 2026 zum Einsatz kommen, zuerst jedoch nur für das neue Versicherten-Stammdatenmanagement „VDMS 2.0“. Ab 2027 sollen daraufhin weitere TI-Anwendungen mit ZETA ausgestattet werden. Hierbei können Industriepartner die Veröffentlichten ZETA-Komponenten einfach übernehmen, ohne sie selbst entwickeln zu müssen.