Telematikinfrastruktur 2.0

Spezifikation

Zero Trust Access (ZETA)

Version
1.3.0
Revision
1573785
Stand
17.04.2026
Status
freigegeben
Klassifizierung
öffentlich
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 Nutzer 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 Nutzer 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 Client-Registrierung

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. Clients sind hier als Kombination aus Gerät (z. B. PC oder mobile Device) und App (Client-Software wie FdV oder Primärsystem)  definiert. Um Clients wiedererkennbar zu machen, muss eine Registrierung dieser erfolgen. Sind in der Registrierung zusätzliche Sicherheitsmerkmale über den 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 Client-Attestation

Die Client-Attestation dient dem Nachweis der Integrität einer Client-Instanz (z. B. einer Frontend-Applikation oder eines Primärsystems) gegenüber einem ZETA Guard. Im Rahmen der Client-Registrierung reicht der Client einen kryptografisch signierten Nachweis ein, der belegt, dass die Anwendung nicht durch unbefugte Dritte modifiziert wurde (Integrität).

Dieser Mechanismus ist ein wesentlicher Bestandteil des Zero-Trust-Modells der TI 2.0, um den Missbrauch von Client-Identitäten durch manipulierte Software oder automatisierte Skripte zu verhindern.

Die ZETA Client-Attestation erfolgt nach [RFC9334].

2.1.3 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 Anomalie-Erkennung 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 Telemetriedaten wird die Durchsetzung von Policies sowie die Auswirkung möglicher Policy-Änderungen transparent.

2.5 Authorization

Die Autorisierung (Authorization) beschreibt innerhalb von ZETA den Prozess der Prüfung und Erteilung von Zugriffsrechten auf geschützte Ressourcen. Während die Authentisierung die Identität eines Nutzers oder Systems feststellt, definiert die Autorisierung, welche Operationen dieser Teilnehmer auf welchen Daten oder Diensten ausführen darf.

In ZETA Guard bildet die Autorisierung den Kern der Zugriffskontrolle. Ziel ist es, das Prinzip der minimalen Rechtevergabe (Principle of Least Privilege) konsequent umzusetzen.

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 keine TI-Plattform-Produkttypen in der Kommunikation zwischen Clients mit Diensten involviert werden.

3.1 ZETA als Umsetzung der Zero Trust Architektur

Im Folgenden ist eine generische Produkttypzerlegung für die Umsetzung der Zero Tust-Referenzarchitektur einer TI 2.0- Fachanwendung dargestellt. Die Zero Trust Ausprägung der Telematikinfrastruktur wird Zero Trust Access (ZETA) genannt.

In diesem Pattern greift ein Nutzer über einen Clientsystem (inkl. ZETA Client) auf Daten eines TI 2.0-Dienstes zu. Ein Nutzer wird hier als der Akteur definiert, der einen TI 2.0-Dienst nutzt. Dabei kann es sich um einen Versicherten oder um einen Mitarbeiter in einer Organisation des Gesundheitswesens handeln (z. B. LEI, LEO, Krankenkasse). 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 Resource Server verbunden und vom Anbieter des TI 2.0-Dienstes zwingend mit betrieben. Der Anbieter implementiert zusätzliche Komponenten, um seine Infrastruktur vor Angriffen aus dem Internet zu schützen und um die Zugriffe zu optimieren (z. B. Content Delivery Network, eigener Ingress und Load Balancer, Web Application Firewall). 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). Darüber hinaus soll durch die roten und gestrichelt umrandeten Komponenten hervorgehoben werden, dass je nach Einsatzumgebung und Anforderungen an die Umgebung verschiedene Deployment-Szenarien unterstützt werden. 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 Empfänger) 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. 

3.2 Kurzbeschreibung der Komponenten

Zu ZETA gehören ZETA Guard, ZETA Client und die ZETA Artifact Registry. Der ZETA Client implementiert clientseitig die Schnittstellen des ZETA Guard und die Attestation-Funktionen des Clientsystems. Der ZETA Client wird von einem Fach-Client initialisiert und mit fachlichen HTTP Requests aufgerufen. ZETA Client führt alle Schritte aus, um ein Access Token vom ZETA Guard zu erhalten, um dann mit diesem Access Token den Request vom Fach-Client an den ZETA Guard zu senden. Die Response wird an den Fach-Client weitergeleitet. Die ZETA Artifact Registry stellt signierte Images für die ZETA Guard Komponenten sowie signierte Policies und Daten für die ZETA Guard Policy Engine bereit. Zusätzlich werden Provisioning Daten wie aktuelle TSL und TPM Hersteller-Stammzertifikate bereitgestellt.

ZETA Guard besteht aus folgenden Komponenten:

• PEP HTTP Proxy: Die zentrale Durchsetzungsinstanz für den Datenverkehr.
• PDP Authorization Server: Die Instanz zur Ausstellung von Access Token und Session-Management.
• PDP Policy Engine (OPA): Die Komponente zur Auswertung der Zugriffsregeln.
• Telemetriedaten-Service: Der OpenTelemetry Collector für sicherheitsrelevante Ereignisse, Traces, Log-Daten und Metriken.
• Notification Service: Optionale ZETA Guard Komponente zur einheitlichen Bereitstellung von Notification-Funktionen für mobile Clients.
• PDP Datenbank: Persistenzschicht für Sessions sowie Nutzer- und Client-Daten.
• HSM Proxy: Schnittstelle zu den ZETA Guard Komponenten und das Hardware-Sicherheitsmodul des Anbieters.
• Local Artifact Registry Cache: Lokales Repository zur Bereitstellung der Images innerhalb der Anbieter-Umgebung.
• Gateway oder Ingress und Egress: Netzwerk-Einstiegspunkt für den Kubernetes Cluster und kontrollierter Grenzübergang für den ausgehenden Verkehr.
• Admission Controller: Hilfskomponente, die Anfragen an den Kubernetes API Server überwacht um Security Policies (wie z. B. die Prüfung der Image-Signatur, bevor ein Image ausgeführt werden kann) durchzusetzen.
• Service Mesh: Infrastrukturschicht, die die Kommunikation zwischen den einzelnen Microservices innerhalb eines Clusters steuert, sichert und überwacht.

3.3 Kurzbeschreibung der Schnittstellen

(1) Die ZETA Guard Instanz wird beim TI Federation Master registriert. Dadurch wird die Zugehörigkeit des ZETA Guard zur TI (in einer bestimmten Umgebung wie Prod, Ref oder Test) durch Signatur des Federation Masters verifizierbar. In einer Folgeversion wird ZETA Guard im Authorization Server Well-known ein Trustmark vom Federation Master enthalten, das die Zugehörigkeit zur TI nachweist.

(2) Die gematik stellt eine ZETA Artifact Registry bereit, die Helm Charts, Images für die ZETA Guard Komponenten und Provisioning Images als OCI Container Images bereitstellt. Alle Images haben eine Signatur mit einer gematik Identität. Anbieter von TI 2.0-Diensten betreiben einen lokalen Artifact Registry Cache, der die ZETA OCI Images direkt in der Umgebung des Anbieter verfügbar macht. In einer Folgeversion wird der Local Artifact Registry Cache Teil von ZETA Guard, um die Anbieter von TI 2.0 Diensten zu entlasten.

(3) Die Policy Engine erhält die Policies und Daten direkt aus der ZETA Artifact Registry.

(4) Die Schnittstelle des HSM Proxy Richtung ZETA Guard Komponenten ist spezifiziert und ermöglicht die einheitliche Anbindung von HSMs verschiedener Hersteller. Der HSM Proxy enthält aktuell nur Funktionen, die von ZETA Guard Komponenten benötigt werden. Grundsätzlich soll der HSM Proxy auch Komponenten des Resource Servers den einheitlichen Zugriff auf HSMs ermöglichen. Fehlende Funktionen werden nach Bedarf ergänzt.

(5) Falls eine Mandantentrennung verwendet wird, dann kann der Fachclient durch Abfrage eines Well-known JSON-Dokuments die zu verwendende URL des Resource Servers ermitteln.

(6) Der ZETA Client bietet dem Fach-Client Operationen zur Initialisierung und zum Versenden von HTTP Requests an. Das heißt, der Fach-Client erstellt einen vollständigen HTTP Request inkl. fachlich benötigter Header und ruft den ZETA Client zur Ausführung des Requests auf. Der ZETA Client ermittelt aus der URL des HTTP Requests im ersten Schritt die Well-known Metadaten des Resource Servers und des Authorization Servers und konfiguriert sich für die Nutzung der ZETA Guard Instanz.

(7) Aus dem Authorization Server Well-known hat der ZETA Client die Endpunkte für die Client-Registrierung und Autorisierung ermittelt und beginnt den OAuth Flow.

(8) Bei mobilen Clients erfolgt eine Trust On First Use Bindung des Clients an eine E-Mail-Adresse des Nutzers.

(9) Der Nutzer muss einen Code aus der Mail vom ZETA Guard im mobilen Clients eingeben, um den Registrierungsprozess des mobilen Clients fortzusetzen.

(10) Bei Primärsystemen erfolgt die Authentifizierung des Nutzers (hier der Organisation) durch ein SMC-B-signiertes Token per OAuth Token Exchange. Die Signatur kann durch Nutzung eines Konnektors oder TI Gateways aber auch durch Nutzung eines direkt am Primärsystem angeschlossenen Kartenterminals erfolgen.

(11), (12) Mobile Nutzer werden mit Hilfe des sektoralen IDPs und des OIDC Flows authentifiziert.

(13) Nachdem die Session-, Client- und Authentifizierungsdaten am Authorization Server validiert wurden, werden diese Daten an die Policy Engine übergeben. Die Policy Engine wendet die Daten auf die Policies und vorgegebenen Wertebereiche an, ermittelt eine Entscheidung und sendet die Entscheidung an den Authorization Server.

(14) Wenn eine Anwendung eine zusätzliche Authorization benötigt, dann wird der Authorization Server so konfiguriert, dass das Authorization Backend für weitere Autorisierungs-Schritte angefragt wird.

(15) Der Authorization Server speichert seine Session-, Client- und Userdaten in der PDP Datenbank. Wenn die Policy Engine eine "Allow"-Entscheidung gefällt hat und auch kein Verbot vom Authorization Backend vorliegt.

(16) Der ZETA Client sendet einen Request Richtung Resource Server. Der HTTP Proxy erlaubt den Zugriff auf Daten des Resource Servers, wenn ein gültiges Access Token im Authorization Header enthalten ist.

(17) Nach erfolgreicher Prüfung des Access Token und des DPoP Token (wenn vorhanden auch des PoPP Token) erfolgt die Weiterleitung des Requests zum Resource Server. Falls ZETA/ASL verwendet wird, erfolgt zuerst der ASL-Verbindungsaufbau.

(18) Vom Resource Server werden Traces und die Selbstauskunft an den Telemetriedaten-Service gesendet. Der Telemetriedaten-Service empfängt von allen ZETA Guard Komponenten Traces, Logs und Metriken. Die Verbindungspfeile dafür sind nicht dargestellt. Zum Einsatz kommt OpenTelemetry. Alle von OpenTelemetry unterstützten Protokolle können vom Anbieter durch Konfiguration des Telemetriedaten-Service verwendet werden, um Daten an den Telemetriedaten-Service zu senden und vom Telemetriedaten-Service zu empfangen. Empfohlen wird das native OTLP Protokoll über gRPC.

(19) Der Telemetriedaten-Service empfängt vom SIEM des TI 2.0-Dienst-Anbieters Security Events.

(20) Der Telemetriedaten-Service kann Monitoring-Daten der ZETA Guard-Komponenten an das Monitoring des TI 2.0-Dienst-Anbieters senden.

(21) Traces, Metriken und Log Events werden an den Telemetriedaten-Empfänger der gematik weitergeleitet.

(22) Security Events werden an das TI SIEM der gematik weitergeleitet.

(23) Das Clientsystem kann über den ZETA Client eine Push-Konfiguration im ZETA Guard Notification Service einrichten.

(24) (25) Wenn Ereignisse eintreten, für die der Resource Server eine Push Nachricht für den Nutzer generiert, dann werden entsprechend der vorhandenen Push-Konfigurationen des Nutzers im Notification Service, Benachrichtigungen an den Client gesendet.

(26) Über den Clientsystem Notification Service (und hier nicht dargestellte Notification Services des mobile OS Herstellers) werden Notifications an das Clientsystem gesendet.

(27) Mittels Shared Signals kann das Monitoring (oder eine andere Komponente des TI 2.0-Dienst-Anbieters) die Session eines Clients beenden und somit eine neue Authentifizierung erzwingen. Aktuell ist die Shared Signals Unterstützung durch SIEM Systeme und Infrastrukturkomponenten noch nicht hinreichend gegeben. Daher werden Shared Signals bis auf weiteres noch nicht von ZETA unterstützt.

(28) Der Kubernetes Cluster bezieht seine Deployment-Images aus dem lokalen Artifact Registry Cache sowie die Provisioning Daten für ZETA Guard (TSL, roots.json, TPM-Hersteller Stammzertifikate, Federation Master URL).

Der Admission Controller setzt durch, dass nur von der gematik signierte OCI Container Images der ZETA Guard Kernkomponenten ausgeführt werden können.

Über ein Service Mesh kann sichergestellt werden, dass nur die Komponenten, die miteinander kommunizieren dürfen, eine Verbindung zueinander aufbauen können.

Der optionale 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. Dadurch wird ein Configuration-Drift unterbunden.

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 Telemetriedaten Service). Der PEP besteht aus einem HTTP Proxy. 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 Nutzer 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 Telemetriedaten 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 von besonderer Bedeutung:

• Der PDP fungiert als OAuth2 Authorization Server und verwaltet die Autorisierung von Nutzeranfragen auf geschützte Ressourcen. Zudem überwacht der Authorization Server die Nutzersessions, 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 Nutzern sicher und vertrauenswürdig beziehen und bei Bedarf eine (erneute) Nutzerauthentifizierung an die IDPs delegieren. Der Authorization Server stellt sicher, dass nur authentifizierte Nutzer mit registrierten Clients 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) 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 Nutzeridentitä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 Token, das für den konkret angefragten Zugriff verwendet wird (siehe Policy Enforcement).

• Die Policy Engine verwendet dabei die Informationen, die sie von der ZETA Artifact Registry bezieht und die Daten der Zugriffsanfrage vom Authorization Server, um die Zugriffsentscheidung zu treffen. Dazu gehören nicht nur die Policies selbst, sondern auch Echtzeitinformationen über den Zustand von Nutzeridentitäten, Clients und andere Kontextinformationen, die für die Bewertung der Zugriffsanfrage relevant sind.

Am PDP werden Betriebsdaten erhoben, verarbeitet und dem Telemetriedaten 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 Nutzers 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 Client-Registrierungen

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 Policy Engines im Zero Trust-Netzwerk Zugriff auf aktuelle Sicherheitsrichtlinien ermöglicht. Der PIP kann Attribute wie Nutzerrollen, Zugriffsrechte, Clientzustände und andere Kontextinformationen bereitstellen, die von den Policy Engines 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 Nutzerrollen, Gruppenzugehörigkeit, Standorten und Clientattributen - zu differenzieren. Änderungen an den Sicherheitsrichtlinien, die im PAP vorgenommen werden, werden von den Policy Engines im Zero Trust Netzwerk übernommen. Das Vertrauen in bereitgestellte und angepasste Policies wird über Signaturen für die Sicherstellung von Integrität und Authentizität jeder Policy sichergestellt.

4.5.3 PIP und PAP Ausprägung in ZETA

In ZETA Guard wird als Policy Engine der Open Policy Agent (OPA) verwendet. OPA bezieht Policies (PAP) und Daten (Wertebereiche für die Policies; PIP) zusammengefasst (OPA Bundle) über ein OCI Container Image aus der ZETA Artifact Registry der gematik. Die einzelnen Dateien im OPA Bundle sind mit einer Identität der gematik signiert.

Dadurch reduziert sich die Bereitstellung der PIP und PAP Daten zu einem Download in einer OCI Registry. Die Anforderungen an den PIP und PAP Service (siehe 5.13 Policies und Daten) beziehen sich daher auf den Policies und Daten CI/CD-Prozess zur Entwicklung und Bereitstellung der Policies und Daten.

4.6 Client-Registrierung

Die Client-Registrierung dient dazu, eine konkrete Installation eines Clientsystems eindeutig zu identifizieren und, wenn möglich, mit einem Nutzer zu verknüpfen. Dabei werden sowohl statische Eigenschaften des Clientsystems als auch dynamische Eigenschaften der Client-Instanz übermittelt.

Die Clientattribute werden vom Client und von den Plattformen der Endgeräte geliefert. Ihre Erhebung erfolgt im ZETA Client des Endgeräts mittels plattformspezifischer Attestierungs- und Erhebungsmechanismen. Die Attribute sind daher für die jeweilige Plattform und ihr Sicherheitsmodell spezifisch. Siehe Kapitel 5.9 Client-Registrierungsdaten.

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.

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.

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.

Aktuell ist die Shared Signals Unterstützung durch SIEM Systeme und Infrastrukturkomponenten noch nicht hinreichend gegeben. Daher werden Shared Signals bis auf weiteres noch nicht von ZETA unterstützt.

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 Telemetriedaten-Service erfasst. Bei der Nachbereitung der Telemetriedaten 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 Nutzer zusätzliche Authentifizierungsschritte durchlaufen muss, um auf sensible Ressourcen zuzugreifen. Diese Maßnahme wird wie folgt realisiert:

1. Nutzer stellt über den ZETA Client eine Anfrage: Der Nutzer versucht auf eine Ressource zuzugreifen, für die das aktuelle Access Token nicht ausreicht.
2. PEP fängt Anfrage ab: Der PEP empfängt die Anfrage.
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 und die passende Audience für die angeforderte Ressource?
4. Zugriff verweigert: Wenn der erforderliche Scope oder die Audience nicht im Access Token enthalten ist, verweigert der PEP den Zugriff.
5. PEP antwortet mit Step-up-Anforderung: Wenn die angefragte Ressource auf dem Resource Server existiert, informiert der PEP den Nutzer, dass für den Zugriff ein Access Token mit einem bestimmten Scope und einer bestimmten Audience benötigt wird.
6. Nutzer initiiert die Step-up-Authentifizierung: Der ZETA Client kommuniziert mit dem Authorization Server, um die Authentifizierung für den benötigten Scope und die Audience zu beginnen.
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 passendem Scope und passender Audience.
• Gibt das neue Access Token an den ZETA Client zurück.
8. Nutzer stellt eine erneute Anfrage: Der Nutzer sendet die Anfrage mit dem neuen Access Token an den PEP.
9. PEP prüft das neue Token: Der PEP prüft wieder:
• Ist das neue Access Token gültig?
• Hat das neue Access Token den Scope und die Audience für die angeforderte Ressource?
10. Zugriff gewährt: Wenn der erforderliche Scope und die Audience 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.

5.1 Übergreifende Anforderungen für Datenschutz und Sicherheit

Hinweis: Es gibt ein Kapitel in dem ZETA Guard Handbuch, das die Integration von Clientsystemen mit Zeta Guard beschreibt. Das Kapitel beschreibt die Client-Informationsobjekte, die der Client verarbeiten muss.

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

Hinweis: Die Anforderungen gelten für die gesamte ZETA‑Guard‑Lösung. Entscheidet sich ein Anbieter dafür, eine eigene Komponente anstelle einer von ZETA bereitgestellten Komponente (z. B. Ingress) zu verwenden, legt der Sicherheitsgutachter(Anbieter) fest, welche Risiken aus der Top‑10‑Liste für diese Komponente relevant sind, da deren konkrete Umsetzung anbieterabhängig ist.

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

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

Hinweis: Die Images für ZETA Guard werden mit einem Zertifikat der Komponenten PKI signiert. Das Zertifikat und die zugehörige Kette müssen für die Signaturprüfung verwendet werden.

Hinweis: Das SBOM für das gesamte Produkt (inkl. ZETA Guard) kann durch den Hersteller über mehrere Dateien abgebildet werden. Für ZETA Guard wird immer ein eigenständiges SBOM geliefert.

ZETA-Guard implementiert für Stufe 1 eine vereinfachte Prüfung des Clients auf gesperrte IP-Adressen und Impossible Travel. Diese Vereinfachung ist möglich, da in Stufe 1 nur eine Role (LEI) mit einem stationären Endgerät vorgesehen ist.

5.2 Schlüssel Management und Verwaltung in ZETA

Teil der Sicherheitsarchitektur von ZETA ist ein robustes Schlüsselmanagement. Um Entwicklern, Betreibern und Auditoren ein klares Verständnis der kryptografischen Architektur zu vermitteln, verwendet diese Spezifikation standardisierte Schlüssel-IDs (z.B. PrK.AuthS.Sig für den privaten Signaturschlüssel des Authorization Servers).

5.2.1 Nomenklatur für Schlüssel-IDs

Jeder Schlüssel erhält eine eindeutige ID nach folgendem Schema: [Typ].[Komponente].[Zweck]

Typ:

• PrK: Privater Schlüssel (Private Key)
• PuK: Öffentlicher Schlüssel (Public Key)
• C: Zertifikat (Public Key inkl. Identitätsbindung, Certificate)
• SymK: Symmetrischer Schlüssel (Symmetric Key)

Komponente oder Schlüssel:

• AuthS: Authorization Server (PDP)
• PEP: Policy Enforcement Point (HTTP Proxy)
• DB: Datenbank (PDP DB)
• Client: ZETA Client (App / Primärsystem)
• K8s: Kubernetes / Infrastruktur
• Sys: Gematik / Zentrales System
• AK: Attestation Keys
• EK: TPM Endorsement Keys
• DPoP: DPoP Keys
• SM(C)-B: SM(C)-B Keys
• TI-RootCA: TI Root CA Signer Keys
• TI-TSL: TI TSL Signer Keys
• TI-KompCA: TI Komponenten PKI CA Keys
• TI-FedMaster: Federation Master Signer Keys
• ZETA-IK: ZETA OCI Container Image Signer Keys
• ZETA-DK: ZETA OCI Data Image Signer Keys
• ZETA-PAK: ZETA OPA Bundle Autor Signer Keys
• ZETA-PFK: ZETA OPA Bundle Freigeber Signer Keys

Zweck:

• TLS: Verschlüsselung des externen Traffics
• mTLS: Interne Komponenten Authentifizierung
• ASL: Application Security Layer
• Sig: Signatur (Token, Policies, Entity Statements)
• Enc: Payload-/Daten-Verschlüsselung (JWE, DB At-Rest)

5.2.2 Übersicht der ZETA Guard Schlüssel (Anbieter-Seite)

Diese Tabelle fasst alle Schlüssel zusammen, die vom Betreiber des TI 2.0-Dienstes (ZETA Guard) verwaltet werden müssen. Bei Verarbeitung von Daten mit Schutzbedarf "sehr hoch" greifen strenge VAU- und HSM-Pflichten.

Hinweis: Schlüssel mit dem Vermerk "Die Schlüsselverwaltung muss dokumentiert werden", werden vom Anbieter des TI 2.0 Dienstes verwaltet. Die Schlüssel ohne Vermerk verwaltet ZETA Guard automatisch.

Betriebsmodi und Schlüsselschutz:
Der ZETA Guard unterscheidet zwei primäre Betriebsmodi:

1. Regulärer Betrieb (ohne VAU): Schlüssel werden in sicheren Software-Keystores (z.B. KMS v2) der jeweiligen Container-Umgebung abgelegt.
2. Betrieb mit Schutzbedarf "sehr hoch" (mit VAU): Sobald sensible Daten verarbeitet werden, muss der ZETA Guard in einer Vertrauenswürdigen Ausführungsumgebung (VAU) betrieben werden (siehe A_25608-01). In diesem Fall MÜSSEN asymmetrische private Schlüssel der TI- und Internet-Identitäten zwingend in einem Hardware Security Module (HSM) verbleiben. Schlüssel, die in den Arbeitsspeicher der VAU geladen werden müssen (z.B. Token-Signatur- oder Datenbank-Schlüssel), müssen durch HSM-generierte Key-Encryption-Keys (KEK) "gewrappt" (Sealing) übergeben werden.

Tabelle 1: Tab-ZETA-Guard-Keys

5.2.3 ZETA Client Schlüssel (Nutzer-Seite)

Diese Schlüssel verbleiben in der Verfügungsgewalt des Endnutzers (Smartphone / Primärsystem) bzw. der Institution.

Tabelle 2: Tab-ZETA-Client-Keys

5.2.4 gematik verwaltete Schlüssel (TI)

Diese Zertifikate und Schlüssel spannen den Vertrauensraum der TI 2.0 auf. Die privaten Schlüssel liegen hochsicher bei der gematik (bzw. den zugelassenen Trust Centern). Die ZETA Guards und Clients nutzen die öffentlichen Teile/Zertifikate zur Validierung. Diese Schlüssel dienen der Sicherstellung der Supply-Chain-Security und der Integrität von Regelwerken.

Tabelle 3: Tab-Gematik-Keys

5.3 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 Telemetriedaten Service im ZETA Guard muss die vom PEP und PDP gesammelten Telemetriedaten 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.4 Sicherheits- und Datenschutz-Anforderungen an das Security Monitoring

Um eine lückenlose Nachvollziehbarkeit komplexer Systeminteraktionen zu gewährleisten, ist die nahtlose Verknüpfung aller anfallenden Telemetriedaten entscheidend. Jede einzelne Anfrage löst eine Vielzahl von Prozessen, Logs und Metriken aus, die erst durch eine konsistente Korrelation ihren vollen diagnostischen Wert entfalten. Ziel ist es, die gesamte Verarbeitungskette eines Requests über alle ZETA-Komponenten hinweg als zusammenhängendes Ereignis sichtbar zu machen, sodass die kausalen Zusammenhänge zwischen den verschiedenen Datenpunkten jederzeit transparent und ohne Informationsverlust nachverfolgbar bleiben.

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

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

Hinweis: Falls der Anbieter aufgrund einer Netzwerk-Sicherheitsrichtlinie Anfragen mit bestimmten Kommunikationsmerkmalen (z. B. Zugriffe aus einem NOR-Netzwerk oder Botnetz) am Netzwerk-Perimeter blockiert, hat diese Richtlinie Vorrang. Es wird nicht erwartet, dass entsprechende Requests dennoch an den ZETA Guard weitergeleitet, da diese Anfragen bereits durch den Schutzmechanismus am Netzwerk-Perimeter abgefangen werden.

Hinweis: Forbidden Countries beinhaltet eine Liste von IP-Ranges der Länder-ASN.

Hier ein Beispiel Metric für die Anzahl von Zugriffen von Botnetzen:

{
  "resourceMetrics": [
    {
      "resource": {
        "attributes": [
          {
            "key": "service.name",
            "value": {
              "stringValue": "zeta-guard"
            }
          },
          {
            "key": "service.version",
            "value": {
              "stringValue": "1.0.0"
            }
          }
        ]
      },
      "scopeMetrics": [
        {
          "scope": {
            "name": "zeta-guard-kpis",
            "version": "1.0.0"
          },
          "metrics": [
            {
              "name": "zeta_guard_kpi_botnet_accesses_24h",
              "description": "Number of botnet accesses detected by ZETA Guard in the last 24 hours",
              "unit": "1",
              "sum": {
                "isMonotonic": true,
                "aggregationTemporality": "AGGREGATION_TEMPORALITY_DELTA",
                "dataPoints": [
                  {
                    "attributes": [
                      {
                        "key": "date",
                        "value": {
                          "stringValue": "2026-03-09"
                        }
                      }
                    ],
                    "startTimeUnixNano": "1762128000000000000",
                    "timeUnixNano": "1762214400000000000",
                    "asInt": "123"
                  }
                ]
              }
            }
          ]
        }
      ]
    }
  ]
}

Hier ein Beispiel eines OTel-Logs für die Policyentscheidung:

{
  "resourceLogs": [
    {
      "resource": {
        "attributes": [
          {
            "key": "service.name",
            "value": {
              "stringValue": "openpolicyagent"
            }
          },
          {
            "key": "service.version",
            "value": {
              "stringValue": "1.14.0"
            }
          },
          {
            "key": "opa.instance.id",
            "value": {
              "stringValue": "4794056b-0001-48e2-8acf-3a6fb0287384"
            }
          },
          {
            "key": "opa.bundle.authz",
            "value": {
              "stringValue": ""
            }
          }
        ]
      },
      "scopeLogs": [
        {
          "scope": {
            "name": "openpolicyagent.org/decision_logs",
            "version": "1.14.0"
          },
          "logRecords": [
            {
              "timeUnixNano": "1741170585787524800",
              "observedTimeUnixNano": "1741170585787524800",
              "severityNumber": 9,
              "severityText": "INFO",
              "body": {
                "stringValue": "Decision Log"
              },
              "attributes": [
                {
                  "key": "opa.decision_id",
                  "value": {
                    "stringValue": "d88b7796-8e90-441e-a572-a2f6ea179c18"
                  }
                },
                {
                  "key": "opa.path",
                  "value": {
                    "stringValue": "policies/zeta/authz/decision"
                  }
                },
                {
                  "key": "opa.result.allow",
                  "value": {
                    "boolValue": false
                  }
                },
                {
                  "key": "opa.result.reasons",
                  "value": {
                    "arrayValue": {
                      "values": [
                        {
                          "stringValue": "User profession is not allowed"
                        },
                        {
                          "stringValue": "TelematikID is blocked"
                        }
                      ]
                    }
                  }
                }
              ],
              "traceId": "",
              "spanId": "",
              "flags": 0
            }
          ]
        }
      ]
    }
  ]
}

Hinweis: Im "opa.path" Attribut soll der Path der Simulation-Policy oder der Policy eingetragen werden.

Hinweis: Dies gewährleistet eine lückenlose und verlustfreie Nachverfolgung der gesamten Verarbeitungskette eines Requests über alle Systemkomponenten hinweg, analog zur Funktionsweise eines Spans in OpenTelemetry.

Hinweis: Betriebliche Telemetriedaten dürfen gemäß A_27260-* an den Betreiber übermittelt werden.

5.5 Sicherheits- und Datenschutz-Anforderungen an die Protokollierung von Administrationsaktivitäten

Administratoren haben weitreichende Zugriffsrechte in Kubernetes, die es ihnen ermöglichen, die Sicherheitskonfigurationen von TI 2.0-Diensten direkt zu ändern. Ohne Kontrolle und Protokollierung dieser Aktivitäten besteht das Risiko, dass unautorisierte oder fehlerhafte Änderungen vorgenommen werden, die die Sicherheit der TI 2.0-Diensten gefährden.

Hinweis: Diese Anforderung umfasst alle Administrationsaktivitäten z.B. Anwendung, Plattform und Cluster Administration.

Hinweis: Die in A_28751-* und A_28749-* definierten Anforderungen dürfen durch Automatisierung bzw. unterstützendes Tooling anstelle manueller Kontrollen umgesetzt werden, sofern das Vier‑Augen‑Prinzip weiterhin gewährleistet ist.

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

ZETA Guard muss in einer VAU laufen können. Daher muss der ZETA Guard die Speicherung und Verwendung der Privatschlüssel von Komponenten-Identitäten in einem HSM unterstützen. Für die Kubernetes etcd Verschlüsselung unterstützt ZETA Guard KMS v2.

Das ZETA Guard-Image ist unabhängig von einer spezifischen VAU-Architektur. Eine VAU ist allerdings in der Regel auf eine bestimmte Architektur (wie z. B. SGX, TDX, SEV usw.) ausgelegt. Da ZETA Guard aus mehreren Komponenten besteht, kann der Hersteller des TI 2.0-Dienstes flexibel entscheiden, wie ZETA Guard auf seiner VAU-Plattform implementiert wird. Dies kann beispielsweise die Nutzung von Confidential Containern, virtuellen Maschinen (VMs) oder die vollständige Ausführung von ZETA Guard innerhalb einer VAU umfassen. Entsprechend dieser Entscheidung muss der Hersteller das ZETA Guard-Image für die jeweils eingesetzte VAU-Architektur umwandeln.

5.7 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.8 Clientsystem und ZETA Client

Ein Clientsystem ist eine Softwarekomponente in der Verwendung eines Nutzers 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 Nutzer 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.8.1 Hersteller

5.8.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.8.3 Client-Registrierung

Hinweis: Dabei ist es unerheblich, ob der TI 2.0-Dienst einen oder mehrere Ressource Server bereitstellt. Der PDP im ZETA Guard kann für mehrere Resource Server eines TI 2.0-Fachdienste zuständig sein. Diese Realisierung wird durch die Verwendung des API-Katalog in der Service Discovery ermöglicht.

Hinweis: Grundsätzlich kann ZETA Guard den Zugriff auf mehrere Ressourcen kontrollieren.

Hinweis: Für die Client-Registrierung 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: Das Client Instance Key Pair soll initial 2 Jahre gültig sein. Der private Client Instance Key PrK.Client.Sig soll im TPM2 Modul verwendet werden (oder Secure Enclave bei macOS und iOS sowie TEE bei Android).

5.8.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.8.5 Session Management

5.8.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, Client-Registrierung und HTTP Proxy.

Die Fehlercodes sollen dem Client die Möglichkeit geben, angemessen auf die jeweilige Fehlersituation zu reagieren.
Dabei wird unterschieden zwischen den folgenden Ergebnisklassen, die über verschiedene Statuscodes angezeigt werden:

1. Erfolgreiche Aktion: dies sind die Statuscodes
1. 2xx
2. 3xx
2. Abschließend nicht erfolgreiche Aktion: dies sind insb. die Statuscodes:
1. 400 Bad Request: sollte ein Request mit 400 abgelehnt werden, kann der Client nicht entscheiden was anders aufzurufen wäre und würde den Request daher nur wiederholen können. Daher wird hier abgebrochen.
2. Alle weiteren 4xx Statuscodes die nicht in den anderen Klassen gelistet sind (insb. nicht 401 und 403, siehe nächsten Punkt).
3. Step-Up Authentifizierung: Eine Step-Up-Authentifizierung wird grundsätzlich nur einmal automatisch durchgeführt, bevor abgebrochen wird. Dies dient auf der einen Seite der erneuten Prüfung gegen die OPA-Regeln z.B. im Falle von Netzwerkwechseln, und auf der anderen Seite dem Vermeiden einer Überlastung durch nur einmalige Wiederholung. Hier wird unterschieden zwischen Requests gegen den PDP, bei denen die OPA Regeln bereits abgefragt werden – diese erlauben keinen Retry bei Forbidden, und anderen Requests, bei denen nach dem 403 Forbidden die OPA Regeln neu abgefragt werden sollen:
1. Bei einem 401 Unauthorized Statuscode bei einem Request gegen den PDP im Rahmen der Client-Registrierung, der Authentifizierung oder des Token Refreshs kann der Client einen Request nach einer erneuten Authentifizierung einmalig wiederholen. Die angenommenen Fehlersituationen hier sind z.B. während des Requests ablaufende Zertifikate/Token (time-of-check to time-of-use Situation), oder die Invalidierung eines Access Token durch Impossible-Travel Detektion oder ähnliches. Die Authentifizierung soll maximal einmal wiederholt werden, bevor ein 401/403 Status nach einem wiederholten Request als abschließend nicht erfolgreich gewertet wird.
2. Bei einem 401 Unauthorized sowie bei einem 403 Forbidden beim Zugriff auf eine Ressource über den PEP HTTP Proxy sowie andere PDP APIs (z.B. Client Management in Stufe 2) kann der Client statt einer vollständig neuen Authentifizierung einen Token-Refresh unter Nutzung eines vorhandenen Refresh-Token versuchen. Falls dort ein weiterer 401/403 Statuscode erhalten wird, wird dann einmalig eine volle Authentifizierung durchgeführt, bevor der ursprüngliche Request mit neuem Access Token wiederholt werden kann.
4. Temporäre Fehlersituation:
1. Bei 5xx Statuscode kann der Client wie in ZT_HTTP_Statuscodes den Request ggf. nach Wartezeit wiederholen
2. 429 Too Many Requests – auch hier kann der Client – nach Wartezeit – den Request wiederholen.
   

Tabelle 7: ZT_HTTP_Statuscodes

5.8.7 ZETA Attestation Service

Der ZETA Attestation Service stellt einen gRPC-Dienst zur Verfügung, der es stationären Clients (Primärsysteme auf Basis von Windows oder Linux) 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 manipulationsgeschützte 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.

Hinweis: Während der Installation oder bei Updates des stationären Clients muss auch ein Update des ZETA Attestation Service erfolgen um eine neue Baseline für die Integrität des stationären Clients zu setzen. Die Baseline besteht aus einem Hash über alle unveränderlichen Komponenten des stationären Clients, inkl. ZETA Attestation Service.

Hinweis: Der ZETA Attestation Service muss bei jedem Start des Clients die Messung über die Integrität des Clients durchführen und in das PCR schreiben.

Hinweis: Der ZETA Attestation Service ist nicht für mobile Clients vorgesehen. Mobile Clients verwenden eine andere Attestierungsmethode, die auf den jeweiligen Plattformen basiert (z.B. Android und iOS).

Hinweis: Wenn die Messung des Clients von der Baseline abweicht, dann soll der Zeta Attestation Service automatisch den Support  des Herstellers informieren.

5.9 Client-Registrierungsdaten

Dieses Kapitel beschreibt die Datenstrukturen für die Kommunikation zwischen ZETA Client und ZETA Guard bei der Client-Registrierung.

Die Client-Registrierung erfolgt über ein vom Client erzeugtes und signiertes Client Assertion JWT, das Informationen über den Client sowie über die aktuelle Gerätesituation (Posture) enthält.

Die übermittelten Informationen werden vom Authorization Server geprüft und anschließend in der Client-Registry gespeichert. Der Authorization Server stellt diese Informationen dem Policy Decision Point für Autorisierungsentscheidungen zur Verfügung.

Die Client-Registrierung besteht aus drei logischen Datenstrukturen:

• Client Assertion JWT – kryptographisch signierte Identifikation der Client-Instanz gemäß [client-assertion-jwt.yaml]
• Client Statement – statische Eigenschaften des Clientsystems gemäß [client-statement.yaml]
• Posture Informationen – Eigenschaften der Laufzeitumgebung des Clients gemäß [posture.yaml] sowie den referenzierten plattformabhängigen Informationen gemäß [posture-apple.yaml], [posture-android.yaml], [posture-tpm.yaml] und [posture-software.yaml].

5.9.1 Client Assertion JWT

Die konkrete Installation eines Clients wird durch ein Client Assertion JWT identifiziert. Das JWT wird vom Client signiert und beim Authorization Server übermittelt.

Tabelle 8: Tab-Client-Assertion-JWT

5.9.2 Client Statement

Das Client Statement (Schema: [client-statement.yaml]) enthält Informationen über die Client-Instanz und wird als Claim client_statement in den Payload des Client Assertion JWT eingebettet.

Tabelle 9: Tab-Client-Statement

5.9.3 Posture Informationen

Das Posture-Objekt dient dem Nachweis der Integrität der Laufzeitumgebung des Clients. Diese Informationen können sich im Laufe der Zeit ändern, beispielsweise durch Updates des Betriebssystems oder der Clientsoftware.

5.9.3.1 TPM Posture

Die TPM-Posture gilt für stationäre Clients (Windows oder Linux) mit TPM-basierter Attestierung.

Tabelle 10: Tab-Posture-TPM

5.9.3.2 Software Posture

Die Software-Posture gilt für generische Software-Clients ohne TPM-Attestierung (Windows oder Linux).

Tabelle 11: Tab-Posture-Software

5.9.3.3 Apple Posture

Die Apple-Posture enthält die dekodierten Inhalte des Attestation- bzw. Assertion-Objekts einer iOS-App (Apple App Attest).

Tabelle 12: Tab-Posture-Apple

5.9.3.4 Android Posture

Die Android-Posture enthält plattformspezifische Geräte- und Sicherheitseigenschaften gemäß
den Android-APIs (vgl. android.os.Build).

Tabelle 13: Tab-Posture-Android

5.10 ZETA Guard

Die Software des ZETA Guards wird im Auftrag der gematik entwickelt und alle Komponenten als signierte OCI Images und als signiertes Helm Chart in einer gematik Artifact Registry bereitgestellt, sodass die Anbieter von TI 2.0 Diensten ihren spezifischen ZETA Guard darauf aufbauend in ihrer Kubernetes Umgebung konfigurieren und betreiben können.

Hinweis: Die TLS-Terminierung für den PDP Authorization Server und den PEP HTTP Proxy kann über eine gemeinsame TLS-Verbindung (gleicher FQDN, gleicher Port) abgebildet werden.

Hinweis: TLS-Verbindungen von ZETA Clients können dort terminiert werden, wo es aus Sicht des Anbieters des TI 2.0-Dienstes am sinnvollsten ist (z. B. an einem CDN). Um dennoch eine verschlüsselte Verbindung bis zum ZETA Guard zu haben, kann ZETA/ASL verwendet werden.

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://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/). Es ist geplant, dass nach Veröffentlichung des RFC ZETA Guard angepasst wird, um die neuen Rate Limit Festlegungen zu unterstützen.

Hinweis: Die Verfügbarkeit von ZETA Guard soll durch die lokale Bereitstellung der Artifact Registry erhöht werden. Die Policies und Daten werden von der Policy Engine direkt aus der ZETA Artifact Registry geladen und aktualisiert.

5.10.1 Klassifizierung der ZETA Guard Komponenten

Der ZETA Guard ist ein logisches Bundle das in der Laufzeitumgebung des TI-2.0-Dienstanbieters (in der Regel ein Kubernetes-Cluster) betrieben wird. Die Komponenten des ZETA Guard werden nach ihrem Funktionsumfang, ihrer Austauschbarkeit und der Verantwortung für die Bereitstellung klassifiziert. Diese Klassifizierung bestimmt die Möglichkeiten bei der Integration von ZETA Guard in die individuelle Laufzeitumgebung des TI-2.0-Dienstanbieters und die Sicherheitsvorgaben z. B. beim Betrieb in einer VAU.

5.10.1.1 Unveränderliche Kernkomponenten

Diese Komponenten bilden den funktionalen Kern des ZETA Guard. Sie werden von der gematik als signierte OCI-Images in der ZETA Artifact Registry bereitgestellt.

5.10.1.2 Austauschbare Kernkomponenten

Diese Komponenten sind für den Betrieb des ZETA Guard notwendig. Der Anbieter des TI 2.0-Dienstes kann wählen, ob die von gematik bereitgestellten Images verwendet werden oder ob eigene Lösungen eingesetzt werden.

Hinweis: Bei der Verwendung von eigenen Lösungen für ZETA Guard Kernkomponenten muss die Umsetzung und Einhaltung der zu den Komponenten gehörenden Anforderungen gemäß Anbietertypsteckbrief nachgewiesen werden. Im ZETA Guard Produkthandbuch ist beschrieben, was hinsichtlich Kompatibilität zu den ZETA Guard Kernkomponenten zu beachten ist.

Es ist möglich auf die Komponente Ingress im ZETA Guard zu verzichten. Dadurch wird der Hersteller des TI 2.0-Dienstes in die Lage versetzt seinen eigenen externen Ingress zu verwenden.

5.10.1.3 Hilfskomponenten und Funktionen

Diese Komponenten und Funktionen bieten zusätzliche Funktionen zur Verbesserung der Sicherheit und zur Vereinfachung des Betriebs. Sie können durch eigene Lösungen umgesetzt werden. ZETA Guard enthält keine fertigen Images, sondern ausschließlich unterstützende Konfigurationen (z. B. Policies für einen Admission Controller).

Hinweis: Bei der Verwendung von eigenen Lösungen für ZETA Guard Hilfskomponenten und Funktionen muss die Umsetzung und Einhaltung der zu den Komponenten gehörenden Anforderungen gemäß Anbietertypsteckbrief nachgewiesen werden. Für die Hilfskomponenten und Funktionen werden keine Images durch die gematik bereitgestellt.

5.10.2 Kommunikation mit Diensten der gematik

ZETA Guard Instanzen benötigen Zugriff auf Dienste der gematik, um PIP und PAP OCI Container Images zu laden, um Telemetriedaten an den gematik Empfänger zu senden und um Security Events an das gematik SIEM zu senden. Für den Zugriff auf diese Dienste ist ein gültiges Access Token erforderlich.

Um ein gültiges Access Token zu erhalten wird Workload Identity Federation eingesetzt. Voraussetzung dafür ist, dass

• der Kubernetes Cluster, in dem ZETA Guard ausgeführt wird, seine OpenID Konfiguration und seine JWKS URI (/.well-known/openid-configuration und bei Kubernetes IDP /openid/v1/jwks) öffentlich erreichbar bereitstellt (alternativ kann ein Schlüssel (JWK) im Workload Identity Federation Pool der gematik registriert werden),
• ein ServiceAccount innerhalb des Clusters existiert, der die benötigten Secrets (Access Token) für die Workloads bereitstellt und
• die Issuer URI des Kubernetes Cluster bei der gematik registriert ist.

Siehe auch Kapitel 5.16.8 Prozesse zur Inbetriebnahme eines ZETA Guard.

Hinweis: Der Kubernetes IDP wird vom kube-apiserver umgesetzt. Der API-Server ist die Instanz, die die Identitätsnachweise (Tokens) signiert und die notwendigen Metadaten für externe Dienste bereitstellt. Damit dies funktioniert, muss er mit bestimmten Flags konfiguriert sein (--service-account-issuer, -service-account-signing-key-file, --service-account-jwks-uri).

Für die Workload Identity Federation (WIF) nutzt Kubernetes die TokenRequest API. Diese API ermöglicht es, kurzlebige, zielgruppenspezifische (Audience-bound) JSON Web Tokens (JWT) zu erstellen. Ein externer Dienst (gematik Telemetriedaten Empfänger) akzeptiert nur Tokens, 
- deren Issuer im gematik WIF Pool registriert sind (per Onboarding Prozess für den TI 2.0 Dienst Anbieter) und
- die eine für ihn definierte aud (Audience) enthalten.

Damit die gematik Dienste die Token validieren können, muss entweder der Token Signatur-Schlüssel bei der gematik registriert sein oder es werden die standardisierten Endpunkte des api-servers öffentlich bereitgestellt:

• /.well-known/openid-configuration: Das Discovery-Dokument, das die unterstützten Funktionen und die URL zum Schlüsselsatz enthält.
• /openid/v1/jwks: Der JSON Web Key Set (JWKS), der die öffentlichen Schlüssel zur Verifizierung der Signatur enthält.

5.10.3 Deployment Szenarien

5.10.3.1 Geo-Redundanz

Der Betrieb von Kubernetes in einer Multi-Cluster-Umgebung bietet Unternehmen erhebliche Vorteile in Bezug auf Skalierbarkeit, Ausfallsicherheit und Flexibilität, bringt jedoch auch eine erhöhte Komplexität in Verwaltung, Netzwerk und Sicherheit mit sich und es Ergeben sich Anforderungen an Anbieter von TI 2.0-Diensten.

5.10.4 Laufzeitüberwachung

Um die Integrität und Vertraulichkeit der ZETA Guard Microservices innerhalb einer Kubernetes-Infrastruktur zu gewährleisten, werden verschiedene sich ergänzende Sicherheitsmechanismen eingesetzt. Diese dienen der Härtung der Laufzeitumgebung, der Isolation von Workloads und der Erkennung von Anomalien. Diese werden nachfolgend beschrieben. Die Mechanismen sind in aktuell eingesetzte und geplante Verfahren unterteilt; darüber hinaus werden weitere empfohlene Maßnahmen zur Vertiefung der Cluster-Sicherheit aufgeführt.

5.10.4.1 Aktuell eingesetzte Verfahren

5.10.4.1.1 Pod Security Standards (PSS)

Kubernetes Pod Security Standards definieren drei Sicherheitsstufen für Pods (Privileged, Baseline, Restricted). Im ZETA-Guard-Cluster soll die Stufe Restricted für alle ZETA-Guard-Namespaces per Namespace-Label durchgesetzt werden. Damit werden unter anderem folgende Eigenschaften erzwungen:

• Ausführung als Nicht-Root-Benutzer (runAsNonRoot: true)
• Keine privilegierten Container (privileged: false)
• Keine Fähigkeiten über die Allowlist hinaus (allowPrivilegeEscalation: false, capabilities.drop: ["ALL"])
• Nur schreibgeschützte Root-Filesysteme (readOnlyRootFilesystem: true)
• Ausschluss von Host-Netzwerk, Host-PID und Host-IPC

5.10.4.1.2 Admission Controller

Admission Controller sind Kubernetes-Webhooks, die API-Server-Anfragen vor der persistenten Speicherung validieren oder mutieren. Im ZETA-Guard-Cluster sollen folgende Admission Controller eingesetzt werden:

Validating Admission Webhooks prüfen eingehende Ressourcen gegen Richtlinien und lehnen nicht-konforme Anfragen ab. Typische Prüfungen umfassen:

• Sicherstellung, dass nur Images mit der gematik Signatur produktiv eingesetzt werden. Bei jedem Deployment wird geprüft, ob das Image eine gültige gematik-Signatur trägt.
• Ablehnung von Deployments ohne definierte resources.requests und resources.limits

Als Policy-Engine für Admission Control sollen Kyverno oder OPA Gatekeeper eingesetzt werden, um Richtlinien deklarativ als Kubernetes-Custom- Resources zu verwalten.

5.10.4.1.3 Network Policies

Kubernetes Network Policies steuern den zulässigen Netzwerkverkehr zwischen Pods auf Basis von Label-Selektoren, Namespaces und Ports. Im ZETA-Guard-Cluster gilt das Default-Deny-Prinzip: Jeder Namespace verfügt über eine Network Policy, die eingehenden und ausgehenden Verkehr standardmäßig verbietet. Explizite Freigaben erfolgen nur für notwendige Kommunikationsbeziehungen, insbesondere:

• Eingehender Verkehr zum PEP (HTTP Proxy) ausschließlich vom Ingress Controller
• Kommunikation zwischen PEP, PDP Authorization Server und Policy Engine (OPA) nur innerhalb dedizierter ZETA-Guard-Namespaces
• Ausgehender Verkehr zu gematik-Diensten (PIP/PAP Artifact Registry, Telemetrie-Service) nur über definierte Egress-Regeln
• Vollständige Isolation zwischen ZETA-Guard-Namespace und Resource-Server- Namespace auf Netzwerkebene

Hinweis: Native Kubernetes Network Policies sind Layer-3/4-Konstrukte und operieren auf IP-Adressen und Ports. Für eine weitergehende Layer-7-Kontrolle wird auf das Service Mesh (s. u.) verwiesen.

5.10.4.1.4 Service Mesh

Ein Service Mesh (z. B. Istio, Linkerd oder Cilium) ergänzt Kubernetes um transparente mTLS-Verschlüsselung, feingranulare Traffic-Kontrolle und Observability zwischen Microservices. Im ZETA-Guard-Cluster übernimmt das Service Mesh folgende Aufgaben:

Mutual TLS (mTLS):
Alle Kommunikationsverbindungen zwischen ZETA-Guard-Komponenten werden durch das Service Mesh mit mTLS verschlüsselt und wechselseitig authentifiziert. Zertifikate werden automatisch rotiert.

Autorisierungsrichtlinien:
Mit AuthorizationPolicy-Ressourcen (Istio) oder Server-Ressourcen (Linkerd) wird die dienstspezifische Kommunikation auf Layer 7 eingeschränkt. So darf z. B. nur der PEP den Resource Server aufrufen.

Traffic-Observability:
Das Service Mesh liefert metrische Daten (Latenz, Fehlerrate, Throughput) und Traces für jede Dienstkommunikation, die in das Monitoring einfließen.

5.10.4.1.5 Ingress und Egress / Gateway

Ingress Controller:
Externer eingehender Verkehr zum ZETA Guard wird über einen Ingress Controller (z. B. NGINX oder Envoy-basiert) terminiert. Der Ingress Controller übernimmt TLS-Terminierung, Rate Limiting und ggf. WAF-Funktionen (Web Application Firewall). Es wird ausschließlich HTTPS mit TLS 1.2 oder höher akzeptiert.

Egress Gateway:
Ausgehender Verkehr aus dem ZETA-Guard-Cluster (z. B. zu PIP/PAP-Registry, Telemetriedaten-Service, Identity Providern) wird über ein dediziertes Egress Gateway geleitet. Durch Egress-Policies auf dem Gateway wird sichergestellt, dass kein unkontrollierter Datenabfluss stattfindet. Zulässige externe Ziele werden in einer Allowlist gepflegt.

Hinweis: Am Anfang wird ZETA Guard nur Network-Policies als Egress Funktion verwenden.

5.10.4.2 Geplante Verfahren

5.10.4.2.1 Pod-Überwachung gemäß Cilium Tetragon

Cilium Tetragon ist ein eBPF-basiertes Security-Observability- und Enforcement-Framework für Kubernetes. Im Unterschied zu netzwerkorientierten Schutzmechanismen operiert Tetragon im Linux-Kernel und ermöglicht Laufzeit-Sicherheitsüberwachung auf Systemaufruf-Ebene (syscall-Ebene) innerhalb von Pods und Containern.

Hinweis: Da Tetragon tief in den Linux-Kernel (via eBPF) eingreift und clusterweite Ressourcen erstellt, benötigt das Service-Konto, das die Installation durchführt, cluster-admin-Rechte. Daher wird Tetragon nicht durch ZETA Guard, sondern durch den Anbieter installiert. Für den laufenden Betrieb und das Erstellen von Regeln reicht ein dediziertes RBAC-Profil für die Cilium-CRDs aus.

Im ZETA-Guard-Cluster ist der Einsatz von Cilium Tetragon geplant für:

Process Execution Monitoring:
Jede Prozessausführung innerhalb eines ZETA-Guard-Pods wird erfasst. Unerwartete Prozesse (z. B. Shell-Aufruf in einem Applikations-Container, Ausführung von Netzwerktools) lösen Sicherheitswarnungen aus und können direkt blockiert werden (Enforcement Mode). Dies erkennt insbesondere Post-Exploitation-Aktivitäten nach einer Kompromittierung.

File Integrity Monitoring (FIM):
Schreibzugriffe auf kritische Dateisystempfade innerhalb von Pods (z. B. Konfigurationsdateien, Zertifikate, Binary-Pfade) werden überwacht. Unzulässiger Zugriff auf Dateien wird unterbunden (Enforcement Mode) und gemeldet.

Network Observability auf Systemaufruf-Ebene:
Netzwerkverbindungen werden auf Basis der tatsächlichen Systemaufrufe (connect, accept, sendmsg etc.) beobachtet, nicht nur auf Paketebene. Dies ermöglicht die Attribution jeder Netzwerkverbindung auf den auslösenden Prozess und Container.

TracingPolicy und Enforcement:
Über TracingPolicy-Custom-Resources können deklarative Sicherheitsregeln definiert werden, die Tetragon im Kernel durchsetzt. Im Enforcement Mode werden unzulässige Aktionen (z. B. execve eines nicht-erlaubten Binaries, Verbindung zu einer nicht-erlaubten IP) direkt durch den Kernel blockiert, noch bevor eine Reaktion auf Anwendungsebene erfolgen kann.

5.10.4.2.2 RBAC-Härtung (Role-Based Access Control)

Kubernetes RBAC steuert, welche Subjekte (ServiceAccounts, User, Groups) welche API-Ressourcen lesen oder verändern dürfen. Für den ZETA-Guard-Cluster gilt:

• Jeder ZETA-Guard-Microservice erhält einen dedizierten ServiceAccount mit minimalen Berechtigungen (Least Privilege).
• Die Verwendung des default-ServiceAccounts in Pods wird durch eine Admission Policy verboten.
• ClusterAdmin- und ClusterRole-Bindings werden auf das absolute Minimum reduziert und regelmäßig überprüft.
• Der Kubernetes API-Server-Zugriff vom Produktivsystem wird auf dedizierte Operator-Identitäten beschränkt; interaktive Zugriffe erfordern MFA und werden auditiert.

5.11 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.11.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. Wenn ein PoPP Token im popp Header vorhanden ist, wird es geprüft.

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. Die Anforderungen für den ZETA/ASL-Kanal sind in [gemSpec_Krypt#8] zu finden.

Wenn der ASL Kanal am HTTP Proxy terminiert, dann enthält der äußere Request kein Access und kein DPoP Token. Der HTTP Proxy terminiert den Kanal und prüft das Access und das DPoP Token im inneren Request.

Wenn der Resource Server den ASL Kanal terminiert, dann enthält der äußere Request ein Access Token und ein DPoP Token passend zum ASL Endpunkt am HTTP Proxy. Der HTTP Proxy leitet den Request nach erfolgreicher Token-Prüfung an den Resource Server weiter. Der Resource Server terminiert den ASL Kanal und findet im inneren Request ein Access und ein DPoP Token passend zum Endpunkt des Resource Servers. Es wird empfohlen, dass der Resource Server das Access und das DPoP Token prüft.

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

Beispiel für den zeta-user-info Header:

{"commonName":"Arztpraxis Walter","identifier":"1-234567890123","organizationName":"Arztpraxis Walter","professionOID":"1.2.276.0.76.4.50"}

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.11.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.12 Policy Decision Point

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

• Authorization Server
• Policy Engine und
• PDP Datenbank

zusammen.

5.12.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 OCI Protokoll von der ZETA Artifact Registry. 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 und dient dazu in produktiven Umgebungen die weiterentwickelte Policies und Daten zu evaluieren.

5.12.2 PDP Authorization Server

Hinweis: Die Gültigkeitsdauer des Refresh Token wird aktuell fest konfiguriert und nicht über die Policy Engine Decision gesetzt, da der verwendete Authorization Server diese Funktion noch nicht unterstützt.

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 oder es werden bei Folge-Attestations nur lokale Verfahren angewendet. 

Hinweis: In ZETA Stufe 2 ist eine Autorisierung vorgesehen, bei der keine Nutzer-Identität durch ZETA Guard festgestellt wird (eGK in Fernversorgung). In diesem Fall erfolgt eine Client-Registrierung ohne Bindung an eine TI-Identität.

Hinweis: TOFU wird nur für mobile Clients genutzt.

5.12.2.1 PDP Relying Party

5.12.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 (PuK.Client.Sig) 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, d ass 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.12.2.3 Service Discovery

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

Die Verwendung der Kombination der Direktiven public und max-age im Cache-Control-Header sorgt für effizientes Caching mit garantierter Aktualität der Inhalte. In Kapitel 5.16.7 Betriebliche Schnittstellendefinition sind die Well-known und JWKS Endpunkte gelistet. 

5.12.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 Pair; PrK.Client.Sig und PuK.Client.Sig), 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 der privaten Schlüssel (PrK.Client.Sig, PrK.DPoP.Sig, PrK.Client.SMCB), 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 (PuK.Client.Sig) enthält. Dieser Schlüssel wird vom Authorization Server verwendet, um die Signatur der Client Assertions (Client Authentifizierung) zu überprüfen.

5.12.2.5 Authentifizierung und Autorisierung für stationäre Clients

Nach erfolgreicher Registrierung besitzt der ZETA Client eine client_id, die an den Schlüssel PuK.Client.Sig gebunden ist. Um auf einen Fachdienst zugreifen zu können, benötigt der Client ein Access Token vom Authorization Server (AuthS). 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.

Hinweis: Der TPM-Attestation Flow muss aufgrund einer Sicherheitslücke im Design überarbeitet werden und wird in einer Folgeversion nachgereicht.

5.12.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 (PrK.DPoP.Sig, PuK.DPoP.Sig).
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 Thumbprint des öffentlichen Client Instance Key (PuK.Client.Sig) und die nonce des AuthS: attestation_challenge = HASH(Thumbprint(PuK.Client.Sig) + 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 (PrK.Client.Sig) signiert, dient als "Umschlag":
    - Es authentifiziert den Client gegenüber dem AuthS (iss und sub sind die client_id).
    - Es enthält die client_statement-Struktur als Beweis für die Clientintegrität. 

    // Client Assertion für initialen Token-Austausch (Beispiel TPM)
  {
    "iss": "cid-win-tpm-abcde",
    "sub": "cid-win-tpm-abcde",
    "aud": [
      "https://auth-server.zeta.gematik.de/token"
    ],
    "exp": 1678888310,
    "jti": "unique-jwt-id-win-tpm-789",
    "client_statement": {
      "sub": "cid-win-tpm-abcde",
      "platform": "windows",
      "posture_type": "tpm",
      "posture": {
        "platform_product_id": {
          "package_family_name": "Primärsystem_123456789"
        },
        "product_id": "Primärsystem-win-v3",
        "product_version": "3.5.0",
        "os": "Windows 11 Pro",
        "os_version": "10.0.22621",
        "arch": "x86_64",
        "tpm_attestation_key": "base64-encoded-tpm-attestation-key...",
        "tpm_quote": "base64-encoded-tpm-quote.l...",
        "tpm_event_log": "base64-encoded-tpm-event-log...",
        "tpm_ek_certificate_chain": [
          "base64-encoded-ek-cert-1...",
          "base64-encoded-ek-cert-2..."
        ]
      },
      "attestation_timestamp": 1678888010
    }
  }

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 Token ist der Token Endpoint des Authorization Servers. Das subject_token enthält ein Binding des Client Instance Keys (PuK.Client.Sig) und des DPoP Keys (PuK.DPoP.Sig) um Manipulationen durch einen Man in the middle zu verhindern.

// Beispiel für die Payload eines Subject Token

{
  "jti": "unique-smcb-token-id-abc123",
  "nonce": "bfb76c3e-8b4a-4f91-9d2a-3c7e5f8a1b20",
  "iss": "cid-win-tpm-abcde",
  "sub": "1-2-SMC-B-Testkarte-883110000129068",
  "aud": [
    "https://auth-server.zeta.gematik.de/token"
  ],
  "exp": 1678888370,
  "iat": 1678888070,
  "client_key": {
    "jkt": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs"
  },
  "dpop_key": {
    "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
  }
}

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.

    **Token Exchange Request Body:**
    grant_type=urn:ietf:params:oauth:grant-type:token-exchange
    &subject_token=<SM(C)-B signed Subject Token>
    &subject_token_type=urn:ietf:params:oauth:token-type:jwt
    &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
    &client_assertion=<Client_Assertion_JWT>
    &audience=<Resource Server Endpoint>
    &scope=<Resource Server scopes>

7. Validierung durch den AuthS: Der AuthS führt eine umfassende Prüfung durch: Validierung der Client Assertion (Signatur gegen den bei der DCR hinterlegten Public Key PuK.Client.Sig), des DPoP-Proofs, des Subject Token und insbesondere der eingebetteten Attestierung (Prüfung der Quote, der attestation_challenge und der PCR-Werte gegen die Sicherheits-Policy) und der Key Bindings (Client Instance Key und DPoP Key).

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

Beispiel Policy Engine Response Body mit "allow": true:

{
  "result": [
    {
      "expressions": [
        {
          "value": {
            "allow": true,
            "ttl": {
              "access_token": 300,
              "refresh_token": 86400
            }
          },
          "text": "data.policies.zeta.authz.decision",
          "location": {
            "row": 1,
            "col": 1
          }
        }
      ]
    }
  ]
}

Beispiel Policy Engine Response Body mit "allow": false:

{
  "result": [
    {
      "expressions": [
        {
          "value": {
            "allow": false,
            "reasons": [
              "User profession is not allowed",
              "One or more requested audiences are not allowed"
            ]
          },
          "text": "data.policies.zeta.authz.decision",
          "location": {
            "row": 1,
            "col": 1
          }
        }
      ]
    }
  ]
}
Beispiel Token Response Body:

{
  "access_token": "ey...",
  "expires_in": 300,
  "refresh_expires_in": 86400,
  "refresh_token": "ey...",
  "token_type": "DPoP",
  "not-before-policy": 0,
  "session_state": "4c1a0db3-e67d-41db-aa46-b81b4c071de9",
  "scope": "vsdservice"
}

5.12.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 (PrK.Client.Sig) 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": "<AuthS_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 AuthS: Der AuthS 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.12.2.5.3 Gemeinsame nachfolgende Schritte

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

5.12.2.6 Ablauf der Authentifizierung bei Dienst-zu-Dienst Kommunikation

Um externen Diensten Zugriff auf den Resource Server zu ermöglichen, wird (in ZETA Stufe 2) Workload Identity Federation verwendet. Jeder Kubernetes Cluster, der ZETA Guard ausführt, stellt einen Identity Provider (IDP) bereit, der Subject Token für die im Cluster ausgeführten Workloads ausstellen kann.

Der ZETA Guard Authorization Server dient als Secure Token Service (STS) und kann per Token Exchange ein Subject Token gegen ein Access-Token austauschen. Er überprüft dabei die Gültigkeit des Subject Token, insbesondere ob der issuer uri des ausstellenden IDP registriert ist. Die Policy Engine (OPA) enthält die Liste der registrierten issuer uri und weiterer Attribute, die zur Autorisierung herangezogen werden.

Der folgende Ablauf beschreibt die Schritte, die für eine erfolgreiche Dienst-zu-Dienst-Kommunikation notwendig sind:

• Registrierung des Issuers: Die issuer URI des externen IDP (z. B. Kubernetes IDP, in dem die Client Workload läuft), oder ein Schlüssel (mit dem Subject Token für den Token Exchange ausgestellt werden), wird bei der gematik registriert. Eine Policy zur Überprüfung und die issuer URI werden in die PIP und PAP Daten des Ziel-ZETA Guard aufgenommen.
• Subject Token-Anforderung: Die Client Workload, oder eine andere Workload im externen Kubernetes Cluster, fordert zunächst ein Subject Token von seinem IDP an. Dieses Subject Token enthält Informationen über die Identität der Workload.
• Token Exchange-Anfrage an ZETA Guard: Die externe Workload sendet das erhaltene Subject Token an den ZETA Guard Authorization Server (STS) und fordert im Austausch ein Access-Token an. Dieser Prozess wird als "Token Exchange" bezeichnet.
• Validierung des Subject Token und Autorisierungsprüfung durch OPA: Der ZETA Guard Authorization Server validiert die Signatur und die Standard-Claims des Subject Token. Anschließend fragt er die Policy Engine (OPA) an, um zu überprüfen, ob der Aussteller (issuer URI) des Subject Token vertrauenswürdig ist und ob die im Token enthaltenen Attribute den definierten Richtlinien für den Zugriff auf den angefragten Resource Server entsprechen. Die Policy Engine enthält hierfür eine Liste der zuvor registrierten Issuer.
• Ausstellung des initialen Access-Token: Nach erfolgreicher Überprüfung durch OPA stellt der ZETA Guard Authorization Server ein Access-Token aus. Dieses Token ist für den Zugriff auf den spezifischen Resource Server vorgesehen.
• Ausstellung Token-Set: Nach erfolgreicher Überprüfung des Refresh-Token durch OPA stellt der ZETA Guard Authorization Server ein neues  Token-Set aus. Dieses Token-Set ist für den Zugriff auf den spezifischen Resource Server vorgesehen.
• Zugriff auf den Resource Server: Die Client Workload im externen Dienst verwendet das erhaltene Access-Token, um Anfragen an den Resource Server zu stellen.
• Validierung des Access-Token durch den PEP HTTP Proxy: Der PEP HTTP Proxy validiert bei jeder Anfrage das mitgesendete Access-Token durch Überprüfung der Signatur des ZETA Guard Authorization Servers sowie der aud und scope claims.
• Zugriffsentscheidung und Antwort: Bei gültigem Access-Token gewährt der PEP HTTP Proxy den Zugriff und verarbeitet die Anfrage. Andernfalls wird der Zugriff verweigert und eine entsprechende Fehlermeldung zurückgegeben.

Abbildung 7: Abb_ZETA-Guard-Dienst-zu-Dienst-Kommunikation

5.12.3 PDP Datenbank

Die Datenbank speichert Session-, Nutzer- und Client-Daten. Die Struktur und Verwaltung der Daten wird vom Authorization Server bestimmt.

Hinweis: Die vom ZETA Guard Authorization Server Keycloak unterstützten Datenbanken werden im ZETA Guard Produkthandbuch aufgelistet (siehe auch https://www.keycloak.org/server/db).

5.12.4 Sicherheits- und Datenschutzanforderungen an den PDP

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

5.13 Policies und Daten

Die Policies und Daten werden in der ZETA Artifact Registry als OPA Bundles im OCI Format für die PDP Policy Engines der ZETA Guard Instanzen bereitgestellt. Die Bundles werden von der gematik in einem CI Prozess mit Quality Gates entwickelt und in die ZETA Artifact Registry deployed. Für jeden Fachdienst-Typ werden spezifische OPA Bundles erstellt. Falls es erforderlich ist, können auch pro ZETA Guard Instanz spezifische OPA Bundles erstellt werden.

Es gibt umgebungsspezifische Repositories in der ZETA Artifact Registry, sodass für Test und Entwicklung andere OPA Bundles verwendet werden können als für die Produktionsumgebung.

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.

Im folgenden werden die Anforderungen an den Prozess zur Erstellung und Verteilung der OPA Bundles, dem dem Policies und Daten CI/CD-Prozess, festgelegt.

Hinweis: Die Tamper-Proof Protokollierung von Adminstrationsaktivitäten betrifft insbesondere Änderungen an der ZETA Artifact Registry. 

5.14 Telemetriedaten-Service

Der Telemetriedaten-Service ist eine Implementierung des OpenTelemetry-Frameworks der die Telemetriedaten 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 Telemetriedaten-Service Fehlermeldungen (Traces), Bestandsdaten (Metriken) und Selbstauskunftsdaten  (Logs) des Resource Servers entgegen und leitet sie an die gematik Telemetriedaten Schnittstelle weiter.

Hinweis: Es sind vom Anbieter, anstatt der Status Code Klassen (first digit of status code), die konkreten 3-stelligen HTTP-Statuscodes gemäß [RFC9110] zu verwenden.

Beispiel: Selbstauskunft OTLP-Log-Nachricht (JSON) vom Resource Server an den Telemetriedaten-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.15 HSM Proxy

Der HSM Proxy dient als Abstraktionsschicht zwischen den ZETA Guard Kernkomponenten (insbesondere dem AuthS und dem HTTP Proxy) und den physischen oder cloudbasierten Hardware Security Modulen (HSM). Er stellt sicher, dass kryptographisches Schlüsselmaterial (Private Keys) die sichere Umgebung des HSM niemals verlässt. Die Kommunikation mit dem HSM Proxy erfolgt zustandslos über das gRPC-Protokoll.

Neben der Erzeugung von Signaturen ermöglicht der HSM Proxy ein sicheres Schlüsselmanagement durch Key Wrapping. Hierbei werden Schlüssel innerhalb der sicheren HSM-Umgebung durch Key Encryption Keys (KEK) verschlüsselt, sodass sie außerhalb des HSM gespeichert werden können, ohne die Vertraulichkeit zu gefährden.

Hinweis: Aktuell wird der HSM Proxy immer durch den Anbieter/Hersteller des TI 2.0 Dienstes bereitgestellt.

Beispiel für eine key_id: zeta-guard-keycloak-jwt-es256-v1 -> Darf nur von Keycloak genutzt werden.

5.15.1 Sicherheits- und Datenschutzanforderungen an den HSM Proxy

5.16 Betrieb

Die Komponenten des ZETA Guard werden in einer Kubernetes (K8s) Umgebung des TI 2.0 Dienst-Anbieters betrieben.

5.16.1 Anforderungen an Hersteller einer ZETA Komponente

5.16.2 Anforderungen an Hersteller eines TI 2.0-Dienstes

5.16.3 Anforderungen an Anbieter eines TI 2.0-Dienstes

Hinweis: Der ausfallsichere Betrieb der lokalen Artifact Registry und die Verbindung zur ZETA Artifact Registry sind vom Anbieter sicherzustellen.

Hinweis: Notwendige Freischaltungen sind vom Anbieter zu beauftragen und deren Funktionsfähigkeit sicherzustellen.

Hinweis: Ausgenommen sind die austauschbaren ZETA Guard Komponenten.

5.16.4 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.16.5 Überwachung des Betriebsstatus

Um die Verfügbarkeit des ZETA‑Guard sicherzustellen, führt die gematik ein externes Probing durch, das von außen den allgemeinen Erreichbarkeits‑ und Betriebsstatus überprüft. Dies erfolgt im Rahmen der überwachten TI 2.0-Dienstes, die eine konkrete ZETA Guard Instanz einsetzen.

Dem Anbieter von TI 2.0-Dienstes wird empfohlen, ergänzend dazu geeignete technische Maßnahmen aufzusetzen, um interne Self‑Checks der ZETA-Guard Komponenten durchzuführen sowie Mechanismen zur Selbstüberwachung und ‑reparatur zu etablieren. Dies umfasst insbesondere automatisierte Verfahren zur Prüfung zentraler Funktionspfade, der Erreichbarkeit benötigter Abhängigkeiten sowie der Integrität interner Zustände.
Durch solche Self‑Checks können potenzielle Störungen frühzeitig erkannt, lokalisiert und häufig sogar ohne manuelle Eingriffe behoben werden. Dies maximiert die Betriebsstabilität, minimiert Ausfallzeiten und stärkt die Resilienz des Gesamtsystems.

Bei einer Bereitstellung in Kubernetes-Umgebungen stehen hierfür erprobte Mechanismen zur Verfügung. Beispiele umfassen:

• Liveness‑Probes (z. B. /health/live): erkennt Hänger oder Deadlocks und startet Pods automatisch neu.
• Readiness‑Probes (z. B. /health/ready): signalisiert, ob eine Komponente aktuell Anfragen zuverlässig bedienen kann; Pods werden erst nach erfolgreichem Probe‑Ergebnis in den Service-Traffic aufgenommen.
• Startup‑Probes: eignen sich für Komponenten mit längerer Initialisierungsphase, um sicherzustellen, dass der Pod nicht fälschlicherweise als „defekt“ betrachtet wird.
• Self‑Healing‑Mechanismen durch Kubernetes (z. B. RestartPolicy, ReplicaSets): ermöglichen automatische Wiederherstellung bei Ausfällen einzelner Komponenten, ohne dass ein manuelles Eingreifen nötig ist.
• Resource‑Überwachung mittels Kubernetes‑Metriken (CPU, RAM, Netzwerk): kann frühzeitig Engpässe und Anomalien im Ressourcenverbrauch sichtbar machen.

5.16.6 Leistungs-Anforderungen

In diesem Kapitel werden die Anforderungen an Performance, Skalierbarkeit und Last an die ZETA-Guard Komponenten zusammengefasst. Die zugrunde liegenden Messungen dienen der Verifikation der Leistungsfähigkeit der Komponenten des ZETA-Guard. Da der ZETA-Guard in verschiedenen Szenarien genutzt werden kann, werden die Messungen einheitlich direkt am Eingang zum PEP bzw. PDP gemessen und durch das Service-Mesh vorgenommen. Die Latenzmessungen müssen über die Differenz zwischen Antwortzeiten beim Eingang in den PEP und dem Ausgang aus dem PEP gebildet werden.

Die geforderten Antwortzeiten bzw. Latenzen werden dabei in Perzentilen vorgegeben. Zur Methode der Perzentile siehe u.a. auch [gemSpec_Perf, Kapitel 2.1] zur Bearbeitungszeit. Dort werden grundsätzlich Mittelwerte der Bearbeitungszeiten sowie 99%-Quantile vorgegeben.

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

Tabelle 22: Tab_gemSpec_ZETA_Schnittstellendefinition_ZETA_Guard

Hinweis: In ZETA Stufe 1 werden die Endpunkte: GET /.well-known/api-catalog und GET /.well-known/openid-federation noch nicht bereitgestellt.

Zusätzlich wird die ZETA Artifact Registry bereitgestellt, die über die lokale Artifact Registry von ZETA Guard abgefragt wird, um beispielsweise aktualisierte Policy-Informationen abzuholen. Folgende Repositories sind in der ZETA Artifact Registry definiert. 

Tabelle 23: Tab_gemSpec_ZETA_ZETA_Artifact_Registry_Repositories

5.16.8 Prozesse zur Inbetriebnahme eines ZETA Guard

Für den Betrieb eines ZETA Guard ist es erforderlich, dass ein Registrierungsprozess der gematik durchlaufen wird. In diesem Prozess werden Informationen über den Kubernetes Cluster und den Authorization Server des ZETA Guard bereitgestellt, die eine sichere Kommunikation mit Diensten der gematik (Artifact Registry, SIEM und Telemetriedaten Empfänger) und die Integration in den Federation Master der TI ermöglichen.

5.17 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.18 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.
• Client-Registrierung: Der ZETA Guard setzt eine sichere Client-Registrierung durch, bei der Clients durch verschiedene Mechanismen attestiert werden (Android Key and ID Attestation, Apple DCAppAttest, TPM Attestation und Software Attestation). Der Client wird in der Regel an eine TI-Identität gebunden (gID, SM(C)-B oder HBA).
• 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 Token Exchange mit SM(C)-B signiertem Subject-Token sowie Authentifizierung über sektorale IDPs mit OIDC Flow.
• 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.
• TLS Transportverschlü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.
• 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.
  Datenverschlüsselung: Die ZETA Guard Daten (ZETA/ASL-Daten, Session-, User- und Client-Daten) werden bei der Persistenz zusätzlich verschlüsselt (SymK.DB.Enc). Der ZETA Guard kann so konfiguriert werden, dass private Schlüssel für die Datenverschlüsselung mit einem Key Encryption Key geschützt werden, der in einem Hardware Security Module (HSM) gespeichert ist.
• VAU Unterstützung: Der ZETA Guard kann optional in einer Vertrauenswürdige Ausführungsumgebung (VAU) ausgeführt werden.
• Monitoring und Logging: Der ZETA Guard sammelt Telemetriedaten 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 Telemetriedaten 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.
• Produkthandbuch sowie Sicherheits- und Datenschutzkonzept: Im Produkthandbuch 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.19 Weitere Leistungen des ZETA Guard für Resource Server

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

• gematik Telemetriedaten Lieferung: Der Telemetriedaten-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 Telemetriedaten 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.

7 Anhang A – Verzeichnisse

7.1 Abkürzungen

Tabelle 24: Im Dokument verwendete Abkürzungen

7.2 Glossar

Tabelle 25: 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 26: Referenzierte Dokumente der gematik

7.5.2 Weitere Referenzen

Tabelle 27: Weitere Referenzen