Elektronische Gesundheitskarte und Telematikinfrastruktur

Feinkonzept

Zero Trust Architektur für die Telematikinfrastruktur

Flexibel, Skalierbar, Zukunftssicher

    

     

      
Version
      
1.0.0
     
     

      
Revision
      
617681
     
     

      
Stand
      
17.03.2023
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemKPT_Zero_Trust
     
    

Inhaltsverzeichnis

Hinweis: Aus Gründen der besseren Lesbarkeit wird auf die separate Verwendung von Sprachformen für männlich, weiblich und divers verzichtet. Sämtliche Personenbezeichnungen gelten gleichermaßen für alle Geschlechter.

Eine zukunftsorientierte Architektur für die TI 2.0

Als die TI im Jahr 2004 konzipiert und in den darauffolgenden Jahren realisiert wurde, war ihre Architektur State-of-the-Art. Vertrauenswürdige, geschlossene Client-Server-Netzwerke mit dezentraler Datenverarbeitung, Kryptographie auf Basis von Chipkarten und Software-Schnittstellen basierend auf dem Standard SOAP repräsentierten Sicherheit und Skalierbarkeit. Annähernd 20 Jahre später ist es an der Zeit, die damaligen Architekturentscheidungen auf den Prüfstand zu stellen und die derzeitige technologische Lage zu betrachten. Von außen betrachtet stellt die TI 1.0 ein durch VPN abgesichertes, isoliertes Netzwerk dar. Teilnehmer werden durch Identitäten auf Hardware identifiziert und dürfen in Folge an der TI teilnehmen. Die mit dem gewünschten starken Wachstum an Nutzern der TI einhergehenden Änderungen an den Anforderungen bzgl. Skalierbarkeit, Verfügbarkeit, nutzerfreundlicher Sicherheit und mobiler Nutzung, können mit der bisherigen Architektur nicht mehr adäquat erfüllt werden und erfordern neue Ansätze. Dabei ist es ein vordergründiges Ziel, Systeme und Konzepte, die bereits erfolgreich eingeführt wurden, weiterhin nutzen zu können bzw. effiziente Migrationen zu ermöglichen.

Das vorliegende Konzept zeigt auf, wie durch eine moderne Zero Trust Architektur der Schutz von Daten auch bei einem Zugriff über das offene Internet durch eine dynamische Überprüfung von aktuellen Informationen zu Nutzer, Gerät und Kontext der Anfrage gewährleistet werden kann. Es berücksichtigt dabei alle heutigen Faktoren wie andere Sicherheitskonzepte, mobile Zugänge, Identitätsmanagement und die deutlich gestiegenen Erwartungen hinsichtlich der User Experience. 

Um bei der Erneuerung der technischen Basis der TI andere Faktoren nicht auszublenden, werden die folgenden kritischen Erfolgsfaktoren adressiert und Lösungsansätze aufgezeigt:

• Einfache Verwendung: Die Teilnahme an der TI sowie der Zugriff und das Teilen von Daten ist von jedem Teilnehmer mit aktuell verfügbaren Endgeräten wie PCs, Smartphones oder Tabletcomputern ohne spezielle Vorrichtungen möglich.
• Niedrigere Zugriffshürden: Applikationen können, ohne Einbußen bei der Sicherheit, sowohl stationär als auch mobil genutzt werden.
• Mitwachsen mit den Verbesserungen bei Sicherheit und Usability der von den Nutzern eingesetzten Endgeräte
• Ganzheitliche Sicherheit: Zugriffe auf Daten und Dienste in der TI werden im Kontext jeder Anfrage nach Prüfung von Sicherheitszustand und Schutzmaßnahmen auf den verwendeten Geräten erlaubt.
• Flexibilität: Ein dynamisches Regelwerk für Zugriffe auf die TI ermöglicht zügige Reaktionen auf aktuelle Entwicklungen und übergreifende Anpassungen ohne Änderung an jedem einzelnen Fachdienst.
• Zukunftssicherheit durch das Anknüpfen an und Weiterentwickeln mit dem Stand der Technik und aktuellen Standards

Das vorliegende Feinkonzept beschreibt die nötigen logischen und technischen Komponenten sowie die organisatorischen Prozesse um die TI als Zero Trust Architektur umzusetzen und die kritischen Erfolgsfaktoren zu erfüllen. Das Konzept wird durch einen Proof of Concept ergänzt, der zeigt, dass die skizzierte Architektur umsetzbar ist und die Anforderungen an Performance und Skalierbarkeit insbesondere aus Sicht des Nutzers erfüllen kann.

Um zu gewährleisten, dass die TI auf Basis der beschriebenen Zero Trust Architektur umgesetzt werden kann, sind folgende weiteren Schritte notwendig:

1. Erstellen eines Stufen- und Migrationsplans sowie einer ersten Kostenschätzung
2. Integration der vorgeschlagenen Architektur in ein TI 2.0 übergreifendes Sicherheits- und Datenschutzkonzept
3. Konkretisierung der Anforderungen an das für die Zugriffskontrolle eingesetzte Regelwerk als Basis für dessen technische Umsetzung
4. Weitere Ausarbeitung der vorgeschlagenen Governance-Prozesse in Abstimmung mit allen beteiligten Stakeholdern
5. Spezifikation der im Konzept beschriebenen Komponenten sowie der Schnittstellen zu anderen Komponenten in der TI
6. Umsetzung der Zero Trust Systemkomponenten
7. Einbringen der Zero Trust Systeme in den Betrieb der TI
8. Ausbau der Föderation der TI für einzelne Sektoren in Abstimmung mit den Entwicklungen der Zero Trust Architektur
9. Anpassen der Zugriffsteuerung der Fachdienste auf Basis der Zero Trust Architektur

Das hier vorliegende Konzept und der dazugehörige Proof-of-Concept zeigen, dass der Zero Trust Ansatz für das Gesundheitssystem funktionieren kann. Die Kapselung eines wesentlichen Teils der Zugriffsteuerung in den Zero-Trust-Komponenten ermöglicht es, den Fokus bei der Entwicklung und Bereitstellen von Fachdiensten auf den fachlichen Mehrwert für die Nutzer der TI zu legen. 

1 Einleitung

Die heute verfügbare Telematikinfrastruktur (TI) basiert auf einem zentralen, vertrauenswürdigen Netz, wie in Abbildung 1 dargestellt, in das mittels zugelassener VPN-Komponenten sowohl die Leistungserbringer als auch die Fachdienste eingebunden sind. Auf Seiten der Leistungserbringer wird der Zugang über das zentrale Netz zu den Fachdiensten durch den Betrieb stationärer Konnektoren in Form von Hardwarekomponenten umgesetzt. Diese Architektur bindet den Leistungserbringer an den Ort seines Konnektors und limitiert Skalierung und Flexibilität durch das Bottleneck der VPN-Gateways. In der heutigen Zeit von intensiver Nutzung mobiler Endgeräte von beliebigen Standorten, führt dies zu deutlichen Einschränkungen bei der Nutzerakzeptanz und Usability.

Abbildung 1: Zentrale VPN-Infrastruktur

Neben der VPN-Verbindung sind auch dienstspezifische sichere kryptografische Funktionen Bestandteil der Firmware und Zulassung der Konnektoren. Diese Architektur reduziert die Geschwindigkeit bei der Entwicklung von Fachdiensten, da für Neu- und Weiterentwicklung zuerst einmal Updates der Konnektor-Spezifikationen nötig werden, gefolgt von Softwareentwicklung bei jedem Hersteller von Konnektoren, Interoperabilitätstests und letztlich dem Ausrollen der aktualisierten Firmware auf den Konnektoren bei allen Leistungserbringern. Dazu kommt die limitierte Leistungsfähigkeit der Konnektor-Hardware, welche z.B. in einer Größenbegrenzung für den Austausch von Dokumenten resultiert.

Die Absicherung der Patientendaten in der vom Leistungserbringer selbst betriebenen Infrastruktur ist nicht im Scope der TI 1.0, sondern wird aktuell außerhalb z.B. durch die KBV-Richtlinie betrachtet. Sobald die Tür zur TI per Konnektor geöffnet ist, besteht Netzwerkzugriff auf Fachdienste und zentrale Komponenten der TI. In Verbindung mit der Ende-zu-Ende Verschlüsselung der Daten zwischen den Nutzern einiger Fachdienste können dann beliebige auch potenziell schädliche Daten zwischen den Teilnehmern der Infrastruktur ausgetauscht werden, ohne dass dies durch die Fachdienste verhindert werden kann. Entsprechend hoch sind die Sicherheitsanforderungen an sämtliche Teilnehmer der TI, Leistungserbringer und Versicherte, sowie ihre Client-Systeme. Das reduziert die mögliche Innovationsgeschwindigkeit innerhalb der TI.

Versicherte spielen in der derzeitigen TI 1.0 eine noch geringe aber stark wachsende Rolle. Die Anbindung der Versicherten erfolgt in Anwendungen wie eRezept oder ePA jedoch nicht wie bei den Leistungserbringern über eine Einbindung in das TI-Netz mittels VPN, sondern es erfolgt eine direkte Kommunikation mit Verschlüsselung auf Transport- (TLS) und ggf. Applikationsebene mit dem jeweiligen Dienst bzw. einem vorgeschalteten Zugangsgateway. Diese Vorgehensweise zeigt die Richtung auf, die auch für die TI 2.0 vorgesehen ist.

Das mit diesem Dokument vorliegende Feinkonzept für eine Zero Trust Architektur (ZTA) der TI soll den im Whitepaper: TI 2.0 - Arena für digitale Medizin von der gematik [gem_Whitepaper_TI2.0] aufgezeigten wesentlichen Anforderungen und Herausforderungen für die TI 2.0 begegnen. Um der sehr hohen Anzahl von Teilnehmern, d.h. jedem Bürger als auch den für die Bürger agierenden Systemen, Zugang zu Diensten in der TI zu ermöglichen, soll - wie in Abbildung 1-2 dargestellt - die Kommunikation zwischen Nutzer und Diensten direkt erfolgen, ohne dass sich Teilnehmer und Dienste in ein zentrales vertrauenswürdiges Netz einwählen müssen. Das geht einher mit einem weitgehenden Verzicht auf TI-spezifische ortsgebundene Zugangshardware, d.h. der Zugriff kann direkt von dem (ggf. mobilen) Endgerät des Nutzers erfolgen - von überall und zu jeder Zeit. Bisher auf dem Konnektor lokalisierte anwendungsspezifische Operationen werden dabei entweder auf das Endgerät oder in neue Dienste der TI 2.0 ausgelagert. Der Verzicht auf die Zugangshardware erhöht nicht nur Mobilität und Nutzungskomfort für den Anwender, sondern senkt auch die Kosten und erhöht die Agilität bei der Entwicklung von Fachdiensten. Mit der Ablösung der Zugangshardware beim Leistungserbringer findet auch eine Ablösung des SZZP (Sicherer Zentraler Zugangspunkt) für die Anbindung der Dienste durch Softwarekomponenten statt.

Abbildung 1-2: Zielvorstellung TI 2.0 im Vergleich zu TI 1.0

Das Vertrauen in den zugelassenen Konnektor wird durch die Prüfung von Zugangsgeräten beim Zugriff und eine genauere Prüfung der Zugriffsmodalitäten ersetzt. Sicherheitsvorgaben werden dabei über ein flexibles Regelwerk entsprechend den Anforderungen des jeweiligen Dienstes mittels eines dienstbezogen konfigurierten Identity Access Management durchgesetzt. Dabei werden sowohl Authentisierungsinformationen als auch Informationen über das Endgerät sowie weitere Faktoren in die Zugriffsentscheidung einbezogen. Ebenfalls einbezogen werden Risiken abhängig von der Kategorie des Zugriffs. Z.B. können für Leistungserbringer höhere Sicherheitsvorgaben beim Zugriff auf die (fremden) Patientendaten bestehen als für den Zugriff des Versicherten auf seine eigenen Daten. Trotz der höheren Granularität der in die Zugriffsentscheidungen einbezogenen Daten, wird auf die Wahrung der Privacy der Teilnehmer geachtet. Eine Verarbeitung oder Speicherung personenbezogener Daten findet nur dort statt, wo es zwingend nötig ist und nur solange es nötig ist. Technische und organisatorische Vorkehrungen verhindern es, sensitive Daten miteinander zu korrelieren und so Nutzerprofile zu erstellen. Wo immer möglich wird eine Assoziation von Kommunikation oder Daten mit einzelnen Anwendern durch Anonymisierung, Pseudonymisierung und Verschlüsselung verhindert oder erschwert.

Das Feinkonzept beschreibt im Folgenden zunächst in Kapitel die relevanten Akteure und Anwendungsfälle sowie die funktionalen und nicht-funktionalen Anforderungen an die Architektur. Basierend darauf werden in Kapitel  die grundsätzlichen Zero-Trust-Paradigmen eingeordnet und die Architektur selbst anhand ihrer Komponenten, der verarbeiteten Datenklassen und der relevanten Datenflüsse beschrieben. Für diese konzeptionelle Architektur werden in Kapitel  basierend auf dem aktuellen Stand der Technik technische Umsetzungsmöglichkeiten aufgezeigt und damit die tatsächliche Umsetzbarkeit geprüft. Kapitel ergänzt die Governance- und Betriebssicht und zeigt auf, welche Rolle die Akteure einnehmen und wie Betriebsprozesse umgesetzt werden können. In Kapitel  wird die definierte Architektur mit Blick auf die Anforderungen evaluiert. Dafür wird einerseits die Umsetzung der definierten Anwendungsfälle aus Nutzersicht beschrieben und andererseits für jede der nicht-funktionalen Anforderungen evaluiert, ob sie mit den technischen und organisatorischen Maßnahmen aus Kapitel ausreichend erfüllt ist. Abschließend werden in Kapitel  die wichtigsten Erkenntnisse aus dem Konzept zusammengefasst und nächste Schritte auf dem Weg zur Umsetzung identifiziert.

Mit dem Feinkonzept wird ein Proof of Concept erarbeitet, welcher die prinzipielle Machbarkeit und Skalierbarkeit zentraler Teile des Feinkonzepts aufzeigt.

Die Migration von der bestehenden TI 1.0 zur vorgeschlagenen Architektur muss in einem folgenden Konzept betrachtet werden. 

2 Anforderungen

Der Umfang des Architekturkonzeptes bestimmt sich aus den Anforderungen an die Architektur. Im Folgenden werden die Akteure (Kapitel  ), die Anwendungsfälle (Kapitel ), die für die Anwendungsfälle notwendigen Kernfunktionen im Rahmen funktionaler Anforderungen (Kapitel ), die nicht-funktionalen Anforderungen (Kapitel ) und weitere Annahmen (Kapitel ) beschrieben.

2.1 Akteure

Im Folgenden werden die im Rahmen des Konzeptes betrachteten Akteure der TI beschrieben und in Abbildung 2.1-1 dargestellt. Die Beschreibung basiert auf der Beschreibung der Akteure in der Leistungsbeschreibung [gem_Leistung], sowie dem Glossar [gem_Glossar] der gematik für die TI.

Abbildung 2.1-1: Zentrale Akteure der Architektur

Technisch

Die TI berücksichtigt folgende technische Akteure:

Nutzer Clients sind dezentrale Komponenten, die als Clients mit der TI interagieren (z.B. Smartphone-Apps, Praxisverwaltungssysteme (PVS), Apothekenverwaltungssysteme (AVS) oder Krankenhausinformationssysteme (KIS)). Sie bestehen aus Hard- und Software-Bestandteilen. Als Hardware werden stationäre Endgeräte (z.B. Windows, macOS, Linux PC) und mobile Endgeräte (z.B. Android, iOS-Smartphone) betrachtet.

Dienste/Fachdienste sind zum einen Anwendungs- oder Infrastrukturdienste der TI, bei denen die gematik die Regulierungshoheit innehat. Dazu zählen zum Beispiel die elektronische Patientenakte (ePA), Identity Provider (IDP) oder der National Contact Point eHealth (NCPeH). Zum anderen zählen auch Anwendungsdienste und digitale Gesundheitsanwendungen dazu, die an der TI teilnehmen und nicht direkt unter der Regulierungshoheit der gematik liegen. Das sind z.B. Digitale Gesundheitsanwendungen (DiGA) gem. § 33a SGB V oder weitere Anwendungen für den Datenaustausch in der Telematikinfrastruktur (WANDA). Dienste können Clients von anderen Diensten sein und so Daten untereinander austauschen.

Nutzer

Die Dienste der TI sollen verschiedenen Nutzergruppen zur Verfügung stehen. Im Fokus stehen dabei die folgenden Akteure:

Versicherte sind z.B. Patienten, die mit einem Client auf einem stationären oder mobilen Endgerät auf Dienste zugreifen. 

Leistungserbringer (LE) sind z.B. Ärzte, Physiotherapeuten, Hebammen, Apotheker oder medizinische Fachangestellte, welche Leistungen des Gesundheitswesens für Versicherte erbringen und aus den folgenden Umgebungen auf Dienste zugreifen: Im mobilen Dienst, in kleinerer Institution (bspw. Arztpraxis oder Apotheke), in größeren medizinischen Einrichtungen (z.B. im Krankenhaus).

Kostenträger sind im Kontext der TI die gesetzlichen Krankenversicherungen. Kostenträger greifen vor allem aus stationären Umgebungen auf Dienste zu, um z.B. Informationen zur Abrechnung anderen Nutzern zur Verfügung zu stellen.

Infrastruktur

Im Rahmen des Betreibermodells der TI werden folgende Akteure berücksichtigt:

Anbieter sind Anbieter von Komponenten oder Diensten der TI oder weiteren Anwendungen wie z.B. DiGA. Ein Anbieter von Betriebsleistungen in der TI ist eine Organisation, die Services gegenüber Anwendern oder anderen Servicenehmern anbietet und verantwortet. Ein Anbieter kann seine Services selbst erbringen oder durch Betreiber erbringen lassen, jedoch verbleibt die Serviceverantwortung beim Anbieter selbst.

Betreiber sind Betreiber von Komponenten oder Diensten. Betreiber sind natürliche oder juristische Personen. Unter Betreiben ist das Anschließen an Betriebsmedien (wie z.B. Strom, Netzwerk, Klima), Starten der Betriebsprozesse, Konfigurieren und Überwachen der gewünschten Funktionalität zu verstehen.

Hersteller stellen ein Produkt gemäß den Spezifikationen her und übernehmen die Produkthaftung gemäß den gesetzlichen Vorgaben und den Support gegenüber den Käufern ihrer Produkte. Hersteller unterscheiden sich von Anbietern insbesondere dadurch, dass das verantwortete Produkt keinen IT-Service darstellt, sondern physische Geräte oder Software, welche in der Hoheit der Anwender bzw. in der Hoheit eines Anbieters/Betreibers betrieben werden.

2.1.1 Governance

Die gematik trägt die Gesamtverantwortung für die TI. Sie hat das Betriebs- und Sicherheits-Monitoring der TI und die Betriebsverantwortung der TI inne. Dienste, die sich an die TI angeschlossen werden sollen, müssen im Regelfall zugelassen oder bestätigt werden. Der Zulassungs- bzw. Bestätigungsprozess wird durch die gematik gesteuert.

2.2 Anwendungsfälle

Grundlage für die Anforderungen an das Architekturkonzept der TI sind die im Rahmen der Leistungsbeschreibung [gem_Leistung] aufgeführten Anwendungsfälle. Die Anwendungsfälle werden in Tabelle 2.2-1 kurz beschrieben. Wie die Architektur diese Anwendungsfälle ermöglicht, wird in Kapitel  beschrieben.

Tabelle 2.2-1: Anwendungsfälle

2.3 Funktionale Anforderungen

Die funktionalen Anforderungen beschreiben die zentralen Funktionen der Architektur, die notwendig sind, um die Anwendungsfälle der Architektur zu ermöglichen. Aus den Anwendungsfällen UC1-UC7 wurden die folgenden funktionalen Anforderungen abgeleitet. Abbildung 2.3-1 visualisiert das Ergebnis des Ableitungsprozesses. Innerhalb der Funktionen wird wie folgt unterschieden:

• ZTA-Funktionen: Kernfunktionen, welche benötigt werden, um die ZTA umzusetzen. Die Realisierung der hier identifizierten Funktionen wird im Kapitel  beschrieben.
• Funktionen extern: Funktionen, welche in anderen Konzepten im Detail beschrieben werden. Die Schnittstellen zu bzw. Erwartungen an diese Funktionen werden im Kapitel  beschrieben.

In Tabelle 2.3-1 werden die zentralen Funktionen der Architektur kurz beschrieben.

Tabelle 2.3-1: Funktionale Anforderungen

Abbildung 2.3-1: Zentrale Funktionen der Architektur

2.4 Nicht-funktionale Anforderungen

Nicht-funktionale Anforderungen beschreiben Anforderungen an die Qualität, in welcher die geforderten Funktionen erbracht werden sollen. Basierend auf der Leistungsbeschreibung [gem_Leistung] (NFA1-16 aus Kapitel II 6. Anforderungen an eine Zero-Trust-Architektur und NFA17 aus Kapitel II 4. Zero Trust) ergeben sich die nicht-funktionalen Anforderungen in Tabelle 2.4-1. Wie die Architektur die nicht-funktionalen Anforderungen erfüllt, wird in Kapitel  beschrieben.

Tabelle 2.4-1: Nicht-funktionale Anforderungen

2.5 Annahmen

Weitere, dem Architekturkonzept zu Grunde liegende, Annahmen sind in Tabelle 2.5-1 dokumentiert.

Tabelle 2.5-1: Annahmen 

3 Architektur

Ein großer Bestandteil des Architekturkonzeptes ist die Beschreibung der wesentlichen Komponenten und die Beschreibung wie diese Komponenten im Zusammenspiel die Kernfunktionen der Architektur erfüllen. Das Architekturkonzept folgt dabei einer Zero-Trust-Strategie. Im Folgenden (Kapitel ) werden diesbezüglich zunächst die wichtigsten Zero-Trust-Paradigmen auf den vorliegenden Kontext der TI abgebildet. Im Anschluss werden die Komponenten (Kapitel ), das verwendete Regelwerk (Kapitel ), die verarbeiteten und gespeicherten Datenklassen (Kapitel ) sowie die Realisierung der Kernfunktionen (Kapitel ) beschrieben.

3.1 Paradigmen

Zu den gängigen, mit einer Zero-Trust-Strategie verbundenen Denkmustern gehören die in der NIST Special Publication 800-207 [NIST_ZeroTrust] in Kapitel 2.1 "Tenets of Zero Trust" erläuterten Paradigmen, die in Tabelle 3.1-1 aufgelistet werden.

Tabelle 3.1-1 Zero Trust Paradigmen gemäß NIST [NIST_ZeroTrust]

Für die Umsetzung der Zero-Trust-Strategie im Rahmen dieses Architekturkonzeptes werden im Folgenden die Paradigmen P1-P7 (Kapitel  - ) für die Anwendung innerhalb der TI abgebildet.

Abbildung 3.1.1-1: Ressourcen im Kontext der TI

3.1.1 Ressourcen

Für die Konzeption einer ZTA ist die Definition dessen, was unter einer Ressource der ZTA verstanden wird, von zentraler Bedeutung. In Abbildung 3.1.1-1 sind unterschiedliche Ebenen hinsichtlich der Granularität einer Ressource im Kontext von Anwendungen der TI dargestellt.

In der obersten Ebene werden Anwendungen in Form von Diensten und Fachdiensten unterschieden. Eine Autorisierung für den Zugriff auf eine Anwendung (z.B. die ePA) kann von einer Autorisierung für den Zugriff auf eine andere Anwendung (z.B. dem E-Rezept) unterschieden werden.

In der darunter liegenden Ebene können für jede Anwendung verschiedene Endpunkte als Ressource hinsichtlich der Autorisierung differenziert werden. Dies kann zum Beispiel anhand des Fully-Qualified Domain Name (FQDN) eines Endpunktes erfolgen.

Die dritte Ebene ermöglicht das Differenzieren zwischen einzelnen Objekten, z.B. FHIR-Ressourcen, welche innerhalb einer Anwendung adressiert werden können. Auf der vierten Ebene wird zusätzlich zur Differenzierung zwischen Objekten auch die angefragte Aktion auf das Objekt, z.B. FHIR-Operationen, unterschieden. Die Unterscheidung von Objekten und Aktionen auf Objekten kann z.B. anhand des URL-Pattern einer Zugriffsanfrage und/oder der HTTP-Methode erfolgen.

Die unterste Ebene kennzeichnet die Unterscheidung von einzelnen Instanzen von Datenobjekten. Dadurch könnte man z.B. das Anlegen eines neuen Patienten mit Namen X vom Anlegen eines neuen Patienten mit Namen Y unterscheiden.

Im Rahmen des Architekturkonzeptes werden die logischen Entitäten der ersten vier Ebenen als Ressourcen betrachtet, deren Zugriff durch das Regelwerk der ZTA gesteuert werden kann. Der Zugriff auf einzelne, personalisierte Daten, d.h. Daten im Sinne von einzelnen Instanzen auf Ebene 5, gehört jedoch nicht dazu. 

Dabei soll es möglich sein, flexibel je nach Zugriffsanfrage und Anwendung, die Zugriffsentscheidung auf unterschiedlichen Ebenen zu treffen und so unterschiedlich granulare Regelwerke durch die ZTA zu unterstützen.

3.1.2 Sichere Kommunikation

Die Kommunikation zwischen Komponenten der ZTA erfolgt über das Internet. Das Architekturkonzept sieht vor, dass jede Kommunikation zwischen den Komponenten der ZTA gemäß dem Stand der Technik verschlüsselt und gegenseitig authentisiert erfolgt. Dies gilt auch wenn Komponenten der ZTA innerhalb organisationsspezifischer Netzwerke kommunizieren. Es werden die gültigen Standards, wie zum Beispiel BSI TR-02102 [BSI_TR02102], herangezogen. Der Transfer von medizinischen Daten erfolgt verschlüsselt zwischen den Entitäten, welche vom Eigentümer der medizinischen Daten (z.B. Patient/Versicherter) für den Zugriff auf diese autorisiert wurden. 

3.1.3 Sessions

Das Architekturkonzept sieht vor, dass der Zugang zu Ressourcen auf Basis von Sessions geprüft und gewährt wird. Die mit der Session verknüpften Informationen werden gegen das Regelwerk geprüft.

Eine Session identifiziert im Rahmen des Architekturkonzepts eine etablierte Kommunikationsbeziehung eines Clients mit einem Fachdienst. Diese Session ist dabei einem einzelnen Nutzer, Gerät und ggf. Umgebung zugeordnet, und kann für mehrere Zugriffe (Requests) auf Ressourcen beim gleichen Fachdienst verwendet werden.

Die Session ist dem Client, PEP und Fachdienst bekannt. Session-spezifische Informationen (wie Identifier) werden ausschließlich während der Session verwendet, und nur für die Lebenszeit einer Session gespeichert. Durch diese clientseitig gespeicherten Session-Informationen allein lassen sich allerdings keine Rückschlüsse auf die hinterlegten Identitäts- und Sicherheitsnachweise ziehen. Die nutzerspezifische Session ist an das Gerät sowie ggf. die Umgebung gebunden und kann nicht in anderen Kontexten verwendet werden.

3.1.4 Dynamisches Regelwerk

Das Architekturkonzept berücksichtigt unterschiedliche Ebenen der Dynamik des Regelwerkes:

• Dynamische Regelauswertung: Das Architekturkonzept sieht ein Regelwerk auf der Basis von Attribute-Based Access Control (ABAC) vor. Dabei können bei der Zugriffsentscheidung Attribute berücksichtigt werden, welche dynamisch zum Zeitpunkt der Zugriffsanfrage erhoben werden (z.B. Zeitpunkt des Zugriffs, Ort des Zugriffs, Sicherheitsattribute des für den Zugriff verwendeten Endgerätes).
• Aktualisierungen von Referenzwerten: Das Regelwerk der ZTA kann für die Bewertung von Attributen Referenzwerte verwenden, die erlaubte (Allowlist) oder verbotene Werte (Blocklist) für ein Attribut festlegen. Diese Referenzwerte können in definierten Prozessen kurz- oder mittelfristig angepasst werden, um auf Monitoring-Ergebnisse oder aktuelle Entwicklungen (z.B. aktuelle Sicherheitsvorfälle) zu reagieren.
• Anpassungen des Regelwerks: Die Regeln im Regelwerk der ZTA sind nicht unveränderlich festgelegt, sondern können über organisatorische Prozesse angepasst, geändert oder entfernt werden. So kann z.B. ein neuer Fachdienst aufgenommen und mittel- und langfristig auf veränderte Anforderungen an die Informationssicherheit reagiert werden.

3.1.5 Monitoring

Das Architekturkonzept sieht drei verschiedene Arten von komponentenübergreifendem Monitoring vor:

• Betriebsmonitoring: Kontinuierliches Monitoring von Informationen über Verfügbarkeit, Auslastung und Performance der Komponenten der TI-Infrastruktur mit dem Ziel, Ausfälle oder Überlastung zu erkennen.
• Security-Monitoring: Kontinuierliches Monitoring, um mögliche Angriffe oder Sicherheitsprobleme zu erkennen. Es umfasst einerseits das Monitoring von Informationen zum Sicherheitsstatus der Komponenten der TI-Infrastruktur zur Identifikation möglicher Schwachstellen und Sicherheitsvorfällen in diesen Komponenten und andererseits das Monitoring von aktuellen Zugriffsanfragen zur Angriffserkennung.
• Monitoring des Regelwerks: Logging und Analyse von Zugriffsentscheidungen, d.h. von zugelassenen und zurückgewiesenen Zugriffen, um die Wirksamkeit des Regelwerkes zu überwachen und Änderungsbedarfe zu erkennen.

Die Monitoring-Informationen werden außerhalb der überwachten Komponenten in der TI-Infrastruktur übergreifend gesammelt, gespeichert und ausgewertet.
Eine Betrachtung des zusätzlich möglichen, internen Komponenten-Monitorings pro Komponente wird im Nachfolgenden nicht vorgenommen.

3.1.6 Dynamische Authentisierung und Autorisierung

Jede Autorisierung eines Zugriffs auf eine Ressource setzt eine vorangegangene Authentisierung des Nutzers voraus. Die Autorisierung ist an den Umfang der Zugriffsanfrage (just-enough) gebunden und zeitlich auf die Dauer der Session begrenzt (just-in-time).

3.1.7 Stetige Verbesserung

Das Architekturkonzept sieht im Rahmen des Monitorings vor, Informationen über den Sicherheitszustand der an der ZTA beteiligten Komponenten, der durch sie geschützten Ressourcen und die erfolgten Zugriffe zu sammeln, um so eine stetige Verbesserung des Regelwerkes und seiner Umsetzung zu ermöglichen.

3.2 Komponenten

Die in diesem Konzept vorgeschlagene Architektur basiert auf den grundlegenden Strategien einer ZTA, wie in NIST SP 800-207 [NIST_ZeroTrust] erläutert. Sie nutzt dafür die gemäß ISO/IEC 29146 [ISO29146] standardisierten und im Rahmen von Zero-Trust etablierten logischen Komponenten. Abbildung 3.2-1 zeigt den konzeptionellen Aufbau der Architektur. Bereits im Rahmen der TI 2.0 konzipierte Komponenten, welche im Rahmen dieses Konzeptes als vorhanden vorausgesetzt werden, sind blau hinterlegt. Neue Komponenten der in diesem Konzept beschrieben ZTA sind orange hinterlegt. Im Folgenden (Kapitel ) werden die Komponenten kurz beschrieben. Im Anschluss (Kapitel ) wird erläutert, welche Architekturkomponenten an der Realisierung welcher Kernfunktionen beteiligt sind.

3.2.1 Dekomposition

Die Architekturkomponenten können den fünf funktionalen Gruppen zugeordnet werden, die im Folgenden beschrieben sind.

I. Systeme der Nutzer

Die Dienste der TI sollen verschiedenen Nutzergruppen zur Verfügung stehen. Für den Zugriff der Nutzer (Versicherte, Leistungserbringer, Kostenträger sowie andere Fachdienste) auf Dienste der TI werden Systeme benötigt, welche eine sichere Authentisierung und die sichere Verarbeitung von Gesundheitsdaten und deren kryptografischen Schlüsseln ermöglichen.

Fach-Client (FCL)/Trust-Client (TCL)

Nutzer greifen auf Dienste der TI über einen Fach-Client zu, welcher die notwendige Fach-Client spezifische Logik für den Zugriff implementiert. Das können z.B. typische Primärsysteme der Leistungserbringer, aber auch mobile Applikationen der Krankenkassen sein. Für die sichere Nutzung der Dienste müssen Nutzer zum Zeitpunkt des Zugriffs ausreichend sichere Endgeräte nachweisen. Dabei sind Geräte, welche für die Nutzeridentifizierung (Authentisierung) verwendet werden, nicht zwingend identisch mit denen für den Zugriff auf Dienste, d. h. es kann ein separates Gerät mit einer Software zur Bestätigung der Anmeldung zum Einsatz kommen. Der Trust-Client sammelt Informationen über die Plattformsicherheit des Endgeräts und stellt diese als Basis für Zugriffsentscheidungen bereit. So kann sichergestellt werden, dass das Endgerät die notwendigen Funktionen zum Aufbau sicherer Kommunikationsverbindungen unterstützt und fachspezifische Anforderungen an das Endgerät und seine Ausführungsumgebung erfüllt werden. Zudem nutzt der Trust-Client eine sichere Schlüsselverwaltung nach dem bei den Nutzern verfügbaren Stand der Technik (z.B. Trusted Execution Environment (TEE), Trusted Platform Module (TPM), Secure Element (SE)), um beispielsweise eine Gerätebindung/-registrierung für den Zugriff auf die TI oder die Bestätigung der Plattformsicherheitsattribute zu unterstützen. Diese Schlüsselverwaltung kann über eine Krypto-API auch vom Fach-Client genutzt werden.

Der Trust-Client steht in Form eines SDK oder als eigenständiges Modul für verschiedene Endgeräteklassen zur Verfügung und kann so je nach Nutzerumgebung in einen Fach-Client integriert werden.

1. Alleinstehende Geräte: In Umgebungen, in denen der Nutzer direkt über das Endgerät, auf dem der Fach-Client installiert ist, auf den Fachdienst zugreift, kann der Trust-Client in einfacher Form direkt in die Applikation des Fach-Clients integriert werden.
2. Client-Server-Infrastruktur: In größeren medizinischen Einrichtungen, wie zum Beispiel einem Krankenhaus, kann der Zugriff auf Fachdienste neben alleinstehenden Geräten zusätzlich über eine einrichtungsspezifische Client-Server-Infrastruktur zur Verfügung gestellt werden. Fach- und Trust-Client laufen dann auf einem Fachclientserver der Client-Server-Infrastruktur. Der Trust-Client stellt dort die notwendigen Funktionen zum Aufbau sicherer Kommunikationsverbindungen bereit und sorgt dafür, dass die nötige Information für die fachdienstspezifische Sicherheitsbewertung des Fachclientservers und dessen Ausführungsumgebung zur Verfügung gestellt werden. Endgerät im Sinne einer Gerätebindung/-registrierung für den Zugriff auf die TI durch die medizinische Einrichtung ist dann der Fachclientserver der Client-Server-Infrastruktur. Der sichere Betrieb der Client-Server-Infrastruktur sollte in Verantwortung des Krankenhauses über ein zertifiziertes ISMS des Krankenhauses und geeignete technische Maßnahmen sichergestellt werden. Zusätzlich zur Authentisierung eines registrierten Fachclientservers sollte der Trust-Client eine ggf. pseudonymisierte Gerätekennung des einrichtungsspezifischen Clientgerätes zur Verfügung stellen, welches innerhalb der medizinischen Organisation für den Zugriff auf den Fachclientserver verwendet wurde. Dies ermöglicht der ZTA über ein Monitoring etwaige kompromittierende Zugriffe aus der Umgebung der medizinischen Einrichtung zu erkennen, einem organisationsinternen Terminal zuzuordnen und ggf. die Einrichtung zu informieren oder den Zugriff des spezifischen Terminals selektiv zu blockieren. Die nicht kompromittierten Teile der Client-Server-Infrastruktur könnten durch eine solche granulare Entscheidung weiter für Zugriffe auf Dienste der TI genutzt werden.
3. Proxy-Server-Infrastruktur: Es ist darüber hinaus denkbar, den Trust-Client in medizinischen Einrichtungen als eigenständige Komponente in Form eines Proxy-Servers unabhängig vom Fach-Client zur Verfügung zu stellen. Der Trust-Client läuft dann auf dem Proxy-Server, während Fach-Clients auf verschiedenen dahinterliegenden Geräten installiert sind. Für die Verwaltung dieser, für die Fach-Clients genutzten, internen Endgeräte verfügt die Einrichtung über ein internes Gerätemanagement, welches die Plattformsicherheit der internen Endgeräte attestiert und resultierende Informationen dem Trust-Client auf dem Proxy-Server zur Verfügung stellt. Der Trust-Client stellt dann die notwendigen Funktionen zum Aufbau sicherer Kommunikationsverbindungen vom Fachdienst bis zum Proxy-Server bereit und stellt die für die Bewertung der Zugriffe nötigen Information über die internen Endgeräte der ZTA zur Verfügung. Endgerät im Sinne einer Gerätebindung/-registrierung für den Zugriff auf die TI durch die medizinische Einrichtung ist dann der Proxy-Server. Der sichere Betrieb der einrichtungsspezifischen Infrastruktur und des internen Gerätemanagements sollte in diesem Fall ebenso in Verantwortung des Krankenhauses über ein zertifiziertes ISMS des Krankenhauses und geeignete organisatorisch-technische Maßnahmen sichergestellt werden. Analog zur Client-Server-Infrastruktur sollte der Trust-Client dabei ggf. pseudonymisierte Gerätekennungen der internen Endgeräte zur Verfügung stellen, um so eine granulare Analyse innerhalb der TI zu ermöglichen.