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.

Abbildung 3.2-1: Konzeptioneller Aufbau der Architektur

Im Ergebnis stehen den medizinischen Einrichtungen verschiedene Optionen zur Verfügung, um den Anschluss an die TI in die eigene Architektur und das einrichtungsspezifische Informationssicherheitsmanagement zu integrieren. Während im Rahmen von Option 1 der Großteil der Informationssicherheitsmaßnahmen durch den Trust-Client unterstützt werden kann, steigt mit Option 2 und insbesondere mit Option 3 die Verantwortung für die medizinische Einrichtung und deren ISMS. Medizinische Einrichtungen können so die Aufwände für das Umsetzen von Maßnahmen eines einrichtungsspezifischen ISMS gegen Aufwände für die Integration des Trust-Clients abwägen. Risiken hinsichtlich der Beschränkung des Zugangs zur TI für ggf. kompromittierte Endgeräte oder Server, können für Option 2 und 3 dadurch reduziert werden, dass pseudonymisierte Gerätekennungen für das Monitoring der TI bereitgestellt werden.

Authenticator-Modul (AUM)

Für die sichere Identifizierung und Authentisierung verfügen Nutzer als Teil des IDP-Ökosystems der TI 2.0 über Identitätsmittel. Diese werden mit dem Authenticator-Modul in das jeweilige eID-System verschiedener Identitätsprovider (IDP) der Föderation der TI integriert. Darüber hinaus stellt das Authenticator-Modul Informationen über das für die Identifizierung bzw. Authentisierung genutzte Endgerät und ggf. dessen Ausführungsumgebung zur Verfügung.

Für medizinische Einrichtungen wird hinter dem Authenticator-Modul in der Regel ein organisationsspezifisches Identitäts- und Zugriffsmanagement (IAM) betrieben. Dabei werden organisationsinterne Identitäten der Mitarbeitenden verwendet, welche nicht in der Föderation registriert sein müssen. Stattdessen ist die Organisation mit einer Organisationsidentität in der Föderation der TI registriert. Bei einer Authentisierung eines Zugriffs sollte neben der Organisationsidentität auch die für den Zugriff verwendete organisationsinterne Identität in pseudonymisierter Form als Attribut in das ID-Token mit einfließen und so der ZTA zur Verfügung gestellt werden. Dies ermöglicht der ZTA z.B. etwaige kompromittierende Zugriffe aus der Umgebung der medizinischen Einrichtung zu erkennen, einer organisationsinternen pseudonymen Identität zuzuordnen und diese ggf. zu blockieren. Die Organisationsidentität selbst kann dabei weiter für Zugriffe auf Dienste der TI genutzt werden. Der sichere Betrieb des IAM sollte in Verantwortung der medizinischen Einrichtung über ein zertifiziertes ISMS der medizinischen Einrichtung und geeignete technische Maßnahmen sichergestellt werden.

Im Ergebnis stehen medizinischen Einrichtungen für den Zugang zur TI neben der Verwendung von Identitäten für natürliche Personen (vgl. HBA) auch Organisationsidentitäten (vgl. SMC-B) zur Verfügung. Während im Rahmen der direkten Verwendung von Identitäten für natürliche Personen der Großteil der Informationssicherheitsmaßnahmen hinsichtlich der Identifizierung und Authentisierung durch die Identity Provider der Föderation der TI realisiert wird, steigt mit der Verwendung einer Organisationsidentität die Verantwortung für die medizinische Einrichtung und deren IAM und ISMS. Risiken hinsichtlich der Beschränkung des Zugangs zur TI für ggf. als kompromittiert identifizierte Organisationsidentitäten, können dadurch reduziert werden, dass organisationsinterne Identität in pseudonymisierter Form für das Monitoring der TI bereitgestellt werden.

Nutzerportal

Einige Komponenten der ZTA benötigen bewusste Nutzeraktionen, wie z.B. das Löschen von Geräten aus der Liste registrierter Geräte. In anderen Fällen ist es sinnvoll, dem Nutzer Informationen bereitzustellen, z.B. zur persönlichen Nutzungshistorie, zu Zugriffen auf seine Daten durch Leistungserbringer oder zum Status der für ihn relevanten Fachdienste. Im Sinne einer besseren Transparenz und Nutzbarkeit für den Nutzer, sollen viele dieser Aufgaben in einem Nutzerportal gebündelt werden. Dieses Portal hat keine eigene Funktion innerhalb der ZTA. Es dient nur als Frontend für die Administration oder das Monitoring spezifischer Komponenten, wie dem Geräte Management Service. Die konkrete Umsetzung wird daher im Feinkonzept nicht betrachtet.

II. Systeme der Dienste der Telematikinfrastruktur und des digitalen Gesundheitswesens

Die TI stellt Dienste und Anwendungen für das Gesundheitswesen zur Verfügung.

Fachdienst

Fachanwendungen sind Anwendungen der TI, wie das Versichertenstammdaten-Management oder die elektronische Patientenakte, mit allen nötigen technischen und organisatorischen Anteilen auf Anwendungsebene. Fachanwendungen können durch einen oder mehrere Fachdienste realisiert werden. Fachdienste können zudem weitere Anwendungen für den Datenaustausch in der Telematikinfrastruktur (WANDA) oder digitale Gesundheitsanwendungen (DiGA) repräsentieren. Fachdienste speichern und verarbeiten unter anderem sensible Nutzerdaten wie Gesundheitsdaten und stellen diese zur Verfügung.

Policy Enforcement Point (PEP)

Jeder Zugriff auf Fachdienste ist ausschließlich nach zuvor erfolgreich erfolgter Autorisierung möglich. Der Policy Enforcement Point setzt dies für jeden einzelnen Zugriff auf einen Fachdienst durch, erlaubt autorisierten Zugriff in der Granularität der ZTA-Ressourcen und schützt vor unautorisiertem Zugriff. Dazu reicht er bei der initialen Autorisierung die vom Client gelieferten Nutzer-, Geräte- und Umgebungsinformationen an den PDP weiter und erwartet von diesem eine Zugriffsentscheidung. Zudem stellt der PEP anonymisierte Informationen über Zugriffsentscheidungen sowie vorverarbeitete Informationen zu auffälligen Zugriffsanfragen für das Monitoring bereit.

Policy Decision Point (PDP)

Der Kern einer Zero-Trust-Architektur besteht in der Entscheidung, ob ein bestimmter Nutzer unter Berücksichtigung der vorliegenden Informationen zu Nutzer, Gerät und Umgebung zu einem bestimmten Zeitpunkt auf eine bestimmte Ressource zugreifen darf. Die Architektur sieht dafür für jeden Fachdienst einen PDP vor, der diese Entscheidung trifft. Voraussetzung dafür sind aktuelle und explizite Richtlinien, die festlegen, wie authentifizierte Nutzer, Dienste, Geräte und Anwendungen miteinander interagieren dürfen. Ein PDP erhält deshalb vom PAP das aktuell gültige Regelwerk des betroffenen Fachdienstes, bestimmt daraus die für den aktuellen Zugriff geltenden Regeln und wertet diese aus. Dafür werden vom PDP alle für die Auswertung notwendigen Informationen ermittelt, soweit sie nicht bereits mit der Autorisierungsanfrage vom Client zur Verfügung gestellt werden.

Das Konzept folgt hinsichtlich der Realisierung von PDP und PEP dem Enterprise-Centric-Implementation-Modell gem. ISO/IEC 29146 [ISO29146] und sieht beide Komponenten innerhalb eines gemeinsames Vertrauensraums vor. Dieser kann realisiert werden durch eine gemeinsame Grenze um Fachdienst und PEP/PDP herum oder als separierte Instanzen (z.B. IaaS-Komponenten), die auf vertrauenswürdige Weise gekoppelt sind.

III. Systeme der eID-Föderation der TI

Die TI 2.0 umfasst ein föderiertes eID-Ökosystem [gem_IDP_Federation] bestehend aus verschiedenen sektorspezifischen IDPs.

Identity Provider (IDP)

Eine der Grundlagen für die Autorisierung eines Zugriffs auf Dienste der TI ist eine erfolgreiche Authentifizierung des Nutzers. IDPs ermöglichen diese Authentifizierung. Sie sind für unterschiedliche Sektoren (z.B. Krankenkassen für Versicherte, Leistungserbringerorganisationen für Ärzte) spezifisch ausgeprägt. IDPs können diese Aufgabe mit unterschiedlichen Technologien erfüllen (z.B. auf Basis von kartenbasierten Identitätsmitteln, mobilen Endgeräten oder der Integration in eID-Wallets). IDPs registrieren, speichern und verwalten Identitätsdaten. 

Federation Master (FEM)

Die Public Key Infrastruktur (PKI) des TI-Vertrauensraum wird durch den sogenannten Federation Master verwaltet. Beim Federation Master sind alle Dienste und zentralen Komponenten der TI registriert. Nur dort registrierte Teilnehmer sind berechtigt, die Dienste der Föderation in Anspruch zu nehmen. Der FEM verwaltet und speichert z.B. die öffentlichen Schlüssel der IDPs, der Fachdienste und weiterer Komponenten der ZTA.

IV. Übergreifende Systeme für die Ausführung des Zugriffsmanagements

Für die Autorisierung von Nutzerzugriffen auf Dienste der TI sind Komponenten notwendig, welche weitere Informationen für die Regelauswertung bereitstellen.

Geräte Management Service (GMS)

Die Architektur ermöglicht das Registrieren, Authentisieren und Entfernen von Endgeräten der Nutzer für den Zugriff auf Ressourcen der TI. Diese Funktionalitäten werden durch den GMS realisiert. Endgerät in diesem Sinne ist das Gerät, auf dem der Trust-Client für den gesicherten Zugriff auf die TI läuft. Dabei wird eine Bindung des registrierten Endgerätes an den registrierenden Nutzer berücksichtigt. Beispiele dafür sind die Registrierung eines mobilen Endgerätes durch einen Versicherten oder die Registrierung eines Fachclientservers oder Proxyservers durch eine medizinische Einrichtung. Angriffe auf Dienste der TI von nicht registrierten Endgeräten können von vornherein eingegrenzt werden. Zusätzlich kann für den Zugriff auf Dienste der TI die Nutzerbindung geprüft werden. Je nach Anforderung des Fachdienstes können z.B. Zugriffe auf solche Endgeräte beschränkt werden, die für den authentifizierten Nutzer registriert sind. Zugriffe von Geräten aus medizinischen Einrichtungen könnten für alle registrierten Rollen der TI ermöglicht werden. Der GMS stellt über das Geräte-Token Informationen über das im Rahmen eines Nutzerzugriffs authentisierte Endgerät und dessen Ausführungsumgebung bereit. 

Der GMS ist als eine von den sektoralen IDPs der Föderation der TI möglichst unabhängige Komponente geplant, welcher die ZTA neben der Identifizierung und Authentisieren des Nutzers durch den IDP um einen weiteren Sicherheitsanker ergänzt. 

Policy Information Point (PIP)

Für die Auswertung einzelner Regeln der Zero-Trust-Architektur sind situationsbezogene Informationen erforderlich. Neben dem IDP, dem GMS und dem Trust-Client, werden diese Informationen von Policy Information Points (PIPs) bereitgestellt. PIPs können Informationen zentral für alle Dienste bereitstellen (fachdienstübergreifender PIP) oder bei einem Fachdienst lokale Informationen für die Regelauswertung bereithalten (fachdienstspezifischer PIP). Ein Beispiel für den ersten Fall sind Informationen über sichere Endgeräteklassen, welche in die Bewertung der Gerätesicherheit und damit in die Zugriffsentscheidung einfließen können. PIPs können auch mit aktuellen Informationen aus dem übergreifenden Monitoring befüllt werden. So können Zugriffsentscheidungen dynamisch auf Basis aktueller Informationen zum Zeitpunkt des Zugriffs getroffen werden.

V. Systeme für die Administration und Verwaltung des Zugriffsmanagements

Policy Administration Point (PAP)

Die Regeln einer Zero-Trust-Architektur müssen erstellt, konfiguriert, getestet und verwaltet werden. Diese Funktion übernimmt der PAP. Das über den PAP verwaltete Regelwerk ermöglicht eine attributbasierte Zugriffskontrolle (ABAC). Dadurch können unterschiedliche Zugriffsanforderungen an verschiedene Rollen wie z.B. Leistungserbringer oder Versicherte mit unterschiedlichen Anforderungen an deren Endgeräte und Umgebung realisiert werden.

Monitoring (MON)

Das übergreifende Monitoring in der TI2.0 ist dafür zuständig, kontinuierlich den Betrieb und Sicherheitsstatus der TI sowie die Anwendung des Regelwerks zu überwachen. Zu diesem Zweck werden Betriebs- und Sicherheitsinformationen von allen Komponenten der TI-Infrastruktur (d.h. allen Komponenten außer denen auf dem Nutzerendgerät) sowie Informationen zu Zugriffsanfragen und -entscheidungen von den PEPs der Fachdienste erfasst und im Monitoring ausgewertet.
Das Betriebsmonitoring ermöglicht dabei das Erkennen von Ausfällen und die Überwachung von vereinbarten SLAs für die Komponenten der TI.

Als Teil des Security-Monitorings dürfen, ggf. über automatisierte Prozesse, direkt Referenzwerte für bestimmte Attribute (z.B. Blocklisten für verdächtige IP-Adressen) an einem entsprechenden PIP aktualisiert werden. Davon abgesehen sollen Informationen aus dem Security-Monitoring in ein übergreifendes Security Information and Event Management (SIEM) einfließen bzw. einem Security Operations Center (SOC) für die TI zur Verfügung gestellt werden.

Das Monitoring der Anwendung des Regelwerks unterstützt bei der Auswertung von erfolgten Zugriffen und der Bewertung von Effektivität und Angemessenheit des Regelwerks. Darüber hinaus können Informationen gewonnen werden, welche es ermöglichen, die Auswirkung eines veränderten Regelwerkes abzuschätzen, z.B. Informationen über an den Transaktionen der ZTA beteiligte Endgeräteklassen.

3.2.2 Funktionale Abbildung

Jede Kernfunktion der ZTA wird durch das Zusammenspiel mehrerer Komponenten der ZTA realisiert. In Tabelle 3.2-2. ist je Kernfunktion dargestellt, welche Komponenten der ZTA an der Realisierung beteiligt sind. Externe Funktionen sind dabei jedoch nicht aufgeführt. Im Kapitel  wird das Zusammenspiel der Komponenten für die Realisierung der Kernfunktionen näher erläutert.

Tabelle 3.2-2: Abbildung der Kernfunktionen auf Komponenten der ZTA

3.3 Regelwerk

Die Umsetzung eines dynamischen Regelwerkes für die Zugriffskontrolle folgt dem Attribute-based Access Control Pattern (ABAC). Die Zugriffsentscheidung basiert dabei auf definierten Attributen, welche der Zugriffsanfrage zugeordnet und mit den Anforderungen einer Ressource verglichen werden können. Identity-based Access Control (IBAC), Pseudonyme-based Access Control (PBAC) und Role-based Access Control (RBAC) sind Sonderfälle von ABAC, bei denen die Attribute Identitäten, pseudonyme Identitäten bzw. Rollen sind. In Abbildung 3.3-1 ist dieses Zusammenwirken grafisch dargestellt.

Jede Zugriffsanfrage erfordert einen authentifizierten Nutzer als Subjekt der Anfrage. Informationen über die Authentisierung und den Nutzer selbst bilden in Form von Attributen die Subjektbeschreibung, die z.B. das Vertrauensniveau der Authentisierung, Rollen des Nutzers in der TI oder den Zeitpunkt der Authentisierung umfassen kann.

Jeder Nutzerzugriff erfolgt mit einem Gerät, welches der Nutzer bedient. Attribute, welche das Gerät beschreiben, bilden die Gerätebeschreibung und können z.B. Informationen über die Registrierung des Gerätes auf den Nutzer, ein Vertrauenslevel für die Sicherheitsfunktionen des registrierten Gerätes oder ggf. Informationen über hinter dem registrierten Endgerät zugreifende Terminals umfassen.

Informationen, welche über die Umgebung des Zugriffs gesammelt werden, werden als Umgebungsbeschreibung berücksichtigt, die z.B. Zeitpunkt oder Ort der Zugriffsanfrage sowie den Adressraum der Zugriffsanfrage enthalten kann. Informationen über die angefragte Ressource (z.B. E-Rezept, medizinisches Dokument, ...) und die damit verbundene Aktion (z.B. lesen, schreiben, ...) können ebenfalls der Zugriffsanfrage entnommen werden und ermöglichen das Ermitteln der über den Zugriff entscheidenden Regeln sowie der dazugehörenden Soll-Attribute bzw. Referenzwerte, bspw. für geforderte Rollen oder Geräteeigenschaften. 

Abbildung 3.3-1: Visualisierung Attribute für ABAC in der ZTA

3.3.1 Mögliche Attribute und Regeln

Auf Basis der zur Verfügung stehenden Attribute können Regeln für den Zugriff auf Ressourcen erstellt werden. In Tabelle 3.3.1-1 sind Beispiele für mögliche Regeln dargestellt. Die Regeln sind den einzelnen Attributklassen aus Abbildung 3.5-1 zugeordnet. Für jede Regel werden die erforderlichen Attribute und deren mögliche Quellen sowie die Soll-Attribute genannt. Die Soll-Attribute selbst sind entweder Teil einer Regel oder sie werden von einem PIP bereitgestellt. Darüber hinaus wird für jede Regel das Ziel hinsichtlich der Informationssicherheit und ein konkretes Beispiel beschrieben.

 Tabelle 3.3.1-1: Beispiele für mögliche Regeln eines ABAC-Regelwerks

3.3.2 Erstellung des Regelwerkes

Für die Erstellung eines Regelwerkes für die Zugriffskontrolle werden zwei Analysen auf unterschiedlichen Abstraktionseben durchgeführt, aus denen sich ein fachdienstspezifisches Regelwerkes ergibt: Eine übergreifende Analyse und eine fachdienstspezifische Analyse (siehe Abbildung 3.3.2-1). Beide Analysen bauen auf den notwendigen Schritten für eine Risikoanalyse auf. Grundsätzlich folgt das Regelwerk einem Allowlisting, d.h. Zugriffe auf Ressourcen werden verhindert, solange nicht eine entsprechende Regel im Regelwerk den Zugriff erlaubt.

Abbildung 3.3.2-1: Abstraktionsebenen hinsichtlich der Erstellung des Regelwerks

Übergreifende Analyse

Die fachdienstübergreifende Analyse dient dazu, den Werkzeugkasten für die fachdienstspezifische Analyse zu erstellen und umfasst folgende Schritte:

(1) Zunächst werden generelle Bedrohungen und Angriffsszenarien im Zusammenhang mit den Zugriffen auf Ressourcen der TI identifiziert und deren Eintrittswahrscheinlichkeiten abgeschätzt. Dies erfordert das Festlegen auf Kriterien für die nachvollziehbare und vergleichbare Abschätzung der Eintrittswahrscheinlichkeiten von Bedrohungen und Angriffsszenarien.

(2) In einem weiteren Schritt werden Attribute identifiziert, welche Nutzer, Endgerät und Umwelt eines Nutzerzugriffs modellieren und mit dem Stand der Technik erfasst werden können. In diesem Zusammenhang werden auch die Quellen für solche Attribute identifiziert sowie die möglichen Soll-Attribute bzw. Referenzwerte (oder deren Quellen z.B. in Form bestehender Datenbanken) festgelegt.

(3) Im Anschluss werden mögliche Regeln für die Autorisierung eines Nutzerzugriffs auf Basis der identifizierten Attribute entwickelt, welche die Angriffsfläche für einen kompromittierten Nutzerzugriff reduzieren und den identifizierten Bedrohungen entgegenwirken (siehe Beispiele in Tabelle 3.3.1-1). Für jede Regel wird in diesem Schritt auch deren ursächliche Bedrohung bzw. das zugehörige Angriffsszenario dokumentiert, um ein nachhaltiges Management des Regelwerks zu unterstützen. Dabei setzen Regeln entweder Maßnahmen um (z.B. Anfragen von nicht vertrauenswürdigen IP-Adressräumen blockieren) oder prüfen die Umsetzung von Maßnahmen (z.B. Nachweis über sichere Endgeräte für den Zugriff auf Dienste prüfen). Darüber hinaus wird für jede Regel eingeschätzt, in welchem Maß die Anwendung der Regel die Eintrittswahrscheinlichkeit für die Realisierung der relevanten Bedrohung reduziert.

Fachdienstspezifische Analyse

Im Rahmen der fachspezifischen Analyse wird der Werkzeugkasten aus der übergreifenden Analyse auf einen konkreten Fachdienst angewendet und dadurch ein konkretes Regelwerk für diesen Fachdienst erstellt:

(1) In einem ersten Schritt werden die für diesen Fachdienst spezifischen Ressourcen identifiziert. Dies erfordert das Festlegen auf den Abstraktionsgrad einer Ressource gemäß Kapitel und das Ermitteln der Ressourcen gemäß diesem Abstraktionsgrad. Hierzu gehört z.B. das Ermitteln der fachdienstspezifischen Objekte, der möglichen Aktionen auf diesen Objekten und der möglichen Akteure bzw. deren Rollen, welche die identifizierten Aktionen auf den Objekten ausführen dürfen.

(2) Im Anschluss werden für jede identifizierte Ressource

• die Anwendbarkeit der in der übergreifenden Analyse identifizierten Bedrohungen geprüft
• die möglichen Schäden bzw. Schadenshöhe durch einen möglicherweise kompromittierten Zugriff auf die jeweilige Ressource ermittelt.

Im Ergebnis ist es möglich, Risiken zu benennen, deren Höhen sich aus der Eintrittswahrscheinlichkeit einer Bedrohung und der Schadenshöhe für eine Ressource ergeben. Hinsichtlich der Bewertung von Schäden und Schadenshöhen ist es erforderlich, einheitliche Schadenskriterien festzulegen.

(3) Die ermittelten Bedrohungen und die damit verbundenen Risiken ermöglichen in einem dritten Schritt die strukturierte Auswahl der passenden Regeln für das Regelwerk des Fachdienstes aus der übergreifenden Analyse und das Festlegen der Soll-Attribute. Darüber hinaus ist es möglich unter Berücksichtigung der mit der Regel verknüpften Wirkung auf die Eintrittswahrscheinlichkeit des Risikos das Restrisiko je Ressource zu ermitteln. Die Risikohöhe kann dabei auch für die Abwägung hinsichtlich der Anwendung einer Regel und dem damit verbundenen Einfluss auf die Usability eines Nutzerzugriffs herangezogen werden.

3.4 Daten

Für die Realisierung der Kernfunktionen werden zwischen den Komponenten der ZTA Daten ausgetauscht und Daten auf den Komponenten gespeichert. Dafür werden die im Folgenden (Kapitel ) dargestellten Datenklassen berücksichtigt. Im Anschluss (Kapitel ) wird erläutert, welche Komponenten welche Datenklassen verarbeiten oder speichern.

3.4.1 Datenklassen

Im Rahmen dieses Konzeptes werden aufgrund ihres unterschiedlichen Schutzbedarfes folgende Datenklassen unterschieden (siehe Tabelle 3.4.1-1). Die Tabelle ist absteigend sortiert nach Schutzbedarf, d.h. DS1 hat den höchsten Schutzbedarf.

Tabelle 3.4.1-1: Datenklassen

3.4.2 Verarbeiten und Speichern von Datenklassen

Jede der Komponenten in der ZTA verarbeitet oder speichert Daten. Tabelle 3.4.2-1 stellt hierfür pro Komponente dar, welche Datenklassen dort verarbeitet/gespeichert werden. Dabei werden Daten der entsprechenden Datenklasse nur aufgeführt, wenn diese in den entsprechenden Komponenten unverschlüsselt verarbeitet (V) oder persistent gespeichert werden. Je nach Art und Schutzbedarf der Daten muss die Verarbeitung in einer vertrauenswürdigen Ausführungsumgebung erfolgen. Persistente Speicherung bedeutet hier, dass die Daten nach einem Neustart der entsprechenden Komponente noch vorhanden sind. Je nach Art und Schutzbedarf der Daten muss diese Speicherung vertraulich und daher verschlüsselt (S**) oder ausschließlich integritätsgesichert (S*) erfolgen. Da Daten der Klasse DS5 als öffentliche Daten und ohne Bezug zur Zugriffsteuerung nicht im Fokus der ZTA stehen, werden sie in der Tabelle nicht betrachtet. 

Tabelle 3.4.2-1: Verarbeiten (V) und persistentes Speichern (S*/S**) von Datenklassen

Fach-Client (FCL)

Der Fach-Client ermöglicht den Austausch von personenbezogenen medizinischen Daten (DS1) und personenbezogenen Daten (DS2) zwischen dem Nutzer und dem jeweiligen Fachdienst. Je nach Fachanwendung kann der Fach-Client auch personenbezogene medizinische Daten (DS1) oder personenbezogene Daten (DS2) für die weitere Verarbeitung persistent speichern, solange dies den berufsständischen bzw. allgemeinen Datenschutzanforderungen gemäß geschieht. Eine Verarbeitung oder Speicherung von Daten für die Zugriffssteuerung (DS3) oder von Daten zum Betrieb der TI (DS4) ist nicht vorgesehen.

Trust-Client (TCL)

Der Trust-Client ermöglicht für den Fach-Client den Austausch von Daten mit dem Fachdienst und interagiert mit anderen ZTA-Komponenten, wenn das für einen Zugriff auf die entsprechenden Ressourcen benötigt wird. Dabei verarbeitet der TCL personenbezogene medizinische Daten (DS1), ohne sie jedoch persistent zu speichern. Personenbezogene Daten (DS2) werden durch den TCL verarbeitet, z.B. das Geräte-Token mit den enthaltenen IDs für Nutzer und Gerät. Ein Teil der personenbezogenen Daten (DS2) wird auch persistent gespeichert, z.B. die ID des Gerätes (basierend auf einem asymmetrischen Schlüsselpaar), das im Rahmen der Geräteregistrierung beim GMS hinterlegt wird und danach für die Identifizierung und Authentifizierung des Gerätes dient. Eine Verarbeitung oder Speicherung von Daten für die Zugriffssteuerung (DS3) oder von Daten zum Betrieb der TI (DS4) ist nicht vorgesehen.

Authenticator-Modul (AUM)

Das Authenticator-Modul verarbeitet personenbezogene Daten (DS2) für die Authentifizierung des Nutzers beim IDP. Je nach Realisierung des sektoralen IDPs kann das AUM solche Daten auch persistent speichern, z.B. als Schlüsselmaterial im Secure Element des Endgerätes oder in Form von Identifiern, welche das AUM mit der Identität des Nutzers verbinden.

Nutzerportal

Das Nutzerportal bietet dem Nutzer eine Möglichkeit, bestimmte Funktionalitäten der ZTA-Dienste über eine einzige Oberfläche zu nutzen, um z.B. einen Überblick über seine beim GMS registrierten Geräte zu bekommen oder benutzerspezifische Werte für Soll-Attribute im Regelwerk zu definieren. Im Rahmen dieser Aufgaben erhält das Nutzerportal personenbezogene Daten (DS2) zu dem Nutzer, um sie in der Nutzer-Oberfläche anzuzeigen. Das Nutzerportal hat keinen persistenten Speicher und verarbeitet auch keine Daten für die Zugriffssteuerung (DS3). Wenn das Nutzerportal als zentrale Komponente (z.B. als Webserver) umgesetzt wird, stellt sie Daten zu ihrem Betrieb (DS4) für das übergreifende Monitoring zur Verfügung.

Fachdienst

Die Fachdienste dienen in den meisten Fällen dazu, für den Nutzer personenbezogene medizinische Daten (DS1) und personenbezogene Daten (DS2) zu verarbeiten und (in verschlüsselter Form) zu speichern. Für das übergreifende Monitoring (MON) stellt der Fachdienst Daten über den Betrieb des Fachdienstes (DS4) zur Verfügung, die jedoch für die im Konzept beschriebenen ZTA-Funktionen nicht persistent gespeichert werden müssen.

PEP

Die PEPs der Fachdienste dienen als TLS-Endpunkte und sind dafür verantwortlich, dass für jeden Zugriff die Erfüllung des Regelwerks durch den PDP geprüft und die Entscheidung des PDPs durchgesetzt wird. Zu diesem Zweck verarbeiten die PEPs die Zugriffsanfragen (inkl. der angefragten URLs), die personenbezogene medizinische Daten (DS1) enthalten/darstellen können. Zudem verarbeiten die PEPs personenbezogene Daten (DS2), z.B. in Form der ID-Token, sowie Daten für die Zugriffssteuerung ohne Personenbezug (DS3) wie z.B. die öffentlichen Schlüssel, die für die Prüfung der Signaturen an ID- und Geräte-Token verwendet werden. Für das übergreifende Monitoring (MON) stellt der PEP Daten über den Betrieb des PEPs sowie über erhaltene Zugriffsanfragen (DS4) zur Verfügung. Eine Speicherung von Daten (DS2) im PEP ist nur kurzzeitig im Rahmen des Session-Managements und für eine Aggregation von Informationen zu erfolgten Zugriffen für das Monitoring vorgesehen.

PDP

Die PDPs treffen Entscheidungen über die Gültigkeit angefragter Zugriffe basierend auf dem Regelwerk. Zu diesem Zweck verarbeiten sie Informationen zur angefragten Ressource, die personenbezogene medizinische Daten (DS1) enthalten/darstellen kann. Personenbezogene Daten (DS2) werden z.B. in Form von IP-Adressen verarbeitet. Für die Entscheidung benötigt ein PDP die Daten zur Zugriffssteuerung ohne Personenbezug (DS3) wie die für den entsprechenden Fachdienst geltenden Regeln des Regelwerks oder Informationen aus PIPs. Für das übergreifende Monitoring (MON) stellt der PDP Daten über seinen Betrieb (DS4) zur Verfügung. Eine persistente Speicherung von Daten im PDP ist nicht vorgesehen.

IDP

Die sektoralen IDPs sind verantwortlich für die Identifizierung und Authentisierung der Nutzer. Zu diesem Zweck erhalten und verarbeiten IDPs Informationen über die angefragten Fachdienste und Ressourcen, was personenbezogene medizinische Daten (DS1) darstellen kann. Diese werden jedoch nicht persistent gespeichert, um eine Profilbildung über das Nutzerverhalten am IDP zu verhindern. Der IDP verarbeitet und speichert personenbezogene Daten (DS2), um damit die Identifizierung und Authentifizierung der Nutzer vorzunehmen. Am IDP ist keine Verarbeitung von Daten für die Zugriffssteuerung ohne Nutzerbezug (DS3) vorgesehen, da Datenverarbeitung am IDP in der Regel im Kontext eines Nutzers geschieht. Für das übergreifende Monitoring (MON) stellt der IDP Daten über seinen Betrieb (DS4) zur Verfügung, die jedoch für die im Konzept beschriebenen ZTA-Funktionen nicht persistent gespeichert werden müssen.

FEM

Der Federation Master verarbeitet und speichert keine personenbezogenen (medizinischen) Daten (DS1, DS2). Er speichert aber Daten für die Zugriffssteuerung ohne Personenbezug (DS3), insbesondere die öffentlichen Schlüssel/Zertifikate für IDPs, GMS und Fachdienste und stellt diese für die TI zur Verfügung. Für das übergreifende Monitoring (MON) stellt der FEM Daten über seinen Betrieb (DS4) zur Verfügung, die jedoch für die im Konzept beschriebenen ZTA-Funktionen nicht persistent gespeichert werden müssen.

PIP

Die Policy Information Points speichern Daten für die Zugriffssteuerung ohne Personenbezug (DS3), insbesondere Referenzwerte für Attribute, und stellen diese den PDPs der Fachdienste zur Verfügung. PIPs verarbeiten und speichern keine personenbezogenen medizinischen Daten (DS1). Die Verarbeitung von personenbezogenen Daten (DS2) kann im Rahmen des Feinkonzeptes nicht ausgeschlossen werden, da sie von den konkreten Attributen des Regelwerks abhängt. Wenn personenbezogene Daten, wie z.B. IP-Adressen, als Referenzwerte für das Regelwerk verwendet werden sollen, muss für den Einzelfall geprüft werden, ob eine Anonymisierung oder Pseudonymisierung möglich ist oder wie durch weitere Schutzmaßnahmen eine datenschutzkonforme Verarbeitung gewährleistet werden kann. Für das übergreifende Monitoring (MON) stellen PIPs Daten über ihren Betrieb (DS4) zur Verfügung, die jedoch für die im Konzept beschriebenen ZTA-Funktionen nicht persistent gespeichert werden müssen.

GMS

Der GMS verarbeitet und speichert personenbezogene Daten (DS2) im Rahmen der Registrierung bzw. Deregistrierung von Geräten und deren Assoziation zu Nutzer-IDs. Er erhält jedoch keine Informationen über verwendete Fachdienste oder andere personenbezogene medizinische Daten (DS1). Der GMS verarbeitet und speichert Daten für die Zugriffssteuerung ohne Personenbezug (DS3), z.B. in Form von Vertrauensankern für die Prüfung verwendeter Hardware-Sicherheitsanker. Für das übergreifende Monitoring (MON) stellt der GMS Daten über seinen Betrieb (DS4) zur Verfügung, die jedoch für die im Konzept beschriebenen ZTA-Funktionen nicht persistent gespeichert werden müssen.

PAP

Der PAP speichert und verarbeitet mit dem Regelwerk Daten zur Zugriffssteuerung (DS3). Für das übergreifende Monitoring (MON) stellt er Daten über seinen Betrieb (DS4) zur Verfügung, die jedoch für die im Konzept beschriebenen ZTA-Funktionen nicht persistent gespeichert werden müssen. Er verarbeitet und speichert keinerlei personenbezogene (medizinische) Daten (DS1, DS2).

MON

Das übergreifende Monitoring (MON) sammelt von allen TI-Komponenten Informationen über deren Betrieb und Sicherheit (DS4) und erhält nutzerunabhängige Attributwerte und Zugriffsentscheidungen (DS3) von den PEPs der Fachdienste. Diese Informationen werden für spätere Auswertungen geloggt und integritätsgeschützt gespeichert. Bei der Spezifikation der Nutzung der Schnittstellen des Monitorings durch andere Dienste muss darauf geachtet werden, dass keine personenbezogenen medizinischen Informationen (DS1) an die Monitoring-Komponente übergeben werden. Die korrekte Umsetzung der Spezifikation wird durch Produktzulassungen sichergestellt. Eine Verarbeitung von personenbezogenen Daten (DS2) kann im Rahmen des Feinkonzeptes nicht ausgeschlossen werden, da sie von den konkreten Attributen des Regelwerks abhängt. Wenn personenbezogene Daten, wie z.B. IP-Adressen, im Rahmen des Security-Monitorings für ein automatisiertes Anpassen von Referenzwerten für das Regelwerk verarbeitet werden sollen, muss für den Einzelfall geprüft werden, ob eine Anonymisierung oder Pseudonymisierung möglich ist oder wie durch weitere Schutzmaßnahmen eine datenschutzkonforme Verarbeitung gewährleistet werden kann.

3.5 Funktionen und Datenflüsse

In diesem Kapitel erfolgt die nähere Beschreibung der Kommunikationsflüsse in der ZTA. Je Kernfunktion wird dargestellt, wie einzelne Komponenten für die Realisierung der Funktion miteinander interagieren, welche Protokolle dafür eingesetzt werden und welche Rollen einzelne Komponenten innerhalb der Protokolle einnehmen.

In Abbildung 3.5-1 ist die Interaktion zwischen Komponenten der Nutzer und Komponenten der ZTA für die Autorisierung von Nutzerzugriffen im Überblick dargestellt. In den folgenden Kapiteln werden die Interaktionen zu den Kernfunktionen, wie in Kapitel definiert, detaillierter dargestellt. Kapitel  beleuchtet die Identifizierung und Authentisierung der Nutzer. Im Anschluss werden in Kapitel  die Funktionen im Zusammenhang mit der Authentifizierung und Attestierung der Endgeräte der Nutzer betrachtet sowie in Kapitel die Funktionen hinsichtlich der Authentifizierung und Attestierung der Fachdienste. In Kapitel werden die Funktionen für das Erstellen, Prüfen, Überwachen und Anpassen des Regelwerks beschrieben. Kapitel erläutert die Interaktion im Zusammenhang mit dem Zugriffs- und Session Management und in Kapitel wird das Betriebsmonitoring der ZTA-Komponenten erläutert. Abschließend wird in Kapitel der Daten- und Kommunikationsfluss für die Autorisierung von Nutzerzugriffen detaillierter dargestellt und erläutert.

Zur vereinfachten Darstellung werden Fach- und Trust-Client hier und in den folgenden Kapiteln als eine integrierte Komponente analog zu Option 1 (Alleinstehende Geräte) und 2 (Client-Server Infrastruktur) in Kapitel betrachtet. Zusätzlich werden die beim Federation Master hinterlegten Informationen ausgeklammert, beziehungsweise als bereits bei den Akteuren vorliegend angenommen. Ebenso wird vereinfachend angenommen, dass sich Authenticator-Modul und Fach- und Trust-Client auf dem gleichen Gerät befindet.

In der ZTA werden alle Zugriffe auf Fachdienste anhand eines Regelwerks geprüft (9, 16). Dafür müssen im Rahmen des Nutzerzugriffs die notwendigen Attribute zu Subjekt, Gerät, Umgebung und Ressource erfasst werden. Übergreifend kann der Ablauf für einen Nutzerzugriff, wie in Abbildung 3.5-1 skizziert, in drei Teile unterteilt werden: Die Autorisierung des Geräts (2-6), die Authentifizierung des Nutzers (8-14) und der Zugriff auf die Ressource mit den beiden vorliegenden Nachweisen (15-17). 

Die Autorisierung des Geräts erfolgt direkt nach Start der Anwendung (1), ohne Interaktion mit dem Nutzer.

Die zur Autorisierung und Attestierung des Geräts notwendigen Schritte sind von dem Fach/Trust-Client gegen das Gerätemanagement-Service (GMS) gerichtet und folgen dem OAuth2 Standard [RFC6740_OAuth2].. Vorausgehend, und hier nicht abgebildet, ist die Registrierung des Geräts beim GMS (siehe Abschnitt ). Durch diese steht jedem Gerät eine hardwaregebundene Geräte-ID auf Basis eines Geräte-Schlüsselpaars zur Verfügung, welche das Gerät eindeutig identifiziert, und es an einen Nutzer bindet. Für die Autorisierung des Geräts baut der Client eine mTLS gesicherte Verbindung zum GMS auf und übermittelt dabei durch das verwendete Zertifikat implizit seine Geräte-ID (2). Der GMS prüft nun durch geeignete Maßnahmen welche Eigenschaften des Geräts durch ihn bestätigt werden können (4, 5). Zusätzlich hinterlegt der GMS die auf das Gerät registrierte Nutzer-Identität, welche zusammen mit dem Gerät verwendet werden darf. (5). Dieses Token erhält der Client und kann es beim PEP als Nachweis für die Attribute seines Geräts verwenden (6). Das Token ist an das TLS Client Zertifikat gebunden und kann so nur von dem tatsächlich attestierten Gerät verwendet werden.

Abbildung 3.5-1: Schematische Übersicht des Daten- und Kommunikationsflusses (vereinfacht)

Erst durch Interaktion des bereits registrierten Nutzers mit dem Fach-Client (7), startet der Authentifizierungsvorgang des Nutzers per OpenID Connect (OIDC) [OpenID-Connect] am IDP. Dazu ruft der Client zuerst die angefragte Ressource auf (8), woraufhin der PEP einen OIDC Authentication Request gegen den IDP mit entsprechenden Scopes formuliert (9). Dieser wird an den Client zurückgegeben (10), welcher wiederum die Authentifizierung an das Authenticator-Modul delegiert. Nach entsprechender Authentifizierung erhält der Client einen Authorization Code (11-14), mit welchem der PEP nach Authentisierung beim IDP ein ID-Token des bereits registrierten Nutzers abfragen kann (15, 16).

Mit dem Geräte-Token und der Information, mit der der PEP das ID-Token abrufen kann, ruft der Client nun erneut die Ressource auf (15). Die Nachweise werden für zukünftige Anfragen mit der Session verknüpft gespeichert (16). Diese Session ist ebenfalls an dasselbe TLS Client Zertifikat gebunden und kann so nur von dem authentifizierten Gerät verwendet werden. Nachdem alle Anforderungen zum Nachweis eines gültigen Geräts und einer gültigen Nutzeridentität erfüllt sind, prüft der Fachdienst, ob der Nutzer eine Berechtigung für den Zugriff auf die angefragten Nutzer-Daten hat und der Client erhält im positiven Fall Zugriff auf die angefragten Fachdienst-Daten (17).

Zukünftige Anfragen müssen nun nur noch auf die bestehende Session verweisen (in der Regel unter Nutzung von TLS-gebundenen Access- und Refresh-Token), um die gleichen Nachweise nutzen zu können.

3.5.1 Nutzer authentisieren und identifizieren

Für die Identifizierung und Authentifizierung von Nutzern, d.h. Versicherten, Leistungserbringern aber auch Fachdiensten selbst, integriert die ZTA die bereits in Spezifikation befindliche Föderation der TI [gem_IDP_Federation] der TI. Dabei wird insbesondere die Spezifikation des Sektoralen Identity Providers [gem_Spec_IDP_Sek] sowie der in diesem Zusammenhang relevante Standard OpenID Connect [OpenID-Connect] berücksichtigt.

FA2 Nutzer bei Fachdienst identifizieren

Die Funktion FA2 hat zum Ziel, die für einen Nutzerzugriff notwendigen Identitätsattribute eines Nutzers zur Verfügung zu stellen. Dazu gehören sowohl Identitätsattribute, welche für die Registrierung des Nutzers bei einem Fachdienst notwendig sind (z.B. Vorname, Name, medizinische Einrichtung, KVNR, ...), als auch Attribute hinsichtlich der TI-spezifischen Rolle des Nutzers oder der gemäß OpenID Connect spezifizierte Pairwise Pseudonymous Identifier [OpenID-Connect] für die Abbildung der Identität des Nutzers auf einen konkreten Nutzer-Account beim Fachdienst. Diese Funktion wird über einen IDP der Föderation der TI auf Basis der Authentifizierung des Nutzers durch diesen IDP realisiert.

Abbildung 3.5.1-1: Authentifizierung des Nutzers per OIDC am PEP und Fachdienst

Der Datenfluss ist in Abbildung 3.5.1-1 abgebildet und beschreibt die Identifizierung des Nutzers auf Basis von OIDC in der ZTA. Die Identifizierung des Nutzers erfolgt erst durch eine Zugriffsanfrage des Nutzers auf eine Ressource (1,2). Diese erste Anfrage wird aufgrund des fehlenden ID-Tokens (3a, 3b) abgelehnt, und an den IDP weiterverwiesen (4). Dabei übergibt der PEP ebenfalls alle notwendigen Scopes, die für die Anfrage des Nutzers notwendig sind. Anschließend sind zwei Datenflüsse möglich, die mit A und B gekennzeichnet sind. Diese werden weiter unten genauer erklärt. Sie beginnen beide mit der Übergabe des Authentication Requests (5) und enden mit dem Erhalt des Authorization Codes (6). Dieser wird anschließend an den PEP übergeben (7), welcher wiederum das ID-Token abruft (8a, 8b). Dabei muss sich der PEP mittels mTLS gegenüber dem IDP authentifizieren. Nach einer erfolgreichen Policy-Abfrage (9a, 9b), wird die Anfrage an den Fachdienst weitergeleitet (10a). Dabei werden die Informationen aus dem ID-Token dem Fachdienst zugänglich gemacht, um eine fachdienstspezifische Verwendung der Identitätsattribute zu ermöglichen. Anschließend werden die Fachdienst-Daten über den PEP und Client dem Nutzer angezeigt (10b, 11, 12).

Die beiden angesprochenen Datenflüsse A und B beschreiben die Identifizierung des Nutzers gegenüber dem IDP genauer. Der Kommunikationsfluss hängt hier davon ab, ob der Fach-Client inkl. Trust-Client und das Authenticator-Modul auf dem gleichen Gerät sind oder nicht. Dementsprechend implementiert Datenfluss A den OIDC-Authorization-Code-Flow, bei dem der TCL direkt mit dem AUM auf demselben Gerät interagiert. Bei Datenfluss B hingegen befinden sich Trust-Client und Authenticator-Modul auf getrennten Geräten und der IDP stellt über geeignete Maßnahmen eine Verknüpfung der beiden Prozesse sicher. Im Diagramm ist dies beispielhaft über OIDC Client Initiated Backchannel Authentication dargestellt [OpenID-Connect_CIBA]. Dabei stellt der Fach-/Trust-Client direkt eine Anfrage an den IDP (5, B1), der wiederum das AUM kontaktiert (B2-B4). Der Fach-/Trust-Client fragt im Hintergrund regelmäßig den aktuellen Status der Authentifizierung an (B6), und erhält nach einer erfolgreichen Authentifizierung ein entsprechendes Token (6). Bei beiden muss sich der Nutzer gegenüber dem IDP über das AUM auf einem separaten Gerät identifizieren (A2, B4) und seine Einwilligung in die Datenweitergabe hinterlegen (A3, B4).

Der Datenfluss kann ebenfalls mittels Pushed-Authorization Requests (PAR) gestaltet werden [RFC9126_OAuth2_PAR]. Dabei kontaktiert der PEP in zwischen Schritt 3b und 4 zusätzlich den IDP, und übergibt in Schritt 4 ausschließlich eine Referenz auf die von ihm zuvor gestellte Anfrage an den Fach-/Trust-Client. Die übrigen Datenflüsse bleiben gleich.

FA2.1 Nutzer authentifizieren (extern)

Die Funktion FA2.1 dient der Authentifizierung eines Nutzers gegenüber einem für diesen Nutzer zuständigen sektoralen IDP der Föderation der TI. Darüber hinaus ist diese Funktion für das Erbringen der Nutzerzustimmung für die Weitergabe von Identitätsattributen an einen Fachdienst zuständig. Der Authentifizierungsmechanismus und das für die Authentifizierung notwendig beim Nutzer verfügbare Authentifizierungsmittel (z.B. mobiles Endgerät, eGK, HBA, SMC-B, ...) ist dabei abhängig von der Implementierung des sektoralen IDP. Schnittstelle für die Authentisierung des Nutzers mit Hilfe des Authentisierungsmittels ist dabei das AUM. Die Authentifizierung selbst erfolgt auf einem definierten Vertrauensniveau hinsichtlich der Widerstandsfähigkeit der Prozesse gegen Angriffe und Manipulation des Authentifizierungsprozesses (z.B. gematik-ehealth-loa-substantial, gematik-ehealth-loa-high) gemäß Spezifikation des Sektoraler Identity Provider [gemSpec_IDP_Sek]. Das Vertrauensniveau der Authentifizierung wird als ein Inhalt des ID-Token vom IDP für die Berücksichtigung in der ZTA zur Verfügung gestellt. 

FA2.2 Nutzer bei Fachdienst registrieren (extern)

Die Funktion FA2.2 umfasst das Anlegen eines Nutzer-Accounts bei einem Fachdienst. Die dafür notwendigen Identitätsattribute des Nutzers werden über die Funktion FA2 in Form eines ID-Token bereitgestellt. Die Umsetzung dieser Funktion obliegt darüber hinaus dem Fachdienst.

FA2.3 eID-Lifecycle IDP (extern)

Die Funktion FA2.3 umfasst die für die Verwaltung einer elektronischen Identität innerhalb der TI notwendige Funktionalität (z.B. Registrieren beim IDP, Aktualisieren von Identitätsattributen, Sperren und Entsperren von Identitätsmitteln, Löschen, usw.) Dies Umsetzung dieser Funktionalität obliegt dem IDP der Föderation der TI.

FA2.4 Vertreterregelung (extern)

Durch fortschreitende Digitalisierung der Gesundheitsdienste tritt auch die Digitalisierung der Vertretung eines Nutzers der TI durch einen anderen Nutzer der TI in den Vordergrund, z.B. bei:

• Eltern in Vertretung für Ihre, ggf. minderjährigen, Kinder oder
• Kinder in Vertretung für Ihre, durch ihre hohen Alter ggf. hilfsbedürftigen, Eltern oder
• Pfleger in Vertretung für in Pflege befindlicher Nutzer,
• aber auch Dienste im Auftrag eines Nutzers.

Die Funktion FA2.4 umfasst diese Funktionalität. Theoretisch wäre eine Umsetzung in Form einer Impersonifizierung des Nutzers oder der Delegation von Rechten des Nutzers möglich [RFC8693_OAuth2_Token_Exchange]. Für die TI wird jedoch eine Umsetzung in Form einer Delegation von Rechten des Nutzers empfohlen, so dass für relevante Komponenten der ZTA erkennbar bleibt, welche Identität sich tatsächlich hinter einem Nutzerzugriff verbirgt und es möglich bleibt das vom Nutzer genutzte Gerät auch im Falle einer Vertretung der Identität des Nutzers zuzuordnen.

Grundsätzlich sind hinsichtlich der Realisierung der Funktion mehrere Lösungen denkbar:

• Option 1: IDPs der Föderation der TI ermöglichen das Hinterlegen von Vertreterbeziehungen
• Option 2: Fachdienste ermöglichen das Hinterlegen von Vertreterbeziehungen
• Option 3: Ein unabhängiger Dienst ermöglicht das Hinterlegen von Vertreterbeziehungen

Option 1 nutzt die bestehende Vertrauensbeziehung zwischen Nutzer und sektoralem IDP, wirkt sich aber ungünstig auf NFA2 (Keine Allmacht) aus, da sich der IDP durch das Anlegen eines kompromittierten Vertreters und einer entsprechend kompromittierten Vertreterbeziehung Zugang zu einem Nutzerkonto eines Fachdienstes verschaffen könnte. Darüber hinaus erfordert das Anlegen von Vertreterbeziehungen, an denen Identitäten von verschiedenen Sektoraler Identity Providern beteiligt sind, ein Protokoll, welches diese Kooperation sicher ermöglicht.

Option 2 nutzt die bestehende Vertrauensbeziehung zwischen Nutzer und Fachdienst. Allerdings können bei einem Fachdienst nur Vertreterbeziehungen für diesen Fachdienst hinterlegt werden. Eine Generalvertretung müsste also bei jedem Fachdienst einzeln angelegt werden. Darüber hinaus könnten nur bei dem Fachdienst registrierte Identitäten als Vertreter eingerichtet werden.

Option 3 erfordert einen neuen Vertretungsdienst. Als unabhängiger Dienst könnte er Vertreterbeziehungen Identity-Provider- und Fachdienst-übergreifend verwalten sowie Dienste, welche im Auftrag von Nutzern agieren, als Vertreter ermöglichen.

Mit Option 1 und 2 kann eine umfassende Vertreterregelung aus den voran genannten Gründen nicht oder nur mit Nachteilen hinsichtlich NFA2 realisiert werden. Im Rahmen dieses Konzeptes wird deshalb eine Realisierung der Funktion gemäß Option 3 empfohlen. Ein unabhängiger Vertretungsdienst könnte Nutzern zentral über das Nutzerportal zugänglich gemacht werden. Für die Integration der Vertreterbeziehungen in die Evaluierung von Nutzerzugriffen durch die PDPs müsste der Vertretungsdienst als PIP ausgelegt sein.

3.5.2 Geräte der Nutzer authentisieren und attestierten

Die Architektur ermöglicht das Authentisieren und Attestieren von Endgeräten der Nutzer, welche für den Zugriff auf Ressourcen der TI genutzt werden. Dabei soll die Authentisierung und Attestierung der Endgeräte einen weiteren von den IDPs unabhängigen Sicherheitsanker der ZTA darstellen, der die Identifizierung und Authentisieren des Nutzers durch den IDP ergänzt. Zusätzlich zum Nachweis über die Identität des Nutzers (ID-Token) soll ein Nachweis über den Besitz eines auf diesen Nutzer registrierten Endgerätes (Geräte-Token) erbracht werden. So kann verhindert werden, dass die Ausstellung eines ID-Tokens ausreicht, um eine erfolgreiche Autorisierung am Fachdienst vorzunehmen, wodurch dem IDP als Aussteller des ID-Token eine besondere Allmachtstellung in der Architektur zukäme. Für das Geräte-Token wird nachfolgend immer der OAuth2 Authorization Code Flow betrachtet [RFC6740_OAuth2].

Voraussetzung für die Zuordnung dieser beiden Nachweise zueinander ist eine erfolgreiche Verknüpfung des registrierten Geräts mit der Identität des Nutzers (Geräte-Nutzer-Assoziation). Diese beruht auf der Verwendung von zwei eindeutigen Identifiern:

• UUID_Nutzer: Eindeutiger unveränderlicher Identifier einer Nutzer-Identität in der TI, die sowohl dem IDP als auch dem GMS im Rahmen der Nutzer-/Geräte-Registrierung bekannt wird und vom Fachdienst zur Adressierung des Nutzeraccount benutzt wird
• UUID_Gerät: Eindeutiger Identifier des Geräts, der aus dem selbst-signierten Zertifikat eines auf dem Endgerät generierten asymmetrischen Schlüsselpaares abgeleitet wird (z.B. Zertifikat-Fingerprint)

Die Assoziation von Nutzer- und Geräteidentitäten erfolgt im Rahmen der Geräteregistrierung (FA5.1 - Gerät registrieren). Alle gültigen UUID_Nutzer <-> UUID_Gerät-Kombinationen sind beim GMS gespeichert und können dort verwaltet werden. Das Geräte-Token ist somit nicht fachdienstspezifisch, sondern kann für alle Fachdienste verwendet werden.

Falls der Fach-Client von mehreren Personen verwendet wird, erhält jeder Nutzer ein eigenes Schlüsselpaar. Daher ist immer nur genau ein Nutzer einem Schlüsselpaar beziehungsweise UUID_Gerät zugeordnet.

Das folgende Datenflussdiagramm zeigt den Kommunikationsfluss für einen Zugriff auf eine Ressource des Fachdienstes basierend auf dieser Assoziation:

Abbildung 3.5.2-1: Übersicht über Geräte-Nutzer-Assoziation bei Zugriff

Die UUID_Nutzer ist beim IDP gespeichert und wird nach erfolgreicher Nutzer-Authentifizierung durch ein gültiges ID-Token nachgewiesen (FA2 Nutzer authentisieren, im Bild nur durch Vorhandensein des ID-Tokens beim PEP abgebildet). Die Authentifizierung des Nutzer-Gerätes (FA5 Gerät authentisieren) erfolgt beim GMS und führt zur Ausstellung eines Geräte-Tokens, in dem unter anderem die gültige Geräte-Nutzer-Assoziation (UUID-Gerät <-> UUID_Nutzer) enthalten ist.

Das ID-Token und das Geräte-Token werden als Teil der Zugriffsanfrage an den PEP des Fachdienstes übertragen. Dieser überprüft zusammen mit dem PDP die Identitätsnachweise und ihre Assoziation und lässt nur bei Übereinstimmung einen Zugriff auf den Fachdienst zu. Der PEP ist dabei nur für die Prüfung von technischen Anforderungen zuständig, unter anderem ob die Token korrekt signiert wurden oder ob bei einem zertifikatsgebundenen Token auch eine Verbindung mit dem korrekten Zertifikat vorliegt [RFC8705_OAuth2_mTLS]. Die inhaltliche Prüfung erfolgt durch den PDP. Die Geräte-Token haben eine begrenzte Gültigkeit und müssen nach Ablauf ihrer Lebensdauer erneut angefordert werden.

Ein Gerät (UUID_Gerät) kann auch auf mehrere Nutzer (UUID_Nutzer) registriert werden, wenn mehrere Benutzer ein Gerät gemeinsam nutzen. Alternativ kann auch durch lokale Systeme (z.B. bei Kontentrennung im OS) oder Fach-Client spezifische Zuordnung (z.B. bei Kontentrennung im FCL) jeweils eine eigene UUID_Gerät erzeugt werden.

App spezifische gerätegebundene Identität

Sollte es aufgrund von Regeln der Geräte-Plattform nicht möglich sein, dass Anwendungen auf einem Gerät Zugriff auf eine UUID_Gerät und das dahinterliegende Schlüsselpaar erhalten, muss jede Anwendungen ihre eigene UUID_App_Gerät erzeugen. Für die Registrierung mehrerer UUID_App_Gerät auf einem Gerät sollten vereinfachte Registrierungs- und Managementprozesse (u.a. im Nutzerportal) vorgesehen werden. Eine erste Betrachtung der aktuellen technischen Möglichkeiten auf marktüblichen Plattformen ist in Anhang 1 zu finden. In allen vorstehenden und folgenden Betrachtungen zur Geräteregistrierung ist UUID_Gerät stellvertretend für UUID_Gerät oder UUID_App_Gerät anzusehen.

Pairwise-Identifier des Nutzers

Die OIDC-Spezifikation sieht die Nutzung eines Pairwise-Identifiers als OIDC-Client-spezifische Nutzeridentität vor [OpenID-Connect]. In diesem Fall erhält jeder PEP bzw. Fachdienst eine fachdienstspezifische Nutzerkennung. Für den für Pairwise-Identifier muss ein zusätzlicher Identifier eingeführt werden: UUID_FD_Nutzer. Um die fachdienstübergreifende Geräteregistrierung weiterhin zu ermöglichen, müssen UUID_FD_Nutzer und UUID_Nutzer für den Fachdienst zuordenbar sein. Beispielsweise könnte UUID_FD_Nutzer zusammen mit der OIDC-Client-ID aus UUID_Nutzer abgeleitet werden. Im folgenden Diagramm (Abb. 3.5.2-2) ist nun einmalig die Verwendung von UUID_FD_Nutzer und UUID_FD_Gerät dargestellt.

Abbildung 3.5.2-2: Übersicht über Geräte-Nutzer-Assoziation bei Zugriff mit erweiterter Nomenklatur

Für eine konkrete Ausgestaltung der UUID_Nutzer, UUID_FD_Nutzer, UUID_Gerät und UUID_App_Gerät, sowie deren Ableitung, sind tiefergehende Analysen notwendig. Idealerweise sollte UUID_Nutzer bzw. UUID_FD_Nutzer so gewählt werden, dass diese keine direkten Rückschlüsse auf die dahinterliegende Person zulassen. Dies würde unter anderem ermöglichen, dass der GMS keine personenbezogenen Informationen persistent speichern muss.

Geräte-Token Refresh

Der Refresh des Geräte-Token erfolgt ausschließlich durch den Trust-Client. Auf Basis der im Token enthaltenen Lebensdauer kann der Trust-Client periodisch ein neues Geräte-Token anfragen und beim nächsten Ressourcen-Zugriff dem PEP übergeben.

Hier kann durch Refresh-Token und die Lebensdauer des Geräte-Tokens an sich eine Abwägung zwischen verschiedenen Schutzzielen und Usability getroffen werden. So ermöglichen kurze Laufzeiten ein schnelles Sperren von Geräten, oder das schnelle Reagieren auf Veränderungen am System. Lange Lebensdauern erhöhen die Performance. Sie erfordern weniger Abfragen und aufwändige Remote-Attestation Vorgänge müssen seltener durchlaufen werden.

FA5 - Gerät authentisieren

Ein Nutzer-Endgerät wird durch den eindeutigen Geräte-Identifier UUID_Gerät identifiziert und kann sich durch den Besitz des privaten Schlüssels aus einem asymmetrischen Schlüsselpaar in der ZTA authentisieren. Die UUID_Gerät ergibt sich direkt aus dem öffentlichen Schlüssel des Schlüsselpaares und wird im Rahmen des Registrierungsprozesses beim GMS hinterlegt. Den privaten Schlüssel und das Zertifikat verwendet der Trust-Client beim TLS-Verbindungsaufbau zu seinen Kommunikationspartnern, um seine Identität nachzuweisen.

Beim GMS ist hierbei das Zertifikat allein für die Authentifizierung ausreichend, da sich die UUID_Gerät daraus ergibt und im Rahmen des Registrierungsprozesses beim GMS abgespeichert wurde.

Zur Umsetzung der hier gewünschten Funktionalität wurde ein selbst-signiertes Zertifikat als ausreichend erachtet, da das Zertifikat ausschließlich für die Übermittlung des öffentlichen Schlüssels dient, um über die standardisierten mTLS-Nachrichten den Nachweis über den Besitz des dazugehörigen privaten Schlüssels zu erbringen. Das erwartete Zertifikat bzw. der öffentliche Schlüssel wird über das Geräte-Token übermittelt und beim Fachdiensten (bzw. dessen PEP) mit dem für den Aufbau der TLS-Verbindung verwendeten Zertifikat abgeglichen, womit eine Art Zertifikats-Pinning bzw. Publik-Key-Pinning umgesetzt wird [RFC8705_OAuth2_mTLS]. Ein von einer PKI ausgestelltes Zertifikat bietet für diese beschriebenen Funktionalitäten keinen Mehrwert.

Eine detaillierte Betrachtung der Möglichkeiten ist in Anhang 1 zu finden.

FA5.1 - Gerät registrieren

Bei der Registrierung eines Geräts wird die Nutzeridentität (UUID_Nutzer) mit der Geräte-Identität (UUID_Gerät) verknüpft und diese Assoziation beim GMS hinterlegt.

Das folgende Datenflussdiagramm (Abbildung 3.5.2-3) zeigt die Registrierung eines Geräts am GMS. Direkt nach Start der Anwendung wird die hardwaregebundene Geräte-ID erzeugt (2). Nachdem der Nutzer die Geräte-Registrierung initiiert hat (3), authentisiert sich der TCL implizit per mTLS am GMS, und startet die Registrierung (4). Anschließend fordert der GMS den TCL auf, einen entsprechenden Nutzernachweis vorzulegen (5). Dies wird durch Identifizierungsmittel erreicht, die möglichst unabhängig von den sektoralen IDP sind (z.B. Identifizierungsmittel, welche auch für die Erstidentifizierung bei einem sektoralen IDP zugelassen sind). Dabei ist notwendig, dass der Nachweis durch die mTLS gesicherte Verbindung am GMS eingereicht wird (7), um den Nachweis sicher mit der Geräte-ID verbinden zu können. Dieser Nachweis wird am GMS hinterlegt (7), und dem Gerät und Nutzer bestätigt (9, 10).

Für die sichere Implementierung müssen einige Besonderheiten beachtet werden:

• UUID_Nutzer muss von einer unabhängigen dritten Stelle vergeben und bestätigt werden. Dies wäre unter anderem direkt durch das Authentifizierungsmerkmal (eGK, HBA) oder einen vertrauenswürdigen dritten Dienst möglich.
• Für die Identifizierung des Nutzers beim FD muss entsprechend diese beim GMS registrierte UUID_Nutzer verwendet werden. Dies kann entweder durch eine direkte Nutzung der UUID_Nutzer oder die Verwendung einer davon abgeleiteten UUID_FD_Nutzer als Pairwise-Identifier erfolgen. Dadurch wird sichergestellt, dass der IDP die Gerätebindung nicht umgehen kann.

Zudem muss sichergestellt werden, dass die Authentifizierung des Nutzers resistent gegen Angriffe ist, wie beispielsweise Phishing. Das ist insbesondere herausfordernd, wenn das Authentisierungsmittel nicht direkt mit dem Trust-Client kommunizieren kann.

Die Registrierung wird direkt vom Trust-Client durchgeführt, kann allerdings vom Fach-Client angestoßen werden, sofern der Trust-Client keine eigene Bedienoberfläche hat, oder dessen Bedienoberfläche direkt in den Fach-Client integriert ist.

Abbildung 3.5.2-3 Registrierung eines Geräts beim GMS

FA5.2 - Gerät entfernen

Die Geräte-Nutzer-Assoziation (UUID_Gerät <-> UUID_Nutzer) ist nur am GMS und im von ihm ausgestellten Geräte-Token hinterlegt. Geräte-Token verlieren automatisch ihre Gültigkeit, nachdem ihre Lebensdauer überschritten ist. Dementsprechend kann die Gerätebindung durch eine einzelne Operation am GMS entfernt werden, welche spätestens nach Ablauf der maximalen Lebensdauer eines Geräte-Token wirksam wird.

Diese Operation muss ohne den Zugriff auf das registrierte Gerät möglich sein, um nicht mehr zugängliche Geräte ebenfalls entfernen zu können. Das Entfernen von Geräten ist weniger sicherheitskritisch als die initiale Registrierung. Daher können hier verschiedene Methoden zur Authentifizierung eingesetzt werden. Hier ist beispielhaft eine Authentifizierung durch den IDP per OIDC dargestellt [OpenID-Connect]. Es ist aber auch möglich das Authentisierungsmittel für die Geräteregistrierung zu verwenden, oder Informationen mit Gerätebezug zu verwenden. So könnte bei der Geräteregistrierung ein Lösch-Code mit ausgestellt werden. Weiterhin könnte die Löschung auch mit einem anderen authentisierten Gerät möglich sein, evtl. über das Nutzer-Portal.

Das nachfolgende Datenflussdiagramm (Abbildung 3.5.2-4) zeigt beispielhaft den Kommunikationsfluss für das Entfernen eines registrierten Gerätes (basierend auf der UUID_Gerät) mittels OIDC gegen den IDP.

Abbildung 3.5.2-4 Entfernen einer Nutzer-Geräte-Assoziation beim GMS

FA6 - Gerät attestieren

Informationen über den Sicherheitszustand des Gerätes werden durch den GMS geprüft und zusammen mit der Geräte-Nutzer-Assoziation in einem Geräte-Token bestätigt. Im Wesentlichen findet dabei ein OAuth2 Authorization Code Flow mit PKCE [RFC6749_OAuth2, RFC7636_OAuth2_PKCE] statt. Der Fach-/Trust-Client kann in dem initialen Authentication Request (2) durch Scopes den GMS darauf hinweisen, welche Nachweise beziehungsweise Claims der Client als notwendig erachtet. Dies kann durch eine vom Fach-Client lokal vorgehaltene Liste erfolgen. Anschließend fordert der GMS vom Trust-Client Informationen über das Nutzerendgerät an, das dieser mithilfe von plattform-spezifischen Frameworks und Diensten zur Verfügung stellt (3). Der GMS überprüft die erhaltenen Attestierungs-Informationen mit dem für den Gerätetyp anzuwendenden Verifizierungsmechanismus (4,5). Je nach verwendetem Framework kann dafür eine Interaktion mit Backend-Diensten des Framework-Anbieters (z.B. Google, Apple, Microsoft) nötig sein (4). Mithilfe eines Authorization Codes (6) können die verifizierten Informationen dann über das Geräte-Token vom GMS angefordert werden (7). Das Geräte-Token enthält einerseits die beim GMS hinterlegte Geräte-Nutzer-Assoziation und andererseits die verifizierten Informationen über das Endgerät in für die TI standardisierter Form (8).

Abbildung 3.5.2-5 Attestierung von Geräte-Eigenschaften

FA6.1 - Geräteinformationen erheben

Die für die Bewertung des Gerätezustands nötigen Informationen werden auf dem jeweiligen Endgerät des Nutzers erhoben. Um zu verhindern, dass ein kompromittiertes Endgerät die Informationen über den Gerätezustand manipulieren kann, müssen die Informationen durch eine vertrauenswürdige Komponente auf dem Gerät zur Verfügung gestellt oder bestätigt werden. Hierfür können beispielsweise TPMs oder Trusted Execution Environments verwendet werden. Da die Nutzung der TI mit den im Alltag bereits genutzten Endgeräten der Nutzer möglich sein soll (besonders bei den Versicherten), sollten für die Erhebung der Geräteinformationen auf den Endgeräten die dort bereits verfügbare Frameworks bzw. Lösungen verwendet werden. Diese sind in der Regel abhängig vom verwendeten Betriebssystem und benötigen bisher meist die Unterstützung durch den entsprechenden Anbieter. So liefert beispielsweise die Google Play Integrity API^{(https://developer.android.com/google/play/integrity/overview)} mithilfe von Key Attestation über einen Google Backend Server Informationen über die Integrität einer verwendeten Anwendung und eine Bewertung der Geräteintegrität. Auch das Device Check Framework^{(https://developer.apple.com/documentation/devicecheck)} von Apple bietet Nachweise über die Integrität von Apps und die Identität des Geräts. Unter Windows stehen mehrere Möglichkeiten zur Verfügung, um Geräteinformationen zu erheben. Einerseits besteht die Möglichkeit, direkt mit dem TPM als Root-of-Trust zu interagieren und den Systemzustand zu attestieren. Ebenfalls steht die Windows Device Health Attestation API^{(https://learn.microsoft.com/en-us/windows/security/threat-protection/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices)} zu Verfügung, die mehrere Komponenten in einer vereinheitlichen Schnittstelle für eine umfassendere Systemattestierung bietet. Diese ist allerdings möglicherweise nicht in allen Systemkonfigurationen verfügbar (bspw. nur AD-Joined).

3.5.3 Fachdienst authentisieren und attestieren

FA3 - Fachdienst gegenüber Nutzer authentisieren

Das Identifizieren und Authentifzieren eines Fachdienstes durch den Nutzer bzw. seinen Client erfolgt über das TLS-Zertifikate des Fachdienstes bzw. seines PEP. Diese Zertifikate werden im Rahmen des TLS-Verbindungsaufbaus an den Trust-Client übertragen. Der Trust-Client prüft gemäß TLS-Standard, ob der Fachdienst im Besitz des zugehörigen privaten Schlüssels ist (Abschnitt 4.4.3. in für TLS1.3 [RFC8446-TLS]) und validiert das Zertifikat nach anerkannten Standards (z.B. [RFC5280-Certs]) gegen eine für die TI zugelassene CA. Der Fachdienst verwendet OCSP-Stapling (wie in Abschnitt 4.4.2.1 in [RFC8446-TLS] beschrieben) und der Trust-Client prüft anhand der übermittelten Informationen, dass das Zertifikat nicht gesperrt oder widerrufen wurde. Falls eine der Prüfungen fehlschlägt, verweigert der Trust-Client den Zugriff auf den Fachdienst und informiert den Endnutzer über das vorliegende Problem.

FA4 - Fachdienst attestieren (extern)

Dienste, die an die TI angeschlossen werden sollen, werden initial von der gematik in einem Zulassungs- bzw. Bestätigungsprozess gegen die Anforderungen der TI geprüft. Zu den Anforderungen kann es gehören, dass der Dienst mithilfe von Attestierung auch im laufenden Betrieb geprüft wird. Hierbei werden Eigenschaften der laufenden Fachdienst-Instanz überprüft, um ihre Vertrauenswürdigkeit im Betrieb zu bewerten. Zu den überprüften Eigenschaften können die Integrität und Aktualität der Software, die Korrektheit der Systemkonfiguration oder die Lokalisierung der Instanz in einer zugelassenen Rechenzentrumsumgebung gehören. Die Integritätsprüfung kann mittels eines TPMs mit Measurements des gesamten SW-Stacks oder mittels der Remote Attestation Features von Confidential Computing Technologien wie AMD SEV-SNP oder Intel TDX umgesetzt werden. Die Attestierung kann implizit durch das Binden der verwendeten kryptografischen Schlüssel an den Zustand des Software-Stacks oder explizit durch eine Attestierung gegenüber einem zentralen Dienst in der TI erfolgen.

Die Konzeptionierung und Umsetzung der Attestierungsfunktion für Fachdienste ist nicht Teil dieses Projektes. Das vorliegende Feinkonzept beschränkt sich deshalb auf das Prüfen der fachdienstspezifischen TLS-Zertifikate.

3.5.4 Regelwerk prüfen, erstellen, überwachen und anpassen

Das Erstellen, Verwalten und Anwenden von Zugriffsregeln innerhalb einer Zero-Trust-Architektur erfordert ein definiertes Schema für das Beschreiben der Zugriffsregeln. Der offene Standard eXtensible Access Control Markup Language (XACML) [OASIS_XACML] der Organisation OASIS (unter anderem vertreten durch Cisco Systems, IBM, Microsoft, Oracle und Red Hat) beschreibt ein solches Schema, in Form einer auf XML basierenden Beschreibungssprache für ein Regelwerk sowie einem Datenflussmodell. Dabei orientiert sich das Datenflussmodell an den logischen Komponenten des Standards ISO/IEC 29146 [ISO29146], welche auch in diesem Konzept berücksichtigt werden.

In Abbildung 3.5.4-1 ist der Aufbau eines Regelwerkes gemäß XACML 3.0 grafisch dargestellt.

Abbildung 3.5.4-1: Modell Regelwerk XACML 3.0

XACML definiert eine hierarchische Struktur für das Verwalten von Regeln. Eine Regel (Rule) ist die elementare Einheit, in der eine Zugriffsentscheidung getroffen werden kann.

Eine Regel ist immer einer Policy zugeordnet. Policies können darüber hinaus in PolicySets gruppiert werden. Dabei können PolicySets wiederum PolicySets zugeordnet werden, wodurch sich Regelwerke beliebig fein untergliedern lassen. Für welche Zugriffsanfragen PolicySets, Policies und Regeln Anwendung finden wird in jeder dieser Komponenten durch die Beschreibung eines Targets in Form eines logischen Ausdrucks über die Attribute der Zugriffsanfrage definiert.

Jede Regel kann eine Bedingung (Condition) in Form eines boolschen Ausdrucks enthalten, welcher den Anwendungsbereich der Regel in Abhängigkeit von weiteren Attributen (Ist-Attribute, Soll-Attribute) weiter einschränkt. XACML stellt eine lange Liste an Funktionen zur Verfügung, um Attribute zu bearbeiten oder mit anderen Attributen zu vergleichen.

Jede Regel erzielt eine Wirkung (Effect) als Teilentscheidung hinsichtlich der Zugriffsanfrage. Die Wirkung der Regel gibt die beabsichtigte Konsequenz (Permit, Deny) an, die der Verfasser der Regel bei einer positiven Auswertung (true) der Bedingung der Regel beabsichtigt.

Konflikte im Rahmen von unterschiedlichen Zugriffsentscheidungen verschiedener Regeln einer Policy werden durch einen definierten Algorithmus (Rule Combining Algorithm) der Policy aufgelöst. PolicySets verfügen über einen analogen Algorithmus (Policy Combining Algorithm) zum Auflösen von Konflikten von Zugriffsentscheidungen darunterliegender Elemente.

Für PolicySets, Policies und Regeln können darüber hinaus verpflichtende (Obligation) oder empfohlene (Advice) Ausführungsanweisungen definiert werden, welche in Abhängigkeit von der Zugriffsentscheidung zusammen mit dieser an den PEP übermittelt werden.

XACML wurde im Jahr 2001 als Policy-Sprache für ABAC entwickelt und im Jahr 2013 in der Version 3.0 veröffentlich. 2017 wurde der Standard letztmalig aktualisiert.

Abbildung 3.5.4-2: Vergleich Modell Regelwerk Rego / XACML 3.0

Eine weitere Regelbeschreibungssprache ist Rego [OPA_Rego]. Rego wurde von der Firma Styra Inc. entwickelt und 2018 zusammen mit der Regelauswertungsengine Open Policy Agent (OPA)^{(https://www.openpolicyagent.org/)} als Open Source Projekt in die Cloud Native Computing Foundation (CNCF) aufgenommen. Rego selbst ist jedoch nicht standardisiert. Rego ermöglicht das Beschreiben von Regeln in Form einer Programmiersprache. Dadurch ergibt sich ein gegenüber XACML erhöhter Grad an Flexibilität und Ausdrucksstärke. 

In Abbildung 3.5.4-2 ist der Aufbau eines Regelwerkes mit Rego anhand der Artefakte von XACML grafisch dargestellt.

Grundsätzlich lässt sich in Rego eine ähnliche Struktur des Regelwerks abbilden, wie dies in XACML möglich ist. Regeln können in Packages und Modulen strukturiert werden. Elemente wie Target, Advice, Obligation, Condition, Effect und Rule Combining Algorithm sind in Rego nicht direkt definiert, können aber über die Logik der Programmiersprache in den Regeln abgebildet werden. Darüber hinaus ist es so möglich, das Modell des Regelwerks weiter an domainspezifische Bedürfnisse anzupassen. Objekte, welche im Rahmen der Zugriffsanfrage an den PEP übergeben werden oder als Entscheidung an den PEP zurückgegeben werden, können zum Beispiel flexibel definiert werden. Ebenso können komplexe Bedingungen durch den erhöhten Freiheitsgrad in Rego einfacher beschrieben werden als in XACML.

XACML oder Rego eröffnen grundsätzlich die Möglichkeit zur Umsetzung des Regelwerkes. Vor einer Umsetzung des Regelwerkes und der damit verbundenen Komponenten sollte jedoch noch ein tiefergehender Vergleich der vorgestellten Schemas mit weiteren Open-Source-Optionen wie z.B. NGAC [NIST_ABAC-Comparison] erfolgen.

FA1 - Zugriff gegen Regelwerk prüfen

In Abbildung 3.5.4-3 ist der Datenfluss für das Prüfen eines Zugriffs gegen das Regelwerk dargestellt. 

Abbildung 3.5.4-3: Datenfluss für das Prüfen eines Zugriffs gegen das Regelwerk

Zugriffsanfragen auf einen Fachdienst leitet der PEP zunächst an den PDP weiter (1). Eine Zugriffsanfrage enthält immer Informationen über die angefragte Ressource, d.h. das angefragte Objekt und die intendierte Aktion. Darüber hinaus werden, sofern vorhanden, ID-Token und Geräte-Token zusammen mit der Zugriffsanfrage an den PDP weitergeleitet. 

Der PDP ermittelt anhand der Informationen aus der Zugriffsanfrage die relevanten Policies und Regeln (2) und wertet diese detaillierter aus (3). Attribute, welche für das Auswerten von Bedingungen der Regeln erforderlich sind, werden dabei entweder der Zugriffsanfrage entnommen oder bei einem PIP angefragt (4a, 4b). 

Der PDP kombiniert die Ergebnisse aller ausgewerteten Regeln zu einer Zugriffsentscheidung (5) und sendet diese zusammen mit möglichen weiteren Handlungsanweisungen an den PEP (6) zurück.

FA1.1 - Regelwerk erstellen und aktualisieren

Die Regeln für das Regelwerk der TI werden vor ihrer Anwendung in der ZTA durch einen geeigneten Prozess definiert und abgestimmt (siehe Kapitel ). Um die Diskussion aller Beteiligten über die angedachten Regeln zu ermöglichen, werden die Regeln dabei in natürlicher Sprache oder einer geeigneten leicht verständlichen Form wie z.B. einer Tabelle oder low-code formuliert. Das könnte beispielsweise wie folgt aussehen:

Option 1: Natürliche Sprache
Der Vorteil an der Verwendung von natürlicher Sprache ist, dass diese grundsätzlich von jedem Diskussionsteilnehmenden verstanden werden kann und kein tiefergehendes technisches Verständnis der Beteiligten erfordert. Die Herausforderung liegt jedoch darin, in natürlicher Sprache die Regeln klar und ohne Raum für Interpretation zu definieren, ggf. komplexe Zusammenhänge sauber aufzuschreiben und danach eine geeignete Übersetzung in eine maschinenlesbare Sprache zu finden. Falls dieser Weg gewählt wird, ist die Verwendung von Templates für die Regelsätze zu empfehlen.

Abbildung 3.5.4-4: Beispiel für eine Regel in natürlicher Sprache

Option 2: Tabellenform

Eine Tabelle erlaubt ein strukturiertes Vorgehen und ein konsequentes Durchgehen/Diskutieren aller möglichen Attribute pro Regel. Sie schränkt jedoch die Flexibilität stark ein, da eine Abbildung komplexerer Regel-Kombinationen (z.B. Verknüpfung mehrerer Zeilen) nur schwierig möglich ist.

Abbildung 3.5.4-5: Beispiel für eine Regel in Tabellenform

Option 3: Low-Code

Low Code beschreibt die Verwendung einer visuellen Gestaltungsoberfläche anstelle von klassischen textbasierten Programmiersprachen. Mithilfe von Low-Code kann eine Darstellung der Regeln geschaffen werden, die nahe an der gewünschten Sprache der Policy-Engine ist und so die technische Abbildung des Regelwerkes vereinfacht. Im Rahmen der Marktanalyse für die zu verwendende Policy-Sprache sollte untersucht werden, ob es bereits geeignete graphische Policy Editoren für die jeweilige Sprache gibt oder wie viel Aufwand es wäre, ein solches Tooling zu entwickeln.

Abbildung 3.5.4-5: Beispiel für eine Regel in Low-Code

Die gewünschte Darstellungsform sollte in Absprache mit allen an der Regelsetzung Beteiligten festgelegt werden. Wichtig ist es, dass die Regeln klar formuliert und ohne Interpretationsspielraum dokumentiert werden können.

Für die Verwendung der Regeln in der TI müssen sie aus der gewählten Darstellungsform in die Sprache der Policy-Engine (z.B. XACML oder Rego) übersetzt werden. Diese Übersetzung kann entweder manuell erfolgen oder auch automatisiert werden, wenn es eine eindeutige Interpretation/Übersetzungsmethodik von der ursprünglich verwendeten Form auf die maschinenlesbaren Regeln gibt.

Nach der Übersetzung sollte die Übereinstimmung der maschinenlesbaren Version mit dem in natürlicher Sprache verfassten Regelwerk geprüft werden. Mögliche Methoden sind z.B.:

• das Testen mit definierten Beispielfällen: Es werden verschiedene Input-Daten für die möglichen Attribute sowie deren erwartete positive oder negative Auswertungsergebnisse definiert und das generierte Regelwerk darauf angewendet/dagegen getestet
• das Rückübersetzen der Policy in eine natürliche Sprache/das Ursprungsformat und der Abgleich, ob die initiale und die rückübersetzte Regel übereinstimmen

Zudem sollte ggf. Tooling zum Einsatz kommen, welches das fertig definierte Regelwerk auf Widerspruchsfreiheit und Konsistenz prüft.
Im Rahmen der Marktanalyse für die zu verwendende Policy-Sprache sollte untersucht werden, ob es zu der jeweiligen Sprache bereits Tooling für die Verifikation oder das Testen gibt (ggf. angelehnt an bestehenden Verifizierungs- und Testmethoden für Policies/Modelle [NIST_PolicyVerification]).

Eine erfolgreiche Prüfung des übersetzten Regelwerks und der darin enthaltenen PolicySets (bzw. Packages) wird vor dem Einbringen in die Komponenten der ZTA durch kryptographische Signaturen bestätigt. Das Regelwerk wird dabei basierend auf der Gültigkeit für die Fachdienste in der TI in verschiedene PolicySets unterteilt und jedes dieser PolicySets wird nach erfolgreicher Prüfung einzeln signiert. Das erlaubt es, den ZTA-Komponenten mit den entsprechenden öffentlichen Schlüsseln die Integrität und Authentizität der erhaltenen Policy-Sets zu prüfen.

Das gesamte Regelwerk wird (in der Sprache der Policy-Engine) am PAP in die TI eingebracht, indem die signierten PolicySets dort z.B. über Konfigurationsdateien zur Verfügung gestellt werden. PDPs sind dazu verpflichtet, in regelmäßigen Abständen (z.B. täglich) beim PAP die aktuelle Version der für ihren Fachdienst gültigen Teile des Regelwerks abzufragen. Sollte die damit gegebene Updatefrequenz für kurzfristige Updates im Emergency Fall nicht ausreichen, so müsste ein zusätzlicher Weg geschaffen werden, über den ein sofortiges Update der PDP bewirkt werden kann (z.B. einen Notification-Mechanismus, über den der PAP den PDP kurzfristig zum Pull einer neuen Regelwerksversion auffordern kann).

Der PAP ermittelt die für den anfragenden Fachdienst geltenden PolicySets und übermittelt diesen Ausschnitt des Regelwerks an den PDP. Der PDP prüft die Integrität und Authentizität jedes PolicySets durch eine Signaturprüfung mithilfe des entsprechenden öffentlichen Schlüssels und verwendet erst nach einer erfolgreichen Prüfung das neue, abgefragte Regelwerk. Jede Version des Regelwerks wird zudem mit einem Aktivierungszeitpunkt versehen und wird von dem PDP erst ab diesem Zeitpunkt verwendet.

Abbildung 3.5.4-7: Datenflussdiagram für das Verteilen des Regelwerkes an die PDPs

Jedem Fachdienst werden ein oder mehrere PolicySets zugeordnet, die durch den PDP vom PAP abgefragt werden. Bei der Gestaltung des Regelwerks kann durch eine Verschachtelung von PolicySets dafür gesorgt werden, dass auch spätere Anpassungen in der Strukturierung des Regelsets möglich bleiben. So kann beispielsweise dem Fachdienst ePA grundsätzlich ein PolicySet "ePA" zugeordnet, dieses aber wiederum aus mehreren "Sub-PolicySets" (z.B. einem generischen PolicySet, einem PolicySet für alle Fachdienste, die medizinische Daten speichern, und einem PolicySet mit ePA-spezifischen Regeln) zusammengesetzt sein.

Die für das Regelwerk benötigten Soll-Attribute können je nach Regel entweder als Teil der Condition direkt in der Regel enthalten sein oder durch einen PIP für die Regelauswertung zur Verfügung gestellt werden.
Im ersten Fall, d.h. wenn die Soll-Attribute direkt in der Regel enthalten sind, erfolgt ein Update der Attribute immer als Teil eines Regelwerk-Updates und wird wie oben beschrieben vom PAP an die PDPs weitergegeben.
Wenn hingegen die Soll-Attribute durch einen PIP zur Verfügung gestellt werden, kann ein Update der gültigen Werte unabhängig von einem Update des gesamten Regelwerks direkt am jeweiligen PIP erfolgen. Die meisten Attribute werden dabei im Rahmen organisatorischer Prozesse (siehe Kapitel ) geändert. Die durch diese Prozesse definierten Soll-Attribute sollten versioniert und signiert werden, um am PDP die Aktualität, Integrität und Authentizität der verwendeten Informationen überprüfen zu können. Für manche Attribute kann (statt eines organisatorischen) ein automatisierter Prozess für die Festlegung der Referenzwerte durch das Monitoring über die in FA1.4 beschriebene Funktion definiert werden.

FA1.2 - Regelwerk überwachen

Abbildung 3.5.4-8: Datenflussdiagram für das Monitoring des Regelwerks

Um die Effektivität und Angemessenheit des Regelwerkes zu bewerten, findet ein Monitoring seiner Anwendung statt, bei dem alle Zugriffsentscheidungen in der ZTA erfasst und geloggt werden. Zu diesem Zweck werden vom PEP zu jeder Regelauswertung Informationen über die getroffenen Zugriffsentscheidungen übermittelt, d.h. welche Attribut-Ist-Werte im Rahmen der Zugriffsanfrage erhalten, welche Regelwerksversion verwendet und welche Entscheidung durch den PDP getroffen wurden. Die Informationen werden vom PEP dabei nur in anonymisierter Form, also insbesondere ohne Identifier wie UUID_Nutzer und UUID_Gerät, übertragen. Bei der Monitoring-Komponente werden die Zugriffsentscheidungen geloggt. Zudem analysiert die Monitoring-Komponente laufend die eingehenden Zugriffsentscheidungen, um signifikante Abweichungen von gelernten Erfahrungswerten zu erkennen (Anomaly Detection). Ein starkes Abweichen von etabliertem Normalverhalten, z.B. eine deutlich erhöhte Anzahl an abgelehnten Zugriffsentscheidungen wegen einer geltenden Regel, kann als Hinweis für einen Änderungsbedarf für das aktuell geltende Regelwerk dienen. Die geloggten Informationen können, wie in Funktion FA1.3 Regelwerk anpassen beschrieben, bei die Abstimmungsprozesse zu möglichen Regelwerksupdates unterstützen.

FA1.3 - Regelwerk anpassen

Um die Aktualität des Regelwerks sicherzustellen, wird das Regelwerk regelmäßig durch das zuständige Gremium begutachtet. Auslöser dieser Begutachtung kann entweder der Ablauf eines festgelegten Zeitraums seit der letzten Überprüfung sein (z.B. spätestens ein Jahr nach der letzten Überprüfung) oder ein durch das Monitoring gemeldeter möglicher Änderungsbedarf, z.B. wenn unverhältnismäßig viele Zugriffe wegen einer Regel abgewiesen werden. Die Beteiligten an Erstellung bzw. Update des Regelwerks können die gespeicherten Monitoring-Daten für die Bewertung möglicher Regeländerungen hinzuziehen. So können beispielsweise Informationen über tatsächlich verwendete Betriebssystemversionen helfen die Auswirkung einer Änderung der Soll-Werte abzuschätzen oder kaum verwendete Regelsätze identifiziert werden, die ggf. aus dem Regelwerk entfernt werden können. Änderungen werden im Rahmen der entsprechenden Governance-Prozesse beschlossen und anschließend wird eine neue Version des Regelwerks über den oben beschriebenen Prozess, FA1.1, an PAP, PDP und ggf. PIP verteilt.

Abbildung 3.5.4-9: Datenflussdiagram für ein Update des Regelwerkes durch organisatorische Prozesse 

FA1.4 - Attribute des Regelwerks anpassen

Neben den Anpassungen von Soll-Werten im Rahmen von Regelwerk-Updates bzw. durch entsprechende Governance-Prozesse gibt es auch Attribute, für die eine automatisierte Anpassung der Referenzwerte auf Basis aktueller Sicherheitsbetrachtungen sinnvoll ist. Ein Beispiel hierfür ist das Identifizieren von IP-Address-Ranges, aus denen unverhältnismäßig viele Anfragen an die Fachdienste gestellt werden.

Das Monitoring sammelt hierfür benötigte Informationen vom PEP ein und ist dafür zuständig, diese Informationen automatisiert zu bewerten und zu entscheiden, ob eine Änderung der Referenzwerte nötig ist. In diesem Fall ist das Monitoring verantwortlich für die Aktualisierung der Referenzwerte im PIP und das Loggen der getroffenen Entscheidungen und Änderungen (Change Log). Bei Bedarf (insbesondere beim Auswerten personenbezogener Daten und zur Erhöhung der Performance) findet am PEP bereits eine Vorverarbeitung (z.B. Aggregation oder Filterung) statt. Bereits vorhandene Informationen beim Monitoring (z.B. die Zugriffsentscheidungen aus FA1.3 Regelwerk anpassen) können ebenfalls in die Auswertung mit einfließen. Die Informationen für die automatisierte Anpassung von Referenzwerten werden nur über einen begrenzten Zeitraum verarbeitet und nicht längerfristig gespeichert.

Abbildung 3.5.4-10: Datenflussdiagram für ein automatisches Update von Soll-Attributen 

FA1.5 - Nutzerspezifische Regelwerkattribute anpassen

Bei der Erstellung des Regelwerks werden möglicherweise auch Attribute identifiziert, die von den Nutzungsgewohnheiten oder Präferenzen einzelner Nutzer abhängen. Beispiele hierfür sind die Definition von vertrauenswürdigen Orten und Zeiten für den Zugriff des Nutzers. Für derartige Attribute kann es schwierig sein, generische Soll-Werte zu definieren. Auch kann es die Effektivität von Regeln steigern nutzerspezifische Soll-Werte zu verwenden. Daher soll der Nutzer die Möglichkeit erhalten, über das Nutzerportal selbst Soll-Attribute zu definieren. Eine Speicherung und Abfrage der Werte im Rahmen der Regelauswertung kann z.B. beim zuständigen IDP, beim GMS oder bei einem dafür zuständigen PIP erfolgen. Die Konzeptionierung und Umsetzung der entsprechenden Funktionalität ist nicht Teil dieses Projektes.

3.5.5 Autorisierter Zugriff und Session Management

FA7 Autorisierter Zugriff

Zugriffe auf Ressourcen der ZTA müssen autorisiert und gegen ein Regelwerk geprüft werden. Die Prüfung der Anfrage erfolgt beim Policy Decision Point (PDP), welcher seine Entscheidung dem Policy Enforcement Point (PEP) zur Durchsetzung der Entscheidung mitteilt. Um die Anfragen korrekt gegen das Regelwerk prüfen zu können, müssen dem PDP alle relevanten Informationen aus der Anfrage zur Verfügung gestellt werden. Dazu erfasst der PEP alle notwendigen Informationen des aktuellen Zugriffs und übergibt sie gesammelt an den PDP. Dies schließt Informationen aus dem ID-/ oder Geräte-Token sowie der TLS/TCP/IP-Verbindung ein. Eine genauere Aufschlüsselung der Attribute und Informationsquellen wird im Kapitel  (Tabelle 3.3.1-1) diskutiert. Der PEP kann die Attributquellen filtern, um dem PDP nur die wirklich notwendigen Teile zugänglich zu machen. Beispielhaft können nur die relevanten Teile des ID-Tokens übertragen werden, aber der Nutzer-Identifier explizit ausgeschlossen. In einem ähnlichen Verfahren werden die Informationen ebenfalls dem Fachdienst zur Verfügung gestellt, damit dieser den Nutzer identifizieren kann. Damit kann der Fachdienst eigene Zugriffskontrollen implementieren.

In den folgenden beiden Abbildungen wird ein erfolgreicher Zugriff auf eine Ressource (Abb. 3.5.5-1), sowie die Zurückweisung einer nicht autorisierten Anfrage abgebildet (Abb. 3.5.5-2). Beide stellen beispielhaft einen durch den Nutzer angestoßenen Zugriff dar.

Abbildung 3.5.5-1: Erfolgreicher autorisierter Zugriff auf eine Ressource der ZTA

Der Zugriff in Abbildung 3.5.5-1 erfolgt durch Fach- und Trust-Client zum PEP (2), welcher in diesem Fall bereits alle notwendigen Informationen für den aktuellen Zugriff vorliegen hat oder selbständig abrufen kann (3a). Diese werden an den PDP zur Regelentscheidung übergeben (3b), welcher seine (in diesem Fall positive) Entscheidung dem PEP zurückgibt (3c). Anschließend reicht der PEP die Anfrage an den Fachdienst weiter (3d), zusammen mit den notwendigen Informationen, um den Nutzer identifizieren zu können. Nach einer Verarbeitung im Fachdienst, gibt der Fachdienst seine Antwort an den PEP zurück (3e), welcher sie an den Fach- und Trust-Client weiterreicht (4). Die Daten werden dann dem Nutzer angezeigt (5).

Abbildung 3.5.5-2: Zurückgewiesener Zugriff auf eine Ressource der ZTA

FA7.1 Session-Management

Die Zugriffe auf Ressourcen sollen auf Basis von Sessions erfolgen. Entsprechend der Definition in 3.1.3 Sessions, bildet eine Session eine etablierte Kommunikationsbeziehung eines Clients mit einem Fachdienst. Mit der Session sind alle notwendigen Informationen für den Zugriff assoziiert, um diese für zukünftige Anfragen innerhalb derselben Session wiederverwenden zu können.

Das Session-Management muss die Möglichkeit bieten, eine Session anzulegen und zu beenden, die Zugehörigkeit einer Anfrage zu einer Session zu prüfen und zugriffsrelevante Informationen mit den Sessions verknüpfen zu können (z.B. ID-Token, Geräte-Token). 

Die Session wird durch einen für den Client nicht weiter interpretierbaren Wert identifiziert. Der Client speichert diesen Wert und sendet ihn bei allen nachfolgenden Anfragen mit. Der Server wiederum legt den Wert zusammen mit dazugehörigen Nachweisen (ID-Token, Geräte-Token etc.) in einer Datenbank ab. 

Ein Spezialfall ist die Beendigung der Session, bei der der Server einen Backchannel-Logout gemäß der OIDC-Spezifikation ausführt, um dem IDP einen Logout zu signalisieren [OpenID-Connect_BCL]. Auch hier muss sicher OIDC-Client mittels mTLS gegenüber dem IDP authentisieren. Diese Spezifikation sieht ebenfalls vor, dass der IDP andere OIDC-Clients zu benachrichtigt. Alternativ wird der Logout bei der nächsten Verlängerung des ID-Tickets an den jeweiligen OIDC-Clients wirksam, da auch alle ID-Refresh-Token invalidiert werden. Um die aktiven Sessions für ein besseres Nutzererlebnis zu bündeln, ist es auch möglich ID-Token bei der Erstellung mit einen IDP-Spezifischen Session-Identifier zu versehen, der eine zusammenhängende Gruppe an Token identifiziert. Damit wäre beispielsweise umsetzbar, dass durch einen Logout alle Sessions auf dem gleichen Gerät geschlossen werden.

In Abbildung 3.5.5-3 sind diese drei zentralen Datenflüsse schematisch dargestellt.

Abbildung 3.5.5-3: Kernfunktionalitäten des Sessionmanagement (Anlegen, Erweitern, Beenden)