Telematikinfrastruktur 2.0

Spezifikation

Zero Trust Access (ZETA)

Version
2.0.0_CC
Revision
1658346
Stand
09.07.2026
Status
zur Abstimmung freigegeben
Klassifizierung
öffentlich_Entwurf
Referenzierung
gemSpec_ZETA

Dokumentinformationen

Gender-Hinweis
Aus Gründen der besseren Lesbarkeit wird in diesem Dokument überwiegend die männliche Form verwendet. Sämtliche Personenbezeichnungen gelten gleichermaßen für alle Geschlechter.

Ä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: Abb-ZETA-Architektur

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. Für die Session-Beendigung wird daher eine anwendungsspezifische, serverseitige Auslösung der Session-Termination über die Plug-In-Schnittstelle des Authorization Servers umgesetzt.

(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.9 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.

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. Für die Session-Beendigung wird daher eine anwendungsspezifische, serverseitige Auslösung der Session-Termination über die Plug-In-Schnittstelle des Authorization Servers umgesetzt.

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 Resource-Identifier (aud) für die angeforderte Ressource?
4. Zugriff verweigert: Wenn der erforderliche Scope oder der passende Resource-Identifier 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 einem bestimmten Resource-Identifier 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 den benötigten Resource-Identifier 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 passendem Resource-Identifier (aud).
• 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 den Resource-Identifier (aud) für die angeforderte Ressource?
10. Zugriff gewährt: Wenn der erforderliche Scope und der passende Resource-Identifier 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 Anforderungen an die Sicherheit und den Datenschutz

5.1.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.1.2 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.1.3 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 TOR-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.1.4 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.1.5 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.1.6 Sicherheits- und Datenschutz Anforderungen an dem ZETA Client in FdVs

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

5.2 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 4: 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 5: 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 6: Tab-Gematik-Keys

5.3 ZETA Abläufe

Dieses Kapitel spezifiziert die dynamischen Kommunikations- und Prozessabläufe innerhalb der ZETA-Architektur. Um die Interaktionen zwischen dem ZETA Client, dem ZETA Attestation Service (ZAS), dem ZETA Guard (Authorization Server) und dem Resource Server nachvollziehbar darzustellen, sind die Unterkapitel chronologisch anhand des Lebenszyklus einer Client-Instanz strukturiert.

Die Beschreibung folgt dem Weg von stationären und mobilen Clients von der initialen Bereitstellung (Installation und Start) über die netzwerktechnische Ermittlung der benötigten Endpunkte (Service Discovery) bis hin zur initialen Schlüsselbindung und Registrierung (Dynamic Client Registration). Darauf aufbauend wird detailliert dargestellt, wie der Client unter fortlaufendem Nachweis seiner Systemintegrität (Attestierung) Access Tokens bezieht und diese für den sicheren Zugriff auf geschützte Fach-dienste (Resource Server) nutzt. Den Abschluss bilden die Prozesse zur Session-Erneuerung sowie die Besonderheiten bei der Dienst-zu-Dienst-Kommunikation.

5.3.1 Abläufe für stationäre Clients

Dieses Unterkapitel beschreibt die spezifischen ZETA-Abläufe für stationäre Endgeräte (Primärsysteme). Im Zentrum steht dabei der Nachweis der Systemintegrität, welcher primär hardwaregestützt über ein Trusted Platform Module (TPM) oder eine Secure Enclave erfolgt. Für Systeme ohne entsprechende Hardware-Voraussetzungen wird eine Software-Attestierung (SW Attestation) als Fallback unterstützt. Auf Basis dieser Attestierung erfolgt die Autorisierung beim ZETA Guard nach OAuth Token Exchange Grant, um die sichere Ausstellung und den Austausch von Access Tokens für den Zugriff auf geschützte Ressourcen zu regeln.

Abbildung 3: Attestierungsablauf nach Betriebssystem gibt einen vereinfachten Überblick über die ganzheitlichen Prozesspfad über die verschiedenen Betriebssystemvarianten und dient als Leitfaden für die folgenden Detailbeschreibungen.

Abbildung 3 : Abb-Attestierungsablauf-nach-Betriebssystem

Der Ablauf kann wie folgt zusammengefasst werden.

1. Initialisierung
   
• Installation des Clients und Generierung eines Client-Schlüsselpaares
• Aufbau einer initialen System-Baseline (Messwerte, Schlüsselmaterial)
2. Hardware-abhängiger Attestierungspfad
   
• Windows / Linux
• Primär: TPM-basierte Attestierung durch den ZETA Attestation Service (ZAS)
• Fallback: Software-basierte Attestierung ohne TPM
• macOS
• Primär: Secure Enclave + Apple App Attest / DeviceCheck
• Fallback: Software-basierte Attestierung
3. Vorbereitung der Registrierung
   
• Bereitstellung der attestierungsrelevanten Schlüssel und Nachweise
• Plattform-spezifische Attestierungsobjekte:
• TPM: EK-, AK- und Client-Schlüssel + Zertifikate
• macOS: Apple Attestation Object
• Software: ausschließlich Client-Schlüssel
4. Client-Registrierung beim ZETA Guard
   
• Durchführung eines Dynamic Client Registration (DCR)
• Ablauf abhängig vom Attestierungstyp:
• TPM (Windows/Linux)
• Secure Enclave (macOS)
• Software (Fallback)
5. Laufende Attestierung und Authentifizierung
   
• Regelmäßige Erhebung von Zustandsdaten (Evidence)
• Token-Abruf über OAuth Token Exchange
• optionales Attestation Token bei hardwaregestützter Vertrauensbildung

5.3.1.1 Client Installation und Schlüsselgenerierung

Nach der Installation werden beim ersten Start des Primärsystems die Schlüssel generiert, die vom ZETA Client als Identitäts-Nachweis gegenüber ZETA Guard Instanzen verwendet werden.

Das Ergebnis des Prozesses ist eine initiale Baseline des Clientsystems, die – abhängig vom gewählten Attestierungsmodus – aus hardware‑ oder software‑gebundenen Schlüsseln sowie initial erhobenen Zustands‑ und Messinformationen besteht. Diese Baseline bildet die Grundlage für alle weiteren Schritte des Attestierungslebenszyklus.

5.3.1.1.1 Schlüsselgenerierung auf Windows und Linux Systemen

Die Installation des Primärsystems (inkl. ZETA Client) erfolgt in der Regel ohne Admin Rechte. Um Zugriff auf die TPM Funktionen zu erhalten, ist jedoch eine Komponente erforderlich, die unter Admin-Rechten ausgeführt wird. Dafür wird der ZETA Attestation Service (ZAS) verwendet. Zwischen ZAS und ZETA Client muss eine Vertrauensbeziehung bestehen, damit nicht beliebige Clients vom ZAS Attestation-Daten anfragen können und damit der ZETA Client nicht mit einem kompromittierten ZAS kommuniziert.

Das folgende Sequenzdiagramm beschreibt den Prozess der Schlüsselgenerierung und Attestierung auf Windows und Linux Betriebssystemen. Der Ablauf gliedert sich in einen primären, hardwaregestützten Pfad über das TPM und einen Software-Attestation Fallback-Pfad.

Abbildung 4 : Abb-ZETA-Schlüsselgenerierung-Windows-und-Linux

Die Schritte (01)-(13) werden nur durchgeführt, wenn auf dem Clientsystem ein TPM vorhanden ist und das Primärsystem ein ZETA Attestation Service beinhaltet.

• (01) Privilegierte Installation: Der ZETA Attestation Service wird mit administrativen Rechten installiert, damit Messungen des Primärsystems in ein TPM Register geschrieben werden können.
  
• (02) Die Installation des Primärsystems (mit Ausnahme des ZAS) erfolgt ohne Admin Rechte.
• (03)-(04) Um eine exklusive und sichere Vertrauensbeziehung zwischen dem ZAS (läuft privilegiert als Root/Admin) und dem Primärsystem (läuft im User Space) herzustellen, müssen Betriebssystem-Mechanismen (IPC-Sicherheit) mit kryptographischer Bindung kombiniert werden. Da beide Komponenten vom selben Hersteller stammen, können zudem Code-Signatur-Prüfungen genutzt werden.
• (05) Erzeugung eines Client‑Signaturschlüsselpaares: Auf Windows‑ oder Linux‑Systemen wird ein Client‑Signaturschlüsselpaar über einen Betriebssystem‑ oder TPM‑Provider erzeugt.
• (06) Übergabe von Schlüsselmaterial: Die öffentlichen Schlüsselanteile sowie zugehörige Schlüssel‑Handles werden dem ZETA Client bereitgestellt.
• (07) Messung des Primärsystems: Der Zustand des Primärsystems wird gemessen. Die Messwerte KÖNNEN optional mit herstellerseitig bereitgestellten Referenzwerten verglichen werden.
• (08) Erzeugung einer Storage Root Key (SRK): Eine Storage Root Key wird innerhalb des TPM als Vertrauensanker erzeugt.
• (09) Erzeugung des Attestierungsschlüssels (AK): Ein Attestierungsschlüssel wird erzeugt und fest an das TPM gebunden.
• (10) Bereitstellung der öffentlichen AK‑Anteile: Die öffentlichen Anteile des Attestierungsschlüssels werden exportiert.
• (11) Laden des Attestierungsschlüssels: Der Attestierungsschlüssel wird in das TPM geladen und aktiviert.
• (12) Übergabe des AK‑Handles: Der ZETA Client erhält einen Handle zur Referenzierung des Attestierungsschlüssels.
• (13) Erweiterung von PCR‑Registern: Die ermittelten Messwerte werden in geeignete Platform Configuration Registers (PCRs) erweitert. Vor der Erweiterung prüft der ZAS, ob die jeweiligen PCR‑Register bereits belegt sind. Nur wenn ein PCR frei ist, kann der ZAS das TPM verwenden. Wenn kein PCR frei ist, muss die Fallback Alternative ohne TPM Nutzung verwendet werden. In den weiteren Schritten ist dann nur die Software-Attestation nutzbar.

Die Schritte (14)–(15) stellen eine Fallback Alternative zu den TPM‑spezifischen Schritten dar.

• (14) Die Installation des Primärsystems erfolgt ohne Admin Rechte.
• (15) Der ZETA Client erzeugt das Client‑Signaturschlüsselpaar lokal im Software‑Kontext.

5.3.1.1.2 Schlüsselgenerierung auf macOS Systemen

Siehe 5.3.2.1.2 Apple Secure Enclave  

5.3.1.2 Client Start mit TPM und ZAS

Wenn unter Windows oder Linux ein TPM 2.0 und der ZAS verfügbar sind, dann wird nach dem Booten und bei jedem Start des Primärsystems eine Messung durch den ZAS durchgeführt. Die Messung wird im weiteren Verlauf bei der Remote Attestierung im ZETA Guard mit einem vom Hersteller vorgegebenen Wert verglichen.

Abbildung 5 Abb-ZETA-Client-Start-mit-TPM-und-ZAS

(01) Der ZAS wird während des Starts des Betriebssystems als Service gestartet.
(02)-(03) Der ZAS führt eine Messung der unveränderlichen Teile des Primärsystems durch und trägt sie in ein TPM PCR ein.
(04) Durch ein kontinuierliches Monitoring prüft der ZAS, ob das Primärsystem gestartet wurde.
(05)-(08) Wenn ein Start des Primärsystems erkannt wurde, führt der ZAS eine Messung der unveränderlichen Teile des Primärsystems durch und trägt sie in ein TPM PCR ein.

5.3.1.3 Service Discovery

Das folgende Sequenzdiagramm beschreibt den sogenannten Discovery-Prozess (Metadaten-Abruf) eines ZETA Clients in der TI 2.0 Architektur. Bevor der Client Zugriffs-Tokens anfordern kann, muss er dynamisch herausfinden, welcher Autorisierungsserver für eine bestimmte Ressource zuständig ist, welche Konfiguration für den Zugriff verwendet werden muss (z. B. ZETA/ASL Nutzung) und welche Endpunkte und Konfigurationen der TI 2.0 Dienst nutzt.
Dieser Prozess basiert auf etablierten IETF/OAuth-Standards (RFCs) und teilt sich in zwei aufeinanderfolgende Abfragen auf.

Abbildung 6 Abb-ZETA-Service-Discovery

(01) Der ZETA Client sendet einen HTTP GET Request an den PEP HTTP Proxy. Der Proxy agiert hier als Stellvertreter für die eigentliche Fachanwendung (Resource Server / RS-FQDN). Der Pfad /.well-known/oauth-protected-resource ist standardisiert und dient exakt diesem Zweck.
(02) Antwort des Proxys: Der PEP Proxy antwortet mit 200 OK und liefert ein JSON-Dokument zurück. Gemäß RFC 9728 (OAuth 2.0 Protected Resource Metadata) enthält dieses Dokument Metadaten über die Ressource. Die für den Client wichtigste Information darin ist der Issuer (die URL) des Autorisierungsservers (PDP), der diese spezielle Ressource schützt. Das Schema für das OAuth Protected Resource Well-known JSON Dokument ist in [opr-well-known.yaml] festgelegt.

Nachdem der Client nun weiß, mit wem er für die Authentifizierung sprechen muss, fragt er diesen Server nach seinen Fähigkeiten und Endpunkten.
(03) Der ZETA Client sendet nun einen GET Request an den in Schritt (02) ermittelten PDP Authorization Server. Er fragt den standardisierten Pfad /.well-known/oauth-authorization-server ab.
(04) Der Authorization Server antwortet mit 200 OK und einem weiteren JSON-Dokument. Nach RFC 8414 (OAuth 2.0 Authorization Server Metadata) enthält dieses Dokument die vollständige Konfiguration des Servers. Dazu gehören z.B. die URLs für den Token-Endpoint (um Tokens anzufordern), den Registration-Endpoint (DCR), unterstützte Verschlüsselungsalgorithmen, Scopes und die URL zu den öffentlichen Schlüsseln (JWKS) des Servers. Über das Feld api_versions_supported gibt der Authorization Server zudem bekannt, welche Vertragsversionen der Token-Ausstellung er unterstützt; hieran erkennt der ZETA Client, ob er den Parameter resource (Contract v2) verwenden kann oder den Parameter audience (Contract v1, Legacy) verwenden muss (siehe 5.4.2.5). Das Schema für das OAuth Authorization Server Well-known JSON Dokument ist in [as-well-known.yaml] festgelegt.

(05) Update Configuration: Der ZETA Client verarbeitet die empfangenen JSON-Dokumente aus Schritt (02) und (04) lokal. Er aktualisiert seine interne Konfiguration mit den abgerufenen Endpunkten und Parametern.

5.3.1.4 Vorbereitung der Client-Registrierung beim ZETA Guard

Wenn ein ZAS und TPM oder eine Secure Enclave verwendet werden, dann müssen Schlüssel für die Attestierung beim Authorization Server bekannt gemacht werden, um die Attestierung dort verifizieren zu können.

5.3.1.4.1 ZAS und TPM

Der folgende Ablauf zeigt die erforderlichen Schritte, um alle benötigten Schlüssel für die Verifikation per TPM Attestation einzusammeln.

Abbildung 7 Abb-ZETA-TPM-Attestation-Key

(01)-(03) Das TPM hat nur wenig Speicher. Daher werden anwendungsspezifische Schlüssel außerhalb des TPM als PCP_KEY_BLOB gespeichert. Die Schlüssel können dennoch nur im TPM verwendet werden. Vor der Verwendung müssen die Schlüssel in das TPM geladen werden.
(04)-(05) Es wird ein TPM2 Attest erzeugt, das das Schlüsselpaar PrK.Client.Sig und PuK.Client.Sig als TPM-Schlüssel bestätigt.
(06)-(14) Aus dem TPM werden der PuK.AK.Sig und der Puk.EK.Enc Schlüssel sowie das C.EK.Enc Zertifikat ausgelesen und an den ZETA Client übergeben.

5.3.1.4.2 Secure Enclave

Abbildung 8 Abb-ZETA-SE-Attestation-Key

(01)-(11) Der Ablauf zeigt, wie ein Apple Attestation Object erzeugt wird, das den Hash des PuK.Client.Sig enthält.

5.3.1.5 Client-Registrierung

Das folgende Sequenzdiagramm beschreibt den Registrierungsprozess eines ZETA Clients bei einem ZETA Guard Authorization Server. Der Ablauf unterscheidet sich grundlegend danach, ob bereits ein ZETA Guard Attestation Token vorhanden ist oder nicht. Dies wird durch den äußeren alt-Block dargestellt. Für eine bessere Übersichtlichkeit sind nicht alle erforderlichen Parameter des DCR Requests dargestellt (siehe [dcr-request.yaml] für detaillierte Informationen). 

Abbildung 9 Abb-ZETA-DCR-für-stationäre-Clients

Wenn der Client noch kein Token besitzt, muss er seine Vertrauenswürdigkeit durch eine Attestierung nachweisen. Hierfür gibt es drei Unterfälle (innerer alt-Block), abhängig von der genutzten Hardware/Software.

(01)–(10) Hardware-Attestation: Windows / Linux (TPM)

Der ZETA Client sendet einen POST /register Request an den PDP Authorization Server mit folgenden Parametern:

attestation_type = "tpm"
PuK.EK.Enc, C.EK.Enc
PuK.AK.Sig
PuK.Client.Sig
signed_Hash_PuK.Client.Sig

Der Authorization Server validiert die Zertifikatskette von C.EK.Enc sowie signed_Hash_PuK.Client.Sig. Anschließend erzeugt er ein CredentialBlob gemäß dem TPM 2.0 Befehl MakeCredential (vgl. TCG TPM Library Part 3, Section 12.5) und antwortet mit 202 Accepted {challenge_type, tpm_credential_blob, tpm_encrypted_secret} gemäß [dcr-response-202.yaml].

Der ZETA Client leitet das CredentialBlob an den ZAS weiter. Der ZAS führt TPM2_ActivateCredential aus und erhält das entschlüsselte Secret. Das Secret wird an den Authorization Server via POST /register/verify {Secret} übermittelt. Nach erfolgreicher Prüfung gelten PuK.Client.Sig und PuK.AK.Sig als hardware-gebunden.

(11)–(12) Hardware-Attestation: macOS (Secure Enclave)

Der ZETA Client sendet POST /register insbesondere mit:

attestation_type = "apple"
PuK.AK.Sig
Apple_Attestation_Object
PuK.Client.Sig
signed_Hash_PuK.Client.Sig

Der Authorization Server validiert das Apple_Attestation_Object und signed_Hash_PuK.Client.Sig. Dabei wird sichergestellt, dass PuK.AK.Sig identisch mit dem Schlüssel aus x5c[0] des Attestation-Objekts ist und die Apple Root CA-Kette gültig ist. Der Wert von signed_Hash_PuK.Client.Sig enthält die Signatur des Hashes von PuK.Client.Sig mit dem eigenen privaten Client-Schlüssel (PrK.Client.Sig). Der Hash_PuK.Client.Sig ist im Apple Attestation Object enthalten.

(13)–(14) Software-Attestation (Legacy OIDC DCR)

Im Software-Attestation-Pfad sendet der ZETA Client einen Standard-OIDC-DCR-Request:

POST /register
{
  "client_name": "<Name des Clients>",
  "grant_types": [
    "urn:ietf:params:oauth:grant-type:token-exchange",
    "refresh_token"
  ],
  "jwks": { "keys": [ PuK.Client.Sig ] },
  "token_endpoint_auth_method": "private_key_jwt"
}

Der Authorization Server legt den Client in der PDP DB an. Erst wenn beim Token Request die Policy Engine dem Authorization Server eine allow: true Decision übergibt, wird der Client als unterstützter Client akzeptiert.

Vorbedingung: ZETA Guard Attestation Token vorhanden

Verfügt der ZETA Client über ein gültiges ZETA Guard Attestation Token aus einer vorherigen Authentifizierung, kann die erneute Registrierung beschleunigt erfolgen.

Beispiel

POST /register
{
  "attestation_type": "zeta_attestation_token",
  "client_name": "ZETA Client App",
  "token_endpoint_auth_method": "private_key_jwt",
  "grant_types": [
    "urn:ietf:params:oauth:grant-type:token-exchange",
    "refresh_token"
  ],
  "redirect_uris": [
    "https://app.example-hersteller.de/cb/zeta-client/oidc",
    "https://app.example-hersteller.de/cb/zeta-client/app"
  ],
  "jwks": {
    "keys": [
      {
        "kty": "EC",
        "crv": "P-256",
        "x": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo",
        "y": "eZXwxvO1hvCY0KucrPfKo7yAyMT6Ajc3N7OkAB6VYy8"
      }
    ]
  },
  "zeta_attestation_token": "ey...",
  "signed_hash_puk_client_sig": "MEQ..."
}

Der Authorization Server prüft die Token-Signatur, die Vertrauensstellung sowie signed_Hash_PuK.Client.Sig anhand des im Token enthaltenen PuK.AK.Sig.

Abschluss der Registrierung

Nach erfolgreichem Durchlauf eines der obigen Pfade antwortet der Authorization Server mit 201 Created {client_id}.

Hinweis: Ein ZETA Client muss nur die für das eigene Betriebssystem passende Variante des Dynamic Client Registration Flows implementieren.

5.3.1.6 Authentifizierung

Die Authentifizierung für Primärsysteme erfolgt per OAuth Token Exchange mit einem SM(C)-B signiertem Subject Token. Eine erfolgreiche Authentifizierung führt auch zu einem Abschluss der Client-Registrierung, da die Clients grundsätzlich einem Nutzer zugeordnet werden.

ZETA Guard prüft nicht nur, ob der Nutzer für den Zugriff berechtigt ist, sondern auch ob der Client Zugriff erhalten darf. Daher muss der ZETA Client neben dem Subject Token auch ein Client Assertion JWT erstellen und mit dem Schlüssel PrK.Client.Sig signieren. Das Client Assertion JWT dient zur Authentifizierung des Clients gegenüber dem ZETA Guard Authorization Server und enthält im client_statement die Attestation Daten des Clients (siehe [client-assertion-jwt.yaml].

5.3.1.6.1 Client Statement mit ZAS und TPM Attestation

Das folgende Sequenzdiagramm beschreibt den Prozess zur Erhebung von Integritäts- und Zustandsdaten (Evidence/Posture) eines Gerätes durch einen ZETA Client mit ZAS und TPM. Dieser Prozess dient dazu, dem ZETA Guard kryptografisch abzusichern, in welchem Sicherheitszustand sich der Client aktuell befindet.

Im Schema [client-statement.yaml] sind die Daten, die bei der Attestierung verwendet werden, festgelegt.

Der Ablauf beginnt mit der Einholung einer kryptografischen Herausforderung (Nonce) und teilt sich danach auf, je nachdem, welche Hardware-Sicherheitsfeatures das Gerät bietet.

Abbildung 10 Abb-ZETA-Client-Statement-mit-TPM-Attestation

(01) Der ZETA Client sendet einen Request (GET /nonce) an den PDP Authorization Server (ZETA Guard), um eine Nonce (eine einmalige Zufallszahl) anzufordern. Dies schützt den späteren Prozess vor Replay-Attacken.
(02) Der Server generiert die Nonce und sendet sie an den Client zurück.
(03) Der ZETA Client beauftragt den ZAS mit der Erhebung der Nachweise (GetEvidence) und übergibt dabei die erhaltene Nonce.
(04)-(05) Der ZAS fordert vom TPM ein sogenanntes Quote an (TPM2_Quote). Dabei fordert er die Signierung bestimmter Platform Configuration Registers (hier PCR=[7,23], welche typischerweise Boot-State und Application-State repräsentieren) an. In diesen Aufruf fließen die Nonce (zur Sicherstellung der Aktualität) und das Handle des privaten Attestation Keys (Handle_PrK.AK.Sig) ein.
(06)-(07) Zusätzlich ruft der ZAS das TCG Event Log (TPM2_GetEventLog()) vom System ab. Das Log enthält die detaillierte Historie, wie die Werte in den PCRs zustande gekommen sind.
(08) Der ZAS bündelt das Quote und das Event Log zu einer Evidence und sendet diese an den ZETA Client zurück.
(09) Der ZETA Client generiert das client_statement, in dem Daten über das Primärsystem, das Betriebssystem und die Evidence Daten enthalten sind.

(10) Software-Attestation: Der ZETA Client sammelt die OS- und Primärsystem-Daten selbst und packt sie in ein client_statement. In diesem Fall findet keine kryptografische Signatur durch ein TPM statt.

5.3.1.6.2 Client Statement mit Apple AppAttest

Das folgende Sequenzdiagramm beschreibt detailliert den Prozess zur Erhebung von Integritäts- und Zustandsdaten (Evidence) auf einem macOS-Gerät durch einen ZETA Client. Es zeigt den korrigierten, architektonisch sauberen Ablauf unter Verwendung der Apple App Attest (bzw. DeviceCheck) API in Verbindung mit der Secure Enclave.

Im Schema [client-statement.yaml] sind die Daten, die bei der Attestierung verwendet werden, festgelegt.

Der Ablauf ist in eine initiale Phase und eine Fallunterscheidung (Attestierungs-Methode) gegliedert.

Abbildung 11 Abb-ZETA-Client-Statement-mit-Apple-AppAttest

Vorbereitungsphase: Nonce-Bezug
Um Replay-Angriffe zu verhindern und die Frische des Integritätsnachweises zu garantieren, benötigt der Client eine kryptografische Challenge vom Server.
(01) GET /nonce: Der ZETA Client fragt eine neue Nonce beim ZETA Guard (Authorization Server) an.
(02) Nonce: Der ZETA Guard generiert eine zufällige Nonce und liefert diese zurück.

Primärer Pfad: Apple AppAttest Attestation (Hardwaregestützt)
Dieser Pfad wird durchlaufen, wenn das Gerät über eine Secure Enclave verfügt und das App Attest Framework bei der initialen Registrierung (DCR) erfolgreich eingerichtet wurde.
(03) Ermittle Posture: Der ZETA Client fragt über native Apple-APIs sicherheitsrelevante Systemparameter ab. Dazu gehören beispielsweise der Status der System Integrity Protection (SIP), Gatekeeper-Einstellungen, die exakte OS-Version und der Status des Secure Boots.
(04) Posture-Daten (Klartext): Das Betriebssystem übergibt diese Systemdaten im Klartext an den ZETA Client.
(05) Hash-Berechnung (clientDataHash): Dies ist der zentrale kryptografische Sicherheitsanker. Der ZETA Client berechnet einen SHA-256 Hash aus der Verkettung der serverseitigen Nonce, den ermittelten Posture-Daten und seinem öffentlichen Client-Schlüssel (PuK.Client.Sig).
(Architektur-Hinweis: Dadurch werden die Frische des Requests, der Systemzustand und die Identität des Clients untrennbar aneinander gebunden).
(06) Assertion anfordern: Der Client ruft die API DCAppAttest.generateAssertion auf. Er übergibt das Handle seines hardwaregebundenen Attestation Keys (Handle_PrK.AK.Sig) sowie den soeben berechneten clientDataHash.
(07) Hardware-Signatur: Das Betriebssystem leitet den Hash an die Secure Enclave weiter. Die Secure Enclave signiert diesen Hash mit dem privaten Attestation Key.
(08) Rückgabe der Signatur & Metadaten: Die Secure Enclave gibt die Signatur sowie zusätzliche Authenticator-Daten (insbesondere einen monoton steigenden Counter zum Schutz vor Klon-Angriffen) an das OS zurück.
(09) dc_assertion (CBOR): Das OS verpackt die Signatur und die Authenticator-Daten in ein standardisiertes CBOR-Objekt (dc_assertion) und reicht es an den ZETA Client weiter.
(10) Generiere client_statement: Der ZETA Client baut das finale client_statement (Evidence) für den Request an den ZETA Guard zusammen. Es besteht aus der kryptografischen dc_assertion und den Posture-Daten im Klartext.
(Der ZETA Guard kann später den Hash aus der ihm bekannten Nonce, den Klartext-Posture-Daten und dem registrierten Client-Key selbst berechnen und die Hardware-Signatur in der dc_assertion validieren).

Alternativer Pfad: Software Attestation (Fallback)
Dieser Pfad dient als Rückfallebene, falls keine Hardware-Unterstützung vorliegt.
(11) Generiere client_statement (Software): Der ZETA Client sammelt die OS- und Primärsystem-Daten (PS-Daten) und fügt sie ungesichert in das Statement ein. Da hierbei keine Signatur durch eine Secure Enclave stattfindet, wird die Policy Engine des ZETA Guards diesen Request mit einem entsprechend niedrigen Trust-Score bewerten.

5.3.1.6.3 Token Exchange mit Attestation

Das folgende Sequenzdiagramm beschreibt den zentralen OAuth Token Exchange Authentifizierungs- und Autorisierungsprozess eines ZETA Clients am ZETA Guard Authorization Server. Der Prozess verknüpft die Nutzer-/Institutions-Authentifizierung (mittels SM(C)-B) mit der Client-Authentifizierung (Client Assertion & Evidence) und bindet die resultierenden Tokens kryptografisch an die aktuelle Sitzung (DPoP).

Das Subject Token zur Authentifizierung der Institution ist nach Schema [subject-token-smb.yaml] festgelegt. Die Client Assertion zur Authentifizierung des Clients ist in [client-assertion-jwt.yaml] festgelegt.

Abbildung 12 Abb-ZETA-Token-Exchange-mit-Attestation

Das Diagramm ist in mehrere logische Phasen und (verschachtelte) Fallunterscheidungen (alt-Blöcke) unterteilt.

Phase 1: Vorbereitung der Tokens und Schlüssel (Schritte 01 - 05)
(01 - 03) Subject Token Erstellung: Der ZETA Client generiert zunächst ein subject_token. Um die Identität des Nutzers bzw. der Institution (z.B. einer Arztpraxis in der Telematikinfrastruktur) nachzuweisen, wird dieses Token an die lokale Smartcard/Sicherheitsmodul (SM(C)-B) gesendet, dort signiert und an den Client zurückgegeben.
(04) DPoP Key Pair: Der Client generiert ein temporäres, sitzungsbasiertes Schlüsselpaar (PrK.DPoP.Sig, PuK.DPoP.Sig). Dieses dient dem Demonstrating Proof-of-Possession (DPoP) – einem Mechanismus, der verhindert, dass gestohlene Access Tokens von Angreifern genutzt werden können.
(05) DPoP Proof: Der Client erstellt mit dem privaten DPoP-Schlüssel und einer vom Server stammenden Nonce einen DPoP Proof.

Phase 2: Der Token-Request (Schritt 06)
(06) POST /token: Der ZETA Client sendet die eigentliche Anfrage an den PDP Authorization Server. Dieser Request enthält ein umfassendes Sicherheitspaket:

• Im Body: den Parameter resource [RFC8707] (Endpunkt-URL der Zielressource aus [opr-well-known.yaml]) sowie scope. Aus Gründen der Abwärtskompatibilität kann stattdessen der Parameter audience verwendet werden (siehe 5.4.2.5).
• Im Header (dpop): Den in (05) erstellten dpop_proof.
• client_assertion: Ein JWT, signiert mit dem privaten Client-Schlüssel (PrK.Client.Sig), um den Client selbst zu authentifizieren.
• subject_token: Das von der SMC-B signierte Token inkl. Nonce aus Schritt (03).
• [Evidence]: Optional/Bedingt mitgeschickte Integritäts- und Zustandsdaten des Geräts (wie in den vorherigen Diagrammen ermittelt).

Phase 3: Validierung durch den ZETA Guard (Schritte 07 - 09)
(07) Basis-Validierung: Der Authorization Server prüft die Client Assertion, den DPoP Proof, das Subject Token, die Nonces und gleicht ab, ob die Schlüssel zu der vorherigen Registrierung (DCR) passen.
Hardware-Attestierungsprüfung (Innerer alt-Block): Falls Evidence mitgeliefert wurde, wird diese hardware-spezifisch geprüft:
(08) [TPM Attestation (Windows / Linux)]: Die TPM-Hardware-Signatur (Quote) wird verifiziert und die Systemzustände (PCRs) werden anhand des Event Logs nachvollzogen.
(09) [macOS Attestation (Secure Enclave)]: Die Apple App Attest Signaturen werden geprüft und der Counter ausgelesen, um Replay-Attacken (Wiederholungsangriffe) zu verhindern.

Phase 4: Policy-Entscheidung und Response (Schritte 10 - 18)
Ab hier spaltet sich der Ablauf je nach Erfolg der Validierung auf (äußerer alt-Block):

Fall A: [Validation successful] (Schritte 10 - 16)
Wenn die technische und kryptografische Validierung (07-09) erfolgreich war, muss inhaltlich über den Zugriff entschieden werden.
(10 - 11): Der Authorization Server bereitet die validierten Daten auf (Policy Engine Input) und sendet sie via POST /v1/data/authz an die PDP Policy Engine.
(12): Die Policy Engine evaluiert die Zugriffsregeln und liefert eine Entscheidung (Policy Decision) zurück.

Unterfall A1: [Policy Decision allow] (Schritte 13 - 16)
Die Policy Engine erlaubt den Zugriff.
(13): Der Server erstellt die Standard-OIDC-Tokens (Access Token, Refresh Token). Diese sind durch den Request an den DPoP-Schlüssel gebunden. Der aud-Claim des Access Tokens wird dabei aus der Policy Engine Decision übernommen (Contract v2, ver: 2); bei einem Legacy-Request über audience wird der Wert verbatim übernommen (ver: 1).

Unterscheidung nach Attestierungs-Level (Innerster alt-Block):
(14 - 15) [Hardware Attestation (TPM / SE)]: Wenn das Gerät seinen Zustand erfolgreich durch Hardware (TPM/Secure Enclave) bewiesen hat, generiert der Server zusätzlich ein ZETA Attestation Token (zeta_attestation_token). Er antwortet mit 200 OK und liefert Access Token, Refresh Token und das ZETA attestation Token an den Client.
(16) [Software Attestation (Fallback)]: Wenn das Gerät nur auf Software-Basis attestiert wurde, erhält der Client zwar Zugriff (200 OK), bekommt aber nur das Access Token und das Refresh Token (kein Attestation Token).

Unterfall A2: [Policy Decision deny] (Schritt 17)
(17): Wenn die Policy Engine den Zugriff verweigert (z.B. weil der Gerätezustand nicht den Sicherheitsrichtlinien entspricht, obwohl die Signaturen gültig sind), antwortet der Server dem Client mit 403 Forbidden (error: access_denied).

Fall B: [Validation fehlerhaft] (Schritt 18)
(18)-(20): Wenn bereits die technische Prüfung in Schritt (07) bis (09) fehlschlägt (z.B. ungültige Signatur der SMC-B, DPoP-Proof falsch, Attestation manipuliert), bricht der Server sofort ab und antwortet dem ZETA Client mit

• 400 Bad Request (invalid_grant bei ungültiger/gesperrter SMC-B bzw. abgelaufenem Grant, invalid_dpop_proof bei fehlerhaftem DPoP-Proof); Client-Authentifizierungsfehler
• 401 (invalid_client).

Die Policy Engine wird in diesem Fall nicht befragt.

5.3.1.6.4 Token Request mit grant_type=refresh_token

Das folgende Sequenzdiagramm beschreibt den Refresh-Token-Prozess (Token Renewal) eines ZETA Clients am ZETA Guard Authorization Server. Es zeigt, wie ein Client, der bereits eine Sitzung etabliert hat, mit einem gültigen Refresh Token neue Zugriffs-Token (Access Tokens) anfordert, ohne den vollständigen (und zeitaufwendigen) Hardware-Attestierungs- und Smartcard-Signaturprozess erneut durchlaufen zu müssen.

Abbildung 13 Abb-ZETA-Token-Request-mit-Refresh-Token

Das Diagramm gliedert sich in die Vorbereitung der Anfrage, die Validierung durch den Server und die finale Autorisierungsentscheidung.

Phase 1: Vorbereitung und Token-Request
(01) DPoP Proof: Der ZETA Client erstellt einen DPoP Proof (Demonstrating Proof-of-Possession). Bemerkenswert ist hier der Hinweis (without Nonce): Um einen zusätzlichen Netzwerk-Roundtrip zu sparen, wird beim Refresh oft zunächst auf eine frische Nonce des Servers verzichtet.
(02) Client Assertion: Der Client erstellt ein JWT (JSON Web Token) zur eigenen Authentifizierung (Client Assertion). Hier geschieht dies explizit (without Attestation), da der Gerätezustand bei einem bloßen Refresh nicht zwingend neu aufwendig hardware-attestiert wird.
(03) POST /token: Der Client sendet die Anfrage an den PDP Authorization Server. Dieser Request enthält im Header den dpop_proof und in der Payload die signierte client_assertion sowie das bisherige refresh_token.

Phase 2: Validierung durch den ZETA Guard
(04) Basis-Validierung: Der Server prüft die kryptografische Gültigkeit der Client Assertion, des DPoP Proofs und verifiziert, ob das eingereichte Refresh Token gültig und dem Client zugeordnet ist.
(05) Token Invalidation: Der Server invalidiert das eingereichte Refresh Token. Dies implementiert das Konzept der Refresh Token Rotation – ein Refresh Token kann nur exakt einmal benutzt werden. Bei einem erneuten Versuch würde dies als Diebstahl-Indikator gewertet.

Phase 3: Policy-Entscheidung und Response
Der weitere Ablauf spaltet sich auf (äußerer alt-Block), je nachdem, ob die technische Validierung in Phase 2 erfolgreich war.

Fall A: [Validation successful]
Wenn die Token gültig sind und die SMC-B nicht gesperrt ist, wird die inhaltliche Autorisierung geprüft.
(06 - 07): Der Authorization Server bereitet die Daten auf (Policy Engine Input) und befragt via POST /v1/data/authz die PDP Policy Engine.
(08): Die Policy Engine liefert ihre Entscheidung (Policy Decision) zurück.

Unterfall A1: [Policy Decision allow]
(09): Die Policy Engine erlaubt die Verlängerung der Sitzung. Der Server antwortet dem Client mit 200 OK und stellt ein brandneues Paar aus Access Token und einem neuen Refresh Token aus.

Unterfall A2: [Policy Decision deny]
(10): Verweigert die Policy Engine den Zugriff (z.B. weil sich übergeordnete Zugriffsregeln geändert haben), antwortet der Server mit 403 (access_denied). Der Client muss sich dann ggf. komplett neu authentifizieren.

Fall B: [Validation fehlerhaft]
(11)-(13): Schlägt bereits die technische Prüfung (Schritte 04-06) fehl – beispielsweise weil das Refresh Token abgelaufen ist, der DPoP-Proof falsch ist oder die SMC-B zwischenzeitlich gesperrt wurde – bricht der Server den Vorgang ab. Die Policy Engine wird nicht befragt und der Client erhält sofort ein

• 400 (invalid_grant / invalid_dpop_proof); reuse eines rotierten Refresh Token
• 400 invalid_grant und Terminierung der Token-Familie. Client-Auth-Fehler
• 401 invalid_client.

Die Sitzung ist damit beendet.

5.3.1.7 Zugriff auf den Resource Server

Voraussetzung für den Zugriff auf eine geschützte Ressource (Resource Server) durch einen Client in der ZETA-Architektur ist, dass der vorgeschaltete Authentifizierungs- und Autorisierungsprozess bereits erfolgreich war und der ZETA Client über ein gültiges Access Token verfügt.

Durch die Auswertung des OAuth Protected Resource Well-known JSON Dokuments kann der ZETA Client erkennen, ob eine ZETA/ASL Verbindung aufgebaut werden muss und welche Token benötigt werden.

5.3.1.7.1 Zugriff auf den Resource Server mit ZETA/ASL

Das folgende Diagramm zeigt, wie eine Anfrage vom Fach-Client über den ZETA Client zum Resource Server geleitet wird.

Das Hauptmerkmal dieses Diagramms ist die Nutzung des ZETA/ASL (Application Security Layer), welcher eine zusätzliche Verschlüsselungsschicht auf Applikationsebene darstellt. Das Diagramm zeigt in einem großen alt-Block zwei unterschiedliche Architektur-Ansätze, je nachdem, wo dieser verschlüsselte Tunnel endet (terminiert). Je nach Einstellung im OAuth Protected Resource Well-known JSON Dokument wird der Tunnel entweder am ZETA Guard HTTP Proxy oder am Resource Server terminiert.

Vorbedingung: Der ZETA Client hat bereits erfolgreich den Authentifizierungsprozess durchlaufen und besitzt ein gültiges Access Token für den Resource Server und ggf. für den ASL Tunnel.

Abbildung 14 Abb-ZETA-Zugriff-auf-RS-mit-ASL

(01)-(02): Der Nutzer (User) möchte auf eine Ressource zugreifen. Das Primärsystem (Fach-Client) sendet eine normale, unverschlüsselte HTTP-Anfrage (GET /resource) an den lokalen ZETA Client.
(03): Der ZETA Client erstellt einen kryptografischen DPoP-Proof (Demonstrating Proof-of-Possession), der an die URL des Resource Servers gebunden ist, um das Access Token vor Diebstahl/Replay zu schützen.

Fall A: [ZETA/ASL terminates at PEP]
In diesem Szenario dient ASL als sicherer Tunnel zwischen dem lokalen Client und dem Netzübergang (PEP) des Anbieters. Im internen Netz des Anbieters (vom PEP zum Resource Server) fließen die Daten nur mit TLS verschlüsselt.
(04)-(05): Es wird ein ZETA/ASL-Verbindungsaufbau zwischen dem ZETA Client und dem PEP HTTP Proxy initiiert.
(06): Der ZETA Client verpackt die eigentliche Anfrage. Er sendet einen "äußeren" Request (POST /ASL) an den PEP. Im verschlüsselten Body (inner request) liegt der eigentliche GET /resource-Aufruf, zusammen mit dem Access Token und dem in (03) generierten DPoP-Proof.
(07): Der PEP terminiert den ASL-Tunnel. Das bedeutet, er entschlüsselt den Body.
(08): Der PEP verifiziert nun das entpackte Access Token und den DPoP-Proof.
(09): Ist die Prüfung erfolgreich, leitet der PEP den ursprünglichen Klartext-Request (GET /resource) an den eigentlichen Resource Server weiter.
(10 - 11): Der Resource Server verarbeitet die Anfrage und sendet die Response an den PEP zurück.
(12): Der PEP verschlüsselt diese Antwort wieder mit ASL, um sie für den sicheren Rückweg über das Internet vorzubereiten.

Fall B: [ZETA/ASL terminates at Resource Server]
In diesem hochsicheren Szenario wird der Payload Ende-zu-Ende verschlüsselt. Der PEP agiert nur als Router und kann den Inhalt der Fachnachricht nicht mitlesen.
(13): Der ZETA Client muss hier einen zweiten DPoP-Proof generieren. Einer ist für den Resource Server (für die Fachdaten), der neue ist für den PEP (um überhaupt den ASL-Endpunkt nutzen zu dürfen).
(14)-(15): Ein ZETA/ASL-Verbindungsaufbau findet logisch zwischen dem ZETA Client und dem Resource Server statt.
(16): Der Request (POST /ASL) ist komplexer verschachtelt:
Auf der äußeren Ebene (für den PEP sichtbar) liegen ein Access Token und ein DPoP-Proof, die nur für den Zugang zum ASL-Endpunkt berechtigen.
Der verschlüsselte Body enthält den eigentlichen Request (GET /resource) samt eigenen Autorisierungsdaten (Access Token und DPoP-Proof für den RS).
(17)-(18): Der PEP prüft nur die äußeren Header. Da er den Body nicht entschlüsseln kann, leitet er den POST /ASL Request ungesehen an den Resource Server weiter.
(19): Erst der Resource Server terminiert den ASL-Tunnel und entschlüsselt die Nachricht.
(20): Der Resource Server prüft nun die inneren Header (Access Token und DPoP-Proof für die Ressource).
(21): Er verarbeitet die Anfrage, erzeugt die Antwort und verschlüsselt diese direkt wieder in eine ASL-Response.

(22)-(23): Unabhängig davon, ob der PEP oder der Resource Server die ASL-Verschlüsselung der Antwort übernommen hat, empfängt der ZETA Client nun die verschlüsselte ASL-Response.
(24): Der ZETA Client entschlüsselt die Antwort lokal.
(25): Er reicht die Response im Klartext an den Fach-Client weiter.
(26): Der Fach-Client stellt dem User die angeforderten Daten dar.

5.3.1.7.2 Zugriff auf den Resource Server ohne ZETA/ASL

Das folgende Sequenzdiagramm beschreibt den direkten Zugriff auf eine geschützte Ressource (Resource Server) durch einen Client in der ZETA-Architektur.

Er zeigt das Routing über den PEP, bei dem die Absicherung primär über tokenbasierte HTTP-Header (Authorization, DPoP) erfolgt, ohne dass ein zusätzlicher ASL-Verschlüsselungstunnel aufgebaut wird.

Vorbedingung: Der ZETA Client hat im Vorfeld bereits erfolgreich einen Authentifizierungsprozess durchlaufen und verfügt über ein gültiges Access Token für den entsprechenden Resource Server.

Abbildung 15 Abb-ZETA-Zugriff-auf-RS-ohne-ASL

(01): Der Endnutzer (User) möchte auf eine bestimmte Ressource zugreifen und interagiert dafür mit seiner Fachanwendung (Fach-Client, z. B. ein Praxisverwaltungssystem).
(02): Der Fach-Client sendet eine reguläre, ungesicherte HTTP-Anfrage (GET /resource) an den lokal installierten ZETA Client. Der Fach-Client selbst muss sich nicht um die komplexe ZETA-Kryptografie kümmern.

(03): Der ZETA Client bereitet die Anfrage vor. Er erstellt einen DPoP Proof (Demonstrating Proof-of-Possession). Dies ist eine kryptografische Signatur, die beweist, dass der Client im Besitz des privaten Schlüssels ist, an den das Access Token gebunden wurde. Dieser Proof wird speziell für die Ziel-URL des Resource Servers (RS) generiert (Schutz vor Replay-Attacken).
(04): Der ZETA Client leitet den GET /resource Request an den PEP HTTP Proxy (den ZETA Guard des Anbieters) weiter. Dabei fügt er zwei Sicherheits-Header hinzu:

• Authorization: DPoP ...: Enthält das eigentliche Access Token.
• DPoP: ...: Enthält den in Schritt 03 generierten DPoP-Token (Proof).

(05): Der PEP HTTP Proxy empfängt die Anfrage und verifiziert die Gültigkeit des Access Tokens und des DPoP Proofs.
(06): Verläuft die Prüfung erfolgreich, leitet der PEP den Request in das interne Netz an den eigentlichen Resource Server weiter. Um dem Resource Server mitzuteilen, wer anfragt, fügt der PEP verifizierte Kontextdaten (Identität, Berechtigungen) in Form von ZETA headers as JSON an die Anfrage an.
(07): Der Resource Server verarbeitet die nun vollständig autorisierte Anfrage und stellt die angeforderten Daten bereit (provide resource access).
(08): Der Resource Server antwortet dem PEP mit einer Response.
(09): Der PEP HTTP Proxy leitet diese Antwort transparent an den ZETA Client zurück.
(10): Der ZETA Client reicht die Response an den Fach-Client durch.
(11): Der Fach-Client nimmt die Daten entgegen und präsentiert die Ressource dem User.

5.3.2 Abläufe für mobile Clients

In diesem Unterkapitel werden die Kommunikations- und Attestierungsprozesse für mobile ZETA Clients (z. B. auf Basis von Android oder iOS) detailliert. Aufgrund der Architektur mobiler Betriebssysteme werden für den Integritätsnachweis plattformspezifische Mechanismen wie die Android Key and ID Attestation oder die Secure Enclave von Apple genutzt. Als Fallback-Lösung ist eine Software-Attestierung vorgesehen, falls hardwarebasierte Nachweise nicht erbracht werden können. Im Unterschied zu stationären Systemen erfordert das mobile Umfeld in der Regel eine interaktive Nutzerauthentisierung. Daher erfolgt die Autorisierung hier standardisiert über OpenID Connect (OIDC) in Verbindung mit dem OAuth Authorization Code Flow.

Im Unterschied zu stationären Clients basieren mobile Clients auf plattformintegrierten Sicherheitsmechanismen und erfordern in der Regel eine interaktive Nutzerauthentisierung. Während bei stationären Clients TPM/ZAS im Fokus steht, erfolgt der Integritätsnachweis bei mobilen Clients über plattformabhängige Attestierungsverfahren. Die Autorisierung erfolgt über den OIDC Authorization Code Flow in Kombination mit OAuth 2.0.

Der Lebenszyklus eines mobilen Clients gliedert sich analog zu stationären Clients in folgende Phasen:

1. Installation und Initialisierung
2. Schlüsselgenerierung
3. Service Discovery
4. Key Preparation und Attestation
5. Dynamic Client Registration (DCR)
6. Authentifizierung (OIDC Flow)
7. Token Exchange und Zugriff
8. Session-Erneuerung

Hardware-Attestation SOLL bevorzugt eingesetzt werden und Software-Attestation dient als Fallback-Mechanismus.

5.3.2.1 Initialisierung und Schlüsselgenerierung

Nach der Installation der mobilen Anwendung wird beim ersten Start ein initialer Satz kryptografischer Schlüssel erzeugt, der als langlebige Identität der Client-Instanz dient.
Im Gegensatz zu stationären Clients erfolgt die Schlüsselgenerierung vollständig innerhalb der durch das mobile Betriebssystem bereitgestellten Sicherheitsmechanismen.

5.3.2.1.1 Android TEE oder Strongbox

Das Sequenzdiagramm zeigt den grundlegenden Prozess der kryptografischen Schlüsselgenerierung und Hardware-Attestierung auf einem Android-Gerät. Es veranschaulicht das Zusammenspiel zwischen der App (mit ZETA Client), dem Betriebssystem (Android OS) und dem isolierten Hardware-Sicherheitsmodul (TEE / StrongBox).  Es nutzt ein Zwei-Schlüssel-Modell (beide in der Hardware verankert) und integriert die externe Google Play Integrity API.

Abbildung 16 Abb-ZETA-Schlüsselgenerierung-Android

1. Generierung des Client Instance Key Pairs
In dieser Phase erzeugt die App den primären kryptografischen Schlüssel, der später für die fortlaufende Authentisierung (Client Assertions) genutzt wird.
(01) Schlüsselgenerierung anfordern: Der ZETA Client ruft die native Android-API KeyStore.generateKey auf, um ein asymmetrisches Schlüsselpaar (Alias: Alias_Client_Sig) zu erzeugen.
(02) Erzeugung in der Hardware: Das Android OS leitet den Befehl an das Hardware-Sicherheitsmodul (TEE oder StrongBox) weiter.
(03) Schlüssel verbleibt in HW: Die StrongBox erzeugt das Schlüsselpaar (PrK.Client.Sig, PuK.Client.Sig). Der private Schlüssel (PrK.Client.Sig) ist hardwaregebunden und kann nicht in den Arbeitsspeicher des Betriebssystems oder der App ausgelesen werden.
(04) Rückgabe der Referenz: Das Android OS gibt dem ZETA Client lediglich eine Referenz (den Alias) auf diesen Schlüssel zurück.
(05) Hash-Berechnung: Der ZETA Client berechnet den SHA-256 Hash des öffentlichen Schlüssels (hash_puk_client_sig = SHA-256(PuK.Client.Sig)). Dieser Hash dient im weiteren Verlauf als zentrales kryptografisches Bindeglied (Key-Binding).

2. Hardware-Attestierung durch den Attestation Key
Um dem ZETA Guard (AuthS) später beweisen zu können, dass der Client-Schlüssel tatsächlich in einem sicheren Hardware-Modul liegt, wird ein dedizierter Attestierungsschlüssel (AK) erzeugt.
(06) AK anfordern mit Challenge: Der ZETA Client fordert die Generierung eines weiteren Schlüssels an (Alias_AK). Das entscheidende Sicherheitsmerkmal: Der zuvor berechnete Hash des Client-Schlüssels (hash_puk_client_sig) wird als AttestationChallenge an das OS übergeben.
(07) AK-Generierung & Zertifikatserstellung: Die StrongBox erzeugt das Attestation Key Pair. Gleichzeitig erstellt die Hardware ein X.509-Attestierungszertifikat und schreibt die übergebene AttestationChallenge unveränderlich in die ASN.1-Erweiterung (KeyDescription) des Zertifikats.
(08) & (09) Rückgabe der Zertifikatskette: Die Hardware liefert die Zertifikatskette (android_key_attestation_certificate_chain), die bis zur Google Root CA reicht, über das OS an den ZETA Client zurück. (Diese Kette beweist später dem ZETA Guard die Hardware-Bindung).

3. Expliziter Besitznachweis / Proof of Possession
Der Client muss beweisen, dass er den soeben erzeugten privaten Client-Schlüssel auch tatsächlich physisch kontrolliert.
(10) Signatur anfordern: Der ZETA Client ruft Signature.sign auf und nutzt dabei den Alias des Client Instance Keys (Alias_Client_Sig), um den Hash (hash_puk_client_sig) zu signieren.
(11) Signatur in der HW: Das Android OS instruiert die StrongBox, den Hashwert mit dem privaten Schlüssel (PrK.Client.Sig) zu signieren.
(12) & (13) Rückgabe der Signatur: Die erzeugte ECDSA-Signatur (signed_hash_puk_client_sig) wird an den Client zurückgeliefert.

4. Play Integrity API - Optional, empfohlen 
Zur zusätzlichen Absicherung (Software- und Geräteintegrität) wird ein serverseitiges Urteil von Google eingeholt.
(14) Integrity Token anfordern: Der ZETA Client ruft die Google Play Integrity API auf (requestIntegrityToken). Auch hier übergibt er den Hash des Client-Schlüssels (hash_puk_client_sig) als nonce. Dadurch wird die Bewertung kryptografisch untrennbar an diesen spezifischen ZETA Client gebunden (Schutz vor Token-Injection).
(15) Rückgabe des Tokens: Die Play Integrity API liefert das signierte Base64-Token (play_integrity_token) an den Client zurück.

Der ZETA Client verfügt nun über alle notwendigen kryptografischen Artefakte, um die Dynamic Client Registration (DCR) am ZETA Guard durchzuführen).

5.3.2.1.2 Apple Secure Enclave

Das Sequenzdiagramm beschreibt die initiale Generierung des Client Key Pair durch eine ZETA Client App auf einem Apple-Gerät. Der Vorgang ist für mobile und stationäre Clients identisch (iOS, iPadOS, macOS).

Abbildung 17 Abb-ZETA-Schlüsselgenerierung-Apple

1. Generierung des Client Instance Key Pairs
In dieser Phase erzeugt die App den primären kryptografischen Schlüssel, der zukünftig für die Authentisierung gegenüber dem ZETA Guard (Client Assertions) genutzt wird.
(01) Installation: Der ZETA Client wird im User Space des Betriebssystems installiert und gestartet.
(02) Schlüsselgenerierung anfordern: Der Client ruft die native Apple-API SecKeyCreateRandomKey auf, um ein asymmetrisches Schlüsselpaar zu erzeugen. Die Parameter erzwingen die Speicherung zwingend in der hardwareisolierten Secure Enclave (SE).
(03) Erzeugung in der SE: Das Betriebssystem leitet den Befehl an die Secure Enclave weiter, welche das Schlüsselpaar (PrK.Client.Sig, PuK.Client.Sig) erzeugt. Der private Schlüssel verlässt die Secure Enclave niemals.
(04) & (05) Rückgabe der Referenz: Die Secure Enclave und das Betriebssystem geben lediglich einen Handle bzw. eine Referenz (keyId) für diesen Schlüssel an den ZETA Client zurück.

2. Hardware-Attestierung durch den Attestation Key
Um dem ZETA Guard (AuthS) beim späteren DCR-Prozess beweisen zu können, dass der Client-Schlüssel tatsächlich in der Secure Enclave dieses spezifischen Apple-Geräts liegt, wird das App Attest Framework genutzt.
(06) AK-Schlüsselpaar anfordern: Der ZETA Client fordert über DCAppAttest.shared.generateKey() die Generierung eines dedizierten Attestierungsschlüssels (AK) an.
(07) bis (09) AK in der SE: Die Secure Enclave erzeugt den Attestation Key und gibt dessen Referenz (keyId_AK) an den Client zurück.
(10) Hash-Berechnung (Challenge): Der ZETA Client berechnet den SHA-256 Hash seines öffentlichen Client-Schlüssels (challenge = SHA-256(PuK.Client.Sig)). Dies ist das entscheidende Key-Binding.
(11) Attestierung initiieren: Der Client ruft DCAppAttest.shared.attestKey auf und übergibt die Referenz des Attestation Keys (keyId_AK) sowie den Hash als clientDataHash (Challenge).
(12) bis (16) Erstellung des Attestation Objects: Die Secure Enclave signiert die Challenge mit dem Attestation Key. Das Betriebssystem kommuniziert im Hintergrund mit den Apple Services, um ein standardisiertes, von Apple signiertes CBOR-Objekt zu erstellen. Dieses finale apple_attestation_object (welches eine X.509-Zertifikatskette, das Apple-Receipt und die eingebettete Challenge enthält) wird dem Client übergeben. (Dieses Objekt beweist später dem ZETA Guard die Hardware-Bindung).

3. Expliziter Besitznachweis / Proof of Possession
Obwohl das Attestation Object beweist, dass der Schlüssel sicher in der Hardware liegt, muss der ZETA Client zusätzlich beweisen, dass genau diese App-Instanz autorisiert ist, den Schlüssel zu verwenden (Besitznachweis).
(17) Signatur anfordern: Der ZETA Client ruft die Standard-Krypto-API SecKeyCreateSignature auf. Er nutzt die Referenz des primären Client Instance Keys (PrK.Client.Sig), um den Hash seines eigenen Public Keys zu signieren.
(18) Signatur in der HW: Die Secure Enclave wird angewiesen, den Hash mit dem privaten Client-Schlüssel zu signieren.
(19) & (20) Rückgabe der Signatur: Die erzeugte ECDSA-Signatur (signed_hash_puk_client_sig) wird an den ZETA Client zurückgeliefert.

4. Software Fallback
(21) Fallback: Für den Fall, dass das Apple-Gerät keine Secure Enclave besitzt oder App Attest nicht verfügbar ist (z. B. in bestimmten Simulator-Umgebungen oder bei veralteter Hardware), generiert der ZETA Client das Schlüsselpaar rein in Software. Es existiert dann keine kryptografische Hardware-Bindung, was bei der Registrierung (DCR) am ZETA Guard zu einer Abwertung des Trust-Scores durch die Policy Engine führt.

5.3.2.2 Client Registrierung und Authentifizierung

Das Sequenzdiagramm zeigt den Prozess der Dynamic Client Registration (DCR) für mobile ZETA Clients. Es vereint die kryptografische Hardware-Attestierung mit der nutzerzentrierten E-Mail-Verifikation (TOFU – Trust On First Use) und die Generierung eines Wiederherstellungscodes (Recovery Code / Faktor F3) für den Fall eines Geräteverlusts.

Abbildung 18 Abb-ZETA-DCR-für-mobile-Clients

Der Gesamtprozess teilt sich in zwei Hauptpfade auf:

• Pfad 1: Kein ZETA Attestation Token vorhanden (Erstregistrierung mit Hardware- oder Software-Attestierung sowie einer E-Mail-Verifizierung mittels OTP).
• Pfad 2: ZETA Attestation Token vorhanden (Fast-Path) (Schnellere Registrierung unter Wiederverwendung eines bereits ausgestellten Attestierungstokens).

Hauptpfad 1: [Kein ZETA Attestation Token]
Falls noch kein Token vorhanden ist, muss sich der Client erst registrieren. Hierbei gibt es drei verschiedene Attestierungsmethoden (Sub-Pfade):

[Hardware Attestation: iOS, iPadOS, macOS (Apple App Attest)]
(01) POST /register: Der ZETA Client sendet eine Registrierungsanfrage an den Authorization Server. Übermittelt werden unter anderem: attestation_type="apple", client_name, jwks (mit dem öffentlichen Schlüssel PuK.Client.Sig), das apple attestation object, die Signatur über den Hash des Client-Signaturschlüssels (signed_hash_puk_client_sig), die Redirect-URIs und die E-Mail-Adresse des Nutzers.
(02) Validiere apple_attestation_object: Der Authorization Server prüft das empfangene Apple-Attestierungsobjekt (Verifikation der Apple App Attest Root CA, Abgleich des extrahierten clientDataHash mit dem SHA-256-Hash des öffentlichen Client-Schlüssels PuK.Client.Sig).
(03) Prüfe signed_hash_puk_client_sig mit PuK.Client.Sig: Der Server verifiziert die Signatur (Selbstsignatur bzw. Proof-of-Possession des Client Instance Keys).

[Hardware Attestation: Android (Keystore, TEE, StrongBox)]
(04) POST /register: Der ZETA Client sendet eine Registrierungsanfrage mit attestation_type="android", client_name, jwks (mit PuK.Client.Sig), der android key attestation certificate chain, der Signatur über den Hash des Client-Signaturschlüssels, dem play integrity token, den Redirect-URIs und der Nutzer-E-Mail.
(05) Validiere Zertifikatskette gegen Google Root CA: Der Server überprüft die Vertrauenskette der Android-Schlüsselattestierung.
(06) Extrahiere attestationChallenge aus KeyDescription ASN.1-Extension des Blatt-Zertifikats: Der Server liest die Challenge aus den Zertifikatsdetails aus.
(07) Prüfe attestationChallenge == SHA-256(PuK.Client.Sig): Der Server stellt sicher, dass die Challenge dem Hash des übermittelten öffentlichen Schlüssels entspricht.
(08) Prüfe signed_hash_puk_client_sig mit PuK.Client.Sig: Verifikation des Proof-of-Possession (PoP) des Client Instance Keys.

Optionaler Block: [Play Integrity Prüfung]

(09) Entschlüssele play_integrity_token (lokal/remote): Der Server entschlüsselt den Play-Integrity-Token von Google.
(10) Verifiziere Nonce: Der Server prüft, ob die Nonce im Token dem SHA-256-Hash von PuK.Client.Sig entspricht.
(11) Werte Verdicts aus: Auswertung der Integritätsurteile (appIntegrity, deviceIntegrity, accountDetails).

[Software Attestation (Legacy OIDC DCR)]
(12) POST /register: Der Client sendet eine klassische Registrierungsanfrage ohne Hardware-Attestierung mit Angaben zu client_name, unterstützten grant_types (Token-Exchange, Refresh Token, JWT-Bearer), jwks, der Authentifizierungsmethode (private_key_jwt), den Redirect-URLs und der Nutzer-E-Mail.
(13) Store Client Placeholder (state: pending_verification): Der Server legt einen vorläufigen Client-Eintrag an.
(14) Generiere OTP & transaction_id, Speichere Request im temporären Cache: Erstellung eines Einmalpassworts (OTP) und Speicherung des Vorgangs.
(15) E-Mail mit OTP-Bestätigungscode (Out-of-Band): Der Server sendet das OTP direkt an die E-Mail-Adresse des Nutzers.
(16) 202 Accepted (transaction_id, message_id: otp_verification): Der Server meldet dem Client, dass die Registrierung läuft und auf die Verifizierung wartet.
(17) Gibt OTP-Bestätigungscode ein: Der Nutzer liest die E-Mail und gibt das OTP in der App (ZETA Client) ein.
(18) POST /register/verify (transaction_id, code): Der Client sendet das eingegebene OTP zusammen mit der Transaktions-ID an den Server.
(19) Verifiziere OTP-Code gegen Cache: Der Server prüft die Gültigkeit des Codes.

Hauptpfad 2: [ZETA Attestation Token vorhanden (Fast-Path)]
Wenn der Client bereits über ein gültiges ZETA-Attestierungstoken verfügt, kann der Prozess stark verkürzt werden:
(20) POST /register: Der Client sendet eine Anfrage mit attestation_type="zeta_attestation_token", client_name, dem ZETA Attestation Token selbst (zeta_attestation_token), dem jwks (mit PuK.Client.Sig) und zur Absicherung die Selbstsignatur des SHA-256-Hashes von puk_client_sig (signed_hash_puk_client_sig) und dem Besitznachweis des Attestation Keys (attestation_pop).
(21) Prüfe Token-Signatur & Vertrauensstellung: Der Server verifiziert das eingereichte ZETA Attestation Token.
(22) Prüfe signed_hash_puk_client_sig mit PuK.Client.Sig: Prüfung der Selbstsignatur (PoP) des neuen Client Instance Keys.
(23) Extrahiere attestation_type und PuK.AK.Sig (cnf.jwk) aus dem Token: Der Server liest den Attestierungstyp und den öffentlichen Attestierungsschlüssel (PuK.AK.Sig) aus dem Token aus.
Bedingte Verifizierung (abhängig vom extrahierten Typ):
Bei attestation_type == "apple":
(24) Validiere attestation_pop als CBOR-Assertion (generateAssertion): Validierung der Signatur über die Authentifikatordaten und den Client-Daten-Hash unter Verwendung von PuK.AK.Sig. Zudem Prüfung des rpIdHash und der Monotonie des Counters.
Bei attestation_type == "android" oder "tpm":
(25) Validiere attestation_pop als Signatur über SHA-256(PuK.Client.Sig) mit PuK.AK.Sig: Direkte Signaturprüfung zur Bindung des (neuen) Client-Schlüssels an den bereits bekannten Attestierungsschlüssel.

Abschluss der Registrierung
Egal welcher Pfad erfolgreich durchlaufen wurde, der Prozess endet mit der Bestätigung:
(26) 201 Created (client_id): Der Authorization Server sendet die Antwort 201 Created inklusive der zugewiesenen client_id an den ZETA Client zurück. Damit ist die Client-Registrierung abgeschlossen.

5.3.2.3 Plattformabhängige Attestierung

Die Attestierungsdaten werden in der Client Assertion (siehe [client-assertion-jwt]) im Attribut client_statement (siehe [client-statement.yaml]) eingetragen.

5.3.2.3.1 Android

Auf Android-Geräten erfolgt die Attestierung über plattformspezifische Sicherheitsmechanismen, die eine Bindung zwischen Anwendung, Schlüsselmaterial und Gerät herstellen.

Abbildung 19 Abb-ZETA-Client-Statement-mit-Android-Attestation

Vorbereitungsphase: Nonce-Bezug
Um Replay-Angriffe zu verhindern und die Frische des Nachweises sicherzustellen, benötigt der Client eine kryptografische Challenge vom Server.
(01) GET /nonce: Der ZETA Client fragt eine neue Nonce beim ZETA Guard (Authorization Server) an.
(02) Nonce: Der ZETA Guard generiert eine zufällige Nonce und liefert diese zurück.

Primärer Pfad: Android Key / ID Attestation (Hardwaregestützt)
Dieser Pfad wird durchlaufen, wenn das Gerät über eine Trusted Execution Environment (TEE) oder StrongBox verfügt und die Hardware-Attestierung bei der Registrierung erfolgreich war.
(03) Ermittle Posture: Der ZETA Client fragt über native Android-APIs die aktuellen, sicherheitsrelevanten Systemparameter ab (z. B. OS-Version, Security Patch Level, Hersteller, Modell, Verified Boot, App-Signaturinformationen).
(04) Posture-Daten (Klartext): Das Android OS übergibt diese Systemdaten im Klartext an den Client.
(05) Hash-Berechnung (clientDataHash): Dies ist der zentrale kryptografische Sicherheitsanker. Der ZETA Client berechnet einen SHA-256 Hash aus der Verkettung der serverseitigen Nonce, den ermittelten Posture-Daten und seinem öffentlichen Client-Schlüssel (PuK.Client.Sig).
(Dadurch werden die Frische des Requests, der Systemzustand und die Identität des Clients untrennbar aneinander gebunden).
(06) Signatur anfordern: Der Client ruft Signature.sign auf. Hierbei referenziert er den dedizierten Attestation Key (Alias_AK), der beim DCR-Prozess in der Hardware erzeugt wurde, und fordert die Signatur des clientDataHash an.
(07) Signatur in der HW: Das Android OS instruiert die TEE / StrongBox, den Hash mit dem privaten Attestation Key (PrK.AK.Sig) zu signieren.
(08) & (09) Rückgabe der Signatur: Die TEE liefert die erzeugte ECDSA-Signatur (signed_client_data_hash) an den ZETA Client zurück.
(Erklärung gemäß Notiz: Da der ZETA Guard bereits beim DCR verifiziert hat, dass der Attestation Key kryptografisch an den Client-Schlüssel gebunden ist [attestationChallenge == SHA-256(PuK.Client.Sig)], beweist diese Laufzeit-Signatur dem Server, dass die Posture-Daten vom selben physischen Gerät stammen).

Optionaler Block: Play Integrity API (ergänzend)
Da die Posture-Daten im Laufzeit-Flow durch Software-APIs ermittelt wurden, kann (und sollte) dieser Status durch eine serverseitige Google-Prüfung verifiziert werden.
(10) Request an Play Integrity: Der ZETA Client ruft den IntegrityTokenProvider auf. Entscheidend: Er übergibt den exakt selben clientDataHash als requestHash.
(11) integrityToken (JWS): Das System liefert das von Google signierte Token zurück, welches unabhängige Bewertungen (Verdicts) zur Geräte- und App-Integrität enthält und kryptografisch an den aktuellen Request gebunden ist.

Zusammenbau des Statements
(12) Generiere client-statement: Der ZETA Client baut das finale client-statement (Evidence) für den ZETA Guard zusammen. Es besteht aus der Hardware-Signatur (signed_client_data_hash), der beim DCR ausgetauschten android_key_attestation_certificate_chain, dem optionalen integrityToken und den Posture-Daten im Klartext.

Alternativer Pfad: Software Attestation (Fallback)
(13) Generiere client-statement (Software): Falls keine TEE/StrongBox verfügbar ist, sammelt der ZETA Client die OS- und Primärsystem-Daten (PS-Daten) und fügt sie ungesichert in das Statement ein. Die Policy Engine des ZETA Guards wird diesen Request mit einem deutlich geringeren Vertrauensniveau (Trust-Score) bewerten.

5.3.2.3.2 Apple

Für Apple-basierte Geräte erfolgt die Attestation durch die Secure Enclave in Kombination mit Apple App Attest.

Abbildung 20 Abb-ZETA-Client-Statement-mit-Apple-AppAttest

Vorbereitungsphase: Nonce-Bezug
Um Replay-Angriffe zu verhindern und die Frische des Integritätsnachweises zu garantieren, benötigt der Client eine kryptografische Challenge vom Server.
(01) GET /nonce: Der ZETA Client fragt eine neue Nonce beim ZETA Guard (Authorization Server) an.
(02) Nonce: Der ZETA Guard generiert eine zufällige Nonce und liefert diese zurück.

Primärer Pfad: Apple AppAttest Attestation (Hardwaregestützt)
Dieser Pfad wird durchlaufen, wenn das Gerät über eine Secure Enclave verfügt und das App Attest Framework bei der initialen Registrierung (DCR) erfolgreich eingerichtet wurde.
(03) Ermittle Posture: Der ZETA Client fragt über native Apple-APIs sicherheitsrelevante Systemparameter ab. Dazu gehören beispielsweise der Status der System Integrity Protection (SIP), Gatekeeper-Einstellungen, die exakte OS-Version und der Status des Secure Boots.
(04) Posture-Daten (Klartext): Das Betriebssystem übergibt diese Systemdaten im Klartext an den ZETA Client.
(05) Hash-Berechnung (clientDataHash): Dies ist der zentrale kryptografische Sicherheitsanker. Der ZETA Client berechnet einen SHA-256 Hash aus der Verkettung der serverseitigen Nonce, den ermittelten Posture-Daten und seinem öffentlichen Client-Schlüssel (PuK.Client.Sig).
(Architektur-Hinweis: Dadurch werden die Frische des Requests, der Systemzustand und die Identität des Clients untrennbar aneinander gebunden).
(06) Assertion anfordern: Der Client ruft die API DCAppAttest.generateAssertion auf. Er übergibt das Handle seines hardwaregebundenen Attestation Keys (Handle_PrK.AK.Sig) sowie den soeben berechneten clientDataHash.
(07) Hardware-Signatur: Das Betriebssystem leitet den Hash an die Secure Enclave weiter. Die Secure Enclave signiert diesen Hash mit dem privaten Attestation Key.
(08) Rückgabe der Signatur & Metadaten: Die Secure Enclave gibt die Signatur sowie zusätzliche Authenticator-Daten (insbesondere einen monoton steigenden Counter zum Schutz vor Klon-Angriffen) an das OS zurück.
(09) dc_assertion (CBOR): Das OS verpackt die Signatur und die Authenticator-Daten in ein standardisiertes CBOR-Objekt (dc_assertion) und reicht es an den ZETA Client weiter.
(10) Generiere client_statement: Der ZETA Client baut das finale client_statement (Evidence) für den Request an den ZETA Guard zusammen. Es besteht aus der kryptografischen dc_assertion und den Posture-Daten im Klartext.
(Der ZETA Guard kann später den Hash aus der ihm bekannten Nonce, den Klartext-Posture-Daten und dem registrierten Client-Key selbst berechnen und die Hardware-Signatur in der dc_assertion validieren).

Alternativer Pfad: Software Attestation (Fallback)
Dieser Pfad dient als Rückfallebene, falls keine Hardware-Unterstützung vorliegt.
(11) Generiere client_statement (Software): Der ZETA Client sammelt die OS- und Primärsystem-Daten (PS-Daten) und fügt sie ungesichert in das Statement ein. Da hierbei keine Signatur durch eine Secure Enclave stattfindet, wird die Policy Engine des ZETA Guards diesen Request mit einem entsprechend niedrigen Trust-Score bewerten.

5.3.2.3.3 Software Attestierung (Fallback)

Falls keine hardwaregestützte Attestierung möglich ist, wird eine softwarebasierte Attestierung durchgeführt.
Dies betrifft insbesondere:

• ältere Geräte
• Emulatoren oder spezielle Umgebungen
• Geräte ohne verfügbare Attestation-APIs oder Hardware

Der Ablauf ist wie folgt:
(01) Generierung des Client-Schlüssels
Das Schlüsselpaar wird im Software-Kontext erzeugt.
(02) Erhebung von Basisinformationen
Der ZETA Client sammelt einfache Kontextdaten:

• Betriebssystem und Version
• Architektur
• Produkt- und Versionsinformationen

Eine hardwarebasierte Vertrauensbindung besteht nicht. Der resultierende Sicherheitsgrad ist daher geringer. Die finale Zugriffserlaubnis erfolgt unter zusätzlicher Policy-Prüfung.

5.3.2.4 Service Discovery

Die Service Discovery ist identisch für stationäre und mobile Clients. Siehe 5.3.1.3 Service Discovery.

5.3.2.5 Authentifizierung

Mobile ZETA Clients authentisieren den Nutzer interaktiv über einen sektoralen Identity Provider (IDP) der TI-Föderation. Hierzu wird ein OpenID Connect (OIDC) Authorization Code Flow mit Pushed Authorization Request (PAR, RFC 9126) und Proof Key for Code Exchange (PKCE, RFC 7636) ausgeführt.

Auf dem mobilen Endgerät wirken zwei Komponenten zusammen:

• Der Fach-Client enthält die fachliche Logik für die Arbeit mit dem Resource Server. Er wählt bzw. lässt den Nutzer den zuständigen sektoralen IDP wählen (idp_iss), erstellt den vollständigen fachlichen HTTPS-Request inklusive aller Header und übergibt ihn an den ZETA Client.
• Der ZETA Client kümmert sich um Client-Registrierung, Session-, Schlüssel- und Token-Verwaltung sowie die Authentifizierung. Er verarbeitet den Request, beschafft bei Bedarf ein gültiges Access Token und gibt die Response an den Fach-Client zurück.

Diese Aufgabenteilung entspricht dem Zusammenspiel von Fach-Client und ZETA Client beim Zugriff auf den Resource Server (siehe Kapitel 5.3.1.7).

Der PDP Authorization Server des ZETA Guard übernimmt zwei Rollen:

• Gegenüber dem mobilen ZETA Client agiert er als der für den Fachdienst zuständige Authorization Server (äußerer Flow, code_challenge_app).
• Gegenüber dem sektoralen IDP agiert er als OpenID-Connect-Relying-Party (Fachdienst, innerer Flow, code_challenge_as). Die Client-Authentifizierung am IDP erfolgt per mTLS (self_signed_tls_client_auth), die Vertrauensbeziehung über OpenID Federation 1.0.

Das vom PDP Authorization Server ausgestellte Access Token ist über DPoP an die Sitzung gebunden.

5.3.2.5.1 Voraussetzungen

• Service Discovery abgeschlossen: Der Client kennt die Endpunkte des PDP Authorization Server (authorization_endpoint, token_endpoint); siehe Kapitel 5.3.1.3 Service Discovery.
• Dynamic Client Registration abgeschlossen: Der Client besitzt eine client_id sowie das Schlüsselpaar PrK.Client.Sig / PuK.Client.Sig.
• App-Link / Universal-Link für ZETA Client und Authenticator-Modul sind im Betriebssystem registriert.
  Sektoraler IDP wird vom Fach-Client ausgewählt und als idp_iss an den ZETA Client übergeben.

5.3.2.5.2 Übersicht

Der Ablauf besteht aus einem äußeren Authorization-Code-Flow (ZETA Client ↔ PDP Authorization Server) und einem inneren Authorization-Code-Flow (PDP Authorization Server ↔ sektoraler IDP) und ist in drei Teilabläufe (A), (B) und (C) zerlegt:

• (A) Authorization Request mit PAR: Der ZETA Client startet den Authorization Request; der PDP Authorization Server stellt einen Pushed Authorization Request (PAR) am IDP und erhält eine request_uri.
• (B) Nutzerauthentisierung: Der ZETA Client öffnet das Authenticator-Modul; der Nutzer authentisiert sich (eGK+PIN / eID) und gibt den Consent frei; der IDP stellt einen AUTHORIZATION_CODE (IDP) aus.
• (C) Token-Bezug und Ausstellung der ZETA Token: Der PDP Authorization Server löst den Code am IDP ein, entscheidet über die Policy Engine und stellt dem ZETA Client ein DPoP-gebundenes Access Token und ein Refresh Token aus.

Abbildung 21 Abb-ZETA-OIDC-Authentifizierung-mobiler-Clients

5.3.2.5.3 Teilablauf (A): Authorization Request mit äußerem und innerem PAR

Das folgende Sequenzdiagramm beschreibt die initiale Phase der Nutzerauthentisierung für mobile Clients (Apps) innerhalb der ZETA-Architektur. Im Kern zeigt es den Aufbau eines OIDC Authorization Requests, erweitert um Sicherheitsmechanismen wie PKCE (Proof Key for Code Exchange), PAR (Pushed Authorization Requests) und die dynamische Vertrauensbildung über die TI-Föderation (OpenID Federation).

Abbildung 22 Abb-ZETA-OIDC-Authorization-Request-mit-äußerem-und-innerem-PAR

Ausgangssituation: Der ZETA Client hat vom aufrufenden Fach-Client (der eigentlichen Fach-App) den Auftrag erhalten, einen Request abzusichern. Dabei wurde auch der Identifier des gewünschten Identity Providers (idp_iss) übergeben.

1. PAR und Initiierung durch den ZETA Client
(01) PKCE & State Generierung (Client): Der ZETA Client generiert einen zufälligen code_verifier_app, leitet daraus über SHA-256 die code_challenge_app ab und erstellt einen state_app zur Verhinderung von CSRF-Angriffen.
(02) POST /par am ZETA Guard: Der Client initiiert den Autorisierungsablauf über Pushed Authorization Requests (RFC 9126) und sendet einen POST /par an den ZETA Guard. Er authentisiert sich dabei über eine Client Assertion (private_key_jwt). Im Body überträgt er die Autorisierungsparameter (u. a. response_type=code, app_redirect_uri, die eigene PKCE-Challenge, scope, state_app und idp_iss).
(03) Validierung & request_uri Erzeugung: Der ZETA Guard validiert die Client Assertion sowie die Request-Parameter, speichert diese zwischen und generiert eine eindeutige request_uri_app.
(04) 201 Created (request_uri_app): Der Guard antwortet mit HTTP 201 und übergibt die request_uri_app mit einer sehr kurzen Gültigkeitsdauer von 5 Sekunden.
(05) GET /authorize: Der ZETA Client ruft nun den Authorization-Endpunkt des ZETA Guards auf (GET /authorize), wobei lediglich die eigene client_id und die zuvor erhaltene sichere request_uri_app übergeben werden.

2. Vorbereitung durch den ZETA Guard (als Relying Party)
(06) PKCE & Nonce Generierung (Guard): Da der Guard als Vermittler (Relying Party) gegenüber dem sektoralen IDP auftritt, generiert er einen eigenen, zweiten PKCE-Satz (code_verifier_as, code_challenge_as), einen eigenen state_as sowie einen nonce für das spätere ID-Token.

3. Dynamischer Vertrauensaufbau: IDP (OpenID Federation)
(Dieser optionale Block wird nur ausgeführt, wenn dem ZETA Guard das Entity Statement des angeforderten IDP noch nicht bekannt ist oder dieses abgelaufen ist).
(07) & (08) Fetch IDP Entity Statement: Der Guard ruft das signierte Entity Statement des sektoralen IDPs über dessen .well-known/openid-federation Endpunkt ab.
(09) & (10) Fetch from Federation Master: Um die Vertrauenswürdigkeit des IDP zu überprüfen, fragt der Guard beim zentralen Federation Master das Entity Statement für diesen IDP (Subjekt = idp_iss) an.
(11) Validierung & Metadaten-Import: Der Guard validiert die erhaltene Trust Chain, importiert den Signaturschlüssel des IDP sowie dessen OP-Metadaten (PAR-, Authorization- und Token-Endpunkt).

4. Pushed Authorization Request (PAR) am sektoralen IDP
(12) POST /PAR am SekIDP: Der Guard sendet die Autorisierungsdaten per mTLS (unter Nutzung seiner self_signed_tls_client_auth) an den PAR-Endpunkt des sektoralen IDP. Im Payload übergibt er seine eigene client_id, die oidc_redirect_uri (der eigene Redirection-Endpunkt für den SekIDP Auth Code Flow), seine PKCE-Daten (code_challenge_as), scope, claims, acr_values, nonce und state_as.

5. Dynamischer Vertrauensaufbau: ZETA Guard (OpenID Federation)
(Dieser optionale Block auf Seiten des IDP wird nur ausgeführt, wenn dem IDP das Entity Statement des anfragenden Fachdienstes/Guards noch nicht bekannt ist).
(13) & (14) Fetch Guard Entity Statement: Der IDP ruft das Entity Statement des anfragenden ZETA Guards ab.
(15) & (16) Fetch from Federation Master: Der IDP verifiziert den Guard beim Federation Master (Subjekt = client_id).
(17) Automatic Registration: Der IDP validiert die Trust Chain, führt die Automatic Registration durch und importiert die Schlüssel (Signatur und Verschlüsselung) des Fachdienstes.

6. PAR-Antwort am IDP und Umleitung an den Authenticator
(18) PAR-Validierung (SekIDP): Der sektorale IDP validiert den PAR-Request (u. a. Prüfung der oidc_redirect_uri gegen die im AS-Entity-Statement hinterlegten redirect_uris, Scopes, Claims und das TLS-Clientzertifikat) und erzeugt eine eindeutige request_uri.
(19) 201 Created (SekIDP): Der IDP antwortet dem Guard mit HTTP 201 und übergibt die generierte request_uri (Gültigkeit max. 90 Sekunden).
(20) 302 Found (HTTP-Redirect an App): Der ZETA Guard beantwortet nun den Authorization Request des ZETA Clients (aus Schritt 05) mit einem HTTP 302 Redirect. Die Location-URL verweist auf den Authorization-Endpunkt des sektoralen IDP (aus dessen Entity Statement), parametrisiert mit der client_id des Guards und der neuen request_uri.
(Dieser Redirect löst auf dem mobilen Endgerät den App-Wechsel in das Authenticator-Modul aus).

5.3.2.5.4 Teilablauf (B): Nutzerauthentisierung am sektoralen IDP

Der ZETA Client delegiert die interaktive Nutzerauthentisierung an das Authenticator-Modul des sektoralen IDP. Im Zentrum dieses Ablaufs steht der Wechsel aus der aufrufenden App (ZETA Client) in eine dedizierte Authenticator-App (z. B. die App der Krankenkasse), in welcher der Versicherte sich sicher authentisiert (z. B. via eGK und PIN oder eID) und dem Datenzugriff zustimmt. Eine In-App-Authentifizierung ist ebenfalls möglich, wenn der Herausgeber der Fach-App (z. B. der ePA-App) identisch mit dem Anbieter des Authenticator-Moduls (z. B. der Krankenkasse als sektoraler IDP) ist.

Abbildung 23 Abb-ZETA-OIDC-Nutzerauthentisierung

(01) Der ZETA Client öffnet das Authenticator-Modul des sektoralen IDP per Deep-Link bzw. Universal-Link und übergibt client_id und request_uri.

(02) Das Authenticator-Modul übermittelt den Authentication Request (GET /auth mit client_id und request_uri) an den Authorization-Endpunkt des sektoralen IDP.

(03) Der IDP prüft die request_uri (Bezug zum zuvor gestellten PAR) und stellt die Consent-Abfrage gemäß den angeforderten claims zusammen.

(04) Der IDP fordert über das Authenticator-Modul die Nutzerauthentisierung und die Consent-Freigabe an (proprietäres Protokoll des sektoralen IDP).

(05)–(06) Der Nutzer authentisiert sich (z. B. eGK+PIN oder eID) und gibt den Consent frei.

(07) Das Authenticator-Modul bestätigt dem IDP die erfolgreiche Authentisierung.

(08) Der IDP erzeugt einen AUTHORIZATION_CODE (IDP) mit einer Gültigkeit von max. 90 Sekunden.

(09) Der IDP antwortet mit einem 302 Found. Die Location verweist auf die oidc_redirect_uri des Fachdienstes und enthält code=AUTH_CODE_IDP und state=state_as.

(10) Das Authenticator-Modul ruft den ZETA Client per App-Link bzw. Universal-Link auf und übergibt code=AUTH_CODE_IDP und state=state_as.

5.3.2.5.5 Teilablauf (C): Token-Bezug und Ausstellung der ZETA Token

Das folgende Sequenzdiagramm (Teildiagramm C) spezifiziert den finalen Abschnitt der Nutzerauthentisierung: die Auflösung des sektoralen IDP-Codes im Backend (Innerer Flow), die dynamische Policy-Evaluation und die anschließende Ausstellung des DPoP-gebundenen ZETA Access Tokens (Äußerer Flow).

Abbildung 24 Abb-ZETA-OIDC-Token-Bezug

Vorab-Definition: Routing-Logik der Redirection URIs
Da sowohl der innere Auth Code Flow (SekIDP) als auch der äußere Auth Code Flow (ZETA Guard) über App-Links/Universal-Links auf dem mobilen Endgerät terminieren, nutzt der ZETA Client eine strikte Pfad-Unterscheidung, um den korrekten Folge-Endpunkt anzusteuern:
oidc_redirect_uri (Schema: /cb/<app>/oidc): Signalisiert dem ZETA Client den Abschluss des inneren Flows. Der Client erkennt am Pfad-Suffix /oidc, dass der empfangene Code an den Redirection-Endpunkt des ZETA Guards (aus dessen as-well-known) weitergeleitet werden muss – und ausdrücklich nicht an dessen /token-Endpunkt.
redirect_uri (Schema: /cb/<app>/app): Signalisiert dem ZETA Client den Abschluss des äußeren Flows. Der Client erkennt am Pfad-Suffix /app, dass der empfangene Code nun am /token-Endpunkt des ZETA Guards eingetauscht werden muss.

Ablaufbeschreibung: OIDC Token-Bezug (Teildiagramm C)
Ausgangssituation: Der ZETA Client hat am Ende von Teildiagramm B den AUTHORIZATION_CODE (AUTH_CODE_IDP) des sektoralen IDP erhalten.

1. Innerer Flow: Token-Bezug beim sektoralen IDP
(01) Code-Übergabe an den Guard: Folgend der 302-Redirection aus Teildiagramm B ruft der ZETA Client den Redirection-Endpunkt des ZETA Guards auf (GET <oidc_redirect_uri>) und überträgt den AUTH_CODE_IDP sowie den state_as.
(02) POST /token am SekIDP: Der ZETA Guard (als Relying Party) ruft per mTLS (unter Nutzung seiner self_signed_tls_client_auth) den Token-Endpunkt des sektoralen IDP auf. Er überträgt den AUTH_CODE_IDP, seinen eigenen code_verifier_as, seine client_id und die oidc_redirect_uri.
(03) Validierung durch den SekIDP: Der sektorale IDP prüft das TLS-Clientzertifikat des Guards, verifiziert den code_verifier_as gegen die code_challenge_as (S256) und invalidiert den einmalig gültigen Authorization Code.
(04) 200 OK (Token-Ausstellung SekIDP): Der SekIDP antwortet mit HTTP 200 und übermittelt ein verschlüsseltes ID-Token (id_token als JWE: ECDH-ES/A256GCM, signiert mit ES256), ein kurzlebiges Access Token (token_type=Bearer) sowie die Gültigkeitsdauer (expires_in).
(05) Token-Entschlüsselung & Extraktion: Der ZETA Guard entschlüsselt das ID-Token, verifiziert die Signatur über die Zertifikatskette (kid/x5c), prüft iss, aud, nonce sowie exp und extrahiert die im Token enthaltenen fachlichen Identitäts-Claims (u. a. die Krankenversichertennummer (KVNR), acr und amr).

2. Äußerer Flow: Policy-Entscheidung (Policy Engine)
(06) Erzeuge AUTHORIZATION_CODE (AS): Bei positiver Policy-Entscheidung generiert der ZETA Guard einen neuen Authorization Code (AUTH_CODE_AS) für den äußeren Flow.
(07) 302 Found (Redirect an App): Der Guard beantwortet den Request des Clients aus Schritt (01) mit einem HTTP 302 Redirect auf die <app_redirect_uri>, parametrisiert mit dem AUTH_CODE_AS und dem ursprünglichen state_app.
(08) DPoP-Schlüsselpaar generieren: Der ZETA Client fängt den Aufruf der app_redirect_uri ab. Er erzeugt im Arbeitsspeicher ein neues, asymmetrisches DPoP-Schlüsselpaar (PrK.DPoP.Sig, PuK.DPoP.Sig) sowie einen frischen DPoP Proof.
(09) POST /token am ZETA Guard: Der Client ruft den Token-Endpunkt des ZETA Guards auf (POST /token), setzt den HTTP-Header DPoP und authentisiert sich via Client Assertion (signiert mit PrK.Client.Sig). Im Body überträgt er den AUTH_CODE_AS, seinen code_verifier_app, seine client_id und die app_redirect_uri.
(10) Validierung durch den ZETA Guard: Der Guard verifiziert den code_verifier_app gegen die code_challenge_app (S256), validiert den DPoP Proof und verifiziert die Client Assertion (Prüfung der Key-Bindung aus der Dynamic Client Registration).
(11) Erzeuge Policy Engine Input: Der ZETA Guard aggregiert die extrahierten Identitäts-Claims des Versicherten, die im Vorfeld erfassten Geräte-Integritätsdaten (Posture) sowie Kontextmetadaten zu einem Bewertungs-Payload.
(12) POST /v1/data/authz: Der Guard ruft die PDP Policy Engine (OPA) auf und übergibt diesen Input.
(13) Policy Decision: Die Policy Engine evaluiert die unternehmensweiten Zugriffsrichtlinien und gibt ihre Entscheidung (allow oder deny) an den Authorization Server zurück.

3. Ausstellung des ZETA Tokens (Fall: [Policy Decision allow])
(14)-(16) Ausstellung ZETA Token: Der Guard antwortet mit HTTP 200 und stellt das finale, DPoP-gebundene Access Token (token_type=DPoP), ein Refresh Token und wenn HW-Attestation verwendet wurde zusätzlich ein ZETA Guard Attestation Token (zeta_attestation_token) aus.

4. Fehlerpfad (Fall: [Policy Decision deny])
(17) 403 Forbidden: Entscheidet die Policy Engine auf Ablehnung, bricht der ZETA Guard den Prozess ab und beantwortet den Request des Clients aus Schritt (01) direkt mit HTTP 403 Forbidden unter Angabe der spezifischen Ablehnungsgründe (reasons).

5.3.2.5.6 Authentifizierung für eine andere Resource am gleichen ZETA Guard

Die Gültigkeitsdauer der Nutzer-Authentifizierung wird bei ZETA durch die Session des Authorization Servers abgebildet. Innerhalb einer gültigen Session kann der ZETA Client das Refresh Token einsetzen, um Zugriff auf andere durch den ZETA Guard geschützte Ressourcen (z. B. Notification Service Endpunkt oder Client Management Endpunkt) zu beantragen.

5.3.3 Authentifizierung ohne Nutzer-Identität

Das folgende Sequenzdiagramm spezifiziert den Prozess zur Autorisierung von Client-Instanzen bei fachlichen Aufrufen, die keinen unmittelbaren Nutzerkontext erfordern (z. B. Abfrage des Verzeichnisdienstes). Der Nachweis der Berechtigung stützt sich ausschließlich auf die kryptografische Identität und die Geräteintegrität (Posture) des anfragenden ZETA Clients.

Abbildung 25 Abb-ZETA-OAuth-Client-Authentifizierung-ohne-Nutzer

Vorbedingungen:
Die Service Discovery ist abgeschlossen; der ZETA Client kennt die Endpunkte des ZETA Guards (insbesondere den token_endpoint).
Der ZETA Client wurde über die Dynamic Client Registration (DCR) registriert und besitzt ein gerätegebundenes Signaturschlüsselpaar (PrK.Client.Sig / PuK.Client.Sig).
Für den aufgerufenen Fachdienst ist keine Nutzerauthentisierung erforderlich; bewertet wird ausschließlich der Client durch die Policy Engine.

1. Initiierung und Vorbereitung der Client-Assertion (Schritte 01 bis 06)
(01) Beauftragung: Der Fach-Client beauftragt den ZETA Client mit der Absicherung eines maschinellen Requests.
(02) DPoP-Schlüsselpaar erzeugen: Der ZETA Client generiert im Arbeitsspeicher ein flüchtiges DPoP-Schlüsselpaar (PrK.DPoP.Sig, PuK.DPoP.Sig).
(03) & (04) Nonce-Bezug: Der ZETA Client ruft proaktiv eine serverseitige Nonce beim ZETA Guard ab (GET /nonce), um Replay-Angriffe auf den nachfolgenden DPoP-Proof zu verhindern.
(05) DPoP Proof erstellen: Der Client erstellt den DPoP Proof unter Einbindung der erhaltenen Nonce.
(06) JWT-Bearer Assertion erzeugen: Der Client erstellt ein selbst-signiertes JWT gemäß RFC 7523 (Section 2.1) inklusive der Nonce und signiert dieses mit seinem privaten Instanz-Schlüssel (PrK.Client.Sig). Die Claims iss und sub entsprechen der eigenen client_id, der Claim aud der URL des Token-Endpunkts des ZETA Guards.

2. Token Request am ZETA Guard (Schritte 07 und 08)
(07) POST /token (JWT-Bearer-Grant): Der ZETA Client ruft den Token-Endpunkt des Guards auf (POST /token). Er setzt den HTTP-Header DPoP und beantragt über den Grant-Typ urn:ietf:params:oauth:grant-type:jwt-bearer ein Access Token. Im Body überträgt er die erzeugte assertion, seine client_id, den angeforderten scope sowie die Ziel-audience (im Bild noch resource).
(08) Validierung am AuthS: Der Authorization Server verifiziert die Signatur der JWT-Bearer Assertion gegen den bei der DCR hinterlegten öffentlichen Schlüssel (PuK.Client.Sig). Er prüft die zeitlichen Claims (iat, exp), schützt über den Claim jti vor Replays und validiert den DPoP Proof.

3. Reine Client-Policy-Entscheidung (Schritte 09 bis 11)
(09) Erzeuge Policy Engine Input: Da kein Nutzer involviert ist, aggregiert der Guard ausschließlich die Client-Identität, die übermittelten Posture-Daten des Geräts sowie Kontextmetadaten zu einem Bewertungs-Input. Nutzer-Identitäts-Claims werden nicht erstellt.
(10) & (11) Policy-Abfrage: Der Guard ruft die PDP Policy Engine auf (POST /v1/data/authz). Diese bewertet den Gerätezustand und gibt ihre Entscheidung (allow oder deny) zurück.

4. Token-Ausstellung & Rückgabe (Schritte 12 bis 14)
(12) 200 OK (Erfolgspfad): Bei positiver Policy-Entscheidung stellt der ZETA Guard ein DPoP-gebundenes Access Token (token_type=DPoP) und ein Refresh Token aus. Das Access Token enthält ausschließlich Client-Claims und keine Nutzer-Identität.
(13) 403 Forbidden (Fehlerpfad): Entscheidet die Policy Engine auf Ablehnung, abweist der Guard den Request unter Angabe der Ablehnungsgründe (reasons).
(14) Fachliche Rückgabe: Der ZETA Client quittiert dem aufrufenden Fach-Client den Vorgang (entweder durch Bereitstellung des abgesicherten Kanals/Tokens oder durch Weitergabe des Fehlers).

5.3.4 Dienst-zu-Dienst Kommunikation

Für die sichere Maschine-zu-Maschine Interaktion zwischen Backends wird die Workload Identity Federation zur Authentifizierung verwendet. Ein Backend-Dienst authentifiziert sich mit einem Subject Token am token_endpoint des Ziel-Dienstes und erhält nach erfolgreicher Prüfung ein Access Token für den Zugriff auf den Ziel-Dienst.

Wenn eine ZETA Guard geschützte Workload (z. B. der Resource Server) auf einen externen Dienst zugreift, der eine Authentifizierung gemäß Workload Identity Federation verlangt, dann stellt der ZETA Guard Authorization Server als OpenID Provider die erforderlichen Subject Token aus. Der ZETA Guard erstellt regelmäßig einen cronjob Pod, der ein Subject Token vom Authorization Server bezieht und dieses per Token Exchange beim Zieldienst in ein Access Token tauscht. Das Access Token wird der Workload als Secret bereitgestellt und jeweils vor Ablauf der Gültigkeit durch erneuten Start des cronjob Pods und Token Exchange erneuert. Dadurch hat die Workload permanent Zugriff auf ein gültiges Access Token und kann mit dem externen Ziel-Dienst kommunizieren.

Wenn ein ZETA Guard geschützter Resource Server als Ziel-Dienst genutzt wird, dann übernimmt der ZETA Guard Authorization Server die Rolle eines Secure Token Service in der Workload Identity Federation und tauscht beim Token Exchange das Subject Token eines anfragenden Dienstes gegen ein Access Token für den Zugriff auf den Resource Server.

Abbildung 26 : Abb-ZETA-Dienst-zu-Dienst-Kommunikation

Voraussetzung für die Dienst-zu-Dienst-Kommunikation ist:

• Die Registrierung der Issuer URI oder des Signing Keys des Anbieters im Workload Identity Pool (unter Einbindung der gematik).
• Die Verteilung der zugriffsberechtigten Workloads an die Policy Engine von Anbieter B.

Regelmäßiger Token Exchange (Subject Token gegen Access Token)
Dieser parallele Block (par) beschreibt, wie Anbieter A ein gültiges Access-Token von Anbieter B erhält:
Lokaler Token-Abruf (01–02): Der cronjob Pod fordert ein lokales Subject Token vom eigenen PDP Authorization Server (Anbieter A) an und erhält dieses.
Token-Austausch-Anfrage (03): Der cronjob Pod sendet dieses Subject Token an den PDP Authorization Server von Anbieter B, um es gegen ein Access-Token einzutauschen.
Metadaten- & Schlüsselabruf (04–07): Zur Verifizierung des Tokens ruft der Autorisierungsserver von Anbieter B die OpenID-Konfiguration und die Signaturschlüssel (JWKS) direkt vom Autorisierungsserver von Anbieter A ab.
Validierung (08): Der Server von Anbieter B validiert die Signatur des Subject Tokens.

Falls die Validierung erfolgreich ist wird ein Input für die Policy Engine erstellt (09).
Dieser wird per POST-Request an die PDP Policy Engine übermittelt (10), welche eine Entscheidung zurückgibt (11).
Entscheidung „allow“ (12–13): Anbieter B antwortet mit 200 OK und liefert das Access Token aus. Der cronjob Pod von Anbieter A speichert dieses Token als Secret im lokalen etcd (oder in einem anderen sicheren Speicher).
Entscheidung „deny“ (14): Es wird ein 403 Forbidden zurückgegeben.
Falls die Validierung fehlschlägt (15): Es wird direkt ein 403 Forbidden an den cronjob Pod zurückgesendet.

Ressourcenzugriff mit Access Token
Der zweite parallele Block (par) beschreibt den eigentlichen Zugriff auf die geschützte Ressource:
Token auslesen (16): Der Resource Server von Anbieter A liest das zuvor im etcd gespeicherte Access-Token aus.
Anfrage senden (17): Der Resource Server von Anbieter A stellt eine Anfrage inklusive des Access-Tokens an den PEP HTTP Proxy von Anbieter B.
Token-Prüfung (18): Der Proxy validiert das Access-Token.
Abzweigung (alt-Block):
Erfolgreiche Validierung (19–21): Die Anfrage wird an den eigentlichen Resource Server von Anbieter B weitergeleitet. Dieser antwortet, und die Antwort wird über den Proxy an den Resource Server von Anbieter A zurückgegeben.
Fehlgeschlagene Validierung (22): Der Proxy blockiert die Anfrage und liefert einen Fehler 401 Unauthorized zurück.

5.3.4.1 Ausgehende Verbindungen der Dienst-zu-Dienst Kommunikation mit ZG Client

5.3.4.1.1 Motivation und Abgrenzung

Die Dienst-zu-Dienst-Kommunikation funktioniert auf Basis eines regelmäßig laufenden Cronjob-Pods, der ein Subject Token bezieht, per Token Exchange gegen ein Access Token tauscht und dieses als Secret für die Workload bereitstellt. Dieses Muster eignet sich für Zielsysteme, die selbst Workload Identity Federation (WIF) gemäß RFC 8693 anbieten, erfordert jedoch, dass jede aufrufende Workload den Lebenszyklus des Secrets (Ablage, Rotation, Aktualisierung) kennt und im Fehlerfall behandelt.

Um Resource Server und andere ZETA Guard Komponenten (z. B. den Telemetriedaten-Service) vollständig von dieser Aufgabe zu entlasten, wird eine neue Komponente ZG Client (ZETA Guard Client) eingeführt. Der ZG Client übernimmt für ausgehende Aufrufe an externe Dienste – diese müssen kein TI-Dienst sein – alle notwendigen Schritte der Authentifizierung mittels Workload Identity Federation. Die aufrufende Fachkomponente sendet ausschließlich den fachlichen Request an den ZG Client; dieser reichert den Request um ein gültiges Access Token an und leitet ihn an den Zieldienst weiter. Die Fachkomponente muss weder Token-Beschaffung noch -Erneuerung noch Schlüsselmaterial verwalten.

Der ZG Client ist damit das Pendant zum ZETA Client (Kapitel 5.4) auf der Seite ausgehender Server-zu-Server-Kommunikation. Während der ZETA Client die Absicherung von Anfragen eines Clientsystems gegenüber einem ZETA Guard übernimmt, übernimmt der ZG Client die Absicherung ausgehender Anfragen einer serverseitigen Workload gegenüber einem beliebigen externen Dienst.

5.3.4.1.2 Architektur

Der ZG Client wird als eigenständiger Prozess (z. B. Sidecar-Container im selben Pod oder lokal erreichbarer Proxy)
neben der Fachkomponente betrieben. Er stellt einen lokalen Endpunkt (Egress-Proxy) bereit, an den die
Fachkomponente ihre ausgehenden Requests adressiert. Der ZG Client:

• ermittelt anhand der Ziel-Adresse des Requests die zuständige Konfiguration (Zieldienst, erforderlicher Scope/Audience, Token-Endpunkt des Zieldienstes, Subject-Token-Quelle),
• bezieht bei Bedarf ein Subject Token vom lokalen ZETA Guard Authorization Server und tauscht das Subject Token per Token Exchange (RFC 8693) beim Zieldienst gegen ein Access Token,
• cached das Access Token bis kurz vor Ablauf der Gültigkeit und erneuert es danach automatisch im Hintergrund,
• fügt das Access Token dem fachlichen Request hinzu und leitet diesen an den Zieldienst weiter,
• gibt die Antwort des Zieldienstes unverändert an die Fachkomponente zurück.

Im Unterschied zum Cronjob-Pod-Muster erfolgt die Token-Beschaffung beim ZG Client requestgetrieben bzw.
proaktiv im Hintergrund innerhalb desselben Prozesses, ohne Ablage des Access Tokens als Kubernetes Secret.

5.3.4.1.3 Konfiguration über die Policy Engine

Die Konfiguration des ZG Client (zulässige Zieldienste, Scopes/Audiences, Token-Endpunkte, Caching-Parameter)
erfolgt nicht statisch, sondern wird zur Laufzeit über die Policy Engine (PAP/PDP) bereitgestellt. Dadurch lassen sich
Berechtigungen für ausgehende Verbindungen zentral pflegen, ohne Deployments der Fachkomponenten anzupassen,
und Änderungen wirken sich ohne Neustart des ZG Client aus.

5.3.4.1.4 Ablauf

Das Sequenzdiagramm beschreibt die maschinelle Dienst-zu-Dienst-Kommunikation über System- und Anbietergrenzen hinweg (hier: von Anbieter A zu Anbieter B) mittels ZG Client.
Es visualisiert das Konzept der Workload Identity Federation. Dabei agiert der ZETA Guard des aufrufenden Anbieters (A) als lokaler Identity Provider (IdP) und stellt ein Subject Token aus. Dieses Token wird über einen OAuth 2.0 Token Exchange beim Secure Token Service (STS) des fremden Anbieters (B) gegen ein dort gültiges Access Token eingetauscht. Den Prozess steuert der ZETA Guard Client (ZG Client), der typischerweise als Egress-Proxy (Sidecar) oder SDK für die Fachkomponente fungiert.

Abbildung 27 Abb-ZETA-Dienst-zu-Dienst-Kommunikation-mit-ZG-Client

1. Konfigurationsbezug
Bevor der ZG Client externe Aufrufe absichern kann, muss er die geltenden Föderationsrichtlinien kennen. Die Konfiguration wird regelmäßig aktualisiert.
(01) Konfiguration abrufen: Der ZG Client fragt die lokale PDP Policy Engine (von Anbieter A) nach den aktuellen Konfigurationsdaten ab.
(02) Konfiguration: Die Policy Engine liefert eine Liste der zulässigen Zieldienste, die erlaubten Scopes sowie die Endpunkt-URLs der fremden Secure Token Services (STS), denen vertraut wird.

2. Initiierung des fachlichen Requests
(03) Fachlicher Request: Eine interne Fachkomponente (z. B. ein Resource Server oder ein Telemetrie-Dienst wie der otel-collector) initiiert einen Aufruf, der an einen externen Dienst (Zieldienst bei Anbieter B) gerichtet ist. Der ZG Client fängt diesen Request ab bzw. nimmt ihn entgegen, um die Autorisierungsschicht transparent hinzuzufügen.

3. Token-Management und Token Exchange
Der ZG Client prüft nun, ob er bereits über ein gültiges Access Token für das angeforderte externe Zielsystem verfügt.
Pfad A: Access Token im Cache gültig
(04) Token aus Cache verwenden: Liegt ein gültiges Access Token für den Zieldienst im lokalen Cache des ZG Clients vor, wird dieses direkt für den Aufruf verwendet (Weiter mit Schritt 10).
Pfad B: Access Token fehlt oder ist abgelaufen (Workload Identity Federation)
(05) Subject Token anfordern: Der ZG Client ruft den lokalen PDP Authorization Server (ZETA Guard von Anbieter A) auf und fordert ein Identitätstoken für den eigenen Dienst an.
(06) Subject Token: Der lokale AuthS stellt ein signiertes Subject Token aus. Dieses Token bestätigt die Identität der lokalen Fachkomponente gegenüber der Außenwelt.
(07) Token Exchange: Der ZG Client ruft den externen Secure Token Service (STS) von Anbieter B auf. Er nutzt den OAuth 2.0 Token Exchange (RFC 8693) und reicht das Subject Token ein, um im Gegenzug ein lokales Access Token von Anbieter B zu erhalten.
(08) 200 OK (Access Token): Der fremde STS validiert das Subject Token (basierend auf der Föderations-Vertrauensstellung), akzeptiert es und stellt ein neues Access Token aus, das für den Zugriff auf den Zieldienst bei Anbieter B berechtigt.
(09) Access Token cachen: Der ZG Client speichert das neu erhaltene Access Token in seinem lokalen Cache, um Folgeaufrufe zu beschleunigen.

4. Ausführung des fachlichen Requests
(10) Fachlicher Request + Access Token: Der ZG Client fügt das (entweder aus dem Cache stammende oder frisch eingetauschte) Access Token als Authorization: DPoP <Token> Header in den ursprünglichen HTTP-Request ein und leitet diesen an den externen Zieldienst (Anbieter B) weiter.
(11) Antwort: Der externe Zieldienst verarbeitet die Anfrage und sendet die fachliche HTTP-Antwort zurück an den ZG Client.
(12) Antwort (unverändert): Der ZG Client reicht die empfangene Antwort transparent und unverändert an die aufrufende interne Fachkomponente zurück.

5.3.4.1.5 Anforderungen

Hinweis: Der externe Zieldienst muss nicht zwingend ein ZETA Guard geschützter TI-Dienst sein. Es werden jedoch nur externe Dienste unterstützt, zu denen alle TI 2.0 Fachdienste des gleichen Typs eine Dienst-zu-Dienst Kommunikation benötigen.

5.3.5 Token Revocation

Das Sequenzdiagramm spezifiziert den Prozess der Token Revocation (Token-Widerruf), welcher bei einer nutzerinitiierten Abmeldung (Logout) durchlaufen wird.

Das Diagramm setzt die Vorgaben aus RFC 7009 (OAuth 2.0 Token Revocation) im Kontext der ZETA-Architektur um. Ziel ist es, aus einem reinen lokalen Logout der App eine echte, serverseitige Terminierung der Sitzung (Grant-Terminierung) beim ZETA Guard zu machen.

Abbildung 28 Abb-ZETA-Token-Revocation

Ausgangssituation: Der Nutzer ist am ZETA Client angemeldet, die App besitzt ein gültiges Refresh Token und ein zugehöriges DPoP-Schlüsselpaar.

1. Initiierung und Request-Vorbereitung
(01) Abmeldung: Der Nutzer initiiert in der Benutzeroberfläche des Primärsystems (ZETA Client) die Abmeldung. Gemäß Anforderung A_30002 ist der Client nun verpflichtet, das Refresh Token serverseitig zu widerrufen.
(02) DPoP Proof: Der Client erstellt einen DPoP Proof für den /revoke-Endpunkt. (Da dieser Endpunkt in der Regel keine Nonce erfordert, wird der Proof ohne Nonce generiert).
(03) Client Assertion: Der Client generiert ein JWT (gemäß RFC 7523) zur eigenen Authentisierung und signiert dieses mit seinem privaten Instanzschlüssel (PrK.Client.Sig). Hardware-Attestierungsdaten (Evidence) sind für diesen Endpunkt nicht erforderlich.
(04) POST /revoke: Der Client sendet den Widerrufs-Request an den Token Revocation Endpoint des ZETA Guards. Er übergibt den DPoP Proof im Header sowie die client_assertion, das zu widerrufende token (das Refresh Token) und den Hinweis token_type_hint=refresh_token im Body.

2. Authentisierung am ZETA Guard
(05) Client-Authentifizierung prüfen: Der ZETA Guard prüft die Identität und Berechtigung des aufrufenden Clients. Analog zum Token-Endpunkt werden die Client Assertion und der DPoP Proof kryptografisch validiert. (Ein Client darf ausschließlich seine eigenen Tokens widerrufen).
Der weitere Ablauf verzweigt sich anhand des Ergebnisses der Client-Authentifizierung (A_29997).

3. Erfolgreiche Client-Authentifizierung (Hauptpfad)
Wenn die Authentifizierung des Clients erfolgreich war, prüft der Server, welcher Token-Typ widerrufen werden soll.

Pfad A: Refresh Token erkannt (Der Standardfall)
(06) Token und Session terminieren: Der ZETA Guard identifiziert das übergebene Refresh Token. Gemäß A_29998 widerruft er nicht nur dieses spezifische Token, sondern alle der aktuellen Session zugeordneten (auch bereits rotierten) Refresh Tokens. Die Sitzung wird serverseitig endgültig beendet.
(07) Protokollierung: Der ZETA Guard protokolliert den Vorgang revisionssicher (inkl. Trace-Id, Session-Id, Trigger-Source und Reason-Code) (A_29857).
(08) 200 OK: Der ZETA Guard antwortet mit HTTP 200 OK.
(Wichtiger Hinweis gem. RFC 7009 §2.2 / A_29999: Diese Erfolgsmeldung wird immer gesendet, unabhängig davon, ob das Token gültig, bereits abgelaufen oder dem Server völlig unbekannt war. Dies verhindert das Ausspähen von Token-Zuständen durch Angreifer).

Pfad B: Access Token übergeben (Außerhalb des Geltungsbereichs)
(09) Umgang mit Access Tokens: ZETA Access Tokens sind extrem kurzlebig, zustandslos und DPoP-gebunden. Ein serverseitiger Widerruf (Revocation List) ist für sie nicht vorgesehen (A_30000). Sendet der Client versehentlich ein Access Token, antwortet der Server entweder mit 200 OK (ohne serverseitige Wirkung) oder weist den Request mit 400 Bad Request ("unsupported_token_type") ab.

Abschluss auf Client-Seite
(10) Lokale Bereinigung: Unabhängig von der Antwort des Servers (solange es kein 401/403 ist), löscht der ZETA Client nach dem Aufruf das Refresh Token, etwaige Access Tokens sowie die zugehörigen flüchtigen DPoP-Schlüssel aus seinem lokalen Speicher (A_30002).
(11) Abmeldung abgeschlossen: Der ZETA Client meldet dem Nutzer den erfolgreichen Logout.
4. Fehlerhafte Client-Authentifizierung (Fehlerpfad)
(12) 401 Unauthorized: Schlägt die Signaturprüfung der Client Assertion oder des DPoP Proofs fehl (Schritt 05), bricht der ZETA Guard ab und antwortet mit 401 Unauthorized (Fehlercode invalid_client).

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

5.4.2 Verbindungsaufbau

Bevor ein ZETA Client auf geschützte Fachdienste zugreifen kann, muss der netzwerktechnische Verbindungsaufbau sowie die korrekte Adressierung und Autorisierung über Token-Strukturen sichergestellt werden. Die nachfolgenden Definitionen bilden die Grundlage für die Ausgestaltung der Token-Requests und den Einsatz des ZETA/ASL-Kanals.

5.4.2.1 Definition der Endpunkte

Für den Verbindungsaufbau und die Anforderung von Token werden die folgenden Endpunkte unterschieden:

Resource Server Endpunkt: Der finale Endpunkt des aufgerufenen Fachdienstes. Die URL dieses Endpunkts MUSS mit dem Parameter resource der OAuth Protected Resource Metadata ([opr-well-known.yaml]) des jeweiligen Dienstes übereinstimmen.

ZETA/ASL Endpunkt: Der fest definierte Endpunkt für die Terminierung des ZETA Application Security Layer (ASL) Protokolls. Die URL dieses Endpunkts MUSS nach dem Schema https://<hostname>/ASL gebildet werden, wobei <hostname> exakt dem Hostnamen des ermittelten Resource Server Endpunkts entspricht.

ZETA Guard Token Endpunkt: Der Autorisierungsendpunkt des ZETA Guards (Authorization Server), an den der Token Exchange Request gesendet wird.

5.4.2.2 Adressierung und Gültigkeitsbereich (Audience und Scope)

Um sicherzustellen, dass Tokens nur für den vorgesehenen Empfänger gültig sind, muss bei der Token-Anforderung strikt zwischen Parametern des HTTP-Requests und den Claims innerhalb der JWT-Strukturen unterschieden werden.

Claim aud im Subject Token: Das Subject Token wird an den ZETA Guard gesendet, damit dieser es auswertet. Folglich MUSS der Claim aud (Audience) innerhalb des Subject Tokens exakt die URL des ZETA Guard Token Endpunkts enthalten.

Parameter resource im Token Request (HTTP Body): Dieser Parameter gemäß [RFC8707] enthält die absolute URL des aufgerufenen Endpunkts am Resource Server und wird der OAuth Protected Resource Metadata ([opr-well-known.yaml], Feld resource) entnommen. Der ZETA Guard ermittelt aus dem angeforderten resource über die Policy Engine den logischen Bezeichner der Zielressource und stellt das Access Token mit diesem Wert im Claim aud aus (siehe 5.4.2.4). Die Ressourcen-URL wird NICHT in den aud-Claim übernommen; sie wird beim späteren Aufruf der Ressource über den Claim htu des DPoP Proofs [RFC9449] an den konkreten Request gebunden.

Parameter audience im Token Request (HTTP Body): Aus Gründen der Abwärtskompatibilität DARF ein ZETA Client anstelle von resource den Parameter audience (logischer Bezeichner) senden. In diesem Fall wird der angegebene Wert unverändert als aud-Claim in das Access Token übernommen (Legacy-Verhalten, siehe 5.4.2.5). Der Parameter audience ist als veraltet gekennzeichnet; neue ZETA Clients SOLLEN ausschließlich resource verwenden.

Parameter scope im Token Request (HTTP Body): Dieser Parameter MUSS die spezifischen Berechtigungen (Scopes) anfordern, die für den Zugriff auf den unter resource definierten Endpunkt erforderlich sind. Die unterstützten Scopes werden der OAuth Protected Resource Metadata ([opr-well-known.yaml], Feld scopes_supported) entnommen.

5.4.2.3 Zusammenhang der Token Exchange Komponenten

Stationäre ZETA Clients nutzen für den Bezug eines Access Tokens den OAuth 2.0 Token Exchange Grant [RFC 8693]. Ein vollständiger, valider Token Request an den ZETA Guard (POST /token) setzt sich aus vier ineinandergreifenden kryptografischen Komponenten zusammen:

Der Token Request (HTTP Body): Die Klammer um alle Parameter. Er definiert über grant_type=urn:ietf:params:oauth:grant-type:token-exchange die Art der Anfrage, benennt über resource [RFC8707] die Endpunkt-URL der Zielressource und über scope die angeforderten Berechtigungen und bindet das Subject Token sowie die Client Assertion ein. Aus der angegebenen resource leitet der ZETA Guard über die Policy Engine den logischen aud-Claim ab; die resource-URL selbst wird nicht in den aud-Claim übernommen, sondern bestimmt den späteren Ziel-Endpunkt (Bezug zum DPoP-Claim htu, siehe 5.4.2.4).

Das Subject Token: Ein JWT, welches den Kontext der Anfrage (z.B. den Nutzer oder die Session) repräsentiert. Es ist (wie oben beschrieben) über den aud-Claim an den ZETA Guard Token Endpunkt gebunden.

Die Client Assertion: Ein JWT (client_assertion_type=...jwt-bearer), welches die Authentisierung und Integrität (Attestierung) des ZETA Clients gegenüber dem ZETA Guard nachweist. Es enthält das client_statement mit den plattformspezifischen Integritätsnachweisen (z. B. Apple App Attest oder das Software-Fallback).

Der DPoP Proof für den Request: Ein über den HTTP-Header (DPoP) übergebenes JWT. Es beweist, dass der Client im Besitz des privaten DPoP-Schlüssels ist. In diesem DPoP-Proof MUSS der Claim htm den Wert POST und der Claim htu die URL des ZETA Guard Token Endpunkts enthalten (da dieser Request an den Guard gerichtet ist).

Hinweis: Über den Parameter resource können in getrennten Token Requests verschiedene Access Tokens für unterschiedliche Zielressourcen bezogen werden. Alle so bezogenen Access Tokens werden über denselben DPoP-Schlüssel an die Client-Instanz gebunden (Claim jkt); sie unterscheiden sich im logischen aud-Claim, den die Policy Engine je Zielressource vergibt. 

5.4.2.4 Resultierende Token für den Aufruf von Fachdiensten

Nach erfolgreicher Validierung des Token Requests stellt der ZETA Guard ein Access Token aus. Der aud-Claim dieses Access Tokens enthält den von der Policy Engine festgelegten logischen Bezeichner der Zielressource, der aus dem im Request angegebenen Parameter resource abgeleitet wird. Tokens, die auf diesem Weg ausgestellt werden, trafen den Claim ver mit dem Wert 2. Wurde der Token Request im Legacy-Verfahren über den Parameter audience gestellt, so entspricht der aud-Claim dem verbatim übernommenen audience-Wert und das Token trägt ver mit dem Wert 1 (siehe 5.4.2.5).

Wenn der ZETA Client anschließend den eigentlichen Request an den Resource Server (oder den ZETA/ASL Endpunkt) durchführt, MUSS er einen neuen DPoP Proof generieren. Für diesen neuen DPoP Proof gilt zwingend: Der Claim htu MUSS exakt der URL des aufgerufenen Endpunkts entsprechen gemäß [RFC9449]; wurde im Token Request der Parameter resource angegeben, MUSS htu mit dieser URL übereinstimmen. Während der aud-Claim die Zielressource über ihren logischen Bezeichner benennt, adressiert der htu-Claim den konkret aufgerufenen Endpunkt und bindet das DPoP-gebundene Access Token an den tatsächlichen Request. Der claim htm MUSS der HTTP Methode des fachlichen Requests entsprechen.

Wenn im OAuth Protected Resource Well-known JSON Dokument angegeben ist zeta_asl_use: required_passthrough, dann hat der ZETA Client beim Token Request neben dem Access und Refresh Token für den Zugriff auf den Resource Server auch ein zusätzliches Access Token für den Zugriff auf den /ASL Endpunkt erhalten (Parameter asl_access_token).

5.4.2.5 Versionierung des Token-Ausstellungsverfahrens

Da bereits produktive ZETA Clients und ZETA Guards im Einsatz sind, MUSS das Verfahren zur Ableitung des aud-Claims versioniert und abwärtskompatibel betrieben werden. Es werden zwei Vertragsversionen (Contract Versions) unterschieden:

• Contract v1 (Legacy): Der ZETA Client sendet den Parameter audience (logischer Bezeichner). Der ZETA Guard übernimmt diesen Wert verbatim in den aud-Claim und stellt das Access Token mit dem Claim ver: 1 aus. Fehlt der Claim ver, ist das Token wie ver: 1 zu behandeln.
• Contract v2: Der ZETA Client sendet den Parameter resource [RFC8707] sowie scope. Der ZETA Guard leitet den logischen aud-Claim aus der Policy Engine Decision ([pdp-decision.yaml], Feld aud) ab und stellt das Access Token mit dem Claim ver: 2 aus.

Der ZETA Guard Authorization Server MUSS die von ihm unterstützten Vertragsversionen in seinem OAuth Authorization Server Well-known JSON Dokument ([as-well-known.yaml], Feld api_versions_supported) bekannt geben. Der ZETA Client MUSS dieses Feld vor dem Token Request auswerten und das Verfahren entsprechend wählen.

Unterstützt der ZETA Guard Contract v2 und wird der Parameter resource für eine nicht unterstützte Zielressource angegeben, so MUSS der Authorization Server den Token Request mit dem Fehler invalid_target gemäß [RFC8707] ablehnen.

Der PEP HTTP Proxy MUSS während der Übergangsphase sowohl Access Tokens mit ver: 1 als auch mit ver: 2 akzeptieren und die jeweils zutreffende Regel zum Audience-Matching anwenden.

5.4.2.6 Anforderungen

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.4.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.4.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.4.5 Session Management

Hinweis: Die Session des ZETA Clients zum ZETA Guard Authorization Server wird über den claim sid im Access Token abgebildet.

5.4.6 Fehlerbehandlung

5.4.6.1 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. Beim Zugriff auf eine Ressource über den PEP HTTP Proxy bzw. andere PDP-APIs wird unterschieden:
   (i) Step-up (401 mit error=insufficient_user_authentication, [RFC9470]): Der Client führt einmalig eine Authentisierung auf dem geforderten Niveau (acr_values aus dem WWW-Authenticate-Header) durch und wiederholt den Request. Schlägt auch dieser fehl, wird abgebrochen.
   (ii) Ungültiges/abgelaufenes Token (401 mit error=invalid_token) oder erneute Policy-Prüfung (403): Der Client DARF einmalig einen Token-Refresh unter Nutzung eines vorhandenen Refresh-Token versuchen (dies löst eine erneute OPA-Prüfung aus, z. B. nach Netzwerkwechsel/Impossible-Travel). Wird erneut 401/403 erhalten, wird 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.4.6.2 Behandlung von PEP-Fehlern mittels HTTP-Header

Für die korrekte Fehlerbehandlung im ZETA-Client (SDK) ist es erforderlich, Fehler, die direkt durch den Policy Enforcement Point (PEP) verursacht werden, von fachlichen Fehlern des dahinterliegenden Resource Servers (Fachdienstes) zu unterscheiden.

Step-up-Bedarf (unzureichendes Sicherheitsniveau) signalisiert der PEP mit 401 (Unauthorized) gemäß [RFC9470]; 403 (Forbidden) kennzeichnet eine endgültige Ablehnung. Beide Codes können sowohl vom PEP (Header zeta-error-origin: pep) als auch vom Fachdienst stammen und werden über diesen Header unterschieden.

Während fachliche Fehler des Resource Servers unverändert an den Fachclient durchgereicht werden müssen, erfordern Fehler des PEP eine dedizierte Behandlung durch das ZETA-SDK (z. B. das Initiieren eines Step-Up-Verfahrens oder ein kontrollierter Retry).
Um diese Unterscheidung ohne komplexe Payload-Analysen (insb. im Kontext von JSON- vs. CBOR-Sicherheitsprüfungen in ASL) zu ermöglichen, signalisiert das PEP eigene Fehler über einen spezifischen HTTP-Response-Header.

Hinweis: Nach RFC 6750 §3.1 ist insufficient_scope klassisch mit 403 assoziiert. Die bewusste Behandlung als 401-Step-up ist hier korrekt, weil der fehlende Scope in ZETA über eine (Step-up-)Authentisierung erlangbar ist.

5.4.7 ZETA Attestation Service

Der ZETA Attestation Service stellt einen 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.5 Client Management

5.5.1 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.5.2 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.5.3 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.5.4 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.5.4.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.5.4.2 Software Posture

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

Tabelle 11: Tab-Posture-Software

5.5.4.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.5.4.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.5.5 Vertrauensmodell, Faktoren und Geltungsbereich

Die eigentliche Client-Registrierung (dynamische Registrierung nach [RFC7591], Client Assertion JWT, Client Statement, Posture/Attestierung sowie der TOFU-Ablauf mit E-Mail-OTP) ist bereits in den vorangehenden Kapiteln normativ definiert (insb. 5.3.2, 5.5.1–5.5.3 sowie A_29658, A_25432-01). Dieses Kapitel definiert kein eigenes Registrierungsverfahren, sondern setzt darauf das Client Management auf: die faktor­gebundene Verwaltung bestehender Registrierungen über ihren Lebenszyklus hinweg (Folgeregistrierung, E-Mail-Bindung, Schlüssel-Rollover, Recovery, Client-Verwaltung und außerordentliche Löschung).

Grundlage dieses Managements ist ein Trust-On-First-Use-Verfahren (TOFU) nach [RFC7591]/[RFC7592] mit dem Faktorsatz:

• F1 – verifizierte E-Mail: auf Identitätsebene gebundener Nachweis, einmalig bei Erstnutzung gepinnt.
• F2 – Instanzschlüssel (PoP): je Client-Instanz gebundenes asymmetrisches Schlüsselpaar.

Schutzgut sind *bestehende* Client-Registrierungen gegenüber Übernahme durch einen kompromittierten sektoralen IDP. Die Grenze des Verfahrens (First-Use-Capture vor Erst­nutzung) ist akzeptiert.

Hinweis (Per-Guard-Modell): Dieselbe Identität ist je ZETA Guard ein eigenständiger Datensatz. Die gebundene E-Mail KANN zwischen Fachdiensten abweichen. Es existiert kein fachdienstübergreifendes Token; jeder Guard stellt eigene, DPoP-/audience-gebundene Token aus. Die fachdienstübergreifende Authentisierung ergibt sich ausschließlich aus dem SSO der
sektoralen IDPs, NICHT aus geteiltem ZETA-Zustand.

5.5.6 Erstregistrierung (First Use)

Hinweis: Erstregistrierung und E-Mail-OTP-TOFU nutzen die bereits definierte Client-Registration-API POST /register (Body [dcr-request.yaml]) → 202 Accepted ([dcr-response-202.yaml], challenge_type: email_otp, transaction_id) →
POST /register/verify (OTP) → 201 Created mit client_id (Status pending_user_binding); vgl. A_29658, A_25432-01.

5.5.7 Folgeregistrierung und E-Mail-Bindung

Hinweis: Die Folgeregistrierung (A_29910 und A_29911) erfolgt über die definierte API POST /register + POST /register/verify (erneute OTP-Verifikation der gebundenen E-Mail; A_29658). Die identitätsweite E-Mail-Änderung (vgl. A_29911 und A_29912) erfolgt über die Erweiterung POST /zeta/identity/email (Annex [zeta-guard-client-management]). Der Step-up-Nachweis wird dabei als vom Authorization Server ausgestelltes, DPoP-gebundenes Access Token im Feld idp_step_up übergeben; der zugehörige DPoP-Proof ([RFC9449], gebunden an Methode und Ziel-URI) im HTTP-Header DPoP. Die Verifikation der neuen Adresse erfolgt über POST /zeta/identity/email/verify (Annex [zeta-guard-client-management]); Challenge und Verify-Payload entsprechen dem definierten E-Mail-OTP-Mechanismus der Registrierung ([dcr-response-202.yaml], [verify-request.yaml], verify_type: email_otp). Erst nach erfolgreicher Verifikation wird die Änderung identitätsweit wirksam (A_29912).

Die Registrierung eines neuen Clients an einem weiteren ZETA Guard soll komfortabel und reibungsarm sein. Statt einer erneuten E-Mail-OTP-Erstnutzung KANN eine bereits bestehende, gültige und faktorgestützte Registrierung derselben Identität an einem anderen Guard als Grundlage dienen. Der Pfad ist ausschließlich clientvermittelt (der Client trägt seinen ZETA Attestation Token vom Quell‑ zum Ziel‑Guard); die Guards tauschen keinen Zustand direkt aus (vgl. A_29898 und A_29899). Da der Pfad über den Instanzschlüssel (F2) verankert ist — der aus einer IDP-Kompromittierung nicht ableitbar ist —, ist er mindestens so stark wie die E-Mail-OTP-Erstnutzung. E-Mail (F1) entwickelt sich anschließend je Guard eigenständig; eine Divergenz zwischen Fachdiensten ist ausdrücklich zulässig.

Hinweis: Da jeder zugelassene Guard einen ZETA Attestation Token für den Cross‑Guard‑Fast‑Path ausstellen kann, ist die Benachrichtigung des Identitätsinhabers die maßgebliche Erkennungs- und Widerspruchsmöglichkeit gegen ein missbräuchliches Vouching eines kompromittierten Quell-Guards.

5.5.8 Schlüssel-Rollover (Proof-of-Possession)

Hinweis: Der Client Instance Key soll initial 2 Jahre gültig sein.

5.5.9 Verwaltung von Clients/Geräten

Genutzte Schnittstellen (Annex [zeta-guard-client-management]): GET /zeta/clients , DELETE /zeta/clients/{target_client_id}, DELETE /register/{client_id} (Selbst-Deregistrierung, RFC 7592).

5.5.10 Außerordentliche Löschung (Out-of-Band) und Protokollierung

Hinweis: Genutzte Schnittstellen Operator-Pfad — Annex zeta-guard-admin-oob.yaml
(POST /deletions , POST /deletions/{deletion_id}/approve,  POST /identities/{identity_ref}/reregister-confirm , mTLS +
IDP-unabhängige Operator-Auth nach [RFC8705]). Clientseitiges Veto — Annex
[zeta-guard-client-management] POST /zeta/deletions/{deletion_id}/veto.

5.6 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.6.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.6.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.6.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.6.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.6.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.13.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.6.3 Deployment Szenarien

5.6.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.6.4 Provisioning Image für den ZETA Guard

Das Provisioning Image dient der sicheren Bereitstellung und Verteilung von kryptografischen Trust Anchors (Vertrauensankern) und Konfigurationsdaten, die der ZETA Guard zur Verifikation von Signaturen, Attestierungen und Zertifikaten benötigt. Es handelt sich um ein rein datenführendes OCI Image, welches von der gematik signiert bereitgestellt wird.

Pfad für die Produktivumgebung:

europe-west3-docker.pkg.dev/gematik-pt-zeta-prod/zeta-provisioning/zeta-guard-provisioning:latest

Pfad für die Testumgebung:

europe-west3-docker.pkg.dev/gematik-pt-zeta-test/zeta-provisioning/zeta-guard-provisioning:latest

5.6.4.1 Struktur und Inhalt

Das Provisioning Image enthält folgende Daten:

.
|-- .manifest
|-- .revision
|-- ECC-RSA_TSL-test.xml
|-- TrustedTpm.cab
|-- android-roots
|   '-- roots.json
|-- apple-roots
|   '-- apple-root.pem
|-- federation-master
|   '-- federation-master.yaml
|-- federation-master.yaml
|-- policy-engine-bundle-keys
|   |-- ca
|   |   |-- GEM.KOMP-CA8.pem
|   |   '-- GEM.RCA7.pem
|   '-- signers
|       '-- ZETA_PIPPAP_Policies_03.06.2026_16_31.pem
|-- roots.json
|-- ti-roots
|   '-- roots.json
|-- trusted-tpm
|   '-- TrustedTpm.cab
'-- tsl
    '-- ECC_PU_TSL_10322.xml

Das Provisioning Image wird als OCI-konformes Image in der oben dargestellten Verzeichnisstruktur bereitgestellt.

Das Provisioning Image enthält im Root-Verzeichnis die Dateien .manifest und .revision.

.manifest: Diese Datei enthält die SHA-256-Prüfsummen aller im Image enthaltenen Dateien im Format:

<SHA-256-Hex-Hash> <Relativer-Pfad>.

.revision: Diese Datei enthält die eindeutige Version des Bereitstellungsstands als Git-Commit-Hash oder als Versionsstring.

Hinweis: Die Dateien im Root-Verzeichnis (außer .manifest und .revision), namentlich:

• ECC-RSA_TSL-test.xml
• TrustedTpm.cab
• federation-master.yaml
• roots.json

werden aus Gründen der Abwärtskompatibilität weiterhin mitgeführt.

Hinweis: Insbesondere bei Dateien mit versions- oder laufzeitabhängigen Namensbestandteilen – wie der Trust Service Status List (TSL) im Verzeichnis /tsl/ (z. B. ECC_PU_TSL_10322.xml) oder den Richtlinien-Signaturen – MÜSSEN die ZETA Guard Komponenten die zu ladenden Dateien dynamisch ermitteln. Dies kann beispielsweise durch das Auslesen des Verzeichnisinhalts (Directory Listing), das Filtern nach Dateiendungen (z. B. *.xml, *.pem, *.json) oder die Auswertung der in der .manifest-Datei gelisteten Pfade gelöst werden.

5.6.4.2 Integritätsschutz und Verifikation

Das von der gematik bereitgestellte Provisioning Image ist kryptografisch signiert. Das für die Verifikation genutzte Signaturzertifikat der gematik wird im offiziellen GitHub-Repository unter:

https://github.com/gematik/zeta/tree/main/zeta-guard-prv-signing-key 

in den umgebungsspezifischen Verzeichnissen (prod und test) veröffentlicht.

5.6.4.3 Verarbeitung durch ZETA Guard Komponenten

5.6.4.4 Lifecycle und Update-Regeln

Das Provisioning Image wird durch die gematik neu erstellt und publiziert, sobald sich enthaltene Vertrauensanker oder Konfigurationsdateien ändern.

Bei regulären TSL-Updates erfolgt die Bereitstellung zyklisch (in der Regel alle 14 Tage). Bei ad-hoc Änderungen (z. B. Sperrung oder Austausch von CA-/Signaturschlüsseln) erfolgt die Bereitstellung unverzüglich.

5.6.5 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.6.5.1 Aktuell eingesetzte Verfahren

5.6.5.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.6.5.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.6.5.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.6.5.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. Das Service Mesh SOLL Kommunikationspfade zwischen ZETA Guard Komponenten absichern und überwachen. 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.6.5.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 und die Ingress-Kommunikation wird für IPv4 und IPv6 bereitgestellt.

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.6.5.2 Geplante Verfahren

5.6.5.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.6.5.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.7 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.7.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: Ein Nicht-Übereinstimmen des aud-Claims oder des DPoP-htu-Claims ist KEIN Step-up-Fall und wird gemäß A_29676 mit 403 (Forbidden) abgewiesen.

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

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

• Authorization Server
• Policy Engine und
• PDP Datenbank

zusammen.

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

Hinweis: Die Policy Engine muss das OPA Bundle Image nicht direkt aus der ZETA Artifact Registry laden. Ein lokaler Artifact Registry Cache kann verwendet werden.

5.8.2 PDP Authorization Server

Hinweis: RFC 6749 §5.2 definiert für den Token-Endpunkt keinen Fehlercode für eine Policy-basierte Ablehnung bei gültigen Credentials; ZETA verwendet hierfür bewusst 403 access_denied, um technische Grant-Fehler (400/401) von der autorisierungsbezogenen Ablehnung zu unterscheiden.

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

Hinweis: In Kapitel 5.3.3 Authentifizierung ohne Nutzer-Identität ist eine Autorisierung vorgesehen, bei der keine Nutzer-Identität durch ZETA Guard festgestellt wird. In diesem Fall erfolgt eine Client-Registrierung ohne Bindung an eine TI-Identität.

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

5.8.2.1 PDP Relying Party

5.8.2.2 Claims amr und acr bei Token Request

Hinweis: Die bei ZETA zulässigen gematik-LoA Werte sind gematik-ehealth-loa-high und gematik-ehealth-loa-substantial sowie gematik-ehealth-loa-low.

5.8.2.3 Token-Ausstellung

Wenn der ZETA/ASL Kanal am Resource Server terminiert, dann benötigt der PEP HTTP Proxy im äußeren POST /ASL Request ein passendes Access Token und ein DPoP Token. Die Ausstellung dieses zusätzlichen Access Tokens folgt dem versionierten Token-Ausstellungsverfahren (Contract v1/v2, siehe 5.4.2.5): Der aud-Claim benennt die Zielressource über ihren logischen Bezeichner, während die Endpunkt-URL ausschließlich über den DPoP-Claim htu gebunden wird.

Tabelle 19 Tab-ZETA-Token-Ausstellung-ASL-am-Resource-Server

Hinweis: Der <FQDN> entspricht dem <FQDN> aus dem Attribut resource des OAuth Protected Resource Well-known JSON Dokuments. Diese Endpunkt-URL https://<FQDN>/ASL wird nicht in den aud-Claim übernommen, sondern ausschließlich über den DPoP-Claim htu an den konkreten Request gebunden ([RFC9449]). Der aud-Claim des Access Tokens enthält den logischen Bezeichner des ZETA/ASL Endpunkts, den die Policy Engine aus dem angegebenen resource-Wert ableitet (Contract v2, ver: 2); bzw bei einem Legacy-Request (ver: 1) wird der Wert verbatim aus audience übernommen.

5.8.2.4 Token Revocation (RFC 7009)

Hinweis: Access Token sind kurzlebig, DPoP-gebunden und werden vom Resource Server zustandslos geprüft; ihr Widerruf ist nicht Zweck dieses Endpunkts. 

5.8.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.8.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.9 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, den Policies und den Daten des CI/CD-Prozess, festgelegt.

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

5.10 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.11 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.11.1 Sicherheits- und Datenschutzanforderungen an den HSM Proxy

5.12 Notification Service

Der ZETA Notification Service ist die zentrale Fassade vor den Push Gateways und übernimmt innerhalb der Telematikinfrastruktur die Aufgabe, Benachrichtigungen eines Fachdienstes (Resource Server) an die zugehörigen Endgeräte der Versicherten zuzustellen. Er baut auf dem Push-Notification-Konzept der gematik [gemF_PushNotification].

Fachlich ordnet sich der Notification Service als Bindeglied zwischen dem Fachdienst und der plattformspezifischen Push-Infrastruktur der Betriebssystemhersteller (Apple APNs, Google FCM) ein. Er entkoppelt den Fachdienst von den Details der Push-Zustellung, verwaltet die Push-Konfigurationen und Pusher der Clients und stellt sicher, dass Nachrichteninhalte und
Nutzeridentifikatoren geschützt verarbeitet werden.

Der Dienst wird in zwei Betriebsvarianten betrieben: mit VAU, bei der Notification Service und Resource Server gemeinsam in einer Vertrauenswürdigen Ausführungsumgebung laufen und HSM-Anbindung sowie At-rest-Verschlüsselung und Pseudonymisierung aktiv sind, sowie ohne VAU, bei der diese HSM-gestützten Schutzmaßnahmen entfallen. Die Verschlüsselung der Nachrichten ist ein pro ZETA-Guard-Instanz zentral konfigurierbares Feature; ist es nicht aktiv, werden Nachrichten unverschlüsselt weitergegeben.

5.12.1 Ablauf des Push-Versands

Das folgende Architekturbild zeigt die am Push-Versand beteiligten Komponenten und ihr Zusammenspiel entlang der Zustellkette vom Fachdienst bis zur FdV App. Es umfasst die optionale VAU mit Resource Server, Notification Service und dessen Datenhaltung, die HSM-Anbindung über den ZETA HSM Proxy, das Push Gateway sowie die plattformspezifische Push-Infrastruktur von Apple und Google. Die eingeklammerten Marker (0) bis (7) sowie (T) und (H) kennzeichnen die einzelnen Ablaufschritte, die im Anschluss an das Bild erläutert werden.

Abbildung 29 - Ablauf Notification Versand

• (0) Registrierung über das SDK: Das ZETA Client Modul (SDK) in der FdV App registriert die Pusher, verwaltet die Schlüssel und konfiguriert die Channel beim Notification Service. Optional kann der Client über das Feature Nachrichten-Historie bereits zugestellte oder ältere Benachrichtigungen abrufen, sofern der Betreiber dieses Feature aktiviert hat. Die Authentisierung erfolgt mit einem dienstspezifischen, DPoP-gebundenen ZETA-Zugriffstoken für den Notification Service.
• (1) Optionale Channel-Abfrage: Der Resource Server (Fachdienst) fragt beim Notification Service die aktiven Channel ab. Die Kommunikation erfolgt innerhalb der VAU über einen technischen Nutzer.
• (2) Nachrichtenversand vom Fachdienst: Der Resource Server übergibt die Notification-Events an den Notification Service. Dieser verschlüsselt die Nachrichten nur dann, wenn das zentral pro ZETA-Guard-Instanz konfigurierte Verschlüsselungs-Feature aktiv ist; andernfalls werden sie unverschlüsselt weitergegeben. Die Authentisierung erfolgt innerhalb der VAU über einen technischen Nutzer.
• (3) Versand an das Push Gateway: Der Notification Service leitet die Push-Nachricht an das Push Gateway weiter, verschlüsselt bei aktivem Verschlüsselungs-Feature, sonst unverschlüsselt. Die Verbindung ist über mTLS abgesichert.
• (4) Zustellung an die Push-Infrastruktur: Das Push Gateway übergibt die Nachricht an die plattformspezifische Push-Infrastruktur von Apple (APNs) beziehungsweise Google (FCM).
• (5) Zustellung an das Endgerät: Die Push-Infrastruktur stellt die Push-Nachricht an das mobile Endgerät zu.
• (6) Verarbeitung im SDK: Die FdV App reicht die empfangene Push-Nachricht an das integrierte ZETA Client Modul (SDK) weiter, das sie verarbeitet und entschlüsselt.
• (7) Anzeige in der App: Das SDK übergibt den Klartext-Payload an die FdV App, die die Benachrichtigung anzeigt.
• (T) Telemetrie: Der Notification Service liefert für alle Operationen Traces und Telemetriedaten an den Telemetriedaten-Service.
• (H) HSM-Zugriff: Der Notification Service nutzt in der Betriebsvariante mit VAU den ZETA HSM Proxy für das KEK-Wrapping (Encrypt/Decrypt). Data Encryption Key und Pseudonymisierungs-HMAC-Schlüssel werden in der VAU erzeugt und per HSM-KEK versiegelt persistiert; der KEK verlässt das HSM nicht.

5.12.2 Authentisierung

Der Notification Service besitzt drei authentisierungspflichtige Schnittstellen mit unterschiedlichen Vertrauensmodellen:

• ZETA Client Modul / SDK → Notification Service: nutzergebundener Zugriff, authentisiert über ein dienstspezifisches, DPoP-gebundenes ZETA-Zugriffstoken des ZETA Guard.
• Resource Server → Notification Service: Service-to-Service-Zugriff innerhalb der (optionalen) VAU, authentisiert über einen technischen Nutzer per mTLS Terminierung innerhalb der VAU-Vertrauensgrenze).
• Notification Service → Push Gateway: mTLS mit EV-Zertifikat in der Rolle des Fachdienstes gemäß [gemF_PushNotification]. Normativ: A_29982.

5.12.3 Rollen der Komponenten

Die Rollen der beteiligten Komponenten:

• ZetaClient Modul / SDK: integrierter Bestandteil der FdV App; übernimmt die Registrierung der Pusher inkl. Schlüsselverwaltung und Channel-Konfiguration, sowie die Verarbeitung/Entschlüsselung der von der App weitergereichten Nachrichten und gibt den Klartext-Payload zur Anzeige an die FdV App zurück.
• Notification Service: Fassade vor den Push Gateways; registriert/verwaltet Push-Konfigurationen, beantwortet die optionale Channel-Abfrage, nimmt Resource-Server-Events entgegen, verschlüsselt die Nachrichten (sofern konfiguriert) und leitet sie an die Push Gateways weiter. Teil der optionalen VAU (gemeinsam mit dem Fachdienst). Übernimmt die Push-Verarbeitungsrolle des Fachdienstes aus [gemF_PushNotification] (Pusher-/Schlüssel-/Channel-Verwaltung, Verschlüsselung, Versand).
• Notification Service DB: persistiert Push-Konfigurationen/Pusher. In Variante (A) liegen alle Daten verschlüsselt at-rest (Envelope-Verschlüsselung mit HSM-versiegeltem Schlüssel); die Nutzeridentifikatoren (KVNR/Telematik-ID) werden ausschließlich pseudonymisiert (schlüsselgebundener MAC) gespeichert und indiziert.
• ZETA HSM Proxy: einheitliche gRPC-Schnittstelle (vgl. Kap. 5.11) zum HSM des Anbieters. Der Notification Service nutzt ausschließlich die bestehende Schnittstelle mit Encrypt/Decrypt (KEK-Wrapping). Sowohl der Data Encryption Key (DEK) als auch der Pseudonymisierungsschlüssel werden in der VAU erzeugt und per HSM-KEK (Encrypt/Decrypt) versiegelt gespeichert; der KEK verlässt das HSM nicht. Die eigentliche Ver-/Entschlüsselung sowie die Pseudonymbildung erfolgen mit dem entwrappten Schlüssel innerhalb der VAU. Zugriff nur durch attestierte/gepairte VAU-Instanzen.
• Resource Server (Fachdienst): fragt optional die aktiven Channel ab und erzeugt bzw. versendet die Notification-Events; liegt ebenfalls in der VAU (falls genutzt).
• Push Gateway und Apple/Google Push-Infrastruktur: plattformspezifische Zustellkette (4)/(5) zum Endgerät.
• FdV App: empfängt die Push-Nachricht (5), reicht sie zur Entschlüsselung an das integrierte ZETA Client Modul / SDK weiter und zeigt die Benachrichtigung an.

5.12.4 Anforderungen

Hinweis zur Abgrenzung: Die hier beschriebene Verschlüsselung/Pseudonymisierung schützt die at-rest in der Notification Service DB gespeicherten Daten. Sie ist unabhängig von der Ende-zu-Ende-Verschlüsselung der eigentlichen Push-Payload zwischen Notification Service und ZETA Client Modul/SDK sowie vom mTLS-Transportschutz gegenüber dem Push Gateway.

Geltungsebene der Channel-Prüfung (Gerät vs. Nutzer): Die Channel-Konfiguration wird gemäß [gemF_PushNotification] A_27190 geräteindividuell pro pushkey geführt; ein Nutzer kann mehrere FdV-Instanzen/Geräte (Pusher) mit je eigener Channel-Auswahl registrieren. Die RS-seitige Schnittstelle GET /users/{userId}/channels bzw. die Vorprüfung beim Versand arbeitet demgegenüber auf Nutzerebene: Der Notification Service MUSS den Channel als für den Nutzer aktiv behandeln, wenn der Channel für mindestens ein registriertes Gerät (pushkey) des Nutzers den Status enabled hat (Aggregation über alle Geräte des Nutzers), und den Versand anschließend an jeden Pusher ausführen, dessen pushkey den adressierten Channel auf enabled gesetzt hat. Die gerätegenaue Auswertung bleibt damit Push-Spec-konform; die Nutzerebene ist nur eine Aggregation/Abstraktion für die RS-Schnittstelle und führt keine zweite, abweichende Channel-Haltung ein.

Hinweis (Umsetzungsvariante PEP): Die in A_29975–A_29977 und A_29979 geforderten Prüfungen des ZETA-Zugriffstokens (Signatur, exp/nbf/iat, iss, aud, Scopes, Sender-Constraining/DPoP) KANN der Betreiber statt im Notification Service selbst durch einen dem Notification Service vorgelagerten, dedizierten Policy Enforcement Point (PEP HTTP Proxy, vgl. Kap. 5.7.1) erbringen; der Ingress routet die Aufrufe des Client-Moduls dann an diesen PEP, der nur erfolgreich autorisierte Anfragen weiterleitet. Die Anforderungen gelten in diesem Fall als durch den vorgelagerten PEP erfüllt. Die objektbezogene Nutzerbindung nach A_29978 verbleibt in jedem Fall beim Notification Service.

5.13 Betrieb

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

5.13.1 Anforderungen an Hersteller einer ZETA Komponente

5.13.2 Anforderungen an Hersteller eines TI 2.0-Dienstes

5.13.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.13.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.13.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.13.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.13.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 23: Tab_gemSpec_ZETA_Schnittstellendefinition_ZETA_Guard

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 24: Tab_gemSpec_ZETA_ZETA_Artifact_Registry_Repositories

5.13.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.14 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.15 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.16 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 25: Im Dokument verwendete Abkürzungen

7.2 Glossar

Tabelle 26: Glossar der explizit im Dokument verwendeten Begriffe

7.3 Abbildungsverzeichnis