Telematikinfrastruktur 2.0

Feature:

Zero Trust

    

     

      
Version
      
1.0.1_CC
     
     

      
Revision
      
925986
     
     

      
Stand
      
07.06.2024
     
     

      
Status
      
zur Abstimmung freigegeben
     
     

      
Klassifizierung
      
öffentlich_Entwurf
     
     

      
Referenzierung
      
gemF_Zero-Trust
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

Dieses Dokument stellt eine übergreifende Spezifikation dar, ohne einen ersten konkreten Bezug zu einem Produkttypen oder zu Schnittstellen herzustellen. Anforderungen dieses Dokuments werden Produkttypen, Schnittstellen, Komponenten oder Diensten von konkreten Use Cases bzw. von Fachanwendungen zugewiesen.

Die in diesem Dokument beschriebenen Konzepte, Abläufe und Informationsmodelle dienen der Umsetzung der Paradigmen des Zero Trust in der "Telematikinfrastruktur 2.0".

Das Zero-Trust-Modell ist ein Sicherheitskonzept, das auf dem Prinzip strenger Zugriffskontrollen und dem grundsätzlichen Misstrauen (kein implizites Vertrauen) gegenüber jedem Kommunikationsteilnehmer beruht, selbst denen, die sich bereits innerhalb eines Netzwerkperimeters befinden. Es handelt sich um ein Sicherheitsrahmenwerk, das erfordert, dass alle Benutzer und deren Clients (Gerät und App), sowohl innerhalb als auch außerhalb der Netzwerkperimeter, authentifiziert, autorisiert und kontinuierlich auf ihre Sicherheitskonfiguration und Sicherheitsnachweise überprüft werden, bevor ihnen Zugriff auf Anwendungen und Daten gewährt oder dieser aufrechterhalten wird. Motiviert durch den „Assume Breach“-Ansatz basiert dieses Architekturdesign-Paradigma im Kern auf dem Prinzip der minimalen Rechte aller Entitäten in der Gesamtinfrastruktur.

1.1 Zielsetzung

Ziel des Dokuments ist die Sammlung der technischen, betrieblichen und testrelevanten Anforderungen an Clients, Backendservices, Produkttypen, Komponenten und Dienste, die sich untereinander über das Internet vernetzen, im Gegensatz zur bestehenden TI als geschlossenes VPN. Dieses Pattern wird bisweilen auch als TI 2.0 bezeichnet.

1.2 Zielgruppe

Dieses Dokument richtet sich an Architekten und Entwickler von Komponenten, Diensten, Produkttypen, Schnittstellen und Clients für den Datenaustausch im deutschen Gesundheitswesen.

1.3 Abgrenzungen

Diesem Dokument ist kein Produkt- oder Anbietertyp zuzuordnen. Anforderungen in diesem Dokument finden Anwendung in Produkt- und Anbietertypen von konkreten Fachanwendungen bzw. Use Cases.

1.4 Methodik

1.4.1 Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworten MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet. Die Schlüsselworte werden außerdem um Pronomen in Großbuchstaben ergänzt, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Anforderungen werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und Textmarke [<=] angeführten Inhalte.

2 Features und Epics

Der folgende Abschnitt gibt einen groben Überblick über die Features und Epics, die sich in Anwendungen wiederfinden, wenn sie nach dem Paradigma des Zero Trust umgesetzt werden. Diese Epics sind als Enabler zu verstehen, um Fachanwendungen einen sicheren Verbindungsaufbau zwischen Clientsystemen und Backenddiensten zu ermöglichen. Es werden keine User Stories formuliert, da für den Verbindungsaufbau keine Nutzerinteraktion angedacht ist.

Im Rahmen der Nutzeridentifikation (Authentifizierung) findet eine Verifikation ausgegebener Authentisierungsmerkmale statt, deren Nutzerinteraktion als Teil der Spezifikation des Identity Managements beschrieben sind.

2.1 Clientregistrierung

Gemäß des Zero Trust Ansatzes ist jeder Schnittstellenaufruf potentiell gefährlich, soweit nicht anders festgestellt. Dazu zählt auch das Vertrauen in bekannte bzw. Misstrauen in unbekannte Geräte bzw. Clients. Um Geräte bzw. Clients wiedererkennbar zu machen, soll eine Registrierung dieser erfolgen. Sind in der Registrierung zusätzliche Sicherheitsmerkmale über das Gerät und den Aufrufkontext feststellbar, stärken diese das Vertrauen in nachfolgenden Aufrufen fachlicher Schnittstellen.

2.1.1 Wiedererkennung bekannter Clients

Die Wiedererkennung bekannter Geräte und Clients und deren Bindung an identifizierbare Nutzer des Gesundheitswesens muss über eine Registrierung erfolgen. Die Identifikation des Nutzers erfolgt dabei über ein unterstütztes Identifikationsmerkmal (SmartCard oder digitale Identität) und einen selbstgewählten, vom System unterstützten zweiten Faktor (E-Mail, SMS, etc.).

2.1.2 Device Security Rating

Zum Einschluss bzw. Ausschluss bestimmter Eigenschaften von Geräten und Clients, sollen selbige einer automatischen Sicherheitsprüfung unterzogen werden können (DSR - Device Security Rating), soweit es die gegebenen Plattformmechanismen erlauben.

2.2 Policy Enforcement

Für den Zugriff auf personenbezogene und medizinische Daten und zur Sicherstellung der Integrität, Verfügbarkeit, Vertraulichkeit und Authentizität transportierter Daten gelten Regeln. Diese fachlichen, technischen und organisatorischen Regeln gelten bei jedem Zugriff auf Daten, die über eine Schnittstelle zugreifbar gemacht werden.

2.2.1 Zugriffsschutz

Das Policy Enforcement soll als eine Art Gatekeeper bzw. Türsteher den Zugriff auf Schnittstellen von Backendservices durch beliebige Clients durchsetzen. Grundlage ist das Vertrauen in eine Policy-Entscheidung durch eine Komponente zur Auswertung eines Regelwerks.

2.2.2 http Proxy

Nur und ausschließlich wenn ein Zugriffsversuch als legitim bewertet wird, soll dieser Zugriff gewährt werden, im Sinne des oben genannten Gatekeepers bzw. Türstehers muss dann auch ein Zugriffsversuch gewährt und an eine fachliche Schnittstelle weitergereicht werden.

2.3 Decide from Policies

Die Menge an Regeln für die Gewähr eines Zugriffs auf Daten oder Schnittstellen speist sich aus gesetzlichen Forderungen bzw. Verboten, Vertragskonstrukten, Sicherheitsmechanismen, Architekturentscheidungen und Informationen aus der "Umgebung" des Betriebs von Clients und Backendservices.

2.3.1 Maschinenlesbare Zugriffsregeln

Die Menge (potentiell) geltender Regeln zur Absicherung des Zugriffs auf Daten und Dienste formt ein Set von Policies. Um im Fall eines Zugriffsversuchs schnell entscheiden zu können, sollen diese Regeln maschinenlesbar definiert sein.

2.3.2 Ein reproduzierbares Ja/Nein/Vielleicht

Die Auswertung eines komplexen Regelwerks liefert bei identischen Eingangsparametern reproduzierbar das identische Ergebnis.

2.3.3 Policies nach Betroffenheit

Regeln beziehen sich auf verschiedene Aspekte einer Zugriffsentscheidung. Es gelten fachliche Regeln, Regeln zur Benutzung von Clients bzw. Geräten und ebenso technische Regeln sowie solche, die Betriebsumgebung von Backenddiensten betreffend.

2.4 Policy Information und Administration

Regeln können sich ändern und Regeln beeinflussen Regeln.

2.4.1 Policy Verwaltung

Eine Policyentscheidung kann Eingangsinformation für andere Policies sein, ebenso kann das Ändern von Rahmenbedingungen oder eine Anomalieerkennung zur Beeinflussung von Policies führen. Aus diesem Grund führen Beobachtungen über Policyentscheidungen zu Informationen über das Gesamtsystem, die als Eingangsdaten für nachfolgende Policyentscheidungen herangezogen werden. Daneben ist es erforderlich, Anpassungen am Regelwerk dem System über authentizitäts- und integritätsgeschützte Wege bekannt zu machen.

2.4.2 Monitoring

Durch ein Monitoring von Betriebsparametern und Telemetriedaten wird die Durchsetzung von Policies sowie die Auswirkung möglicher Policyänderungen transparent.

2.5 Client Authorization

Menschen benutzen Clients (Kombination aus Gerät und App). Jeder Zugriff auf Daten oder Schnittstellen wird auf eine menschliche Interaktion (Authentisierung) zurückgeführt. Nach Stand der Technik erfolgt die sichere Authentifizierung meist über 2 Faktoren. Zur Wiedererkennung und sicheren Identifikation werden Menschen und Clients Authentifizierungsmerkmale ausgestellt. Die sichere Identifikation und Authentifizierung ist eine wichtige Eingangsgröße für Zugriffsentscheidungen (s. o.).

2.5.1 Autorisierung auf Basis von Policy Entscheidungen

Die Autorisierung von Zugriffen auf Daten oder Schnittstellen wird bei positiver Entscheidung durch ein Set von Policies gewährt. Die Zugriffsentscheidung und -gewähr bettet sich in eine Verkettung von Informationen und von Aufrufen verschiedener Schnittstellen ein, die dem fachlichen Aufruf einer Schnittstelle bzw. Abruf von Daten voranstehen. Stand der Technik dieses Flows mehrerer Aufrufe und der dabei transportierten Informationen ist der OAuth2-Standard, vgl. [RFC6749 et al.].

2.5.2 Client Authentication

Menschen und Clients werden anhand sicherer Merkmale authentifiziert, die Identifikation ist nachrangig bzw. in nachgelagerten fachlichen Anwendungsfällen bzw. in fachlichen Zugriffsregeln relevant.

Kann ein Mensch oder Client nicht sicher authentifiziert werden oder wird der Authentifizierung zeitlich oder anderweitig nicht vertraut oder passen die Umgebungs- bzw. die den Aufruf begleitenden Parameter nicht zum Vertrauen in die Authentifizierung, wird eine erneute Authentifizierung als erforderlich angesehen ("Step-Up-Authentication").

3 Einordnung in die TI 2.0

Die TI 1.0 bildet eine Infrastruktur, deren Sicherheit auf der sicheren Zugangskontrolle zu einem geschlossenen zentralen Netzwerk mit Diensten beruht. In der TI 2.0 werden die Dienste direkt im Internet angeboten und bedürfen daher einem Schutz vor unberechtigtem Zugriff pro Dienst. Dieser Schutz wird nach dem Zero Trust Paradigma durch den Policy Enforcement Point und den Policy Decision Point durchgesetzt.

Diese übergreifende Spezifikation richtet Anforderungen an Akteure, die sich über das Internet miteinander vernetzen. Diese Akteure seien im Folgenden einerseits Clients (Software: Aufrufende einer Schnittstelle, Anfragende an einen Datenabruf oder -zugriff, wird auf einem bestimmten Gerät ausgeführt), häufig bedient durch einen Menschen, und Backendservices (Software: bereitstellende Schnittstelle, Datenbereitstellung etc.) auf der anderen Seite.

Zur Absicherung dieser Clients und Backendservices werden zum einen Anforderungen erhoben und wird eine Empfehlung gegeben, diese Anforderungen in konkreten Softwarekomponenten innerhalb dieser Akteure umzusetzen. Die Empfehlung zur Separierung der Zero Trust Mechanismen in unterschiedliche Komponenten folgt der Zero Trust NIST Referenzarchitektur, welche im Feinkonzept [gemKPT_Zero_Trust] vorgeschlagen und für passend befunden wurde.

Abbildung 1: NIST Zero Trust Referenzarchitektur

Im Architekturkonzept der TI 1.0 werden konkrete Umgebungsannahmen zu Consumer Zonen, Secure Consumer Zonen, Plattformzonen, Personal Zonen usw. getroffen, in denen kein (Personal Zone) bzw. ein gewisses Sicherheitsniveau (überall sonst) axiomatisch angenommen wird. Das Zero Trust Konzept löst sich von der Aufteilung in verschiedene Zonen, insbesondere, da weniger (teilweise gar keine mehr) TI-Plattform-Produkttypen zwischen den Datenaustauschen unter Clients mit Backendservices involviert werden. Im Folgenden ist eine Produkttypzerlegung für die Umsetzung der NIST-Referenzarchitektur einer generischen Fachanwendung dargestellt.

In diesem Pattern greift ein Nutzer über ein Clientsystem auf Daten eines TI 2.0 Dienstes zu. Das folgende Bild zeigt eine Übersicht der beteiligten Komponenten in der Vernetzung zwischen einem Clientsystem (links grün) und einem Backendservice (rechts grün: Ressource Server).

Abbildung 2 : Zero_Trust_Architektur_der_TI_2.0

Die obige Abbildung zeigt die Einbettung von Zero Trust bezogenen, logischen Komponenten (orange) in die Aufrufkette zwischen einem Client und einem Ressource Server (grün). Dargestellt sind zusätzlich heute bereits vorhandene und genutzte Komponenten und Dienste, die für die Nutzerauthentifizierung (z. B. eGK und IDP) bzw. die Betriebsüberwachung (z. B. mittels Betriebsdatenerfassung - kurz BDE) in Anwendungsfällen der TI 2.0 weitergenutzt werden können (grau). In diese Abbildung sind diverse Architekturentscheidungen eingearbeitet, die im Kapitel 4 und 5 erläutert bzw. spezifiziert werden.

Kurzbeschreibung der Komponenten und Schnittstellen

(1) und (6): Der http Proxy erlaubt den Zugriff auf Daten des Resource Servers, wenn ein gültiges Access token im Authorization Header enthalten ist.

(2), (2.1) und (2.2): sowie optional (2.3): Um ein Access token vom Authorization Server zu erhalten, ist eine Authentifizierung des Nutzers erforderlich.

(3): Der Authorization Server stellt nur ein Access token aus, wenn der PDP seine Erlaubnis gegeben hat.

(4a) und (4b): Der Authorization Server fordert bei mobilen Apps zusätzlich zur Nutzer-Authentifizierung eine Client Registrierung mit Geräte/App-Attestierung ein, bevor ein Access token ausgestellt wird. Bei stationären Clientsystemen (z. B. Primärsystem) erfolgt die Geräteregistrierung implizit bei der SM-B Authentisierung.

(5): Die Client Registrierung erfordert eine Bestätigung des Nutzers durch einen zweiten Faktor.

(7): Die Telemetrie-Daten der Komponenten des ZT Clusters werden an das Monitoring System des Betreibers übergeben.

(8.1) und (8.2): Der Resource Server und der optionale Application Authorization Server werden ebenfalls vom Monitoring überwacht.

(j9.1) und (9.2): Aus den Monitoring Daten werden die Daten der Betriebs-Daten-Erfassung gebildet und versendet.

(10.1) und (10.2): Wenn der Betreiber ein SIEM einsetzt, werden aus dem Monitoring SIEM Daten ermittelt und optional an das zentrale SIEM der gematik gesendet.

(11): Der PDP fragt regelmäßig den PIP und PAP Service nach neuen Policies und Daten ab.

(12): Der Cluster Management Service überwacht die Clusterkonfiguration und setzt durch, dass die im GitHub Repository gespeicherte Konfiguration ausgeführt wird.

4 Technisches Konzept

Im Kapitel zuvor wurden zwei Abbildungen vorgestellt, welche technischen Zero Trust-Komponenten (orange) an der Umsetzung fachlicher Anwendungsfälle von Clients, Komponenten und Backendservices von Fachanwendungen (grün) beteiligt sind. Im Folgenden werden diese technischen Komponenten genauer beschrieben und eingeordnet, welche Rolle sie in einer Architektur nach dem Zero Trust-Paradigma einnehmen.

Zero Trust in der TI zeichnet sich über folgende Eigenschaften aus:

• Registrierung des Clients (Gerät und App) zu einer Identität
• Attestation der Client-Eigenschaften
• Bereitstellung einer von Maschinen interpretierbaren Policy durch die gematik
• Einheitliches Durchsetzen der Policy durch die Fachdienste
• Sicherstellung des Sicherheitszustands der gesamten TI, Anbieter übergreifend
• Telemetrie und Monitoring

4.1 Zero Trust Cluster

Der Zero Trust Cluster (ZT Cluster) besteht aus Policy Enforcement Point (PEP), Policy Decision Point (PDP) sowie betriebsunterstützenden Komponenten (Cluster Management Service und Telemetrie Daten Service). Der PEP ist aufgeteilt in http Proxy, Authorization Server und Client Registry. Jeder TI 2.0 Dienst hat einen ZT Cluster zum Schutz des Dienstes vor unberechtigtem Zugriff. Der ZT Cluster wird in der Verantwortung des TI 2.0 Dienst-Betreibers betrieben.

4.2 Policy Enforcement Point (PEP)

Ein Policy Enforcement Point (PEP) ist eine Schlüsselkomponente im Zero Trust-Paradigma, der darauf abzielt, dass Sicherheitsmodell von einem vertrauensbasierten auf ein verifizierungsbasiertes umzustellen. Der PEP dient dazu, den Zugriff auf Ressourcen, basierend auf vordefinierten Richtlinien, zu kontrollieren und durchzusetzen. Im Kontext der TI 2.0 übernimmt der PEP folgende Funktionen:

• Der PEP agiert als http Proxy, der den Datenverkehr zwischen Clientanwendungen und den zu schützenden Ressourcen kontrolliert. Dadurch kann der PEP den gesamten Datenverkehr überwachen und filtern, um sicherzustellen, dass er den festgelegten Sicherheitsrichtlinien entspricht.

• Der PEP ist als vertrauenswürdige Relying Party im föderierten Identitätsmanagement registriert. Dadurch kann der PEP Identitätsinformationen von Benutzern sicher und vertrauenswürdig beziehen und bei Bedarf eine (erneute) Nutzer-Authentifizierung an die IDPs delegieren. Dadurch stellt der PEP sicher, dass nur authentifizierte Benutzer Zugriff auf die geschützten Ressourcen erhalten.

• Der PEP fungiert als OAuth2 Authorization Server und verwaltet die Autorisierung von Benutzeranfragen auf geschützte Ressourcen. Zudem überwacht der PEP die Benutzersessions, um sicherzustellen, dass sie gültig sind und den Sicherheitsrichtlinien entsprechen.

• Der PEP ermöglicht die dynamische Registrierung von Clients, die auf geschützte Ressourcen zugreifen möchten. Dies umfasst auch die Offband-Bestätigung, bei der zusätzliche Sicherheitsmechanismen (Verifikation via E-Mail oder SMS) verwendet werden, um die Identität und Integrität (plattformabhängig) der registrierten Clients zu überprüfen.

Insgesamt agiert der PEP als Kontrollpunkt in der Zero Trust Architektur, der sicherstellt, dass nur autorisierte Benutzer und Geräte Zugriff auf die Ressourcen eines Dienstes erhalten und dass dabei die definierten Sicherheitspolicies eingehalten werden. Die Entscheidung zwischen verschiedenen Policies auf Basis der vom Client übergebenen Signale, Sicherheitsnachweise und Token trifft der Policy Decision Point.

In der TI 2.0 ist der PEP Teil der Betriebsumgebung eines Fachdienstes einer Fachanwendung.

4.3 Policy Decision Point (PDP)

Ein Policy Decision Point (PDP) ist die wesentliche Komponente im Zero Trust-Paradigma, die Zugriffsentscheidungen auf Plattformebene trifft, indem sie Richtlinien (Policies) interpretiert und anhand dieser Richtlinien Zugriffsanfragen bewertet. Folgende Funktionen eines PDP sind dabei zentral:

• Der PDP analysiert und interpretiert die Sicherheitsrichtlinien, die im Rahmen des Zero Trust-Modells definiert sind. Diese Policies können Kriterien enthalten wie Benutzeridentität, Gerätetyp, Standort, Zeitpunkt der Anfrage und andere Kontextinformationen ("Signale"), die relevant für die Zugriffsentscheidung sind.

• Basierend auf der Interpretation der Policies trifft der PDP Entscheidungen darüber, ob eine Zugriffsanfrage auf eine bestimmte Ressource genehmigt oder abgelehnt wird. Diese Entscheidungen erfolgen auf Plattformebene, was bedeutet, dass der PDP die Zugriffsanfragen im Kontext der gesamten Plattform oder des Netzwerks bewertet, und nicht isoliert betrachtet. Die Zugriffsentscheidung resultiert dann in der Ausstellung eines Access Tokens, das für den konkret angefragten Zugriff verwendet wird (siehe Policy Enforcement).

• Der PDP verwendet dabei die Informationen, die ihm übermittelt werden, um die Zugriffsentscheidung zu treffen. Dazu gehören nicht nur die Policies selbst, sondern auch Echtzeitinformationen über den Zustand von Benutzeridentitäten, Geräten und andere Kontextinformationen, die für die Bewertung der Zugriffsanfrage relevant sind.

Durch die Analyse von Policies und die Bewertung von Zugriffsanfragen auf Plattformebene trägt der PDP dazu bei, sicherzustellen, dass nur autorisierte Benutzer und Geräte Zugriff auf geschützte Ressourcen erhalten.

4.4 Trust Client

Im Kontext von Zero Trust stellt der "Trust Client" eine logische Komponente innerhalb einer Clientanwendung (Primärsystem (PS), Frontend des Versicherten (FdV) etc.) dar, die im Rahmen des Zero Trust-Paradigmas als vertrauenswürdig eingestuft wird. Dies steht im Gegensatz zu der traditionellen Annahme, dass ein, eine Schnittstelle aufrufendes, Clientsystem automatisch als vertrauenswürdig betrachtet wird. Das Vertrauen in Clientanwendungen erwächst beispielsweise durch regelmäßige Softwareupdates, authentische und  verschlüsselte Kommunikation und die Verwendung von Zertifikaten, die die Einhaltung dieser Maßnahmen beweisen.

Ein Trust Client im Zero Trust-Modell wird nicht mehr blind als vertrauenswürdig angesehen, sondern muss genauso wie alle Komponenten im Netzwerk kontinuierlich authentifiziert und autorisiert werden. Selbst wenn ein Endpunkt als Trust Client eingestuft ist, bedeutet dies nicht, dass er ungehinderten Zugriff auf alle Ressourcen im Netzwerk hat. Stattdessen werden Zugriffsentscheidungen basierend auf aktuellen Richtlinien, Kontextinformationen, Bedrohungsinformationen und insbesondere in Kenntnis des diesen Client benutzenden Benutzers getroffen (s. u. Zusammenspiel mit Identity Provider (IdP)).

4.5 Policy Information und -Administration

Im Zero Trust-Paradigma spielen der Policy Information Point (PIP) und der Policy Administration Point (PAP) wichtige Rollen bei der Verwaltung und Durchsetzung von Sicherheitsrichtlinien bzw. Policies. Zusammen ermöglichen der PIP und der PAP eine zentrale Verwaltung und Bereitstellung von Policies im Zero Trust-Netzwerk.

Der PAP stellt Policies bereit und der PIP stellt die Daten für die Policies bereit, sodass sich aus beiden ein Regelwerk ergibt, das der PDP anwendet, um zu entscheiden, ob eine Kommunikationsanfrage zulässig ist.

4.5.1 Policy Information Point (PIP)

Der PIP ist für die Bereitstellung von Informationen über Sicherheitsrichtlinien zuständig. Er dient als zentraler Informationsdienst, der anderen Systemen und Komponenten im Zero Trust-Netzwerk Zugriff auf aktuelle Sicherheitsrichtlinien ermöglicht. Der PIP kann Attribute wie Benutzerrollen, Zugriffsrechte, Gerätezustände und andere Kontextinformationen bereitstellen, die von anderen Komponenten für die Zugriffsentscheidung benötigt werden. Der PIP kann Daten aus verschiedenen Quellen beziehen, einschließlich einer zentralen Richtliniendatenbank, externen Identitätsanbietern, Sicherheitsinformationen von Geräten und anderen Quellen.

4.5.2 Policy Administration Point (PAP)

Der PAP ist für die Verwaltung und Konfiguration von Sicherheitsrichtlinien verantwortlich. Er bietet eine Schnittstelle oder eine Konsole, über die Richtlinien in hoheitlicher Verantwortung definiert, geändert und gelöscht werden können. Policy-Administratoren können im PAP Zugriffsregeln, Autorisierungsniveaus, Bedrohungsabwehrmaßnahmen und andere Sicherheitsrichtlinien festlegen. Der PAP ermöglicht es Policy-Administratoren, Richtlinien - basierend auf verschiedenen Kriterien wie Benutzerrollen, Gruppenzugehörigkeit, Standorten und Geräteattributen - zu differenzieren. Änderungen an den Sicherheitsrichtlinien, die im PAP vorgenommen werden, werden an den PIP weitergegeben, damit andere Komponenten im Zero Trust-Netzwerk auf die aktualisierten Richtlinien zugreifen können. Das Vertrauen in bereitgestellte und angepasste Policies wird über Signaturen für die Sicherstellung von Integrität und Authentizität jeder Policy sichergestellt.

4.6 Clientregistrierung

Alle Clients, die mit Diensten der TI2.0 kommunizieren, sind zur Laufzeit bekannt. Mit einer Attestierung in Abhängigkeit der verfügbaren Mechanismen der Laufzeitumgebung (Geräte-Features, Betriebssystem) kann ein Vertrauen und eine Wiedererkennung von Clients und Geräten aufgebaut werden.

Die folgenden statischen Eigenschaften werden im Rahmen der Bereitstellung von Clientanwendungen erfasst und sind unabhängig von der Nutzung durch einen konkreten Benutzer.

Tabelle 1: Statische Eigenschaften Clientsysteme auf Hersteller-/Herausgeber-/Anbieterebene

Bei der Registrierung werden die statischen Eigenschaften eines Client-Systems für jede Client-Instanz mit einem vom Client-Nutzer signierten Softwarestatement bekannt gemacht. Durch die Registrierung bekommen die Clients eine kryptographische Identität und werden Server-seitig an den Nutzer gebunden. Der Nutzer muss bei der Registrierung eine TI-Identität vorweisen, z. B. GesundheitsID oder SM-B (über IDP-Dienst der gematik).

Zur Laufzeit werden die Client-Eigenschaften durch Client-Instanz-Eigenschaften ergänzt. Sie sind spezifisch für eine konkrete Installation auf einem bestimmten Gerät eines Benutzers. Sie sind insofern dynamisch, als dass sich der Patchlevel des Betriebssystems oder sich die Version der Clientinstanz durch Updates verändern kann.

Tabelle 2 : Eigenschaften Clientsysteme auf Instanzebene (pro Installation

Die Auskünfte bzw. Attestation von Clientsoftware und Geräten werden von einer Backendschnittstelle für die Clientregistrierung geprüft. Zusätzlich wird über diese Schnittstelle eine Offband-Verifikation des Benutzers durchgeführt, beispielsweise über Bestätigungscode oder -link via E-Mail. Ist die Clientregistrierung erfolgreich, wird der Client-Instanz(!) ein Nachweis über die attestierten Client- und Client-Instanz-Eigenschaften ausgestellt. Dieser Nachweis ist in folgenden Aufrufen von Schnittstellen der TI Teil der Zugangsprüfung.

Die Geräteattribute werden von den Plattformen der Endgeräte geliefert. Ihre Erhebung erfolgt im TrustClient des Endgeräts mittels plattformspezifischer Attestierungs- und Erhebungsmechanismen (siehe [Apple Platform Security Guide] und [Android Platform Security Model]). Die Attribute sind daher für die jeweilige Plattform und ihr Sicherheitsmodell spezifisch. Die für die Zugriffsentscheidung verwendeten Attribute werden daher im Folgenden für iOS-Geräte separat von denen für Android-Geräte aufgeführt.

Android

Tabelle 3: Verwendete Device Claims für Android-Geräte

iOS

Tabelle 4: Verwendete Device Claims für iOS-Geräte

4.7 Monitoring

Das Monitoring im Kontext von Zero Trust ist ein entscheidender Aspekt, um die Sicherheit des Netzwerks und der Ressourcen kontinuierlich zu überwachen und potenzielle Bedrohungen oder Anomalien zu identifizieren. Dieses bedient sich auch eines Security Information and Event Management (SIEM) und Shared Signals, die zukünftige Policyentscheidungen beeinflussen, in dem Erkenntnisse des Monitorings über den Policy Information Point den Policy Decision Points der verschiedenen Fachanwendungen verfügbar gemacht werden.

Insgesamt ermöglicht das Monitoring im Kontext von Zero Trust eine kontinuierliche Überwachung der Sicherheitslage, indem es aktuelle Sicherheitsrichtlinien berücksichtigt, potenzielle Bedrohungen identifiziert und auf Shared Signals zurückgreift, um umfassende Sicherheitseinblicke zu erhalten.

4.7.1 Security Information and Event Management (SIEM):

SIEM-Systeme spielen eine zentrale Rolle im Monitoring im Zero Trust-Paradigma. Sie sammeln Daten aus verschiedenen Quellen wie Protokollen, Ereignissen und Alarmen von Sicherheitskomponenten im Netzwerk. Durch die Analyse dieser Daten in Echtzeit können SIEM-Systeme potenzielle Sicherheitsvorfälle erkennen und Anomalien identifizieren. SIEM-Systeme können auf die vom PIP bereitgestellten Sicherheitsrichtlinien zugreifen und sicherstellen, dass die Überwachung entsprechend den aktuellen Richtlinien erfolgt. Anbieter von Betriebsleistungen mittels Produkttypen der TI (1.0) erhalten durch eine Anbieterzulassung die Auflage, Anforderungen an ein [ISMS] zu erfüllen. Hierfür können sie bspw. SIEM-Systeme oder Intrusion Detection Systeme (IDS) verwenden. In der Weiterentwicklung zur TI 2.0 wird dieses Konzept fortgeführt, und finden die so gesammelten Informationen über den Sicherheitszustand eines Systems wieder Eingang in Zugriffsentscheidungen eines Policy Decision Points.

4.7.2 Shared Signals

Shared Signals sind Hinweise oder Indikatoren für Sicherheitsvorfälle, die von verschiedenen Systemen und Quellen im Netzwerk gemeinsam genutzt werden. Diese Signale können von verschiedenen Sicherheitskomponenten wie Firewalls, Endpunktschutzsystemen, Intrusion Detection Systems (IDS) und anderen generiert werden.

SIEM-Systeme aggregieren und korrelieren diese Signale, um umfassende Einblicke in die Sicherheitslage des Netzwerks zu erhalten und potenzielle Bedrohungen zu identifizieren. Durch die Integration von Shared Signals in das Monitoring kann eine umfassende und ganzheitliche Sicherheitsüberwachung gewährleistet werden, die potenzielle Angriffe frühzeitig erkennt und darauf reagiert.

4.7.3 Telemetrie, Monitoring und Logging

Betriebliche Daten zum Zwecke des Monitorings (Telemetrie) werden von den Zero Trust Komponenten erhoben und für die eingesetzten Zero Trust Komponenten übergreifend in einer gesicherten Monitoring-Komponente erfasst. Bei der Nachbereitung der Telemetriedaten werden personenbezogene oder-beziehbare Daten anonymisiert, um diese bereinigten Daten dem Betreiber regelhaft zugänglich zu machen. Das bereinigte Monitoring-Log kann von dem Betreiber für sein eigenes betriebliches Monitoring und als Quelle für sein SIEM-System verwendet werden. Das bereinigte Monitoring-Log wird unter Anderem zur Generierung von Rohdatenlieferungen und Bestandsdaten für die gematik benutzt. 

4.8 Zusammenspiel mit IdP

Im Zero Trust-Paradigma arbeiten der PEP und der IdP zusammen, um den Zugriff auf Ressourcen - basierend auf den definierten Sicherheitsrichtlinien und der Benutzeridentität - zu kontrollieren. Das Stichwort "Step-up-Authentifizierung" bezieht sich auf eine Sicherheitsmaßnahme, bei der der Benutzer zusätzliche Authentifizierungsschritte durchlaufen muss, um auf sensible Ressourcen zuzugreifen. Diese Maßnahme wird wie folgt realisiert:

1. Zugriffsanfrage des Benutzers: Ein Benutzer möchte auf eine geschützte Ressource zugreifen und sendet eine Zugriffsanfrage an den PEP.
   
2. Überprüfung durch den PEP: Der PEP empfängt die Zugriffsanfrage und überprüft die http Header-Daten. Dies kann bedeuten, dass der PEP feststellt, dass die Zugriffsanfrage eine höhere Sicherheitsstufe erfordert als die Standardauthentifizierungsmethode des Benutzers. Oder der Authentifizierung wird nicht mehr vertraut, da sie zu weit in der Vergangenheit liegt.
   
3. Weiterleitung an den IDP: Falls eine Step-up-Authentifizierung erforderlich ist, löst der PEP die Zugriffsanfrage an den IDP aus, der für die Authentifizierung des Benutzers zuständig ist.
   
4. Step-up-Authentifizierung: Der IDP erkennt die Anforderung für eine Step-up-Authentifizierung und fordert den Benutzer auf, zusätzliche Authentifizierungsschritte durchzuführen. Dies könnte beispielsweise die Eingabe eines Einmalpassworts, die Verwendung von Biometrie oder die Bestätigung über ein zweites Gerät sein.
   
5. Authentifizierungsbestätigung: Nach erfolgreicher Durchführung der Step-up-Authentifizierung bestätigt der IDP die Identität des Benutzers gegenüber dem PEP.
   
6. Zugriffsgewährung durch den PEP: Der PEP erhält die Authentifizierungsbestätigung vom IDP und gewährt dem Benutzer basierend auf den Sicherheitsrichtlinien Zugriff auf die angeforderte Ressource.
   

Das Zusammenspiel zwischen PEP und IDP ermöglicht es, den Zugriff auf sensible Ressourcen - basierend auf der aktuellen Sicherheitslage und der Identität des Benutzers - zu steuern. Die Step-up-Authentifizierung stellt sicher, dass zusätzliche Sicherheitsmaßnahmen - wenn erforderlich - ergriffen werden, um die Integrität und Vertraulichkeit der geschützten Daten zu gewährleisten.

4.9 Fachdienst-Backend

Das Fachdienst-Backend stellt das Ziel jedes Zugriffswunschs eines Nutzers über sein Clientsystem dar. Es stellt fachliche Schnittstellen zur Nutzung durch Clientsysteme dar, die über die Mechanismen des Zero Trust abgesichert werden. 

5 Spezifikation

Dieses Kapitel beschreibt die technische Umsetzung der beschriebenen Konzepte an die oben eingeführten Komponenten des Zero Trust (Zero Trust-Komponenten) als generische Produkt- und Anbietertypen. Diese Anforderungen finden Anwendung in den Steckbriefen von konkreten Produkt- und Anbietertypen der jeweiligen Fachanwendung und erhalten erst in der dortigen Zuordnung ein konkretes Prüfverfahren.

5.1 Übergreifende Anforderungen für Datenschutz und Sicherheit

Hinweis: Für die Kategorisieren von Angriffen ist eine Kategorisierung nach "CAPEC: OWASP Related Patterns"[CAPEC OWASP] zu verwenden.

Hinweis: Eine Eingabe-Validierung von Fachdienst APIs erfolgt im Fachdienst und nicht in den Zero Trust-Komponenten. 

Hinweis: Die Anforderung ist besonders wichtig, falls die Zero Trust-Komponente in einer VAU betrieben wird. Die Bereitstellung der Daten soll in das betriebliche Rohdaten-Log erfolgen.

5.1.1 Sicherheits- und Datenschutzanforderungen an Logging und Monitoring

Hinweis: Die Anforderungen dieses Abschnitts könnten sich noch ändern, falls sich bei der Umsetzung des Zero Trust herausstellt, dass weitere Protokollierungen auf Seiten des Betreibers notwendig werden.

Hinweis: Sicherheitsrelevante Daten sind zum Beispiel, Kryptoschlüssel, Access/Refresh Token usw.

5.1.2 Sicherheits- und Datenschutz-Anforderungen an das Security Monitoring

Das SIEM, Plattform-Monitoring und Shared Signals bilden das Security Monitoring von Zero Trust ab.  Die folgenden Anforderungen beschreiben die Fähigkeiten des Security Monitorings und welche Ereignisse erkannt werden sollen.

Hinweis: Impossible Travel ist eine Methode zur Anomalieerkennung in der Cybersicherheit, die potenzielle Kompromittierungen identifiziert, indem sie Benutzeranmeldeaktivitäten analysiert und mit geografischen Standorten korreliert. Dabei werden Fälle markiert, in denen auf das Benutzerkonto innerhalb eines verdächtig kurzen Zeitraums aus zwei verschiedenen Ländern zugegriffen wird.

Der Fachdienst kann eine Missbrauchserkennung implementieren. Dabei werden mögliche Angriffe und Anomalien innerhalb der Anwendungslogik erkannt (z. B. falsche/manipulierte Metadaten für Dokumente in der elektronischen Patientenakte (ePA)) und an das SIEM System gemeldet.

Hinweis: Mit dem Signal erhält der PEP die Information, dass sich eine Eigenschaft der aktuellen Session geändert hat. Der PEP sperrt automatisch das aktuelle Access Token, sodass der Client ein neues Access Token beim Authorization Server abfragen muss. Die Abfrage des neuen Access Token beinhaltet immer eine Entscheidung durch den PDP.

Hinweis: Security KPIs beinhalten anonyme Daten und sind nicht auf individuelle Nutzer zurückzuführen. 

Hinweis: Netzwerk-Protokoll-Anomalien sind z.B. ungewöhnliche Netzwerk-Aktivitäten, Netzwerk-Protokoll-Aktivitäten oder die Manipulation von Netzwerk-Paketen. 

5.1.3 Sicherheits- und Datenschutz-Anforderungen an die Verarbeitung von Daten mit dem Schutzbedarf "sehr hoch"

Falls der ZT Cluster Daten mit dem Schutzbedarf „sehr hoch“ verarbeitet und der Betreiber keine Kenntnis über die in dem ZT Cluster verarbeiteten Daten erlangen darf, gibt es Sonderanforderungen, um die Daten während der Verarbeitung zu schützen.

Hinweis: Ein Beispiel dafür wäre eine Art Plattform Attestierung, die eine Manipulation von Images erkennen und ausschließen kann.

5.1.4 Sicherheits- und Datenschutz Anforderungen an dem Trust Client

Hinweis: Nicht anwendbar können zum Beispiel sein: O.Paid .. Die Anwendbarkeit ist zwischen Hersteller des Trust Clients und dem Gutachter zu klären. Der Gutachter gibt sein Votum über die Erfüllung der BSI [TR-03161] in Form der Bewertung der Erfüllung der A_25802  ab, wobei die A_25802 als „umgesetzt“ bewertet werden kann, wenn die anwendbaren Prüfaspekte der BSI [TR-03161] aus Sicht des Gutachters erfüllt sind. 

5.2 Anforderungen an Clientsysteme

Ein Clientsystem ist eine Softwarekomponente in der Verwendung eines Benutzers zum Ausführen fachlicher Anwendungsfälle z.B. als Primärsystem (PVS, AVS, LIS, KIS etc.) oder als Frontend des Versicherten (ePA-App, E-Rezept-App, TI-Messenger etc.). Dieses Clientsystem wird dem Benutzer durch einen Hersteller bzw. Herausgeber zur Verfügung gestellt.

5.2.1 Hersteller und Herausgeber

5.2.2 Verbindungsaufbau

5.2.3 Clientregistrierung

Hinweis: Perspektivisch werden weitere Attestierungsmechanismen für Clientsysteme aufgenommen, z. B. FIDO2, TPM2.

5.2.4 Nutzerauthentifizierung

Hinweis: Perspektivisch sollen Clientsysteme auch OpenID for Verifiable Credentials (OIDC4VC) unterstützen.

5.2.5 Session Management

5.3 Zero Trust Cluster

Die Software des Zero Trust Clusters wird im Auftrag der gematik entwickelt und als signierte Docker Container in einer gematik Container Registry sowie mit Kubernetes Manifest Dateien in einem gematik GitHub Repository bereitgestellt, sodass die Betreiber von TI 2.0 Diensten ihren spezifischen ZT Cluster darauf aufbauend als Kubernetes Cluster konfigurieren können. Die ZT Cluster-Konfiguration muss in ein GitHub Repository der gematik als git submodule verlinkt werden. Der Cluster Management Service des Zero Trust Clusters setzt durch, dass nur die im gematik GitHub Repository verlinkte ZT Cluster Konfiguration ausgeführt werden kann. Dadurch ist es möglich, dass der Betreiber seine Cluster-Konfiguration selbständig anpassen und die gematik den korrekten Einsatz des ZT Clusters prüfen kann.

Hinweis: Für die Anpassung und Inbetriebnahme von geänderten ZT Cluster Konfigurationen ist ein Continuous Delivery Prozess mit Quality Gates vorgesehen, der sich noch in der Entwicklung befindet.

5.4 Anforderungen an Policy Enforcement Points

Der Policy Enforcement Point (PEP) stellt die zentrale Sicherheitskomponente einer Zero Trust Architektur dar, da in dieser alle Zugriffsentscheidungen durchgesetzt (engl.: enforce) werden. Gemäß oben vorgeschlagener Architekturzerlegung, empfiehlt es sich, den PEP in mehreren Teilkomponenten zu realisieren.

Mit der Registrierung an der Komponente Client Registry werden von Nutzern verwendete Clients (Gerät/App Kombinationen) identifizierbar gemacht und können an ausgegebene Zugriffstoken gebunden werden. Über einen Authorization Server kann im PEP eine Benutzersession angelegt und verwaltet werden, über die eine mögliche Veränderung von Sessionparametern (verwendetes Gerät/App, Zugriffsfrequenz) beobachtet werden kann, um nach Bedarf zusätzliche Sicherheitsmechanismen aktivieren zu können (Step-Up-Authentication, Throttling etc.). Ist ein Zugriff zu gewähren, wird der Nutzer-Request über einen http Proxy an das angefragte Resource Backend weitergeleitet.

5.4.1 PEP Client Registry

Hinweis: Wie Clients ihre Push Konfiguration in den PEP eintragen können, wird in einer Folgeversion des vorliegenden Dokuments festgelegt.

Hinweis: der Client muss danach ein neues Access Token beim Authorization Server abfragen. Die Abfrage des neuen Access Token beinhaltet immer eine Entscheidung durch den PDP. 

5.4.1.1 Sicherheits- und Datenschutz-Anforderungen an dem PEP Client Registration

Hinweis: Der Nutzer kann z.B. durch eine geeignete E-Mail oder App-Notifikation über die sicherheitsrelevanten Ereignisse informiert werden.

5.4.2 PEP Relying Party

5.4.3 PEP Authorization Server

5.4.3.1 Service Discovery

Der Authorization Server ermöglicht Clients die Ermittlung der bereitgestellten Endpunkte durch Abfrage des Well-known json Dokuments unter http GET /.well-known/oauth-authorization-server. Wenn der FQDN des Authorization Servers nicht bekannt ist, kann das Well-known json Dokuments abgefragt werden, indem ein Endpunkt des Resource Servers ohne gültiges access token aufgerufen wird. Im body der http 401 Response ist das Well-known json Dokument enthalten.

Hinweis: Der FQDN des Authorization Servers wird vom Anbieter des TI 2.0 Dienstes vergeben.
Die unterstützten OpenID Provider sind in der PU https://idp.app.ti-dienste.de/directory/fed_idp_list  und in der RU https://idp-ref.app.ti-dienste.de/directory/fed_idp_list.

Beispiel Well-known json Dokument des Authorization Servers:
{
  "issuer": "https://zerobin.zt.dev.ccs.gematik.solutions",
  "authorization_endpoint": "https://zerobin.zt.dev.ccs.gematik.solutions/auth",
  "token_endpoint": "https://zerobin.zt.dev.ccs.gematik.solutions/token",
  "jwks_uri": "https://zerobin.zt.dev.ccs.gematik.solutions/jwks",
  "nonce_endpoint": "https://zerobin.zt.dev.ccs.gematik.solutions/nonce"
  "openid_providers_endpoint": "https://idp.app.ti-dienste.de/directory/fed_idp_list"
  "scopes_supported": [
    "zero:register",
    "zero:manage"
  ],
  "response_types_supported": [
    "code"
  ],
  "response_modes_supported": [
    "query"
  ],
  "grant_types_supported": [
    "authorization_code"
  ],
  "token_endpoint_auth_methods_supported": [
    "none"
  ],
  "token_endpoint_auth_signing_alg_values_supported": [
    "ES256"
  ],
  "service_documentation": "https://gihub.com/gemazik/zero-lab",
  "ui_locales_supported": [
    "de",
    "en"
  ],
  "code_challenge_methods_supported": [
    "S256"
  ]
}

5.4.3.2 Ablauf der SM-B Authentifizierung mit DPoP

Die SM-B Authentifizierung wird für Nutzer und Clients angeboten, die nicht über andere geeignete Credentials verfügen, um sich als berechtigte TI-Teilnehmer auszuweisen. Die Authentifizierung erfolgt gemäß OAuth2 Client Authentifizierung [RFC7523] mit SM-B signiertem Client Assertion JWT. Replay-Attacken werden durch die Aufnahme einer server-generierten Nonce als JTI Claim in der Client-Assertion verhindert.

Abbildung 3 SM-B_Authentisierung_mit_DPoP

Schritt (1) bis (4) dienen dazu die Endpunkte des Authorization Servers zu ermitteln. Wenn der FQDN des Authorization Servers noch nicht bekannt ist, dann versucht der Client in Schritt (1) auf Daten des Resource Servers zuzugreifen. Die Anfrage wird vom http Proxy mit http 401 Unauthorized abgelehnt und der Client erhält das Well-known json Dokument mit den Endpunkten des Authorization Servers. Alternativ kann bei bekanntem FQDN des Authorization Servers das Well-known json Dokument direkt abgefragt werden (Schritte (3) und (4)).

Im Schritt (05) generiert der Client ein ephemeres key pair für DPoP ([RFC9449]). DPoP stellt kryptografisch sicher, dass Access token, die für diesen Client vom Authorization Server ausgestellt wurden, auch nur von diesem Client verwendet werden können.

{
     "crv": "P-256",
     "kty": "EC",
     "x": "...",
     "y": "...",
     "d": "..."
} 

Zur Abwehr von Replay-Attacken wird in Schritt (06) eine server-generierte Nonce abgefragt.

HEAD /nonce http/1.1
Host: as.example.com
 
http/1.1 200 OK
new-nonce: ...Nonce from the AS...

Danach erzeugt der Client in Schritt (08) bis (13) das Client Assertion JWT, in dem auch Informationen über das Gerät, das Betriebssystem und die App (PS) enthalten sind. Das JWT wird mit der SM-B signiert. Im Attribut "jkt" ist der Hash des öffentlichen Schlüssels des Client DPoP Keys enthalten.

{
    "nonce": "...Nonce from the AS...",
    "iss":"urn:telematik:telematik-id:9-123456789", // Telematik ID from X.509 certificate
    "sub":"...Client ID...",
    "aud":"https://as.example.com", // AS URL
    "iat":1562262611,
    "exp":1562266216,
    "cnf": {
        "jkt":"..thumbprint of the DPoP key..."
    },
    "urn:telematik:client-self-assessment": {
        "product_id": "PS-000",
        "product_version": "0.5.0",
        "manufacturer_id": "HRST-001",
        "platform": "software"
        "runtime": {
            "os": "Microsoft Windows",
            "os_version": "10.0.19045.4291",
            "os_arch": "x86",
        },
}

Der Client erzeugt in Schritt (14) das DPoP Proof JWT, in dem die nonce enthalten ist.

{
  "typ":"dpop+jwt",
  "alg":"ES256",
  "jwk": {
    "kty":"EC",
    "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
    "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA",
    "crv":"P-256"
  }
}
.
{
  "jti":"-BwC3ESc6acc2lTc",
  "htm":"POST",
  "htu":"https://server.example.com/token",
  "nonce":"...nonce from the AS..."
  "iat":1562262616
}
.
ES256 signature of the DPoP JWT

In Schritt (15) wird ein POST /token Request gesendet, um Access token und Refresh token zu erhalten.

POST /token HTTP/1.1
Host: as.example.com
 
grant_type=authorization_code&
code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
client_assertion=...JWT Assertion signed by SM-C...

Der Authorization Server prüft die im Request übergebenen Client Assertion JWT und DPoP JWT (16) und erzeugt oder aktualisiert den Eintrag für den SM-B Nutzer und seine App in der Client Registry (17).

Wenn ein gültiges Refresh token vorhanden ist, dann kann der Client anstatt der Schritte (06) bis (17) den Schritt (18) nutzen, um das Refresh token gegen ein neues Access token und ein neues Refresh token einzutauschen. Das alte Refresh token wird geprüft (19) und verliert sofort seine Gültigkeit (20).

In Schritt (21) und (22) wird durch den PDP die Entscheidung getroffen, ob die vom Client übergebenen Header-Daten hinreichend sind, um dem Authorization Server zu erlauben, für den Client neue Access und Refresh token auszustellen. Wenn ein Refresh token verwendet wurde, übergibt der Authorization Server zusätzlich Daten aus dem Eintrag in der Client Registry an den PDP.

Wenn die Erlaubnis erteilt wurde, stellt der Authorization Server neue Access und refresh token mit DPoP Binding aus (23) und sendet sie an den Client (24).

HTTP/1.1 200 OK
Content-Type: application/json
 
{
    "access_token": "...",
    "token_type": "DPoP",
    "expires_in": 3600,
    "refresh_token": "...",
    "scope": "..."
}

Inhalt des Access token

{
    "alg": "ES256",
    "kid": "...",
}
.
{
    "iss": "https://as.example.com",
    "sub": "...Client ID...",
    "aud": "...Client ID...",
    "exp": 1562266216,
    "cnf": {
        "jkt": "...thumbprint of the DPoP key..."
    }
}
.
ES256 signature of the access token

Der Client erzeugt ein neues DPoP Proof JWT für den Zugriff auf Daten des Resource Servers (25) und sendet Request, mit Access token und DPoP Proof im Header, an den Resource Server.

Der http Proxy prüft das Access token und das DPoP Binding (27) und leitet, wenn diese gültig sind, den Request an den Resource Server weiter (28).

Der Resource Server empfängt den Request, führt seine Fachlogik aus (29) und sendet eine Antwort an den http Proxy (30), der diese an den Client weiterleitet (31).

5.4.4 PEP http Proxy

Die Komponente http Proxy ist die "letzte" vor das Resource Backend geschaltete Zero Trust-Komponente und prüft das Access token im Authorization Header des Requests. Ist das Access token gültig, wird der Zugriff gewährt. Zudem wird der Request um zusätzliche http-Header angereichert, um ein Tracing zu ermöglichen.

5.4.5 Sicherheits- und Datenschutz-Anforderungen an dem PEP

5.4.6 Konfiguration

Hinweis: Weitere Konfigurationsparameter werden zusammen mit dem Zero Trust Hersteller festgelegt und hier ergänzt.

5.5 Anforderungen an den Policy Decision Point

Der PDP implementiert einen [Open Policy Agent] (OPA). Die Policies und die zugehörigen Daten erhält der PDP per Download vom PIP und PAP Service. Aus den Input-Daten vom PEP, den Daten vom PIP und den Policies vom PAP ermittelt der PDP eine Entscheidung und gibt diese zurück an den PEP.

Neben der OPA Instanz, die die Entscheidung für den PEP trifft (aktive Instanz), ob eine Kommunikation zulässig ist, implementiert der PDP noch eine zweite OPA Instanz, die mit einem zweiten OPA Bundle vom PIP und PAP Service arbeitet, aber die getroffenen Entscheidungen nicht an den PEP zurück gibt. Diese Instanz wird Simulations-Instanz genannt.

Hinweis: Änderungen an der Konfiguration sind im Einvernehmen mit der gematik möglich.

Der OPA aktualisiert seine Policies und Daten nach dem vorgegebenen Polling-Intervall. Jede Download Anfrage enthält immer ein If-None-Match Header mit dem hash des zuletzt heruntergeladenen bundles (aus dem ETag Header der Response). Wenn es keine neuen Daten zum Download gibt, dann beantwortet der PIP/PAP Service die Anfrage mit 304 Not Modified.

Die Bundles sind immer signiert. Der OPA prüft die Signatur mit dem zur konfigurierten keyid passenden Schlüssel. Gültige Schlüssel und deren keyid werden über einen Continuous Delivery Workflow aus GitHub geladen.

Die decision logs werden an die vom Betreiber des PDP festgelegte URL gesendet.

5.6 Anforderungen an den PIP und PAP Service

Der PIP und PAP Service stellt OPA Bundles für die PDP Instanzen der Zero Trust Cluster der Dienste der TI 2.0 bereit. 

Hinweis: Die Bereitstellung der Test-Instanz erfolgt nur während einer Testphase und kann eine andere Version der [pip-pap-service.yaml] unterstützen. Für die Entwicklung und Tests anderer Komponenten wird empfohlen, die Referenz-Instanz zu verwenden.

Hinweis: Siehe [pip-pap-service.yaml]. Unter dem label "latest" werden Bundles für den aktiven PDP bereitgestellt. Unter dem label "latest-sim" werden Bundles für die Simulations-PDP Instanz bereitgestellt.
Der PIP und PAP Service bezieht die OPA Bundles aus einem GitHub Repository der gematik. Die Bundles werden in einem GitOps CI Prozess mit Quality Gates entwickelt und für die PDPs der Zero Trust Cluster bereitgestellt.

Hinweis: Durch die Verwendung des Hashwertes der bundle.tar.gz Datei als ETag wird es möglich, den Download-Endpunkt auf mehrere Server zu verteilen. Wichtig ist nur, dass das ETag auf allen Servern gleich ist, damit bereits erhaltene OPA Bundles nicht erneut heruntergeladen werden.

Hinweis: In dieser Spezifikation wird der Prozess, wie die OPA Bundles sicher in den PIP und PAP Service gelangen, nicht festgelegt.

5.7 Anforderungen an den Betrieb der Zero Trust Komponenten

Die Zero Trust-Komponenten PEP und PDP werden als Kubernetes (k8s) Cluster betrieben. In einem von der gematik vorgegebenen GitHub Repository werden die Konfigurationsdateien des k8s Clusters bereitgestellt, mit denen die aktuelle Version des Clusters erstellt und ausgeführt werden kann. Im Cluster ist zusätzlich ein Cluster Management Service (Continuous Delivery (CD) Komponente) enthalten, der den Betriebszustand des Clusters überwacht und regelmäßig prüft, ob eine neuere Version des Clusters im GitHub Repository verfügbar ist, und ggf. das Cluster automatisch aktualisiert.

5.7.1 Anforderungen für nahtlose Aktualisierungen

Es ist durch geeignete Maßnahmen sicherzustellen, dass ein unterbrechungsfreier Betrieb, bzw. die durchgängige Verfügbarkeit zu jeder Zeit gewährleistet ist.

5.7.2 Anforderungen für Steuerung durch Feature-Flags

Hinweis: Hier sollte das Protokoll mit dem Tamper-Proof Audit-Log in A_25452 kombiniert werden.

5.7.3 Anforderungen zur Überwachung des Betriebsstatus

Der Hersteller der Zero Trust-Komponenten wird im Rahmen seiner Entwicklungs- und Wartungstätigkeit die Aufgaben eines Third (3^rd) Level Supports gewährleisten. First- (1^st) und Second- (2^nd) Level Supporttätigkeiten fallen zukünftig in den Verantwortungsbereich des Dienstes, in welchen die Zero Trust-Komponenten eingebettet werden.

Hinweis: Weitere spezifikatorische Regelungen finden zu einem späteren Zeitpunkt statt.

5.7.4 Betriebliche Schnittstellendefinition der Zero Trust-Komponenten

Die Zero-Trust Komponenten PEP und PDP stellen Endpunkte zur Verfügung, um die grundlegende Funktionalität, eingebettet in einen Service, zu gewährleisten. Jeder Dienst, der die Zero-Trust Komponenten betreibt, stellt damit folgende Endpunkte für einen Nutzer zur Verfügung. Die Tabelle orientiert sich an den Schnittstellendefinition aus [gemKPT_Betr].

Table # Tab_gemF_Zero-Trust_Schnittstellendefinition_PEPPDP

Zusätzlich werden mittels zentralen Komponenten weitere Endpunkte zur Verfügung gestellt (PIP/PAP), welche von den Zero-Trust Komponenten abgefragt werden, um beispielsweise aktualisierte Policy-Informationen abzuholen. Folgende Endpunkte werden nachfolgend definiert.

Table # Tab_gemF_Zero-Trust_Schnittstellendefinition_PIPPAP

Beim Erfassen der Daten des Funktionsaufrufs GET /policies/{application}/{label} muss der PIP/PAP-Dienst die Werte für {application} und {label} zusätzlich mit erfassen. Die Systematik zur Betriebsdatenerfassung wird zu einem späteren Zeitpunkt konkret festgelegt, orientiert sich aber an den Festlegungen zur Betriebsdatenerfassung Version 2 der [gemSpec_Perf].

5.8 Anforderungen an den Test der Zero-Trust Komponenten

Durch einen Shift-Left-Ansatz werden Testmaßnahmen von Anfang an für alle spezifizierten Komponenten und Dienste in der Produktentwicklung verankert. Hierbei arbeiten alle Beteiligten eng zusammen und machen Ihre Testmaßnahmen transparent.

Es wird angestrebt, so früh wie möglich durch PoCs und Durchstichtests die Umsetzbarkeit der Spezifikationen und die Anwendungsszenarien der Nutzer nachzuweisen.

5.8.1 Testartefakte

Hinweis: Eine genaue Definition zum Format der Testszenarien und Testfälle erfolgt später in Abstimmung mit dem Hersteller.

Hinweis: Eine genaue Definition der benötigten Testartefakte erfolgt später in Abstimmung mit dem Hersteller.

Hinweis: Eine genaue Definition von Art und Umfang des zu leistenden Support erfolgt später in Abstimmung mit dem Hersteller.

5.8.2 Testtreiberschnittstelle und Testunterstützung

Die hier spezifizierten Komponenten und Dienste dienen der Absicherung von Produkttypen einer Fachanwendung. Da sie elementare Sicherheitsfunktionen umsetzen, stehen sie ggf. einer Implementierung und Testung der zu schützenden Fachlichkeit in nicht-produktiven Umgebungen im Wege. Daher ist es sinnvoll, in den entsprechenden Zero Trust-Komponenten eine Testtreiber-Schnittstelle bzw. einen Testmodus zu implementieren, der die Umgehung der Sicherheitsmechanismen unter bestimmten Rahmenbedingungen (z. B. Routing in ein Testsystem, wenn Testpolicy aktiv etc.) ermöglicht.

Hinweis: Eine genaue Abstimmung zu Art und Umfang der Testtreiberschnittstelle in den jeweiligen Komponenten erfolgt später in Abstimmung mit dem Hersteller.

5.8.3 Bereitstellung der Testkomponenten und Testartefakte

Die hier spezifizierten Komponenten und Dienste haben keinen Selbstzweck, sondern kommen in der Realisierung von Produkttypen einer Fachanwendung zum Einsatz. Sie werden "as Code" bereitgestellt, und in Build-Pipelines der Komponenten und Produkttypen der Fachanwendung eingebettet. Weiterhin soll die Testausführung automatisiert werden. Dadurch wird ein automatisches und regelmäßiges Deployment in Testumgebungen im Sinne eines Continuous Testings ermöglicht.

Hinweis: Eine genaue Definition zum Format der signierten Artefakte erfolgt später in Abstimmung mit dem Hersteller.

Hinweis: Eine genaue Definition aller benötigten Testumgebungen erfolgt später in Abstimmung mit dem Hersteller.

5.8.4 Testumgebungen und Quality Gates

Um die Qualität einer Zero Trust Komponente zu messen, muss diese in verschiedenen Testumgebungen (z.B. für die Entwicklung, den Produkttest, den Integrationstest) validiert werden und müssen die für die jeweilige Testumgebung vorgesehenen Quality Gates bestehen. Quality Gates bestehen zum Beispiel im erfolgreichen Durchführen von Testsuiten oder im Erbringen geforderter Nachweise. Dies soll nach Möglichkeit automatisiert erfolgen.

Hinweis: Eine genaue Definition, welche Testumgebung und welche Quality Gates dazugehören, erfolgt später in Abstimmung mit dem Hersteller.

6 Dokumentenhaushalt

Dieses Dokument hat die nachfolgenden Auswirkungen auf den Dokumenten- und Anforderungshaushalt der Telematikinfrastruktur.

6.1 Neue Dokumente

Dieses Dokument wird zunächst als "Sicherheitsfeature" eines TI 2.0 Dienstes eingeführt. Die Anforderungen sind als übergreifende Spezifikation zu betrachten, die erst im Kontext eines konkreten TI 2.0 Dienstes wirksam werden. Daher erfordert die Realisierung des Zero Trusts immer eine zusätzliche TI 2.0 dienstspezifische Spezifikation, wobei die hier formulierten Anforderungen Eingang in die Produkt- und Anbietertyp-Steckbriefe des entsprechenden TI 2.0 Dienstes finden.

6.2 Übersicht betroffener Dokumente

Aus dieser Spezifikation ergeben sich zunächst keine direkten Änderungsbedarfe an anderen Dokumenten.

6.3 Übersicht Produkt- und Anbietertypen

Die hier spezifizierten Komponenten und Dienste stellen keine isoliert zulassungsfähigen Produkttypen dar. Sie liefern einen Anforderungshaushalt für anwendungsspezifische Komponenten und Dienste, die dann zusammen einen Produkt- bzw. Anbietertyp einer konkreten Fachanwendung bzw. der TI als Plattform bilden. 

7 Beispiele und Referenzimplementierungen

Die gematik stellt API-Spezifikationen und Proof-of-Concept-Implementierungen im Internet zur freien Verfügung.

Das Projekt https://dsr.gematik.solutions demonstriert eine Attestation mobiler Anwendungen auf gängigen mobilen Betriebsystemplattformen.

Im github-Projekt https://github.com/gematik/spec-t20r werden die Schnittstellenspezifikationen der hier spezifizierten Zero Trust-Komponenten veröffentlicht.

Die folgenden beiden Projekte https://github.com/gematik/zero-lab und https://github.com/gematik/zero-lab-apple demonstrieren die Anwendungsfälle zur Clientregistrierung auf Apple- und Android-Geräten.

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

Tabelle 9: Im Dokument verwendete Abkürzungen

8.2 Abbildungsverzeichnis

8.3 Tabellenverzeichnis

8.4 Referenzierte Dokumente

8.4.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

Tabelle 10: Referenzierte Dokumente der gematik

8.4.2 Weitere Referenzen

Tabelle 11: Weitere Referenzen