Telematikinfrastruktur 2.0

Spezifikation

Zero Trust Access (ZETA)

    

     

      
Version
      
1.1.0_CC
     
     

      
Revision
      
1280131
     
     

      
Stand
      
30.06.2025
     
     

      
Status
      
zur Abstimmung freigegeben
     
     

      
Klassifizierung
      
öffentlich_Entwurf
     
     

      
Referenzierung
      
gemSpec_ZETA
     
    

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 konkreten Bezug zu einem Produkttypen 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, Komponenten und Dienste, die Zero Trust-Aspekte beinhalten oder nutzen.

Das Ziel des Zero Trust-Ansatzes besteht darin, die IT-Sicherheitslandschaft grundlegend zu transformieren, um den Schutz von Daten, Anwendungen und Systemen vor modernen Bedrohungen und Angreifern zu gewährleisten. Im Gegensatz zu traditionellen Sicherheitsmodellen, die auf dem Konzept eines sicheren Perimeters basieren, setzt Zero Trust auf die Annahme, dass keine Benutzer oder Systeme, unabhängig von ihrem Standort innerhalb oder außerhalb des Netzwerks, von Natur aus vertrauenswürdig sind.

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 Clients 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 Clients. Um Clients wiedererkennbar zu machen, muss eine Registrierung dieser erfolgen. Sind in der Registrierung zusätzliche Sicherheitsmerkmale über das Client und den Aufrufkontext feststellbar, stärken diese das Vertrauen in nachfolgenden Aufrufen fachlicher Schnittstellen.

2.1.1 Wiedererkennung bekannter Clients

Die Wiedererkennung bekannter 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 Clients, sollen selbige einer automatischen Sicherheitsprüfung unterzogen werden können (Device Security Rating - DSR), 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

Der HTTP Proxy stellt sicher, dass nur Requests mit gültigem Access Token sowie bestandenen zusätzlichen Prüfungen an den Resource Server weitergeleitet werden. Welche Prüfungen zusätzlich erfolgen, wird über Attribute im Access Token gesteuert.

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. Die Regeln sollen zusätzlich menschenlesbar sein, um die Entwicklung und Wartung der Regeln zu vereinfachen.

2.3.2 Ein reproduzierbares Ja/Nein

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 und ebenso technische Regeln sowie solche, die Betriebsumgebung von Backenddiensten betreffend.

2.4 Policy-Information und -Administration

Die Aufgabe des Policy Information Point (PIP) ist es, relevante Attribute und Informationen zur Entscheidungsfindung (Daten) zu liefern, während der Policy Administration Point (PAP) für die Verwaltung und Bereitstellung der Richtlinien (Policies) verantwortlich ist.

2.4.1 Policy-Verwaltung

Eine Policy-Entscheidung 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 Policy-Entscheidungen zu Informationen über das Gesamtsystem, die als Eingangsdaten für nachfolgende Policy-Entscheidungen 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 Telemetrie-Daten 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.).

Für die Dienst zu Dienst Kommunikation ist es ebenso erforderlich den anfragenden Dienst zu identifizieren, um eine Zugriffsentscheidung treffen zu können.

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 dezentral im Internet angeboten und bedürfen daher eines Schutzes 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 Client ausgeführt), häufig bedient durch einen Menschen, und Backendservices (Software: bereitstellende Schnittstelle, Datenbereitstellung etc.) auf der anderen Seite.

Zur Absicherung der Clients und Backendservices werden Anforderungen erhoben, die in konkreten Softwarekomponenten innerhalb dieser Akteure umzusetzen sind. Die Separierung der Zero Trust-Mechanismen in unterschiedliche Komponenten folgt der Zero Trust-NIST-Referenzarchitektur.

Abbildung 1: NIST Zero Trust-Referenzarchitektur, Quelle [NIST_SP1800-35_FIG1]

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 generische Produkttypzerlegung für die Umsetzung der NIST-Referenzarchitektur einer TI2.0 Fachanwendung dargestellt. Die Zero Trust Ausprägung der Telematikinfrastruktur wird Zero Trust Access (ZETA) genannt.

In diesem Pattern greift ein Nutzer über ein Clientsystem inkl. ZETA Client auf Daten eines TI 2.0 Dienstes zu. Ein TI 2.0 Dienst setzt sich zusammen aus einem ZETA Guard und mindestens einem Resource Server. Der ZETA-Guard wird als eingebettetes Modul engmaschig mit dem Produkttypen verbunden und vom Anbieter des TI2.0 Dienstes zwingend mit betrieben. Das folgende Bild zeigt eine Übersicht der beteiligten Komponenten in der Vernetzung zwischen einem Clientsystem (links grün) und einem Backendservice (rechts grün: Resource Server).

Abbildung 2: Abbildung Zero Trust-Architektur der TI 2.0

Die obige Abbildung zeigt die Einbettung von ZETA bezogenen, logischen Komponenten (orange) in die Aufrufkette zwischen einem Clientsystem und einem Resource 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 gematik Telemetriedaten) 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): Der HTTP Proxy erlaubt den Zugriff auf Daten des Resource Servers, wenn ein gültiges Access Token im Authorization Header enthalten ist. Der ZETA Client muss am HTTP Proxy das OAuth Protected Resource Well-known JSON Document abfragen, um herauszufinden, von welchem Authorization Server die Access Token für diesen Resource Server ausgestellt werden können.

(2): Um ein Access Token vom Authorization Server zu erhalten, ist eine Authentifizierung des Nutzers erforderlich. Die Nutzerauthentifizierung erfolgt per OIDC (4) mit Pushed Authorization Request (3) und OAuth Authorization Code Flow (2) oder per OAuth Token Exchange (5 und 2) mit vorheriger Client-Registrierung am Authorization Server.

(6): Es ist vorgesehen, dass Fachanwendungen eine zusätzliche Autorisierung mittels der Komponente Application Authorization Backend nutzen können.

(7): Wenn die Authentisierung per OIDC erfolgt, dann ist im Rahmen der Client-Registrierung eine E-Mail mit Confirmation Code erforderlich, in der der Nutzer bestätigt, dass es sich um seinen Client handelt. Die E-Mail Confirmation ist nur einmalig notwendig, falls die App mehrere TI 2.0 Resource Server nutzt.

(27) Die Policy Engine bezieht die aktuellen Policies und Daten vom ZETA PIP und PAP Service.

(8): Der Authorization Server stellt nur ein Access Token aus, wenn die Policy Engine durch Anwendung der Policies die Erlaubnis gegeben hat. Für die Entscheidung der Erlaubnis werden die Nutzer-Daten und Client-Daten der aktuellen Session (Input) anhand von Policies mit den vorgegebenen Daten der Policy Engine verglichen.

(9): Die Session-, User- und Client-Daten werden vom Authorization Server in der PDP Datenbank gespeichert.

(10): Der HTTP Proxy kann optional eine zusätzliche Verschlüsselung der Daten per ZETA/ASL terminieren. Die Schlüssel verwaltet der HTTP Proxy in der PEP Datenbank.

(11): Der HTTP Proxy fragt Nutzer- und Client-Daten anhand eines Claims aus dem Access Token aus der PDP Datenbank ab, um diese Daten per Custom Header im Request (1) dem Resource Server zu übergeben (12).

(13): Der Management Service überwacht die Konfiguration der ZETA Guard-Komponenten und setzt durch, dass die im Git Repository der ZETA Guard Instanz gespeicherte Konfiguration ausgeführt wird.

(14): Mittels Shared Signals kann das Monitoring (oder eine andere Komponente des TI 2.0 Dienst-Anbieters) sicherheitsrelevante Informationen von den ZETA-Guard Komponenten erhalten und ebenfalls mittels Shared Signals darauf reagieren, indem z. B. das Access und das Refresh Token eines Nutzers gesperrt werden und somit eine neue Authentifizierung erzwungen wird.

(15) und (16): Der Telemetrie-Daten Service sammelt Telemetrie-Daten von den ZETA Guard-Komponenten ein und bereitet sie für den Versand an die gematik Telemetriedaten Schnittstelle und das TI SIEM der gematik auf. Es wird das OTLP Protokoll über gRPC verwendet.

(17, 18, 19): Der Telemetrie-Daten Service empfängt die Selbstauskunft Daten (und nach Bedarf weitere) vom TI 2.0 Dienst und kann Daten vom SIEM und Monitoring des TI 2.0 Dienst-Anbieters entgegennehmen und an die gematik Telemetriedaten Schnittstelle sowie das TI SIEM der gematik weiterleiten. Ebenso kann der Telemetrie-Daten Service Monitoring-Daten der ZETA Guard-Komponenten an das Monitoring des TI 2.0 Dienst-Anbieters senden. Zum Einsatz kommt OpenTelemetry. Alle von OpenTelemetry unterstützten Protokolle können vom Anbieter durch Konfiguration des Telemetrie-Daten Service verwendet werden, um Daten an den Telemetrie-Daten Service zu senden und vom Telemetrie-Daten Service zu empfangen. Empfohlen wird das native OTLP Protokoll über gRPC.

(20), (21) und (22): Die Komponenten des TI 2.0 Dienstes werden im Monitoring überwacht und es werden Daten für das SIEM erzeugt.

(23): Das Clientsystem kann über den ZETA Client eine Push-Konfiguration im ZETA Guard Notification Service einrichten. Wenn Ereignisse eintreten, für die der Resource Server oder der ZETA Guard eine Push Nachricht für den Benutzer generiert (24), dann werden entsprechend der vorhandenen Push-Konfigurationen des Nutzers im Notification Service, Benachrichtigungen an den Client gesendet (25 und 26).

4 Technisches Konzept

Im Kapitel zuvor wurden zwei Abbildungen vorgestellt, welche technischen ZETA Guard-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 den ZETA Guard
• Sicherstellung des Sicherheitszustands der gesamten TI, Anbieter übergreifend
• Telemetrie und Monitoring

4.1 ZETA Guard

Der ZETA Guard besteht aus Policy Enforcement Point (PEP), Policy Decision Point (PDP) sowie betriebsunterstützenden Komponenten (Management Service und Telemetrie-Daten Service). Der PEP besteht aus einem HTTP Proxy und einer Datenbank. Der PDP enthält die Policy Engine, den Authorization Server und eine Datenbank. Jeder TI 2.0 Dienst hat einen ZETA Guard zum Schutz des Dienstes vor unberechtigtem Zugriff. Der ZETA Guard wird in der Verantwortung des TI 2.0 Dienst-Anbieters 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 stellt die Außenschnittstelle des Dienstes dar, in den er integriert ist.

Insgesamt agiert der PEP als Kontrollpunkt in der Zero Trust-Architektur, der sicherstellt, dass nur autorisierte Benutzer und Clients 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. Am PEP werden Betriebsdaten erhoben, verarbeitet und dem Telemetrie-Daten Service im ZETA Guard zur Verfügung gestellt.

4.3 Policy Decision Point (PDP)

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

• Der PDP fungiert als OAuth2 Authorization Server und verwaltet die Autorisierung von Benutzeranfragen auf geschützte Ressourcen. Zudem überwacht der Authorization Server die Benutzersessions, um sicherzustellen, dass sie gültig sind und den Sicherheitsrichtlinien entsprechen. Der Authorization Server ist als vertrauenswürdige Relying Party im föderierten Identitätsmanagement registriert. Dadurch kann der Authorization Server Identitätsinformationen von Benutzern sicher und vertrauenswürdig beziehen und bei Bedarf eine (erneute) Nutzerauthentifizierung an die IDPs delegieren. Dadurch stellt der Authorization Server sicher, dass nur authentifizierte Benutzer Zugriff auf die geschützten Ressourcen erhalten.

• Der PDP ermöglicht am Authorization Server 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.

• Der PDP analysiert und interpretiert in der Policy Engine die Sicherheitsrichtlinien, die im Rahmen des Zero Trust-Modells definiert sind. Diese Policies können Kriterien wie Benutzeridentität, Gerätetyp, Standort, Zeitpunkt der Anfrage und andere Kontextinformationen ("Signale") enthalten, die relevant für die Zugriffsentscheidung sind. Basierend auf der Interpretation der Policies trifft die Policy Engine Entscheidungen darüber, ob eine Zugriffsanfrage auf eine bestimmte Ressource genehmigt oder abgelehnt wird. Diese Entscheidungen erfolgen auf Plattformebene, was bedeutet, dass die Policy Engine 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).

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

Am PDP werden Betriebsdaten erhoben, verarbeitet und dem Telemetrie-Daten Service im ZETA Guard zur Verfügung gestellt.

4.4 ZETA Client

Im Kontext von Zero Trust der TI stellt der "ZETA Client" eine logische Komponente innerhalb einer Clientanwendung (Primärsystem (PS), Frontend des Versicherten (FdV) etc.) dar.

Ein ZETA Client im Zero Trust-Modell wird nicht als vertrauenswürdig angesehen, sondern muss - genauso wie alle Komponenten im Netzwerk - kontinuierlich authentifiziert und autorisiert werden. Die Zugriffsentscheidungen werden basierend auf aktuellen Richtlinien, Kontextinformationen, Bedrohungsinformationen und insbesondere in Kenntnis des diesen Client benutzenden Benutzers getroffen.

Die Aufgaben des ZETA Clients sind:

• Erzeugung, sichere Speicherung und Prüfung der kryptographischen App/Geräte Identität
• Erzeugung der App/Gerät-Attestierung und Ermittlung und Übertragung der Eigenschaften der Laufzeitumgebung (Betriebssystem, Betriebssystem Version, etc.)
• Implementierung des OAuth Flows
• Management der Sessions inkl. Verwaltung der Access und Refresh Token.
• Management der Clientregistrierungen

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 die Policy Engine des 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, Clientezustä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 Clients 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 Clientattributen - 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 (Client-Features, Betriebssystem) kann ein Vertrauen und eine Wiedererkennung von Clients 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-/Anbieterebene

Der Nutzer muss sich vor der Clientregistrierung mit einer TI-Identität authentifizieren, z. B. GesundheitsID oder SM(C)-B. Bei der Registrierung werden die statischen Eigenschaften eines Client-Systems für jede Client-Instanz mit einem vom Client-Nutzer signierten Softwarestatement bekannt gemacht. Der Client erzeugt dabei eine kryptographische Identität (DPoP Key [RFC9449]), die Server-seitig an den Nutzer und Client gebunden wird.

Bei der SM(C)-B Authentisierung mit DPoP erfolgt die Clientregistrierung implizit (wenn die SM(C)-B freigeschaltet ist). Das vom ZETA Client automatisch erstellte Client Assertion JWT enthält die Clientregistrierungsdaten und wird per SM(C)-B signiert.

Zur Laufzeit werden die Client-Eigenschaften durch Client-Instanz-Eigenschaften ergänzt. Sie sind spezifisch für eine konkrete Installation auf einem bestimmten Client 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)

Hinweis: Für andere mobile Betriebssysteme wird die Attestation unterstützt, wenn sie verfügbar ist.

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 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 Clientattribute 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-Clients

iOS

Tabelle 4: Verwendete Device Claims für iOS-Clients

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 Policy-Entscheidungen 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 TI1.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 [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 ZETA Guard-Komponenten erhoben und für die eingesetzten ZETA Guard-Komponenten übergreifend mittels dem Telemetrie-Daten-Service erfasst. Bei der Nachbereitung der Telemetrie-Daten werden personenbezogene oder -beziehbare Daten anonymisiert, um diese bereinigten Daten dem Anbieter regelhaft zugänglich zu machen. Das bereinigte Monitoring-Log kann von dem Anbieter 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 Traces und Metriken für die gematik benutzt. 

4.8 Zusammenspiel mit Identity Provider

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. Nutzer stellt über den ZETA Client Anfrage: Der Nutzer versucht auf eine "besser geschützte Ressource" auf dem Resource Server zuzugreifen.
2. PEP fängt Anfrage ab: Der PEP fängt die Anfrage ab.
3. PEP validiert Access Token: Der PEP prüft:
• Ist das Access Token gültig (Signatur, Ablaufdatum etc.)?
• Hat das Access Token den erforderlichen Scope für die angeforderte Ressource?
4. Zugriff verweigert: Wenn der erforderliche Scope nicht im Access Token enthalten ist, verweigert der PEP den Zugriff.
5. PEP antwortet mit Step-up-Anforderung: Der PEP informiert den Nutzer, dass für den Zugriff auf die Ressource ein Access Token mit einem bestimmten Scope benötigt wird.
6. Nutzer initiiert Step-up-Authentifizierung: Der ZETA Client wird zum Authorization Server weitergeleitet, um die zusätzliche Authentifizierung durchzuführen.
7. Authorization Server authentifiziert und gewährt neues Access Token: Der Authorization Server:
• Steuert die Durchführung der Step-up-Authentifizierung.
• Erstellt ein neues Access Token mit einem erweiterten Scope, der den Zugriff auf die angeforderte Ressource erlaubt.
• Gibt das neue Access Token an den ZETA Client zurück.
8. Nutzer stellt erneute Anfrage: Der Nutzer sendet die Anfrage mit dem neuen Access Token an den PEP.
9. PEP prüft neues Token: Der PEP prüft wieder:
• Ist das neue Access Token gültig?
• Hat das neue Access Token den erforderlichen Scope für die angeforderte Ressource?
10. Zugriff gewährt: Wenn der erforderliche Scope im neuen Access Token enthalten ist, gewährt der PEP den Zugriff auf die Ressource.

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 TI 2.0 Dienst-Backend

Das TI 2.0 Dienst-Backend (im folgenden Resource Server genannt) 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 (ZETA Guard-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.

Die Festlegungen zu Schemas, OpenAPI Schnittstellen und Abbildungen sind in [gemAPI_ZETA] enthalten.

Hinweis: Details in diesem Kapitel werden im Rahmen der Implementierung zwischen gematik und dem Zero Trust-Hersteller festgelegt und in einer Folgeversion veröffentlicht.

5.1 Übergreifende Anforderungen für Datenschutz und Sicherheit

Hinweis: Es wird empfohlen ein Service Mesh (z. B. Istio oder linkerd) einzusetzen.

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

Hinweis: Feature Flags sind Konfigurationseinstellungen, die Funktionen ein- oder ausschalten.

Hinweis: Die Anforderung ist besonders wichtig, falls die Zero Trust-Komponente in einer VAU betrieben wird.

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 Anbieters notwendig werden.

Hinweis: Der Telemetrie-Daten Service im ZETA Guard muss die vom PEP und PDP gesammelten Telemetrie-Daten so verändert an das Monitoring System des Anbieters weitergeben, dass eine Profilbildung nicht mehr möglich ist.

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 Resource Server 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 Authorization Server die Information, dass sich eine Eigenschaft der aktuellen Session geändert hat. Der Authorization Server 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 die Policy Engine.

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 ZETA Guard Daten mit dem Schutzbedarf „sehr hoch“ verarbeitet und der Anbieter keine Kenntnis über die in dem ZETA Guard verarbeiteten Daten erlangen darf, gibt es Sonderanforderungen, um die Daten während der Verarbeitung zu schützen.

5.1.4 Sicherheits- und Datenschutz Anforderungen an dem ZETA Client in FdVs

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

5.2 Clientsystem und ZETA Client

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 zur Verfügung gestellt.

Ein ZETA Client ist ein Teil des Clientsystems, der die Kommunikation mit dem PDP und dem PEP eines Dienstes übernimmt.

Mobile iOS und Android Apps werden unterstützt und setzen ebenfalls einen ZETA Client um. Anforderungen, die nur für diese Clientsysteme und ZETA Clients gelten werden, verwenden die Bezeichnung "mobiler Client" oder "mobiles Clientsystem" und "mobiler ZETA Client".

5.2.1 Hersteller

5.2.2 Verbindungsaufbau

Hinweis: Die Parameter für das Verfahren des Exponential Backoffs werden vom Hersteller des ZETA Clients festgelegt.

Hinweis: Ob ein ZETA/ASL Kanal zu verwenden ist, wird im OAuth Protected Resource Well-known Dokument des TI 2.0 Dienstes festgelegt (claim zeta_asl_use). Die Anforderungen für den ZETA/ASL-Kanal sind in [gemSpec_Krypt#8] zu finden.

5.2.3 Clientregistrierung

Hinweis: Für die Clientregistrierung muss das Vertrauensniveau hoch, nicht erreicht werden.

Hinweis: Eine Speicherung der Schlüssel in einem Hardware-Modul ist gegenüber einer Software-Lösung (z. B. Android TEE) zu bevorzugen.

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

5.2.4 Nutzerauthentifizierung

Hinweis: Perspektivisch sollen ZETA Clients auch OpenID for Verifiable Credentials (OIDC4VC) unterstützen. OAuth2 Token Exchange wird für stationäre Clients mit SM(C)-B Authentisierung verwendet. OAuth Authorization Code Flow, OpenID Connect und OpenID Federation wird grundsätzlich von mobilen Clients verwendet, kann aber auch von stationären Clients verwendet werden.

5.2.5 Session Management

5.2.6 Liste der HTTP-Statuscodes

Der folgende Abschnitt enthält die HTTP-Statuscodes, die ZETA Clients von Zero Trust-Komponenten erhalten können, basierend auf den spezifischen Schritten wie Authentifizierung, Clientregistrierung und HTTP Proxy.

Tabelle 5: ZT_HTTP_Statuscodes

5.2.7 ZETA Attestation Service

Der ZETA Attestation Service stellt einen gRPC-Dienst zur Verfügung, der es stationären Clients (Primärsystem) ermöglicht, TPM-signierte Attestierungsinformationen für den Client abzurufen. Diese Informationen basieren auf Integritätsmessungen, die in ausgewählten Platform Configuration Registers (PCRs) des Trusted Platform Module (TPM) gespeichert sind. Der ZETA Guard Authorization Server verwendet diese Attestierungsdaten, um die Integrität und Authentizität der Softwareumgebung des Clients zu verifizieren, bevor Zugriff auf geschützte Ressourcen gewährt wird.

Der ZETA Attestation Service wird vom Hersteller des stationären Clients bereitgestellt und es muss eine Vertrauensbeziehung zwischen stationären Client und ZETA Attestation Service bestehen, um zu gewährleisten, dass die Attestation über die vorgesehenen Software-Komponenten erfolgt.

Der ZETA Attestation Service muss gemäß [API-ZETA-Attestation-Service] implementiert werden.

5.3 ZETA Guard

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

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

Beispiel für eine sinnvolle Ergänzung der Fehlerdetails:

Bei der Authentifizierung mit Client Assertion JWT fehlt im JWT eine Angabe product_version oder die product_version ist nicht in der Policy Engine bekannt, dann antwortet der Authorization Server mit HTTP Status 400 Bad Request sowie einer Beschreibung, dass die product_version fehlt oder nicht bekannt ist.

Hinweis: Es gibt einen RFC Draft, der Rate Limits neu spezifiziert (https://www.ietf.org/archive/id/draft-ietf-httpapi-ratelimit-headers-09.html ). Es ist geplant, dass nach Veröffentlichung des RFC ZETA Guard angepasst wird, um die neuen Rate Limit Festlegungen zu unterstützen.

5.4 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.

5.4.1 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.

Hinweis: Jeder Authorization Server, der zur Föderation des Federation Masters gehört, veröffentlicht ein eigenes Entity Statement, in dem die Schlüssel enthalten sind, mit denen die Signatur der Access Token geprüft werden kann.
Hinweis: Einige TI 2.0 Dienste benötigen ein PoPP Token. Diese werden im Request Header PoPP übertragen und vom HTTP Proxy geprüft.

Hinweis: Wenn ein ZETA/ASL-Kanal am HTTP Proxy terminiert wird, dann wird das PoPP Token durch den ZETA/ASL-Kanal geschützt transportiert.

Hinweis: Ob ein ZETA/ASL Kanal zu verwenden ist, wird in der Spezifikation des TI 2.0 Dienstes festgelegt.

Hinweis: Die Anforderungen für den ZETA/ASL-Kanal sind in [gemSpec_Krypt#8] zu finden.

Hinweis: Die Schema-Dateien sind in [GitHub ZETA Schemas] festgelegt.

Hinweis: Die Abfrage der Client-Daten kann zusammen mit der Abfrage der Nutzer-Daten in einem Request an die PDP Datenbank erfolgen.

Hinweis: Es ist geplant, die Protected Resource Metadata Well-known JSON Dokumente in einer folgenden ZETA Ausbaustufe durch den Federation Master bereitzustellen. Der Federation Master signiert die Protected Resource Metadata Dokumente und stellt so sicher, dass alle Services zur Föderation und zur gleichen Umgebung gehören (dev, prod, ref, etc.). Dadurch verbessert sich für ZETA Clients die Authentizität der TI 2.0 Services.

5.4.2 Sicherheits- und Datenschutz-Anforderungen an den PEP

Hinweis: Die positive Zugriffsentscheidung auf den Resource Server ist gegeben, wenn der Client im Request Authorization Header ein gültiges Access Token mit passendem scope - ausgestellt von einem Authorization Server, zu dem eine Vertrauensbeziehung besteht - vorweisen kann. Durch das gültige Access Token ist sichergestellt, dass der Zugriff von dem PDP freigegeben wird.

5.5 Policy Decision Point

Der Policy Decision Point (PDP) setzt sich aus den Komponenten

• Authorization Server
• Policy Engine und
• PDP Datenbank

zusammen.

5.5.1 Policy Engine

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

Neben der OPA Instanz, die die Entscheidung für den Authorization Server trifft (aktive Instanz), ob eine Kommunikation zulässig ist, implementiert die Policy Engine noch eine zweite OPA Instanz, die mit einem zweiten OPA Bundle vom PIP und PAP Service arbeitet, aber die getroffenen Entscheidungen nicht an den Authorization Server zurückgibt. 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 Downloadpunkt des PIP und PAP Service als JWKS geladen.

Wenn konfiguriert, dann werden die decision logs an die vom Anbieter des ZETA Guard festgelegte URL gesendet.

5.5.2 PDP Authorization Server

Hinweis: Eine Session des Authorization Servers ist gültig vom Zeitpunkt t1 = (Ausstellungszeitpunkt des ersten Refresh Token nach vollständiger Authentifizierung) bis zum Zeitpunkt t2 = t1 + (Gültigkeitsdauer des ersten Refresh Token). Bei mobilen Clients werden für die Attestation Services des mobilen Betriebssystems verwendet, die ein Rate Limit haben können. In diesem Fall kann die Attestation eventuell nicht für jede neue Session widerholt werden. 

5.5.2.1 PDP Relying Party

5.5.2.2 Ablauf für den Zugriff auf einen Resource Server

Um auf einen durch ZETA Guard geschützten Resource Server zugreifen zu können, müssen abhängig vom Zustand des ZETA Clients verschiedene Teilabläufe ausgeführt werden, oder können übersprungen werden. Die ZETA API besteht aus mehreren Endpunkten, die verschiedene Funktionen bereitstellen. Diese Endpunkte sind in verschiedene Unter-Abläufe aufgeteilt:

• Konfiguration und Discovery: Der ZETA Client muss die Konfiguration des ZETA Guards ermitteln, um die richtigen Endpunkte zu erreichen.
• Client-Registrierung: Jeder ZETA Client muss sich einmalig beim ZETA Guard registrieren, um eine `client_id` zu erhalten und seinen öffentlichen Schlüssel zu hinterlegen.
• Authentifizierung und Autorisierung: Der Client muss sich authentifizieren und die Integrität seiner Plattform nachweisen. Zusätzlich muss sich der Nutzer oder beim Primärsystem die Organisation authentifizieren, um ein Access Token für den Zugriff auf geschützte Ressourcen zu erhalten.

Der Gesamtprozess beginnt damit, dass ein Nutzer auf einen Endpunkt eines Resource Servers zugreifen möchte. Dieser Zugriff wird über das Primärsystem vom ZETA Client im Auftrag des Nutzers ausgeführt; siehe folgende Abbildung.

5.5.2.3 Service Discovery

Der ZETA Guard ermöglicht ZETA Clients die Ermittlung der bereitgestellten Endpunkte durch Abfrage von Well-known JSON Dokumenten.

5.5.2.4 Client-Registrierung für stationäre Clients

Jeder ZETA Client muss sich am ZETA Guard registrieren, über den er auf geschützte Ressourcen zugreifen möchte. Dieser Prozess findet einmalig pro ZETA Guard-Instanz statt. Der gesamte Prozess ist zweistufig, um die administrative Einrichtung von der technischen Inbetriebnahme zu trennen:
- Initiale Registrierung: Der Client erzeugt ein langlebiges kryptographisches Schlüsselpaar (Client Instance Key), sendet den öffentlichen Teil an den Authorization Server und erhält im Gegenzug eine client_id. Der Client ist danach im System bekannt, aber sein Status ist pending_attestation, d.h. er ist noch nicht für den Zugriff auf Ressourcen freigeschaltet.
- Aktivierung (Erster Token Exchange): Der Client wird aktiviert, indem er zum ersten Mal einen Token Exchange mit einer erfolgreichen Attestierung durchführt. Damit beweist er nicht nur den Besitz des privaten Schlüssels, sondern (bei der TPM-Attestierung) auch die Integrität der Plattform, auf der er läuft. Nach erfolgreicher Prüfung wird sein Status im ZETA Guard auf active gesetzt.

A_27799 - ZETA Guard, Client-Registrierung für stationäre Clients

Der ZETA Guard MUSS die Client-Registrierung für stationäre Clients gemäß Abbildung Abb_Client_Registrierung bereitstellen.

Abbildung 5: Abb_Client_Registrierung

[<=]

Für die initiale Registrierung sendet der ZETA Client eine Anfrage an den Dynamic Client Registration (DCR) Endpoint. Diese Anfrage enthält alle notwendigen Metadaten, um den Client für die private_key_jwt Authentifizierungsmethode vorzubereiten:
- client_name: Ein für Menschen lesbarer Name für den Client.
- token_endpoint_auth_method: Die geplante Authentifizierungsmethode, hier private_key_jwt.
- grant_types: Die erlaubten Grant Types (z.B. urn:ietf:params:oauth:grant-type:token-exchange, refresh_token).
- jwks: Ein JSON Web Key Set, das den öffentlichen Client Instance Key enthält. Dieser Schlüssel wird vom Authorization Server verwendet, um die Signatur der Client Assertions zu überprüfen.

5.5.2.5 Authentifizierung und Autorisierung für stationäre Clients

Nach erfolgreicher Registrierung besitzt der ZETA Client eine client_id und ein zugehöriges Schlüsselpaar. Um auf einen Fachdienst zugreifen zu können, benötigt der Client ein Access Token vom Authorization Server (AS). Stationäre ZETA Clients verwenden dafür den Token Exchange Flow, während mobile ZETA Clients den Authorization Code Flow mit OpenID Connect nutzen.

Die Authentifizierung und Autorisierung für stationäre Clients unterscheidet zwei Hauptfälle:
1. Token-Austausch mit Attestierung: Hier wird die Identität der Institution (mittels subject_token von der SM(C)-B) nachgewiesen und die Integrität des Clients durch eine Attestierung überprüft. Dieser aufwändigere Prozess wird zu Beginn einer neuen Session (oder zur Re-Attestierung) durchgeführt, um sicherzustellen, dass der ZETA Client und das Primärsystem vertrauenswürdig sind.
2. Token-Erneuerung (Refresh Token): Hier wird ein vorhandenes Refresh Token genutzt, um ein neues Access Token zu erhalten. Dieser Prozess ist performanter und verzichtet auf eine erneute Attestierung.
Diese Trennung schafft eine Balance zwischen höchster Sicherheit beim initialen Zugriff und Effizienz bei der Erneuerung bestehender Sitzungen.

Die folgende Abbildung zeigt den Ablauf des Token-Austauschs mit Client Assertion JWT Authentifizierung und DPoP.

5.5.2.5.1 Pfad A: Token-Austausch mit Attestierung

Dieser Pfad wird beschritten, wenn der Client keine bestehende Session (d.h. kein gültiges Refresh Token) hat.
1. Vorbereitung:
    - Der Client fordert eine frische, einmalig gültige nonce vom Authorization Server an (GET /nonce).
    - Der Client erzeugt ein temporäres, nur für diese Session gültiges DPoP-Schlüsselpaar.
2. Integritätsprüfung und kryptografische Bindung:
    - Um zu beweisen, dass die Attestierung für genau diesen Client und diese Transaktion erstellt wurde, erzeugt der Client eine attestation_challenge. Diese bindet den Zustand des TPMs an den öffentlichen Client Instance Key und die nonce des AS: attestation_challenge = HASH( HASH(Client_Instance_Public_Key_JWK) + nonce ).
    - Der Client fordert beim ZETA Attestation Service eine TPM Quote an, die diese attestation_challenge als qualifyingData enthält. Das TPM signiert somit eine Aussage, die mit der Identität des Clients verbunden ist.
3. Erstellen des Client Statement: Die Attestierungsartefakte (TPM Quote, Event Log, Zertifikatskette) werden in eine client_statement-Struktur gepackt. Im Falle des Fallbacks (Software-Attestierung) enthält diese Struktur andere, softwarebasierte Evidenz.
4. Erstellen der Client Assertion (mit Attestierung): Für die Authentifizierung am Token-Endpoint erstellt der Client eine Client Assertion. Dieses JWT, mit dem privaten Client Instance Key signiert, dient als "Umschlag":
    - Es authentifiziert den Client gegenüber dem AS (iss und sub sind die client_id).
    - Es enthält die client_statement-Struktur als Beweis für die Clientintegrität, verpackt in einem spezifischen Claim (urn:gematik:params:oauth:client-attestation:tpm2 oder ...:software).

    // Client Assertion für initialen Token-Austausch (Beispiel TPM)
    {
      "iss": "<client_id>",
      "sub": "<client_id>",
      "aud": "<AS_Token_Endpoint_URL>",
      "exp": ...,
      "jti": "...",
      // Kapselung des Attestierungsnachweises
      "urn:gematik:params:oauth:client-attestation:tpm2": {
         "attestation_data": "<Base64(client_statement)>",
         "client_statement_format": "client-statement"
       }
    }

5. Authentisierung der Institution (SM(C)-B Token): Parallel dazu erstellt der Client das subject_token. Dies ist ein vom ZETA Client erzeugtes JWT, dessen Hash vom Konnektor mittels der SM(C)-B signiert wird und die Identität der Institution (z.B. Praxis) belegt. Die Audience (`aud`) dieses Tokens ist der Ziel-Fachdienst (Resource Server).
6. Token Request: Der Client sendet eine POST-Anfrage an den /token-Endpoint, die alle Teile kombiniert: grant_type=token-exchange, das subject_token, die client_assertion (mit der eingebetteten Attestierung) und den DPoP-Proof.
7. Validierung durch den AS: Der AS führt eine umfassende Prüfung durch: Validierung der Client Assertion (Signatur gegen den bei der DCR hinterlegten Public Key), des DPoP-Proofs, des Subject Tokens und insbesondere der eingebetteten Attestierung (Prüfung der Quote, der attestation_challenge und der PCR-Werte gegen die Sicherheits-Policy).

Hinweis: Für die Signaturprüfung der Quote muss der Authorization Server die vertrauenswürdigen TPM Stamm- und Zwischensignaturzertifikate installieren, die zum Signieren des Endorsement Key in den TPMs verwendet werden. Eine Liste der CAs wird hier bereitgestellt: [TrustedTPM_RootCA_und_IntermediateCA].

5.5.2.5.2 Pfad B: Token-Erneuerung via Refresh Token

Dieser effiziente Pfad wird genutzt, wenn ein gültiges Refresh Token vorhanden ist.
1. Erstellen der Client Assertion (ohne Attestierung): Der Client erstellt eine einfache client_assertion. Sie beweist durch ihre Signatur mit dem Client Instance Key die Identität des Clients. Diese Assertion enthält keine Attestierungsdaten.

    // Client Assertion für Refresh-Token-Nutzung
    {
      "iss": "<client_id>",
      "sub": "<client_id>",
      "aud": "<AS_Token_Endpoint_URL>",
      "exp": ...,
      "jti": "..."
    }

2. Token Request: Der Client sendet eine POST-Anfrage an den /token-Endpoint mit grant_type=refresh_token, dem Refresh Token und der einfachen client_assertion.
3. Validierung durch den AS: Der AS validiert das Refresh Token, die Signatur der Client Assertion und den DPoP-Proof. Die Prüfung einer TPM-Attestierung entfällt. Bei Erfolg wird das alte Refresh Token invalidiert (Rotation).

5.5.2.5.3 Gemeinsame nachfolgende Schritte

Nach erfolgreicher Validierung in einem der beiden Pfade fragt der AS bei der Policy Engine (PE) an, ob der Zugriff gewährt werden soll. Ist die Entscheidung positiv, stellt der AS ein neues Access Token (gebunden an den DPoP-Schlüssel) und ein neues Refresh Token aus.

5.5.2.6 Ablauf der Authentifizierung bei Dienst-zu-Dienst Kommunikation

5.5.3 PDP Datenbank

Die Datenbank speichert Session-, Nutzer- und Client-Daten. Die Struktur der Daten ist in den Schemadateien [session.yaml], [user-info.yaml], und [client-instance.yaml] festgelegt.

Die Session Daten gemäß [session.yaml] enthalten die Attribute Access Token_jti zur Verlinkung der Session mit dem aktuell gültigen Access Token (Attribut jti) und Refresh Token_jti zur Verlinkung der Session mit dem aktuell gültigen Refresh Token (Attribut jti). Das Attribut subject enthält die Verlinkung mit den User-Daten (Attribut subject) und das Attribut client_id enthält die Verlinkung mit den Client-Daten (Attribut client_id).

Abbildung 7: Beziehungen zwischen Session-, Nutzer- und Client-Daten sowie Token

5.5.4 Sicherheits- und Datenschutzanforderungen an den PDP

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. 

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

5.5.5 Konfiguration

5.6 PIP und PAP Service

Der PIP und PAP Service stellt OPA Bundles für die PDP Policy Engine Instanzen der ZETA Guard 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 die aktive Policy Engine bereitgestellt. Unter dem label "latest-sim" werden Bundles für die Simulations-Policy Engine bereitgestellt.
Der PIP und PAP Service bezieht die OPA Bundles aus einem Git Repository der gematik. Die Bundles werden in einem GitOps CI Prozess mit Quality Gates entwickelt und für die Policy Engines der ZETA Guard 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 Telemetrie-Daten Service

Der Telemetrie-Daten Service ist eine Implementierung des OpenTelemetry-Frameworks der die Telemetrie-Daten aller ZETA Guard-Komponenten einsammelt (Collector) und für die Weitergabe (Exporter) an externe Systeme (Monitoring des Anbieters, gematik Telemetriedaten Schnittstelle und gematik SIEM) aufbereitet.

Zusätzlich nimmt der Telemetrie-Daten Service Fehlermeldungen und Selbstauskunfts-Daten des Resource Servers entgegen und leitet sie an die gematik Telemetriedaten Schnittstelle weiter.

Beispiel: Selbstauskunft OTLP-Log-Nachricht (JSON) vom Resource Server an den Telemetrie-Daten Service. Die Log-Nachricht wird unverändert an die gematik Telemetriedaten Schnittstelle weitergeleitet.

{
  "resourceLogs": [
    {
      "scopeLogs": [
        {
          "logRecords": [
            {
              "timestamp": "1678886400000000000",
              "body": { "stringValue": "Selbstauskunft" },
              "attributes": [
                { "key": "product.name", "value": { "stringValue": "Backend-Service" } },
                { "key": "product.version", "value": { "stringValue": "1.2.0" } },
                { "key": "producttype.version", "value": { "stringValue": "1.2.3" } },
                { "key": "configuration.version", "value": { "stringValue": "cfg-rev-45" } },
                { "key": "pod.name", "value": { "stringValue": "my-app-pod-1" } }
              ]
            }
          ]
        }
      ]
    }
  ]
}

5.8 Betrieb

Die Komponenten des ZETA Guard werden in einer Kubernetes (k8s) Umgebung betrieben. In einem von der gematik vorgegebenen Git Repository werden die Konfigurationsdateien des ZETA Guards bereitgestellt, mit denen die ZETA Guard Instanz für den TI 2.0 Dienst erstellt und ausgeführt werden kann. Im ZETA Guard ist ein Management Service (eine Continuous Delivery (CD) Komponente) enthalten, der den Betriebszustand des ZETA Guards überwacht und regelmäßig prüft, ob eine neuere Version des ZETA Guards im Git Repository verfügbar ist, und ggf. ZETA Guard automatisch aktualisiert.

Hinweis: Für TI 2.0 Dienste, die inkl. ZETA Guard in der VAU betrieben werden, wird noch festgelegt, wie sichergestellt wird, dass ZETA Guard-Komponenten eingesetzt werden.

Hinweis: Die Kubernetes Manifeste (Konfiguration) des ZETA Guards werden per git submodule in das git Repository der gematik integriert, sodass der Anbieter des ZETA Guards seine Konfiguration selbständig anpassen kann.

5.8.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.8.2 Anforderungen für Steuerung durch Feature-Flags

Feature Flags dürfen nur unter 4 Augen und unter strenger Einhaltung des Change-Management Prozesses geändert werden.

5.8.3 Anforderungen zur Überwachung des Betriebsstatus

Hinweis: Im ZETA Guard ist dafür der Telemetrie-Daten Service vorgesehen, der die Daten an ein Monitoring System des Anbieters weitergibt.

Der Hersteller der ZETA Guard-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 im Rahmen der ZETA Guard-Komponenten nicht an. Diese sind bei Bedarf vom jeweiligen TI 2.0 Dienst eigenständig einzusetzen.

5.8.4 Leistungs-Anforderungen

Hinweis: Anfragen an abhängige Dienste im Hintergrund, um einen Request vollständig zu bearbeiten (z.B. OCSP), werden bei den Bearbeitungszeiten mit berücksichtigt, jedoch nicht dem abfragenden Dienst zur Last gelegt.

5.8.5 Betriebliche Schnittstellendefinition

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

Tabelle 12: Tab_gemSpec_ZETA_Schnittstellendefinition_ZETA_Guard

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

Tabelle 13: Tab_gemSpec_ZETA_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 im Kapitel 5.7 Telemetrie-Daten Service beschrieben.

5.9 Anforderungen an Dienste der TI

Dienste der TI (Resource Server), die durch einen ZETA Guard geschützt sind, erhalten nur Requests von Clients oder anderen Diensten, wenn der PDP des ZETA Guard den Zugriff gewährt und ein Access Token ausgestellt hat. Der PEP des ZETA Guards setzt durch, dass nur Requests mit gültigem Access Token zum Resource Server gelangen.

5.10 Anforderungen an den Test der Zero Trust-Komponenten

5.11 Sicherheitsleistungen des ZETA Guard für Resource Server

Der ZETA Guard bietet umfassende Sicherheitsleistungen für Resource Server in der TI 2.0, indem er das Zero Trust-Paradigma umsetzt. Seine wichtigsten Sicherheitsleistungen lassen sich wie folgt zusammenfassen:

• Zugriffskontrolle: Der Policy Enforcement Point (PEP) fungiert als HTTP Proxy und kontrolliert den gesamten Datenverkehr zwischen Client-Anwendungen und dem Resource Server. Er lässt nur Anfragen mit gültigem Access Token durch, das vom Policy Decision Point (PDP) ausgestellt wurde. Zusätzliche Prüfungen, gesteuert durch Attribute im Access Token, können integriert werden. Optional kann konfiguriert werden, dass im Request Header PoPP ein PoPP Token vorhanden sein muss.
• Clientregistrierung: Der ZETA Guard setzt eine sichere Clientregistrierung durch, bei der Clients durch verschiedene Mechanismen attestiert werden (z.B. Android Key ID Attestation, Apple DCAppAttest, SM(C)-B signiertes JWT, TPM signiertes JWT). Der Client wird an eine TI-Identität gebunden. Der ZETA Guard unterstützt die Nutzer bei der Registrierung und Verwaltung der Client-Registrierungen.
• Autorisierung und Authentifizierung: Der ZETA Guard OAuth2 Authorization Server steuert die Authentifizierung des Nutzers. Die Entscheidung zur Ausstellung des Access Token, nach erfolgreicher Client-Registrierung und Authentifizierung, wird durch die ZETA Guard Policy Engine basierend auf definierten Richtlinien (Policies) getroffen. Dies beinhaltet die Überprüfung von Nutzer- und Client-Registrierungsdaten inkl. Client-Attestierung. Unterstützte Authentifizierungsverfahren sind SM(C)-B mit DPoP sowie Authentifizierung über sektorale oder zentrale IDPs mit OIDC.
• Policy-Based-Access-Control: Der Policy Information Point (PIP) und der Policy Administration Point (PAP) verwalten und liefern die freigegebenen Policies an die ZETA Guard Policy Engine. Die Policies sind maschinenlesbar und definieren die Zugriffsregeln, nach denen die Entscheidung zur Ausstellung von Access und Refresh Token erfolgt. Die Integrität und Authentizität der Policies wird durch Signaturen sichergestellt.
• Schutz vor Token-Theft: Durch den Einsatz von DPoP wird verhindert, dass gestohlene Access und Refresh Token durch Angreifer verwendet werden können, um Zugriff auf den Resource Server zu erhalten.
• Datenverschlüsselung: Alle Komponenten des ZETA Guards stellen die Vertraulichkeit und Integrität der transportierten Daten sicher, indem sie TLS an allen Endpunkten verwenden und clientseitig mTLS unterstützen. Die ZETA Guard Daten (ZETA/ASL-Daten, Session-, User- und Client-Daten) werden bei der Persistenz zusätzlich verschlüsselt. Der ZETA Guard kann so konfiguriert werden, dass private Schlüssel in einem Hardware Security Module (HSM) gespeichert werden.
• VAU Unterstützung: Der ZETA Guard kann optional in einer Vertrauenswürdige Ausführungsumgebung (VAU) ausgeführt werden.
• Mehrschichtige Transport-Sicherheit: ZETA/ASL bietet neben TLS eine zweite Sicherungsschicht beim Transport der Daten vom Client zum ZETA Guard, um Schwachstellen in der TLS-Schicht abzufangen. Dies schützt vor bekannten und zukünftigen Schwachstellen in TLS-Protokoll und -Implementierungen. Der Betrieb der Anwendung kann fortgeführt werden, selbst wenn Schwachstellen im TLS-Protokoll entdeckt werden. Diese Funktion ist optional nutzbar.
• Monitoring und Logging: Der ZETA Guard sammelt Telemetrie-Daten und sicherheitsrelevante Ereignisse von PEP und PDP, um die Sicherheit kontinuierlich zu überwachen. Dies beinhaltet die Erkennung von Anomalien und potenziellen Bedrohungen. ZETA Guard sendet fachdienstspezifische Telemetrie-Daten und sicherheitsrelevante Ereignisse an die gematik (TI SIEM und gematik Telemetriedaten Schnittstelle) sowie an den Anbieter des TI 2.0 Dienstes in einer anonymisierten Form, um eine Profilbildung zu verhindern.
• Sicherheits- und Produktgutachten: Für die ZETA Guard Implementierung werden ein Sicherheits- und ein Produktgutachten bereitgestellt.
• Betriebshandbuch sowie Sicherheits- und Datenschutzkonzept: Im Betriebshandbuch sind die Anforderungen an den Betrieb sowie die Konfiguration des ZETA Guard beschrieben. Im Sicherheits- und Datenschutzkonzept sind die Bedrohungen und umgesetzten Maßnahmen gegen Bedrohungen beschrieben. Dadurch wird für den Anbieter des TI 2.0 Dienstes erkennbar, welche zusätzlichen Sicherheitsleistungen zum Schutz des Dienstes und der Daten vom Anbieter erbracht werden müssen.

5.12 Weitere Leistungen des ZETA Guard für Resource Server

Der ZETA Guard übernimmt für Resource Server weitere Leistungen:

• gematik Telemetriedaten Lieferung: Der Telemetrie-Daten Service sammelt von allen Komponenten des ZETA Guard Metriken, Traces und Logdaten und bereitet diese für den Versand an das Monitoring des TI 2.0 Dienst-Anbieters und an den gematik Telemetriedaten Empfänger in anonymisierter Form auf.
• SIEM Daten Lieferung: Der Telemetrie-Daten Service sammelt vom Monitoring des TI 2.0 Dienst-Anbieters SIEM Daten und leitet sie an das SIEM der gematik weiter.
• Notification Service: Der ZETA Guard implementiert eine API um Notification-Konfigurationen für Nutzer und ihre Clients zu speichern und um Notification-Events vom Resource Server entgegenzunehmen und an die Clientsystem Notification Services weiterzuleiten.
• Protected Resource Metadata: Über den HTTP Proxy können Clients das OAuth 2.0 Protected Resource Metadata Well-known JSON-Dokument ([RFC9728]) abfragen, um die notwendigen Informationen für die Interaktion mit diesem Resource Server zu erhalten.

6 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 [gemAPI_ZETA] 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.

7 Anhang A – Verzeichnisse

7.1 Abkürzungen

Tabelle 14: Im Dokument verwendete Abkürzungen

7.2 Glossar

Tabelle 15: Glossar der explizit im Dokument verwendeten Begriffe

7.3 Abbildungsverzeichnis

7.4 Tabellenverzeichnis

7.5 Referenzierte Dokumente

7.5.1 Dokumente der gematik

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

Tabelle 16: Referenzierte Dokumente der gematik

7.5.2 Weitere Referenzen

Tabelle 17: Weitere Referenzen