gemF_Zero-Trust_V1.0.1_CC_Aend
Prereleases:
Telematikinfrastruktur 2.0
Feature:
Zero Trust
Version |
1.0. |
Revision |
|
Stand |
|
Status |
zur Abstimmung freigegeben |
Klassifizierung |
öffentlich_Entwurf |
Referenzierung |
gemF_Zero-Trust |
Dokumentinformationen
Änderungen zur Vorversion
Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.
Dokumentenhistorie
Version |
Stand |
Kap./ Seite |
Grund der Änderung, besondere Hinweise |
Bearbeitung |
1.0.0_CC |
15.04.2024 |
|
initiale Erstellung |
gematik |
1.0.1_CC |
07.06.2024 |
|
ZT für LE-Zugang hinzugefügt |
gematik |
2.1.1 Wiedererkennung bekannter Clients
2.3.1 Maschinenlesbare Zugriffsregeln
2.3.2 Ein reproduzierbares Ja/Nein/Vielleicht
2.3.3 Policies nach Betroffenheit
2.4 Policy Information und Administration
2.5.1 Autorisierung auf Basis von Policy Entscheidungen
4.2 Policy Enforcement Point (PEP)1 Zero Trust Cluster
4.32 Policy DecisionEnforcement Point (PDPPEP)
4.4 Trust Client3 Policy Decision Point (PDP)
4.5 Policy Information und -Administration4 Trust Client
4.5.1 Policy Information Point (PIP)und -Administration
4.5.21 Policy AdministrationInformation Point (PAPPIP)
4.6 Clientregistrierung5.2 Policy Administration Point (PAP)
4.7 Monitoring6 Clientregistrierung
4.7.1 Security Information and Event Management (SIEM): Monitoring
4.7.2 Shared Signals1 Security Information and Event Management (SIEM):
4.7.3 Telemetrie, Monitoring und Logging2 Shared Signals
4.8 Zusammenspiel mit IdP7.3 Telemetrie, Monitoring und Logging
4.9 Fachdienst-Backend8 Zusammenspiel mit IdP
5 Spezifikation4.9 Fachdienst-Backend
5.1 Übergreifende Anforderungen für Datenschutz und Sicherheit Spezifikation
5.21.4 Sicherheits- und Datenschutz Anforderungen an Clientsystemedem Trust Client
5.2.1 Hersteller und Herausgeber Anforderungen an Clientsysteme
5.2.2 Verbindungsaufbau1 Hersteller und Herausgeber
5.2.3 Clientregistrierung2 Verbindungsaufbau
5.2.4 Nutzerauthentifizierung3 Clientregistrierung
5.2.5 Session Management4 Nutzerauthentifizierung
5.4 Anforderungen an Policy Enforcement Points2.5 Session Management
5.4.1 PEP Client Registry3 Zero Trust Cluster
5.4.21 PEP Relying PartyClient Registry
5.4.42 PEP http ProxyRelying Party
5.4.5 Sicherheits- und Datenschutz-Anforderungen an dem PEP3 PEP Authorization Server
5.5 Anforderungen an den Policy Decision Point4.3.1 Service Discovery
5.6 Anforderungen an den PIP und PAP Service4.3.2 Ablauf der SM-B Authentifizierung mit DPoP
5.7 Anforderungen an den Betrieb der Zero Trust Komponenten4.4 PEP http Proxy
5.74.1 5 Sicherheits- und Datenschutz-Anforderungen für nahtlose Aktualisierungenan dem PEP
5.74.2 Anforderungen für Steuerung durch Feature-Flags6 Konfiguration
5.7.35 Anforderungen zur Überwachung des Betriebsstatusan den Policy Decision Point
5.86 Anforderungen an den Test der Zero-Trust KomponentenPIP und PAP Service
6 Dokumentenhaushalt5.7 Anforderungen an den Betrieb der Zero Trust Komponenten
65.1 Neue Dokumente7.1 Anforderungen für nahtlose Aktualisierungen
65.2 Übersicht betroffener Dokumente7.2 Anforderungen für Steuerung durch Feature-Flags
65.3 Übersicht Produkt- und Anbietertypen7.3 Anforderungen zur Überwachung des Betriebsstatus
8 Anhang A – Verzeichnisse5.8 Anforderungen an den Test der Zero-Trust Komponenten
5.8.1 AbkürzungenTestartefakte
8.2 Abbildungsverzeichnis5.8.2 Testtreiberschnittstelle und Testunterstützung
8.3 Tabellenverzeichnis5.8.3 Bereitstellung der Testkomponenten und Testartefakte
5.8.4 Referenzierte DokumenteTestumgebungen und Quality Gates
8.4.1 Dokumente der gematik6 Dokumentenhaushalt
86.4.2 Weitere Referenzen1 Neue Dokumente
6.2 Übersicht betroffener Dokumente
6.3 Übersicht Produkt- und Anbietertypen
7 Beispiele und Referenzimplementierungen
1 Einordnung des Dokuments
Dieses Dokument stellt eine übergreifende Spezifikation dar, ohne einen ersten konkreten Bezug zu einem Produkttypen oder zu Schnittstellen herzustellen. Anforderungen dieses Dokuments werden Produkttypen, Schnittstellen, Komponenten oder Diensten von konkreten Use Cases bzw. von Fachanwendungen zugewiesen.
Die in diesem Dokument beschriebenen Konzepte, Abläufe und Informationsmodelle sind eine Blaupause für diedienen der Umsetzung der Paradigmen des Zero Trust in einerder "Telematikinfrastruktur 2.0". Zero Trust stellt keinen Produkttyp innerhalb der Telematikinfrastruktur (TI) dar.
Sämtliche Ausführungen sind zurückzuführen auf das Konzept [gemKPT_ZeroTrust] über die Einführung von Zero Trust zur Modernisierung der TI und konkretisieren die dortigen Ansätze zur Umsetzung in einer Fachanwendung, und revidieren an einigen Stellen vorzeitige Vorfestlegungen bzw. wählen zwischen dort vorgeschlagenen Varianten einer möglichen Zero Trust Umsetzung.
Das Zero-Trust-Modell ist ein Sicherheitskonzept, das auf dem Prinzip strenger Zugriffskontrollen und dem grundsätzlichen Misstrauen (kein implizites Vertrauen) gegenüber jedem Kommunikationsteilnehmer beruht, selbst denen, die sich bereits innerhalb eines Netzwerkperimeters befinden. Es handelt sich um ein Sicherheitsrahmenwerk, das erfordert, dass alle Benutzer und deren Clients (Gerät und App), sowohl innerhalb als auch außerhalb der Netzwerkperimeter, authentifiziert, autorisiert und kontinuierlich auf ihre Sicherheitskonfiguration und Sicherheitsnachweise überprüft werden, bevor ihnen Zugriff auf Anwendungen und Daten gewährt oder dieser aufrechterhalten wird. Motiviert durch den „Assume Breach“-Ansatz basiert dieses Architekturdesign-Paradigma im Kern auf dem Prinzip der minimalen Rechte aller Entitäten in der Gesamtinfrastruktur.
Ziel des Dokuments ist die Sammlung der technischen, betrieblichen und testrelevanten Anforderungen an Clients, Backendservices, Produkttypen, Komponenten und Dienste, die sich untereinander über das Internet vernetzen, im Gegensatz zur bestehenden TI als geschlossenes VPN. Dieses Pattern wird bisweilen auch als TI 2.0 bezeichnet.
Dieses Dokument richtet sich an Architekten und Entwickler von Komponenten, Diensten, Produkttypen, Schnittstellen und Clients für den Datenaustausch im deutschen Gesundheitswesen.
Diesem Dokument ist kein Produkt- oder Anbietertyp zuzuordnen. Anforderungen in diesem Dokument finden Anwendung in Produkt- und Anbietertypen von konkreten Fachanwendungen bzw. Use Cases.
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.
Der folgende Abschnitt gibt einen groben Überblick über die Features und Epics, die sich in Anwendungen wiederfinden, wenn sie nach dem Paradigma des Zero Trust umgesetzt werden. Diese Epics sind als Enabler zu verstehen, um Fachanwendungen einen sicheren Verbindungsaufbau zwischen Clientsystemen und Backenddiensten zu ermöglichen. Es werden keine User Stories formuliert, da für den Verbindungsaufbau keine Nutzerinteraktion angedacht ist.
Im Rahmen der Nutzeridentifikation (Authentifizierung) findet eine Verifikation ausgegebener Authentisierungsmerkmale statt, deren Nutzerinteraktion als Teil der Spezifikation des Identity Managements beschrieben sind.
Gemäß des Zero Trust Ansatzes ist jeder Schnittstellenaufruf potentiell gefährlich, soweit nicht anders festgestellt. Dazu zählt auch das Vertrauen in bekannte bzw. Misstrauen in unbekannte Geräte bzw. Clients. Um Geräte bzw. Clients wiedererkennbar zu machen, soll eine Registrierung dieser erfolgen. Sind in der Registrierung zusätzliche Sicherheitsmerkmale über das Gerät und den Aufrufkontext feststellbar, stärken diese das Vertrauen in nachfolgenden Aufrufen fachlicher Schnittstellen.
2.1.1 Wiedererkennung bekannter Clients
Die Wiedererkennung bekannter Geräte und Clients und deren Bindung an identifizierbare Nutzer des Gesundheitswesens sollmuss ü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.).
Zum Einschluss bzw. Ausschluss bestimmter Eigenschaften von Geräten und Clients, sollen selbige einer automatischen Sicherheitsprüfung unterzogen werden können (DSR - Device Security Rating), soweit es die gegebenen Plattformmechanismen erlauben und die Usability der im Fokus stehenden Anwendung nicht karikiert.
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.
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.
Nur und ausschließlich wenn ein Zugriffsversuch als legitim beschriebenbewertet wird, soll dieser Zugriff gewährt werden, im Sinne des oben genannten Gatekeepers bzw. Türstehers muss dann auch ein Zugriffsversuch gewährt und an eine fachliche Schnittstelle weitergereicht werden.
Die Menge an Regeln für die Gewähr eines Zugriffs auf Daten oder Schnittstellen ist groß und speist sich aus gesetzlichen Forderungen bzw. Verboten, Vertragskonstrukten, Sicherheitsmechanismen, Architekturentscheidungen und Informationen aus der "Umgebung" des Betriebs von Clients und Backendservices.
2.3.1 Maschinenlesbare Zugriffsregeln
Die Menge (potentiell) geltender Regeln zur Absicherung des Zugriffs auf Daten und Dienste formt ein Set von Policies. Um im Fall eines Zugriffsversuchs schnell entscheiden zu können, sollen diese Regeln maschinenlesbar definiert sein.
2.3.2 Ein reproduzierbares Ja/Nein/Vielleicht
Die Auswertung eines komplexen Regelwerks liefert bei identischen Eingangsparametern reproduzierbar das identische Ergebnis.
2.3.3 Policies nach Betroffenheit
Regeln beziehen sich auf verschiedene Aspekte einer Zugriffsentscheidung. Es gelten fachliche Regeln, Regeln zur Benutzung von Clients bzw. Geräten und ebenso technische Regeln sowie solche, die Betriebsumgebung von Backenddiensten betreffend.
2.4 Policy Information und Administration
Regeln können sich ändern und Regeln beeinflussen Regeln.
Eine Policyentscheidung kann Eingangsinformation für andere Policies sein, ebenso kann das Ändern von Rahmenbedingungen oder eine Anomalieerkennung zur Beeinflussung von Policies führen. Aus diesem Grund führen Beobachtungen über Policyentscheidungen zu Informationen über das Gesamtsystem, die als Eingangsdaten für nachfolgende Policyentscheidungen herangezogen werden. Daneben ist es erforderlich, Anpassungen am Regelwerk dem System über authentizitäts- und integritätsgeschützte Wege bekannt zu machen.
Durch ein Monitoring von Betriebsparametern und Telemetriedaten wird die Durchsetzung von Policies sowie die Auswirkung möglicher Policyänderungen transparent.
Menschen benutzen Clients und Geräte(Kombination aus Gerät und App). Jeder Zugriff auf Daten oder Schnittstellen wird auf eine menschliche Interaktion (AuthentifizierungAuthentisierung) zurückgeführt. Nach Stand der Technik erfolgt die sichere Authentifizierung meist über 2 Faktoren. Zur Wiedererkennung und sicheren Identifikation werden Menschen und Clients bzw. Geräten Authentifizierungsmerkmale ausgestellt. Die sichere Identifikation und Authentifizierung ist eine wichtige Eingangsgröße für Zugriffsentscheidungen (s. o.).
2.5.1 Autorisierung auf Basis von Policy Entscheidungen
Die Autorisierung von Zugriffen auf Daten oder Schnittstellen wird bei positiver Entscheidung durch ein Set von Policies gewährt. Die Zugriffsentscheidung und -gewähr bettet sich in eine Verkettung von Informationen und von Aufrufen verschiedener Schnittstellen ein, die dem fachlichen Aufruf einer Schnittstelle bzw. Abruf von Daten voranstehen. Stand der Technik dieses Flows mehrerer Aufrufe und der dabei transportierten Informationen ist der OAuth2-Standard, vgl. [RFC6749 et al.].
Menschen und Clients bzw. Geräte 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 bzw. Gerät 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").
Die TI 1.0 bildet mit ihremeine Infrastruktur, deren Sicherheit auf der sicheren Zugangskontrolle zu einem geschlossenen Netz eine reale Infrastruktur. Das Konzept einer TI 2.0 löst sich von einer real existierenden, dedizierten Infrastruktur und setzt auf die Vernetzung über das Internet. zentralen Netzwerk mit Diensten beruht. In der TI 2.0 werden die Dienste direkt im Internet angeboten und bedürfen daher einem Schutz vor unberechtigtem Zugriff pro Dienst. Dieser Schutz wird nach dem Zero Trust Paradigma durch den Policy Enforcement Point und den Policy Decision Point durchgesetzt.
Diese übergreifende Spezifikation richtet Anforderungen an Akteure, die sich über das Internet miteinander vernetzen. Diese Akteure seien im Folgenden einerseits Clients (Software: Aufrufende einer Schnittstelle, Anfragende an einen Datenabruf oder -zugriff, wird auf einem bestimmten Gerät ausgeführt), häufig bedient durch einen Menschen, und Backendservices (Software: bereitstellende Schnittstelle, Datenbereitstellung etc.) auf der anderen Seite.
Zur Absicherung dieser Clients und Backendservices werden zum einen Anforderungen erhoben und wird eine Empfehlung gegeben, diese Anforderungen in konkreten Softwarekomponenten innerhalb dieser Akteure umzusetzen. Die Empfehlung zur Separierung der Zero Trust Mechanismen in unterschiedliche Komponenten folgt der Zero Trust NIST Referenzarchitektur, welche im Feinkonzept [gemKPT_Zero_Trust] vorgeschlagen und für passend befunden wurde.
Abbildung 1: NIST Zero Trust Referenzarchitektur
Im Architekturkonzept der TI 1.0 werden konkrete Umgebungsannahmen zu Consumer Zonen, Secure Consumer Zonen, Plattformzonen, Personal Zonen usw. getroffen, in denen kein (Personal Zone) bzw. ein gewisses Sicherheitsniveau (überall sonst) axiomatisch angenommen wird. Das Zero Trust Konzept löst sich von der Aufteilung in verschiedene Zonen, insbesondere, da weniger (teilweise gar keine mehr) TI-Plattform-Produkttypen zwischen den Datenaustauschen unter Clients mit Backendservices involviert werden. Im Folgenden ist eine Produkttypzerlegung für die Umsetzung der NIST-Referenzarchitektur einer generischen FachwendungFachanwendung dargestellt.
In diesem Pattern greift ein Nutzer über ein Client-SystemClientsystem auf Daten einer Fachanwendung zu, die von einem Anbieter des fachanwendungsspezifischen Fachdienstes bereitgestellt wirdeines TI 2.0 Dienstes zu. Das folgende Bild zeigt eine Übersicht der beteiligten Komponenten in der Vernetzung zwischen einem ClientClientsystem (links grün) und einem Backendservice (rechts grün: Ressource BackendServer).
Abbildung 2 : Komponenten zwischen Client und ServerZero_Trust_Architektur_der_TI_2.0
Die obige Abbildung zeigt die Einbettung von Zero Trust bezogenen, logischen Komponenten (orange) in die Aufrufkette zwischen einem Client und einem Ressource Backend. (Grau)Server (grün). Dargestellt sind zusätzlich heute bereits vorhandene und genutzte Komponenten und Dienste, die für die Nutzerauthentifizierung (z. B. eGK und IDP) bzw. die Betriebsüberwachung (z. B. mittels Betriebsdatenerfassung - kurz BDE) in Anwendungsfällen der TI 2.0 weitergenutzt werden können (grau). In diese Abbildung sind diverse Architekturentscheidungen eingearbeitet, die im Kapitel 4 und 5 erläutert bzw. spezifiziert werden.
Kurzbeschreibung der Komponenten und Schnittstellen
(1) und (6): Der http Proxy erlaubt den Zugriff auf Daten des Resource Servers, wenn ein gültiges Access token im Authorization Header enthalten ist.
(2), (2.1) und (2.2): sowie optional (2.3): Um ein Access token vom Authorization Server zu erhalten, ist eine Authentifizierung des Nutzers erforderlich.
(3): Der Authorization Server stellt nur ein Access token aus, wenn der PDP seine Erlaubnis gegeben hat.
(4a) und (4b): Der Authorization Server fordert bei mobilen Apps zusätzlich zur Nutzer-Authentifizierung eine Client Registrierung mit Geräte/App-Attestierung ein, bevor ein Access token ausgestellt wird. Bei stationären Clientsystemen (z. B. Primärsystem) erfolgt die Geräteregistrierung implizit bei der SM-B Authentisierung.
(5): Die Client Registrierung erfordert eine Bestätigung des Nutzers durch einen zweiten Faktor.
(7): Die Telemetrie-Daten der Komponenten des ZT Clusters werden an das Monitoring System des Betreibers übergeben.
(8.1) und (8.2): Der Resource Server und der optionale Application Authorization Server werden ebenfalls vom Monitoring überwacht.
(j9.1) und (9.2): Aus den Monitoring Daten werden die Daten der Betriebs-Daten-Erfassung gebildet und versendet.
(10.1) und (10.2): Wenn der Betreiber ein SIEM einsetzt, werden aus dem Monitoring SIEM Daten ermittelt und optional an das zentrale SIEM der gematik gesendet.
(11): Der PDP fragt regelmäßig den PIP und PAP Service nach neuen Policies und Daten ab.
(12): Der Cluster Management Service überwacht die Clusterkonfiguration und setzt durch, dass die im GitHub Repository gespeicherte Konfiguration ausgeführt wird.
4 Technisches Konzept
Im Kapitel zuvor wurden zwei Abbildungen vorgestellt, welche technischen Zero Trust-Komponenten (orange) an der Umsetzung fachlicher Anwendungsfälle von Clients, Komponenten und Backendservices von Fachanwendungen (grün) beteiligt sind. Im Folgenden werden diese technischen Komponenten genauer beschrieben und eingeordnet, welche Rolle sie in einer Architektur nach dem Zero Trust-Paradigma einnehmen. Dieser Komponentenschnitt ist nicht notwendigerweise ein Schnitt in konkrete Produkttypen einer Fachanwendung. Je nach gegebenem Rahmen setzen Produkttypen einer Fachanwendung diese Komponenten um oder nutzen Schnittstellen zu diesen Komponenten in anderen (bestehenden) Produkttypen der TI 2.0.
Zero Trust in der TI zeichnet sich über folgende Eigenschaften aus:
- Registrierung
der Gerätedes Clients (Gerät und App) zu einer Identität - Attestation der
GeräteeigenschaftenClient-Eigenschaften - Bereitstellung einer von Maschinen interpretierbaren Policy durch die gematik
- Einheitliches Durchsetzen der Policy durch die Fachdienste
- Sicherstellung des Sicherheitszustands der gesamten TI, Anbieter übergreifend
- Telemetrie und Monitoring
Der Zero Trust Cluster (ZT Cluster) besteht aus Policy Enforcement Point (PEP), Policy Decision Point (PDP) sowie betriebsunterstützenden Komponenten (Cluster Management Service und Telemetrie Daten Service). Der PEP ist aufgeteilt in http Proxy, Authorization Server und Client Registry. Jeder TI 2.0 Dienst hat einen ZT Cluster zum Schutz des Dienstes vor unberechtigtem Zugriff. Der ZT Cluster wird in der Verantwortung des TI 2.0 Dienst-Betreibers betrieben.
4.2 Policy Enforcement Point (PEP)
Ein Policy Enforcement Point (PEP) ist eine Schlüsselkomponente im Zero Trust-Paradigma, der darauf abzielt, dass Sicherheitsmodell von einem vertrauensbasierten auf ein verifizierungsbasiertes umzustellen. Der PEP dient dazu, den Zugriff auf Ressourcen, basierend auf vordefinierten Richtlinien, zu kontrollieren und durchzusetzen. Im Kontext der TI 2.0 übernimmt der PEP folgende Funktionen:
- Der PEP agiert als
Forwardproxyhttp Proxy, der den Datenverkehr zwischen Clientanwendungen und den zu schützenden Ressourcen kontrolliert. Dadurch kann der PEP den gesamten Datenverkehr überwachen und filtern, um sicherzustellen, dass er den festgelegten Sicherheitsrichtlinien entspricht.
- Der PEP ist als vertrauenswürdige Relying Party im föderierten Identitätsmanagement registriert. Dadurch kann der PEP Identitätsinformationen von Benutzern sicher und vertrauenswürdig beziehen und bei Bedarf eine (erneute) Nutzer-Authentifizierung an die IDPs delegieren. Dadurch stellt der PEP sicher, dass nur authentifizierte Benutzer Zugriff auf die geschützten Ressourcen erhalten.
- Der PEP fungiert als OAuth2
AutorisierungsdienstAuthorization Server und verwaltet die Autorisierung von Benutzeranfragen auf geschützte Ressourcen. Zudem überwacht der PEP die Benutzersessions, um sicherzustellen, dass sie gültig sind und den Sicherheitsrichtlinien entsprechen.
- Der PEP ermöglicht die dynamische Registrierung von Clients
bzw. Geräten, die auf geschützte Ressourcen zugreifen möchten. Dies umfasst auch die Offband-Bestätigung, bei der zusätzliche Sicherheitsmechanismen (Verifikation via E-Mail oder SMS) verwendet werden, um die Identität und Integrität (plattformabhängig) der registrierten Clients zu überprüfen.
Insgesamt agiert der PEP als zentraler Kontrollpunkt imin der Zero Trust-Netzwerk Architektur, der sicherstellt, dass nur autorisierte Benutzer und Geräte Zugriff auf die Ressourcen eines Dienstes erhalten und dass dabei die definierten Sicherheitspolicies einhalteneingehalten werden. Die Entscheidung zwischen verschiedenen Policies auf Basis der vom Client übergebenen Signale, Sicherheitsnachweise und Token trifft der Policy Decision Point.
In der TI 2.0 ist der PEP Teil der Betriebsumgebung eines Fachdienstes einer Fachanwendung.
4.3 Policy Decision Point (PDP)
Ein Policy Decision Point (PDP) ist die wesentliche Komponente im Zero Trust-Paradigma, die Zugriffsentscheidungen auf Plattformebene trifft, indem sie Richtlinien (Policies) interpretiert und anhand dieser Richtlinien Zugriffsanfragen bewertet. Folgende Funktionen eines PDP sind dabei zentral:
- Der PDP analysiert und interpretiert die Sicherheitsrichtlinien, die im Rahmen des Zero Trust-Modells definiert sind. Diese Policies können Kriterien enthalten wie Benutzeridentität, Gerätetyp, Standort, Zeitpunkt der Anfrage und andere Kontextinformationen ("Signale"), die relevant für die Zugriffsentscheidung sind.
- Basierend auf der Interpretation der Policies trifft der PDP Entscheidungen darüber, ob eine Zugriffsanfrage auf eine bestimmte Ressource genehmigt oder abgelehnt wird. Diese Entscheidungen erfolgen auf Plattformebene, was bedeutet, dass der PDP die Zugriffsanfragen im Kontext der gesamten Plattform oder des Netzwerks bewertet, und nicht isoliert betrachtet. Die Zugriffsentscheidung resultiert dann in der Ausstellung eines Access Tokens, das für den konkret angefragten Zugriff verwendet wird (siehe Policy Enforcement).
- Der PDP verwendet dabei die Informationen, die ihm übermittelt werden, um die Zugriffsentscheidung zu treffen. Dazu gehören nicht nur die Policies selbst, sondern auch Echtzeitinformationen über den Zustand von Benutzeridentitäten, Geräten und andere Kontextinformationen, die für die Bewertung der Zugriffsanfrage relevant sind.
Insgesamt fungiert der PDP als zentraler Mechanismus zur Durchsetzung von Sicherheitsrichtlinien im Rahmen des Zero Trust-Modells. Durch die Analyse von Policies und die Bewertung von Zugriffsanfragen auf Plattformebene trägt der PDP dazu bei, sicherzustellen, dass nur autorisierte Benutzer und Geräte Zugriff auf geschützte Ressourcen erhalten, unabhängig von ihrem Standort oder anderen Kontextfaktoren.
In der TI 2.0 ist der PDP entweder Teil der Betriebsumgebung eines Fachdienstes einer Fachanwendung oder wird durch einen zentralen Fachdienst realisiert, der die (erste) Autorisierungsentscheidung für Fachdienste weiterer Fachanwendungen übernimmt - bspw. als Nachweis einer Proof-of-Patient-Presence.
Im Kontext von Zero Trust stellt der "Trust Client" eine logische Komponente innerhalb einer Clientanwendung (Primärsystem (PS), Frontend des Versicherten (FdV) etc.) dar, die im Rahmen des Zero Trust-Paradigmas als vertrauenswürdig eingestuft wird. Dies steht im Gegensatz zu der traditionellen Annahme, dass ein, eine Schnittstelle aufrufendes, Clientsystem automatisch als vertrauenswürdig betrachtet wird. Das Vertrauen in Clientanwendungen erwächst beispielsweise durch regelmäßige Softwareupdates, authentische und verschlüsselte Kommunikation und die Verwendung von Zertifikaten, die die Einhaltung dieser Maßnahmen beweisen.
Ein Trust Client im Zero Trust-Modell wird nicht mehr blind als vertrauenswürdig angesehen, sondern muss genauso wie alle Komponenten im Netzwerk kontinuierlich authentifiziert und autorisiert werden. Selbst wenn ein Endpunkt als Trust Client eingestuft ist, bedeutet dies nicht, dass er ungehinderten Zugriff auf alle Ressourcen im Netzwerk hat. Stattdessen werden Zugriffsentscheidungen basierend auf aktuellen Richtlinien, Kontextinformationen, Bedrohungsinformationen und insbesondere in Kenntnis des diesen Client benutzenden Benutzers getroffen (s. u. Zusammenspiel mit Identity Provider (IdP)).
4.5 Policy Information und -Administration
Im Zero Trust-Paradigma spielen der Policy Information Point (PIP) und der Policy Administration Point (PAP) wichtige Rollen bei der Verwaltung und Durchsetzung von Sicherheitsrichtlinien bzw. Policies. Zusammen ermöglichen der PIP und der PAP eine zentrale Verwaltung und Bereitstellung von Policies im Zero Trust-Netzwerk.
Der PAP stellt Policies bereit und der PIP stellt die Daten für die Policies bereit, sodass sich aus beiden ein Regelwerk ergibt, das der PDP anwendet, um zu entscheiden, ob eine Kommunikationsanfrage zulässig ist.
4.5.1 Policy Information Point (PIP)
Der PIP ist für die Bereitstellung von Informationen über Sicherheitsrichtlinien zuständig. Er dient als zentraler Informationsdienst, der anderen Systemen und Komponenten im Zero Trust-Netzwerk Zugriff auf aktuelle Sicherheitsrichtlinien ermöglicht. Der PIP kann Attribute wie Benutzerrollen, Zugriffsrechte, Gerätezustände und andere Kontextinformationen bereitstellen, die von anderen Komponenten für die Zugriffsentscheidung benötigt werden. Der PIP kann Daten aus verschiedenen Quellen beziehen, einschließlich einer zentralen Richtliniendatenbank, externen Identitätsanbietern, Sicherheitsinformationen von Geräten und anderen Quellen.
4.5.2 Policy Administration Point (PAP)
Der PAP ist für die Verwaltung und Konfiguration von Sicherheitsrichtlinien verantwortlich. Er bietet eine Schnittstelle oder eine Konsole, über die Richtlinien in hoheitlicher Verantwortung definiert, geändert und gelöscht werden können. Policy-Administratoren können im PAP Zugriffsregeln, Autorisierungsniveaus, Bedrohungsabwehrmaßnahmen und andere Sicherheitsrichtlinien festlegen. Der PAP ermöglicht es Policy-Administratoren, Richtlinien - basierend auf verschiedenen Kriterien wie Benutzerrollen, Gruppenzugehörigkeit, Standorten und Geräteattributen - zu differenzieren. Änderungen an den Sicherheitsrichtlinien, die im PAP vorgenommen werden, werden an den PIP weitergegeben, damit andere Komponenten im Zero Trust-Netzwerk auf die aktualisierten Richtlinien zugreifen können. Das Vertrauen in bereitgestellte und angepasste Policies wird über Signaturen für die Sicherstellung von Integrität und Authentizität jeder Policy sichergestellt.
Alle Clients, die mit Diensten der TI2.0 kommunizieren, sind zur Laufzeit bekannt. Mit einer Attestierung in Abhängigkeit der verfügbaren Mechanismen der Laufzeitumgebung (Geräte-Features, Betriebssystem) kann ein Vertrauen und eine Wiedererkennung von Clients und Geräten aufgebaut werden.
Die folgenden statischen Eigenschaften werden im Rahmen der Bereitstellung von Clientanwendungen erfasst und sind unabhängig von der Nutzung durch einen konkreten Benutzer.
Tabelle 1: Statische Eigenschaften Clientsysteme auf Hersteller-/Herausgeber-/Anbieterebene
Client Eigenschaft |
Beschreibung |
Produkt-Id |
Eindeutige ID der Client-Software,, vergeben durch gematik über einen ITSM Prozess |
Produkt-Name |
Produkt-Name, vergeben durch den Hersteller |
Hersteller-Id |
Kennung des Herstellers aus TI-ITSM |
Hersteller-Name |
Name des Herstellers aus TI-ITSM |
Produkt-Platform |
Zunächst werden zwei Plattformen gesondert behandelt: Android und Apple (iOS, macOS etc). Diese beide Plattformen bieten Mechanismen für die Attestation der Client-Instanzen und der Umgebung, in welcher diese Clients ausgeführt werden. |
Produkt-Plattform-Id |
Plattformspezifisch eindeutige Kennung der Client-Software |
Attestation-Methode |
Die Methode, nach welcher die Client-Software und die Ablaufumgebung attestiert werden kann. |
Bei der Registrierung werden die statischen Eigenschaften eines Client-Systems für jede Client-Instanz mit einem vom Client-BesitzerNutzer signierten Softwarestatement bekannt gemacht. Durch die Registrierung bekommen die Clients eine kryptographische Identität und werden Server-seitig an den BesitzerNutzer gebunden. Der BesitzerNutzer muss bei der Registrierung eine TI-Identität vorweisen, z. B. GesundheitsID oder SM-B (über IDP-Dienst der gematik).
Zur Laufzeit werden die Client-Eigenschaften durch Client-Instanz-Eigenschaften ergänzt. Sie sind spezifisch für eine konkrete Installation auf einem bestimmten Gerät eines Benutzers. Sie sind insofern dynamisch, als dass sich der Patchlevel des Betriebssystems oder sich die Version der Clientinstanz durch Updates verändern kann.
Tabelle 2 : Eigenschaften Clientsysteme auf Instanzebene (pro Installation
Client-Instanz-Eigenschaften |
Beschreibung |
Produkt-Version |
Aktuelle Version der Client-Software |
Client- |
Informationen über den Client- |
Client-Eigenschaften (Posture) |
Aktuelle Eigenschaften der Ablaufumgebung des Clients, insbesondere:
|
Client-Attestation |
Falls die Plattform die Attestation des Clients ermöglicht, wird hier plattformspezifische Attestation angegeben.
|
Die Auskünfte bzw. Attestation von Clientsoftware und Geräten werden von einer Backendschnittstelle für die Clientregistrierung geprüft. Zusätzlich wird über diese Schnittstelle eine Offband-Verifikation des Benutzers durchgeführt, beispielsweise über Bestätigungscode oder -link via E-Mail. Ist die Clientregistrierung erfolgreich, wird der Client-Instanz(!) ein Nachweis über die attestierten Client- und Client-Instanz-Eigenschaften ausgestellt. Dieser Nachweis ist in folgenden Aufrufen von Schnittstellen der TI Teil der Zugangsprüfung.
Die Geräteattribute werden von den Plattformen der Endgeräte geliefert. Ihre Erhebung erfolgt im TrustClient des Endgeräts mittels plattformspezifischer Attestierungs- und Erhebungsmechanismen (siehe [Apple Platform Security Guide] und [Android Platform Security Model]). Die Attribute sind daher für die jeweilige Plattform und ihr Sicherheitsmodell spezifisch. Die für die Zugriffsentscheidung verwendeten Attribute werden daher im Folgenden für iOS-Geräte separat von denen für Android-Geräte aufgeführt.
Android
Tabelle 3: Verwendete Device Claims für Android-Geräte
Attribute |
Beschreibung |
aktuelle Android Version |
aktuell auf dem Gerät laufende Android Version bzw. API Level / SDK Version |
Android Version bei Veröffentlichung |
Android Version (API level) mit welchem das Gerät veröffentlicht / CTS durchlief |
Patchlevel |
Verschiedene Patch-Level-Angaben für OS & Co |
FDE / FBE |
Gibt an, ob Geräteverschlüsselung unterstützt wird und ob diese aktiviert ist. |
System PIN / Password /Pattern gesetzt |
Gibt an, ob ein PIN/Pattern/Passwort für den Sperrbildschirm gesetzt ist. |
System PIN / Password /Pattern Qualität |
Über den Device Policy Manger kann abgefragt werden, ob aktuell bestimmte Passwort-Komplexitätslevel erfüllt werden. |
VerifiedBoot verfügbar |
Gibt an, ob VerifiedBoot auf dem Gerät zur Verfügung steht (siehe [VerifiedBoot]). |
Mainline Patchlevel |
Gibt an, wann der letzte Mainline Patch installiert wurde. |
Gerätehersteller / -modell |
Gibt Informationen zu Hersteller, Model usw. zurück. |
Biometric Class |
Gibt Informationen zur Güte der vorhandenen biometrischen Sensoren zurück. |
iOS
Tabelle 4: Verwendete Device Claims für iOS-Geräte
Attribute |
Description |
System Name |
Name des Betriebssystems auf dem Gerät |
System Version |
Version des Betriebssystems auf dem Gerät |
Model |
Art des Geräts, z. B. ”iPhone” oder”iPod touch” |
identifierForVendor |
Eindeutige Kennung des Geräts für den App-Anbieter |
App Version |
Version der App auf dem Gerät |
Das Monitoring im Kontext von Zero Trust ist ein entscheidender Aspekt, um die Sicherheit des Netzwerks und der Ressourcen kontinuierlich zu überwachen und potenzielle Bedrohungen oder Anomalien zu identifizieren. Dieses bedient sich auch eines Security Information and Event Management (SIEM) und Shared Signals, die zukünftige Policyentscheidungen beeinflussen, in dem Erkenntnisse des Monitorings über den Policy Information Point den Policy Decision Points der verschiedenen Fachanwendungen verfügbar gemacht werden.
Insgesamt ermöglicht das Monitoring im Kontext von Zero Trust eine kontinuierliche Überwachung der Sicherheitslage, indem es aktuelle Sicherheitsrichtlinien berücksichtigt, potenzielle Bedrohungen identifiziert und auf Shared Signals zurückgreift, um umfassende Sicherheitseinblicke zu erhalten.
4.7.1 Security Information and Event Management (SIEM):
SIEM-Systeme spielen eine zentrale Rolle im Monitoring im Zero Trust-Paradigma. Sie sammeln Daten aus verschiedenen Quellen wie Protokollen, Ereignissen und Alarmen von Sicherheitskomponenten im Netzwerk. Durch die Analyse dieser Daten in Echtzeit können SIEM-Systeme potenzielle Sicherheitsvorfälle erkennen und Anomalien identifizieren. SIEM-Systeme können auf die vom PIP bereitgestellten Sicherheitsrichtlinien zugreifen und sicherstellen, dass die Überwachung entsprechend den aktuellen Richtlinien erfolgt. Anbieter von Betriebsleistungen mittels Produkttypen der TI (1.0) erhalten durch eine Anbieterzulassung die Auflage, Anforderungen an ein [ISMS] zu erfüllen. Hierfür können sie bspw. SIEM-Systeme oder Intrusion Detection Systeme (IDS) verwenden. In der Weiterentwicklung zur TI 2.0 wird dieses Konzept fortgeführt, und finden die so gesammelten Informationen über den Sicherheitszustand eines Systems wieder Eingang in Zugriffsentscheidungen eines Policy Decision Points.
Shared Signals sind Hinweise oder Indikatoren für Sicherheitsvorfälle, die von verschiedenen Systemen und Quellen im Netzwerk gemeinsam genutzt werden. Diese Signale können von verschiedenen Sicherheitskomponenten wie Firewalls, Endpunktschutzsystemen, Intrusion Detection Systems (IDS) und anderen generiert werden.
SIEM-Systeme aggregieren und korrelieren diese Signale, um umfassende Einblicke in die Sicherheitslage des Netzwerks zu erhalten und potenzielle Bedrohungen zu identifizieren. Durch die Integration von Shared Signals in das Monitoring kann eine umfassende und ganzheitliche Sicherheitsüberwachung gewährleistet werden, die potenzielle Angriffe frühzeitig erkennt und darauf reagiert.
4.7.3 Telemetrie, Monitoring und Logging
Betriebliche Monitoring-Daten werden Zero-Trust-Komponenten-übergreifend in einem betrieblichen Rohdaten Log erfasst. Das Log wird für die Generierung von Bestandsdaten für die gematik benutzt. Dieses Daten zum Zwecke des Monitorings (Telemetrie) werden von den Zero Trust Komponenten erhoben und für die eingesetzten Zero Trust Komponenten übergreifend in einer gesicherten Monitoring-Komponente erfasst. Bei der Nachbereitung der Telemetriedaten werden personenbezogene oder-beziehbare Daten anonymisiert, um diese bereinigten Daten dem Betreiber regelhaft zugänglich zu machen. Das bereinigte Monitoring-Log kann von dem Betreiber für sein eigenes betriebliches Monitoring und als Quelle für sein SIEM-System verwendet werden. Das bereinigte Monitoring-Log wird unter Anderem zur Generierung von Rohdatenlieferungen und Bestandsdaten für die gematik benutzt.
Im Zero Trust-Paradigma arbeiten der PEP und der IdP zusammen, um den Zugriff auf Ressourcen - basierend auf den definierten Sicherheitsrichtlinien und der Benutzeridentität - zu kontrollieren. Das Stichwort "Step-up-Authentifizierung" bezieht sich auf eine Sicherheitsmaßnahme, bei der der Benutzer zusätzliche Authentifizierungsschritte durchlaufen muss, um auf sensible Ressourcen zuzugreifen. Diese Maßnahme wird wie folgt realisiert:
- Zugriffsanfrage des Benutzers: Ein Benutzer möchte auf eine geschützte Ressource zugreifen und sendet eine Zugriffsanfrage an den PEP.
- Überprüfung durch den PEP: Der PEP empfängt die Zugriffsanfrage und überprüft
sie gemäß den definierten Sicherheitsrichtliniendie http Header-Daten. Dies kann bedeuten, dass der PEP feststellt, dass die Zugriffsanfrage eine höhere Sicherheitsstufe erfordert als die Standardauthentifizierungsmethode des Benutzersoder. Oder der Authentifizierung wird nicht mehr vertraut, da sie zu weit in der Vergangenheitliegenliegt. - Weiterleitung an den IDP: Falls eine Step-up-Authentifizierung erforderlich ist, löst der PEP die Zugriffsanfrage an den IDP aus, der für die Authentifizierung des Benutzers zuständig ist.
- Step-up-Authentifizierung: Der IDP erkennt die Anforderung für eine Step-up-Authentifizierung und fordert den Benutzer auf, zusätzliche Authentifizierungsschritte durchzuführen. Dies könnte beispielsweise die Eingabe eines Einmalpassworts, die Verwendung von Biometrie oder die Bestätigung über ein zweites Gerät sein.
- Authentifizierungsbestätigung: Nach erfolgreicher Durchführung der Step-up-Authentifizierung bestätigt der IDP die Identität des Benutzers gegenüber dem PEP.
- Zugriffsgewährung durch den PEP: Der PEP erhält die Authentifizierungsbestätigung vom IDP und gewährt dem Benutzer basierend auf den Sicherheitsrichtlinien Zugriff auf die angeforderte Ressource.
Das Zusammenspiel zwischen PEP und IDP ermöglicht es, den Zugriff auf sensible Ressourcen - basierend auf der aktuellen Sicherheitslage und der Identität des Benutzers - zu steuern. Die Step-up-Authentifizierung stellt sicher, dass zusätzliche Sicherheitsmaßnahmen - wenn erforderlich - ergriffen werden, um die Integrität und Vertraulichkeit der geschützten Daten zu gewährleisten.
Das Fachdienst-Backend stellt das Ziel jedes Zugriffswunschs eines Nutzers über sein Clientsystem dar. Es stellt fachliche Schnittstellen zur Nutzung durch Clientsysteme dar, die über die Mechanismen des Zero Trust abgesichert werden.
Dieses Kapitel beschreibt die technische Umsetzung der beschriebenen Konzepte an die oben eingeführten Komponenten des Zero Trust (Zero Trust-Komponenten) als generische Produkt- und Anbietertypen. Diese Anforderungen finden Anwendung in den Steckbriefen von konkreten Produkt- und Anbietertypen der jeweiligen Fachanwendung und erhalten erst in der dortigen Zuordnung ein konkretes Prüfverfahren.
5.1 Übergreifende Anforderungen für Datenschutz und Sicherheit
A_25400 - Zero Trust-Komponenten - Umsetzung Sicherer Softwareentwicklungsprozess
Der Hersteller einer Zero Trust-Komponente MUSS einen sicheren Softwareentwicklungsprozess umsetzen (siehe [gemSpec_DS_Hersteller#Kapitel 2.2 Sicherer Softwareentwicklungsprozess]). [<=]
A_25401 - Zero Trust-Komponenten - Darstellung der Voraussetzungen für sicheren Betrieb des Produkts im HandbuchBetriebshandbuch
Der Hersteller einer Zero Trust-Komponente MUSS für sein Produkt im dazugehörigen HandbuchBetriebshandbuch leicht ersichtlich darstellen, welche Voraussetzungen vom Betreiber und der Betriebsumgebung erfüllt werden müssen, damit ein sicherer Betrieb des Produktes gewährleistet werden kann. [<=]
A_25402 - Zero Trust-Komponenten - Schutz der transportierten Daten
Alle Zero Trust-Komponenten MÜSSEN sicherstellen, dass die Vertraulichkeit und Integrität der transportierten Daten gewährleistet ist. [<=]
A_25403 - Zero Trust-Komponenten - Schutzmaßnahmen gegen die OWASP Top 10 Risiken
Alle Zero-Trust-Komponenten MÜSSEN technische Maßnahmen zum Schutz vor den Risiken in der aktuellen Version der [OWASP-Top-10-Risiken] umsetzen. [<=]
A_25404 - Zero Trust-Komponenten - Angriffe erkennen
Alle Zero Trust-Komponenten MÜSSEN Maßnahmen zur Erkennung, Kategorisierung und Protokollierung bzw. Meldung von Angriffen umsetzen. [<=]
Hinweis: Für die Kategorisieren von Angriffen ist eine Kategorisierung nach "CAPEC: OWASP Related Patterns"[CAPEC OWASP] zu verwenden.
A_25405 - Zero Trust-Komponenten - Angriffen entgegenwirken
Alle Zero Trust-Komponenten MÜSSEN Maßnahmen zur Schadensreduzierung und -verhinderung von Angriffen umsetzen. [<=]
A_25406 - Zero Trust-Komponenten - Eingabe Validierung von Operationen
Alle Zero Trust-Komponenten MÜSSEN sicherstellen, dass alle Daten und Parameter, die über eine API kommuniziert werden, sicherheitstechnisch validiert werden. [<=]
Hinweis: Eine Eingabe-Validierung von Fachdienst APIs erfolgt im Fachdienst und nicht in den Zero Trust-Komponenten.
A_25407 - Zero Trust-Komponenten - Sicherheitstechnische Validierung von Policy und Konfigurationen
Alle Zero Trust-Komponenten MÜSSEN sicherstellen, dass alle Daten und Parameter, die von einer Konfigurationsdatei oder Policy gelesen werden, sicherheitstechnisch validiert werden. [<=]
A_25408 - Zero Trust-Komponenten - Verbot unbefugter Profilbildung
Der Betreiber einer Zero Trust-Komponente DARF anfallende Zero Trust-Verbindungsdaten (Client Eigenschaften, Client-IP-Adresse etc.) NICHT für eine unbefugte Profilbildung der verbundenen Clients bzw. ihrer Nutzer verwenden.
[<=]
A_25409 - Zero Trust-Komponenten - Privacy by Design
Alle Zero Trust-Komponenten MÜSSEN sicherstellen, dass bei Konfigurationsmöglichkeiten die datenschutzfreundlichere Option vorausgewählt ist. [<=]
A_25410 - Zero Trust-Komponenten - Verbot von Werbe- und Usability-Tracking
Alle Zero Trust-Komponenten DÜRFEN im Produktivbetrieb ein Werbe- und Usability-Tracking NICHT verwenden. [<=]
A_25411 - Zero Trust-Komponenten - Verbot vom dynamischen Inhalt
Alle Zero Trust-Komponenten DÜRFEN dynamischen Inhalt von Drittanbietern NICHT herunterladen und verwenden. [<=]
A_25412 - Zero Trust-Komponenten - Zusätzliche Verschlüsselung bei der Persistierung
Unabhängig davon, ob die Daten schon verschlüsselt vorliegen, MÜSSEN alle Zero Trust-Komponenten die Daten der Komponente bei der Persistierung verschlüsseln. [<=]
A_25413 - Zero Trust-Komponenten - Ordnungsgemäße IT-Administration
Der Betreiber einer Zero Trust-Komponente MUSS die Maßnahmen für erhöhten Schutzbedarf des BSI-Bausteins „OPS.1.1.2 Ordnungsgemäße IT-Administration“ [BSI-Grundschutz] während des gesamten Betriebs der Komponente umsetzen. [<=]
A_25718 - Zero Trust-Komponenten - Bereitstellung Security-KPIs
Alle Zero Trust-Komponenten MÜSSEN sicherstellen, dass die für die Komponente relevante Security-KPIs in automatisch für den Betreiber bereitgestellt werden.
[<=]
Hinweis: Die Anforderung ist besonders wichtig, falls die Zero Trust-Komponente in einer VAU betrieben wird. Die Bereitstellung der Daten soll in das betriebliche Rohdaten-Log erfolgen.
5.1.1 Sicherheits- und Datenschutzanforderungen an Logging und Monitoring
Hinweis: Die Anforderungen dieses Abschnitts könnten sich noch ändern, falls sich bei der Umsetzung des Zero Trust herausstellt, dass weitere Protokollierungen auf Seiten des Betreibers notwendig werden.
A_25744 - Zero Trust-Komponenten - Datenschutzkonformes Logging und Monitoring
Die Zero Trust-Komponenten MÜSSEN die für den Betrieb des Zero Trust erforderlichen Logging- und Monitoring-Informationen in solcher Art und Weise erheben und verarbeiten, dass mit technischen Mitteln ausgeschlossen ist, dass dem Betreiber der Zero Trust-Komponenten vertrauliche oder zur unautorisierten Profilbildung geeignete Daten zur Kenntnis gelangen. [<=]
A_25745 - Zero Trust-Komponenten - Keine medizinischen Informationen in Logging und Monitoring
Die Zero Trust-Komponenten MÜSSEN sicherstellen, dass in für den Betrieb erstellten Protokollen keine personenbezogenen medizinischen Informationen enthalten sind (u. a. medizinische Daten von Versicherten oder Informationen, aus denen sich ableiten lässt, bei welchen Leistungserbringerinstitutionen ein Versicherter in Behandlung ist). [<=]
A_25746 - Zero Trust-Komponenten - Keine sicherheitsrelevanten Daten in Logging und Monitoring
Die Zero Trust-Komponenten MÜSSEN sicherstellen, dass in für den Betrieb erstellten Protokollen des Betreibers keine sicherheitsrelevanten Daten enthalten sind. [<=]
Hinweis: Sicherheitsrelevante Daten sind zum Beispiel, Kryptoschlüssel, Access/Refresh Token usw.
A_25747 - Zero Trust-Komponenten - Löschfristen Protokolle
Der Betreiber einer Zero Trust-Komponente MUSS sicherstellen, dass die
- zum Zwecke der Fehleranalyse erhobenen Protokolle nach Behebung des Fehlers unverzüglich gelöscht werden,
- zum Zwecke des Security Monitorings erhobenen Protokolle nach 6 Monaten gelöscht werden.
[<=]
5.1.2 Sicherheits- und Datenschutz-Anforderungen an das Security Monitoring
Das SIEM, Plattform-Monitoring und Shared Signals bilden das Security Monitoring von Zero Trust ab. Die folgenden Anforderungen beschreiben die Fähigkeiten des Security Monitorings und welche Ereignisse erkannt werden sollen.
A_25419 - Security Monitoring - Erkennungsfähigkeit
Der Betreiber des Monitoring SystemsTI 2.0 Dienstes MUSS sicherstellen, dass das Monitoring System die folgenden Arten von Anomalien erkannt werden könnenMerkmale der Kommunikation erkennen kann:
- Geolokation - Land und Ort
- Impossible Travel
- Zugriffe über TOR Netzwerke
- Zugriff von VPN-Provider
- Zugriffe über Proxies
- Zugriffe über Botnetze
- Traffic Volumen Anomalien
- Network-Protokoll Anomalien
[<=]
Hinweis: Impossible Travel ist eine Methode zur Anomalieerkennung in der Cybersicherheit, die potenzielle Kompromittierungen identifiziert, indem sie Benutzeranmeldeaktivitäten analysiert und mit geografischen Standorten korreliert. Dabei werden Fälle markiert, in denen auf das Benutzerkonto innerhalb eines verdächtig kurzen Zeitraums aus zwei verschiedenen Ländern zugegriffen wird.
Der Fachdienst kann eine Missbrauchserkennung implementieren. Dabei werden mögliche Angriffe und Anomalien innerhalb der Anwendungslogik erkannt (z. B. falsche/manipulierte Metadaten für Dokumente in der elektronischen Patientenakte (ePA)) und an das SIEM System gemeldet.
A_25421 - Security Monitoring - Empfang von Missbrauchserkennung auf Fachdienstebene
Falls der Fachdienst eine Missbrauchserkennung durchführt, MUSS der Betreiber des Security Monitorings sicherstellen, dass das Security Monitoring solche Missbrauchssignale von dem Fachdienst empfangen und verarbeitet werden kann. [<=]
A_25420 - Security Monitoring - AnomalienKommunikationsmerkmale signalisieren
Der Betreiber des Monitoring Systems MUSS sicherstellen, dass bei der Erkennung von den folgenden Anomalien automatisiert ein Abbruchsignal an dem PEP und PDP gesendet wird:folgender Kommunikationsmerkmale die erforderlichen Informationen automatisiert an den PEP gesendet werden:
- Impossible Travel
- Zugriffe über TOR Netzwerke
- Zugriffe über Proxies
- Zugriffe über Botnetze
- Zugriff von VPN-Provider
- Traffic Volumen Anomalien
- Network-Protokoll Anomalien
- Missbrauchssignale von dem Fachdienst (falls implementiert)
[<=]
Hinweis: Mit dem Abbruchsignal wird signalisiert, dass der PEPSignal erhält der PEP die Information, dass sich eine Eigenschaft der aktuellen Session geändert hat. Der PEP sperrt automatisch das aktuelle Access Token sperren soll, sodass der Client ein neues Access Token beim Authorization Server abfragen muss. Die Abfrage des neuen Access Token beinhaltet immer eine Entscheidung durch den PDP.
A_25484 - Security Monitoring - Security KPIs
Der Betreiber des Monitoring Systems MUSS einmal täglich als Teil der Bestandsdatenlieferung die folgende Sicherheits-KPIs automatisiert über die von der gematik angebotene Schnittstelle an das TI SIEM System übermitteln:
- Anzahl versuchter Zugriffe von nicht registrierten Geräten (hier muss die KPIs zwischen Fachdienst APIs und Clientregistrierung APIs unterscheiden)
- Anzahl von Netzwerk-Protokoll-Anomalien
- Anzahl von Zugriffen von Botnetzen
- Anzahl von Zugriffen aus jedem Land gezählt plus weitere Zugriffe, die separat in Versicherte und LE ausgewiesen werden
- Anzahl fehlerhafter Gerätfreischaltungen plus weitere breakdown in Versicherte und LE
- Anzahl von Impossible travel Zugriffen (inkl. Land- und Ortsdaten) plus weitere breakdown in Versicherte und LE
- Anzahl von Zugriffen über TOR Netzwerke plus weitere breakdown in Versicherte und LE
- Anzahl von Zugriffen über Proxies plus weitere breakdown in Versicherte und LE
- Anzahl von Zugriffen über VPNs plus weitere breakdown in Versicherte und LE
- Traffic Volumes plus weitere breakdown in Versicherte und LE
- Anzahl erkannte Angriffe in Kategorie (siehe ) plus weitere breakdown in Versicherte und LE
- Anzahl fehlerhafte Authorization Codes vom IDP.
[<=]
Hinweis: Security KPIs beinhalten anonyme Daten und sind nicht auf individuelle Nutzer zurückzuführen.
Hinweis: Netzwerk-Protokoll-Anomalien sind z.B. ungewöhnliche Netzwerk-Aktivitäten, Netzwerk-Protokoll-Aktivitäten oder die Manipulation von Netzwerk-Paketen.
A_25485 - Security Monitoring - Sicherheitsmeldung bei Aktualisierung von PIP-Daten oder PDP-Policies
Der Betreiber des Security Monitoring MUSS sicherstellen, dass bei der Aktualisierung der PIP-Daten oder PDP-Policies eine Sicherheitsmeldung automatisiert über die von der gematik angebotene Schnittstelle an das TI SIEM System übermittelt wird. [<=]
A_25606 - Security Monitoring - Fehlermeldung bei Aktualisierung von PIP-Daten oder PDP-Policies
Der Betreiber des Security Monitoring MUSS sicherstellen, dass beim folgenden Fehler während der Aktualisierung der PIP-Daten oder PDP-Policies eine Fehlermeldung automatisiert über die von der gematik angebotene Schnittstelle an das TI SIEM System übermittelt wird:
- Policy Download Fehler ((
HTTPhttp Fehlercode: 400, 404) - Fehler bei der Integritätsprüfung der Policysignatur
[<=]
Falls der Fachdienst personenbezogene medizinische Daten verarbeitetZT Cluster Daten mit dem Schutzbedarf „sehr hoch“ verarbeitet und der Betreiber keine Kenntnis über die in dem ZT Cluster verarbeiteten Daten erlangen darf, gibt es Sonderanforderungen, um die Daten während der Verarbeitung zu schützen.
A_25608 - PEP und PDP - Verarbeitung von personenbezogenen medizinische Daten in einer VAUmit Schutzbedarf "sehr hoch"
Der PEP und der PDP MÜSSEN in einer VAU umgesetzt werden. Falls der ZT Cluster Daten mit dem Schutzbedarf „sehr hoch“ verarbeitet und der Betreiber keine Kenntnis über die in dem ZT Cluster verarbeiteten Daten erlangen darf, MUSS der Betreiber den ZT Cluster in einer VAU umsetzen. [<=]
A_25763 - Zero Trust-Komponenten - Private Schlüssel der Komponenten-Identitäten in einem HSM
DieFalls der ZT Cluster Daten mit dem Schutzbedarf „sehr hoch“ verarbeitet und der Betreiber keine Kenntnis über die in dem ZT Cluster verarbeiteten Daten erlangen darf, MUSS der Betreiber die privaten Schlüssel der Identitäten aller Zero Trust-Komponenten MÜSSEN in einem HSM gespeichert werdenspeichern. [<=]
A_25764 - Zero Trust-Komponenten - Sicherer Betrieb und Nutzung eines HSMs
Der Betreiber einer Zero Trust-Komponente MUSSFalls der ZT Cluster Daten mit dem Schutzbedarf „sehr hoch“ verarbeitet und der Betreiber keine Kenntnis über die in dem ZT Cluster verarbeiteten Daten erlangen darf, MUSS der Betreiber beim Einsatz eines HSMs sicherstellen, dass die auf dem HSM verarbeiteten privaten Schlüssel, Konfigurationen und eingesetzte Software nicht unautorisiert ausgelesen, unautorisiert verändert, unautorisiert ersetzt oder in anderer Weise unautorisiert benutzt werden können. [<=]
A_25765 - Zero Trust-Komponenten - Einsatz zertifizierter HSM
Alle Zero Trust-Komponenten MÜSSENFalls der ZT Cluster Daten mit dem Schutzbedarf „sehr hoch“ verarbeitet und der Betreiber keine Kenntnis über die in dem ZT Cluster verarbeiteten Daten erlangen darf, MUSS der Betreiber beim Einsatz eines HSMs sicherstellen, dass dessen Eignung durch eine erfolgreiche Evaluierung nachgewiesen wurde. Als Evaluierungsschemata kommen dabei Common Criteria, ITSEC oder Federal Information Processing Standard (FIPS) in Frage.
Die Prüftiefe MUSS mindestens:
- FIPS 140-2 Level 3 oder
- FIPS 140-3 Level 3 oder
- Common Criteria EAL 4+ (mit AVA_VAN.5)
entsprechen. [<=]
A_26065 - Nur zugelassene Images in Produktion
Falls der ZT Cluster Daten mit dem Schutzbedarf „sehr hoch“ verarbeitet und der Betreiber keine Kenntnis über die in dem ZT Cluster verarbeiteten Daten erlangen darf, MUSS der Betreiber mit technischem Mittel sicherstellen, dass nur von gematik signierte und für den Einsatz in der PU vorgesehene Produktimages in der PU laufen können. [<=]
Hinweis: Ein Beispiel dafür wäre eine Art Plattform Attestierung, die eine Manipulation von Images erkennen und ausschließen kann.
5.1.4 Sicherheits- und Datenschutz Anforderungen an dem Trust Client
A_25802 - Trust Client - Einhaltung der BSI-Prüfvorschrift
Der Trust Client MUSS die Prüfaspekte aus der BSI-Prüfvorschrift [BSI-Prüfvorschrift [TR-03161] erfüllen, sofern sie für das Trust Client anwendbar sind. [<=]
Hinweis: Nicht anwendbar können zum Beispiel sein: O.Paid .. Die Anwendbarkeit ist zwischen Hersteller des Trust Clients und dem Gutachter zu klären. Der Gutachter gibt sein Votum über die Erfüllung der BSI-Prüfvorschrift [TR-03161] in Form der Bewertung der Erfüllung der A_25802 ab, wobei die A_25802 als „umgesetzt“ bewertet werden kann, wenn die anwendbaren Prüfaspekte der BSI-Prüfvorschrift [TR-03161] aus Sicht des Gutachters erfüllt sind.
5.2 Anforderungen an Clientsysteme
Ein Clientsystem ist eine Softwarekomponente in der Verwendung eines Benutzers zum Ausführen fachlicher Anwendungsfälle z.B. als Primärsystem (PVS, AVS, LIS, KIS etc.) oder als Frontend des Versicherten (ePA-App, E-Rezept-App, TI-Messenger etc.). Dieses Clientsystem wird dem Benutzer durch einen Hersteller bzw. Herausgeber zur Verfügung gestellt.
5.2.1 Hersteller und Herausgeber
A_25335 - Hersteller Clientsystem - Hinweise und Maßnahmen sicherer Betrieb
Der Hersteller bzw. Herausgeber eines Clientsystems MUSS den Benutzer über Maßnahmen zum sicheren Betrieb seines Clientsystems vor der Inbetriebnahme informieren und während des Betriebs stets zum Abruf durch den Benutzer bereithalten. [<=]
A_25336 - Hersteller Clientsystem - Regelmäßige Updates
Der Hersteller bzw. Herausgeber eines Clientsystems MUSS dem Benutzer für wenigstens 5 Jahre, solange das Produkt nicht abgekündigt ist, dem Benutzer regelmäßig (z. B. quartalsweise) Updates für das Clientsystem bereitstellen, um das Clientsystem dauerhaft auf dem Stand der Technik zu halten und Sicherheitslücken zu schließen. [<=]
A_25337 - Hersteller Clientsystem - Registrierung für product_id
Der Hersteller bzw. Herausgeber eines Clientsystems MUSS sich über einen organisatorischen Prozess bei der gematik für die Nutzung von Diensten, für welche Token abgerufen werden sollen, registrieren. Der Hersteller bzw. Herausgeber eines Clientsystems bekommt dabei eine "product_id" zugewiesen, die in jeder Instanz des Clientsystems verwendet werden MUSS. [<=]
A_25427 - Hersteller Clientsystem Android - Google Cloud Projekt
Der Hersteller bzw. Herausgeber eines Clientsystems für eine Android-basierte Betriebsumgebung MUSS ein Google Cloud Projekt führen oder eine alternative Plattformattestierung verwenden, um Nachweise über die Geräteintegrität einer jeden Clientsysteminstallation über die Google Play Integrity API beziehen zu können. [<=]
A_25338 - Clientsystem - User-Agent
Das Clientsystem MUSS in allen HTTPhttp-Requests an Dienste der TI den HTTPhttp-Header user-agent gemäß [RFC7231] mit <product_id>/<product_version> mit
- <product_id> gemäß Registrierung bei der gematik
,mit Länge maximal 20 Zeichen, Zeichenvorrat [0-9a-zA-Z\-] - <product_version> gemäß Produktidentifikation mit Länge 1-20 Zeichen, Zeichenvorrat [0-9a-zA-Z\-\.]
des Clientsystems befüllen. [<=]
A_25339 - Clientsystem - Exponential Backoff
Das Clientsystem SOLL bei Server-seitigen Fehlermeldungen, die auf eine Überlastung des Zielsystems schließen lassen (z. B. http-status 5xx, 429 - too many requests etc.), erneute Verbindungsversuche nach dem Prinzip des Exponential Backoffs [ExpBack] durchführen. [<=]
A_25340 - Clientsystem - Zertifikatsprüfung
Das Clientsystem MUSS alle Zertifikate, die es aktiv verwendet (bspw. TLS-Verbindungsaufbau), auf Integrität und Authentizität prüfen. Falls die Prüfung kein positives Ergebnis ("gültig") liefert, so MUSS es die von dem Zertifikat und den darin enthaltenen Attributen (bspw. öffentliche Schlüssel) abhängenden Arbeitsabläufe ablehnen.
Das Clientsysem MUSS alle öffentlichen Schlüssel, die es verwenden will, auf eine positiv verlaufene Zertifikatsprüfung zurückführen können. [<=]
A_25341 - Clientsystem - TLS- oder JWT-Clientauthentisierung
Das Clientsystem MUSS sich in allen HTTPhttp-Requests an der Außenschnittstelle des PEP entweder
- mittels eines gültigen TLS-Clientzertifikats oder
- mittels private JWT und DPoP-Token
als legitimer Client authentisieren. Verfügt das Clientsystem über kein gültiges Clientauthentisierungsmittel, MUSS es den Bezug über die Clientregistrierung starten. [<=]
Offener Punkt: Details in diesem Kapitel werden im Rahmen der Implementierung zwischen gematik und dem Zero-Trust-Hersteller festgelegt. Die Client Registrierung wird dienstübergreifend ermöglichen, dass im Falle von Big Apps der Nutzer nur einmalig aktiv werden muss, um sein Gerät mittels 2. Faktor zu bestätigen. |
A_25432 - Clientsystem - Ablauf Clientregistrierung
Das Clientsystem MUSS, sofern es an Schnittstellen der Telematikinfrastruktur wegen einer ungültigen/fehlenden GeräteregistrierungGeräte/App-Registrierung abgewiesen wird, eine ClientregistrierungRegistrierung am Service der Dynamic Client RegistrationRegistry durchführen, in dem es
- den/die Benutzer:in mittels OpenID Connect authentifiziert,
- kryptografische Client-Credentials lokal generiert,
- die generierten Credentials sowie die Clientintegrität attestiert und
- eine zusätzliche Benutzerbestätigung mittels One-Time-Passwort über einen zweiten Kommunikationsweg (z. B. E-Mailbestätigung) startet
[<=]
A_25766 - Clientsystem - Client Credentials in TI Qualität
Das Clientsystem MUSS die Client-Credentials im Form von kryptografischen Schlüsseln gemäß der Festlegungen in [gemSpec_Krypt] (Verfahren, Algorithmen, Schlüssellängen etc.) unterstützen. [<=]
A_25769 - Clientsystem - Client Credentials sicher generieren und schützen
Das Clientsystem auf mobilem Gerät mit Apple- oder Android-basierter Betriebsumgebung MUSS die Generierung der Client-Credentials in Hardware-Modulen (alternativ Android TEE) derart generieren und speichern, dass ein Kopieren und Exportieren der Schlüssel durch die Hardware (alternativ Android TEE) verhindert wird. [<=]
A_25770 - Clientsystem - Client Credentials Rotation
Das Clientsystem MUSS seine Client-Credentials regelmäßig rotieren (erneuern und neu registrieren), wobei die Häufigkeit der Rotation durch die gematik nach einer Auswertung der initialen Benutzererfahrung festgelegt wird. [<=]
Hinweis: Perspektivisch werden weitere Attestierungsmechanismen für Clientsysteme aufgenommen, z. B. FIDO2, TPM2, SMC-B.
A_25767 - Clientsystem - Clientkey in JWT oder Zertifikat
Das Clientsystem MUSS wahlweise Private Key JWT ([RFC7521] und [RFC7523)] sowie DPoP [RFC9449] oder mutual TLS ([RFC8705)] zur Authentifizierung unterstützen. [<=]
A_25434 - Clientsystem - Clientregistrierung mit bestätigten Umgebungseigenschaften Android
Das Clientsystem für eine Android-basierte Betriebsumgebung MUSS seine Client-Credentials, App-Integrität und -Authentizität sowie AblaufumgebungOS-/FW und HW-Eigenschaften über Key and ID Attestation gegenüber PEP Client Registrierung bestätigen.. [<=]
A_25768 - Clientsystem - Clientregistrierung mit bestätigten Umgebungseigenschaften Apple
Das Clientsystem für eine Apple-basierte Betriebsumgebung (iOS, macOS) MUSS die Client-Credentials, App Integrität und Authentizität über DCAppAttest gegenüber PEP Client Registrierung bestätigen. Eigenschaften der AblaufumgebungLaufzeitumgebung MÜSSEN durch das Clientsystem über einen geprüften Prozess bestätigt werden. [<=]
A_25758 - Clientsystem - Erfassung Kontaktinformation für Offband-Verifikation
Das Clientsystem MUSS vom Benutzer eine strukturell valide Kontaktinformation (E-Mailadresse, Telefonnummer) abfragen und für eine Offband-Verifikation (Trust on First Use) an Endpunkt der Dynamic Client RegistrationRegistry übertragen. [<=]
A_25732 - Clientsystem - Unterstützung des Nutzers bei der Registrierung
Das Clientsystem MUSS den Nutzer bei der Clientregistrierung und -Verwaltung geeignet unterstützen (z. B. mittels Guide, Tutorial o. ä.). [<=]
A_25733 - Clientsystem - Clientverwaltung und manuelle De-Registrierung
Das Clientsystem MUSS dem Nutzer eine Übersicht aller beim Clientregistrierungsdienst registrierten Clients darstellen und die Möglichkeit zur De-Registrierung einzelner Clients anbieten. [<=]
A_25734 - Clientsystem - Zugriffsprotokoll Clientregistrierung
Das Clientsystem MUSS dem Nutzer einen Einblick in das Zugriffsprotokoll der Schnittstellen des Clientregistrierungsdienstes für genutzte Clients dieses Nutzers geben. [<=]
A_25735 - Clientsystem - Aktivierung Push-Benachrichtigung
Das Clientsystem MUSS dem Nutzer die Möglichkeit geben, Push-Benachrichtigungen für Aktivitäten über registrierte Clients und Neuregistrierungen für diesen Nutzer zu aktivieren. [<=]
A_25761 - Clientsystem - Nutzerauthentifizierung mittels etablierter Standards
Das Clientsystem MUSS die Mechanismen OAuth2, OpenID Connect und OpenID Federation (Auswahl des zuständigen sektoralen IDP) unterstützen. [<=]
Hinweis: Perspektivisch sollen Clientsysteme auch OpenID for Verifiable Credentials (OIDC4VC) unterstützen.
A_25762 - Clientsystem - Nutzerauthentifizierung - Unterstützung etablierter Identitäten und Dienste
Das Clientsystem MUSS zur Authentifizierung des Nutzers mindestens eines der folgenden Verfahren unterstützen:
- Authentifizierung des
BenutzersNutzers gegenüber einem Sektoralen IDP der IDP Föderation gemäß [gemSpec_IDP_Sek] (GesundheitsID) - Authentifizierung des
BenutzersNutzers gegenüber dem zentralen IDP-Dienst der TI gemäß [gemSpec_IDP_Dienst] (SmartCardIDP für kartengebundene Identitäten). - Authentifizierung des Nutzers mittels SM-B signiertem Client Assertion JWT und DPoP gemäß [RFC7523] und [RFC9449].
[<=]
A_25781 - Clientsysteme - OAuth2 Autorisierung
Das Clientsystem MUSS die Rolle eines OAuth2 Clients [RFC6749] übernehmen und eine Autorisierung vom Autorisation Server einholen. Dabei MUSS PKCE Flow [RFC7636] verwendet werden.
[<=]
A_25782 - Clientsystem - OAuth2 Session Management
Das Clientsystem MUSS
- die vom Autorisation Server ausgestellten Access- und Refresh-Token gemäß [RFC6749#1.5] sowie die DPoP Schlüssel gemäß [RFC9449] bis zur nächsten Aufforderung zur Autorisierung oder Authentifizierung als User-Session sicher aufbewahren,
- regelmäßig neue Access-Token über Refresh-Token erneuern und
- eine Refresh-Token-Rotation gemäß [RFC6749#10.4] unterstützen.
[<=]
A_25783 - Clientsystem - Anweisungen aus HTTPhttp Response Status Codes und Header folgen
Das Clientsystem MUSS die HTTPhttp Response Status Codes und HTTPhttp Header entsprechend der Vorgaben der Fachdienste und Zero Trust APIs auswerten und den Anweisungen daraus folgen und insbesondere
- eine Step-Up- oder erneute Authentifizierung des Nutzers,
- eine Re-Autorisierung und erneute Attestation der Client-Instanz,
- eine Anzeige der Warnungen aufgrund der Policy Entscheidungen und
- ein Nonce-Replay gemäß [RFC8555#6.5.1]
umsetzen. [<=]
Die Software des Zero Trust Clusters wird im Auftrag der gematik entwickelt und als signierte Docker Container in einer gematik Container Registry sowie mit Kubernetes Manifest Dateien in einem gematik GitHub Repository bereitgestellt, sodass die Betreiber von TI 2.0 Diensten ihren spezifischen ZT Cluster darauf aufbauend als Kubernetes Cluster konfigurieren können. Die ZT Cluster-Konfiguration muss in ein GitHub Repository der gematik als git submodule verlinkt werden. Der Cluster Management Service des Zero Trust Clusters setzt durch, dass nur die im gematik GitHub Repository verlinkte ZT Cluster Konfiguration ausgeführt werden kann. Dadurch ist es möglich, dass der Betreiber seine Cluster-Konfiguration selbständig anpassen und die gematik den korrekten Einsatz des ZT Clusters prüfen kann.
A_26106 - ZT Cluster, Verwendung der gematik Docker Container
Der Betreiber eines TI 2.0 Dienstes MUSS für seinen ZT Cluster die von der gematik bereitgestellten signierten Docker Container für PEP, PDP, Cluster Management Service und Telemetrie-Daten Service verwenden. [<=]
A_26105 - ZT Cluster, Durchsetzung der Konfiguration
Der Betreiber eines TI 2.0 Dienstes MUSS für seinen ZT Cluster die ihm zugewiesene Konfiguration aus dem GitHub Repository der gematik verwenden. [<=]
Hinweis: Für die Anpassung und Inbetriebnahme von geänderten ZT Cluster Konfigurationen ist ein Continuous Delivery Prozess mit Quality Gates vorgesehen, der sich noch in der Entwicklung befindet.
5.4 Anforderungen an Policy Enforcement Points
Der Policy Enforcement Point (PEP) stellt die zentrale Sicherheitskomponente einer Zero Trust Architektur dar, da in dieser alle Zugriffsentscheidungen durchgesetzt (engl.: enforce) werden. Gemäß oben vorgeschlagener Architekturzerlegung, empfiehlt es sich, den PEP in mehreren Teilkomponenten zu realisieren.
Mittels einer Dynamic Client RegistrationMit der Registrierung an der Komponente Client Registry werden von Nutzern verwendete GeräteClients (Gerät/App Kombinationen) identifizierbar gemacht und können an ausgegebene Zugriffstoken an diese Geräte gebunden werden. Über einen Authorization Server kann im PEP eine Benutzersession angelegt und verwaltet werden, über die eine mögliche Veränderung von Sessionparametern (verwendetes Gerät/App, Zugriffsfrequenz) beobachtet werden kann, um nach Bedarf zusätzliche Sicherheitsmechanismen aktivieren zu können (Step-Up-Authentication, Throttling etc.). Ist ein Zugriff zu gewähren, wird der NutzerrequestNutzer-Request über einen http Upstream Proxy an das angefragte Resource Backend weitergeleitet.
A_25644 - PEP Client Registration - Mobile Attestation
Die Komponente Dynamic Client RegistrationRegistry MUSS die Clients/Apps bei der Registrierung über folgende Mechanismen attestieren:
- Android Key ID Attestation
- Apple DCAppAttest.
- SM-B signiertes Client Assertion JWT
[<=]
A_25645 - PEP Client Registration - User Authentication in AttestationAttestation mittels TI-Smartcard
Die Komponente Dynamic Client RegistrationRegistry MUSS die Registrierung über eine TI-Smartcard durchführen (eGK, SMC-B, HBA), falls die Ausführungsumgebung des Clients keine plattformseitigen AttestationsmechanismenAttestation-Mechanismen anbietet. Die Verwendung des zentralen IDP-Dienstes ist für die Nutzerauthentifizierung zulässig. [<=]
A_25646 - PEP Client Registration - SubCA Device Certificate
Die Komponente Dynamic Client Registration MUSS über ein SubCA-Zertifikat verfügen, um TLS Client Zertifikate für die Client Instanzen ausstellen zu können. [<=]
Hinweis: Die Mechanismen und Prozesse zur Absicherung des Schlüsselmaterials zu diesem SubCA-Zertifikat haben nach dem Stand der Technik zur Herstellung eines angemessenen Vertrauensniveaus zu erfolgen. Detailfestlegungen erfolgen zu einem späteren Zeitpunkt, wenn die funktionalen Lücken zwischen Clientsystem und der Komponente Dynamic Client Registration geschlossen werden.
A_25647 - PEP Client Registration - Certificate Signing Request
Die Komponente Dynamic Client Registration MUSS die automatisierte Erneuerung bzw. Ausstellung neuer TLS Client Zertifikate über einen Certificate Signing Request unterstützen. [<=]
A_25648 - PEP Client Registration - Device Session Credentials
Die Komponente Dynamic Client RegistrationRegistry MUSS die Client Credentials aufbewahren und Verifikationsmechanismen dem PEP AuthorisationAuthorization Server bereitstellen. [<=]
A_25649 - PEP Client Registration - Regelmäßige Wiederholung der Attestation
Die Komponente Dynamic Client RegistrationRegistry MUSS die Client Attestierung regelmäßig gemäß Festlegungen in der Device Policy wiederholen. [<=]
A_25650 - PEP Client Registration - UserIDTI-Identität in Attestation
Die Komponente Dynamic Client RegistrationRegistry MUSS den registrierten Client an eine TI-Identität (KVNR oder TelematikID, festgestellt z. B. über die Einbindung des zentralen IDP-Dienstes oder eines Sektoralen IDP) binden. [<=]
A_25651 - PEP Client Registration - Offband UserNutzer Verification
Die Komponente Dynamic Client RegistrationRegistry MUSS einen Offband Prozess (z. B. E-Mail, SMS) für die Kommunikation mit diesem Nutzer unterstützen (Trust on First Use), wobei der Nutzer seine E-Mail Adresse bzw. Kontaktinformation eigenverantwortlich vergibt. [<=]
A_25652 - PEP Client Registration - Push Gateway
Die Komponente Dynamic Client RegistrationRegistry MUSS Push-Notifications über die von App-Anbietern bereitgestellten Push-Gateways unterstützen, um die Notifications an bestimmte oder alle registrierte Clients eines Anwenders verschicken zu können. [<=]
A_25737 - PEP Client Regisration - Push Notification
Die Komponente Client Registry MUSS eine Push Benachrichtigung an alle registrierten Clients des Nutzers, für die eine Push Notification aktiviert ist, verschicken, sobald sich Änderungen an der Liste der registrierten Clients dieses Nutzers ergibt. [<=]
Hinweis: Wie Clients ihre Push Konfiguration in den PEP eintragen können, wird in einer Folgeversion des vorliegenden Dokuments festgelegt.
A_25653 - PEP Client Registration - Umsetzung der Device Policy
Die Komponente Dynamic Client RegistrationRegistry MUSS die zulässigen Clients entsprechend der Konfiguration oder Policy (über PDP-Decision) ermitteln und nur diese gemäß der festgelegten Device Policy registrieren. Geräte, die die geforderten Parameter der Device Policy nicht unterstützen bzw. nicht das geforderte Niveau erreichen, MÜSSEN abgelehnt werden. [<=]
A_25752 - PEP Client Registration - Nutzer über Hintergrund zur Ablehnung der Gerätregistrierung informieren
Falls ein Gerät nicht die geforderten Parameter der Device Policy unterstützt bzw. das geforderte Niveau nicht erreicht, MUSS die Komponente Dynamic Client RegistrationRegistry den Nutzer nutzerfreundlich darüber informieren, welche Geräteigenschaften zu der Ablehnung geführt haben. [<=]
A_25654 - PEP Client Registration - Minimum Device Policy
Die Komponente Dynamic Client RegistrationRegistry MUSS Client Mindestanforderungen vor der Registrierung verifizieren und kann hierfür eine Schnittstelle des PDP verwenden. [<=]
A_25737 - PEP Client Regisration - Push Notification
Die Komponente Dynamic Client Registration MUSS eine Push Benachrichtigung an alle registrierten Clients des Nutzers, für die eine Push Notification aktiviert ist, verschicken, sobald sich Änderungen an der Liste der registrierten Clients dieses Nutzers ergibt. [<=]
A_25738 - PEP Client Registration - Telemetrie Clientregistrierung
Die Komponente Dynamic Client RegistrationRegistry MUSS in den Telemetriedaten zu jeder versuchten Clientregistrierung folgende Parameter ohne einen Nutzerbezug protokollieren:
- Geräteparameter (Betriebssystem(-version), Patchlevel, Geolocation etc.) gemäß Geräteattestierung
- verwendeter Faktor für Offband-Verifikation (E-Mail, SMS etc.)
- Zeitstempel Registrierung, Zeitpunkt Offband-Bestätigung
- verwendeter Faktor der Nutzerauthentifizierung (SmartCard, Digitale Identität)
- Status/Ergebnis des Registrierungsversuchs
[<=]
A_25754 - PEP Client Registration - Notfall-Recovery-Prozess für Nutzer
Die Komponente Dynamic Client RegistrationRegistry MUSS dem Nutzer einen Notfall-Recovery-Prozess anbieten, falls der Nutzer sein letztes Gerät verloren und keinen Zugriff mehr auf seine registrierte E-Mail-Adresse/Telefonnummer hat. [<=]
A_26064 - Access Token bei Monitoring-Signalen sperren
Falls das Monitoring System eine Änderung in den Kommunikationsmerkmalen signalisiert, muss der PEP das aktuelle Access Token sperren. [<=]
Hinweis: der Client muss danach ein neues Access Token beim Authorization Server abfragen. Die Abfrage des neuen Access Token beinhaltet immer eine Entscheidung durch den PDP.
5.4.1.1 Sicherheits- und Datenschutz-Anforderungen an dem PEP Client Registration
A_25751 - PEP Client Registration - Anwendungsfälle nur vom registrierten GerätClient
Nach der erfolgreichen Registrierung von demdes ersten Gerät, mussClients (Geräts/App Kombination), MUSS die Komponente Dynamic Client RegistrationRegistry sicherstellen, dass die folgenden Anwendungsfälle nur von einem registrierten GerätClient durchgeführt werden kann:
- Gerät löschen
- Gerät umbenennen
- E-Mail-Adresse hinzufügen
- E-Mail-Adresse aktualisieren
[<=]
A_25748 - PEP Client Registration - Maximale Anzahl von Geräten
Die Komponente Dynamic Client RegistrationRegistry MUSS sicherstellen, dass ein Nutzer maximal 256 Geräte registrieren kann. Der Wert muss konfigurierbar sein. [<=]
A_25749 - PEP Client Registration - Nutzer Protokollierung
Die Komponente Dynamic Client RegistrationRegistry MUSS ein Nutzerprotokoll führen und die folgenden Anwendungsfälle für den Nutzer protokollieren:
- Gerät hinzufügen
- Gerät löschen
- Gerät umbenennen
- E-Mail-Adresse hinzufugen
- E-Mail-Adresse aktualisieren
[<=]
A_25750 - PEP Client Registration - Nutzer über sicherheitsrelevante Ereignisse informieren
Die Komponente Dynamic Client RegistrationRegistry MUSS sicherstellen, dass der Nutzer bei folgenden Anwendungsfällen informiert wird:
- Gerät hinzufügen
- Gerät löschen
- Gerät umbenennen
- E-Mail-Adresse aktualisieren
[<=]
Hinweis: Der Nutzer kann z.B. durch eine geeignete E-Mail oder App-Notifikation über die sicherheitsrelevanten Ereignisse informiert werden.
A_25655 - PEP - Relying Party
Die Komponente Policy Enforcement Point MUSS in der TI-Föderation als Relying Party registriert sein. [<=]
A_25656 - PEP - Entity Statement
Die Komponente Policy Enforcement Point MUSS die Redirect-URIs aller zulässigen Clients als erlaubte Redirect-URIs im Entity Statement ausweisen. [<=]
A_25657 - PEP - User Authentication über sektoralen IDP
Die Komponente Policy Enforcement Point (bzw. ihre Subkomponente Authorization Server) MUSS die AnwenderNutzer über sektorale IDPs authentifizieren können. [<=]
A_25658 - PEP - User Authentication über SmartCard IDP
Die Komponente Policy Enforcement Point (bzw. ihre Subkomponente Authorization Server) MUSS die AnwenderNutzer über den zentralen IDP-Dienst (SmartCard-IDP) authentifizieren können. [<=]
5.4.3 PEP Authorization Server
A_25760 - PEP Authorization Server - OAuth2 Schnittstellen
Die Komponente Authorization Server MUSS eine OAuth2 Schnittstelle gemäß [RFC6749] und [RFC7636] implementieren.
Der Authorization Server MUSS am Token Endpunkt REFRESH_TOKEN entsprechend [RFC6749] ausstellen können. [<=]
A_25659 - PEP Authorization Server - Check Device Registration
Die Komponente Authorization Server MUSS die Client Instanzen über einen der folgenden Mechanismen authentifizieren:
- Mutual-TLS Client Authentication gemäß [RFC8705]
- JSON Web Token Client Authentication gemäß [RFC7523] mit DPoP gemäß [RFC9449]
und Anfragen, die weder noch eine der genannten Mechanismen verwendet konsequent ablehnen. [<=]
A_25660 - PEP Authorization Server - Session Management mittels AccessTokens und Refresh-Tokens
Die Komponente Authorization Server MUSS ein Session Management mittels OAuth2 und Ausgabe, Verwaltung und Entzug von Access- und Refresh-Token gemäß [RFC6749#1.5] unterstützen. [<=]
A_25661 - PEP Authorization Server - Umsetzung der Policy Decision
Die Komponente Authorization Server MUSS die Zugriffs-Entscheidung eines PDP mittels der Ausgabe eines Access- und eines Refresh-Tokens umsetzen bzw. eine Zugriffsverweigerung mit einem http-Statuscode 403 quittieren. [<=]
A_25662 - PEP Authorization Server - Refresh-Token Rotation
Die Komponente Authorization Server MUSS eine Refresh-Token Rotation gemäß [RFC6749#10.4] erzwingen und MUSS sicherstellen, dass ein Refresh Token nur einmal gegen ein Access-Token und ein Refresh-Token getauscht werden kann. [<=]
A_25663 - PEP Authorization Server - Token-Binding an Device-Registration
Die Komponente Authorization Server MUSS auszugebende Access-Token und Refresh-Token an die, über einen der Mechanismen:
- TLS Client Zertifikat Binding gemäß [RFC8705]
- OAuth 2.0 Demonstrating Proof of Possession (DPoP) gemäß [RFC9449]
identifizierte Client-Instanz binden, in dem im Token-Binding-Claim cnf die Angabe der verwendeten Clientidentifikation als "jkt" oder "x5t#S256" eineindeutig referenziert wird. [<=]
A_25664 - PEP Authorization Server - Token Laufzeit gemäß Policy
Die Komponente Authorization Server MUSS die Laufzeit der ausgegebenen Token entsprechend der Festlegungen aus der getroffenen Zugriffsentscheidung des PDP setzen. [<=]
A_25665 - PEP Authorization Server - Plugin-Schnittstelle Application Authorization Backend
Die Komponente Authorization Server MUSS eine Plug-In Schnittstelle zu einem anwendungsspezifischen Authorization Backend [GITHUB-Authz-Backend] implementieren und dabei die folgenden Signale und Informationen aus der erhaltenen Zugriffsanfrage weiterreichen.
Tabelle 5: PEP Authorization Server - Plugin-Schnittstelle Application Authorization Backend
Operation |
Operation Kennung |
Input |
Output |
Benachrichtigung über die Ablehnung des Zugriffs durch PEP |
notifiyAccessDenied |
Trace-Id |
- |
Anwendungsspezifische Autorisierung |
authorizeAccess |
Trace-Id |
Zugriff erlauben Ja/Nein |
Benachrichtigung über abgelaufene oder terminierte Sessions |
notifySessionTermination |
Trace-Id |
- |
[<=]
Der Authorization Server ermöglicht Clients die Ermittlung der bereitgestellten Endpunkte durch Abfrage des Well-known json Dokuments unter http GET /.well-known/oauth-authorization-server. Wenn der FQDN des Authorization Servers nicht bekannt ist, kann das Well-known json Dokuments abgefragt werden, indem ein Endpunkt des Resource Servers ohne gültiges access token aufgerufen wird. Im body der http 401 Response ist das Well-known json Dokument enthalten.
A_26037 - PEP Authorization Server, Well-known
Die Komponente http Proxy MUSS für den Authorization Server ein Well-known json Dokument gemäß [RFC8615] und [RFC8414] unter folgender URL bereitstellen: https://<as-fqdn>/.well-known/oauth-authorization-server
Das Well-known json Dokument MUSS mit dem Schema https://raw.githubusercontent.com/gematik/spec-t20r/main/src/schemas/as-well-known.yaml validiert werden können.
Das Attribut scopes_supported MUSS mindestens die folgenden Werte enthalten:
- zero:register
- zero:manage
Weitere Werte für das Attribut scopes_supported müssen per Konfiguration ergänzt werden können.
Es MUSS ein Attribut nonce_endpoint enthalten sein, dass die URL zur Abfrage neuer Nonce-Werte angibt.
Es MUSS ein Attribut openid_providers_endpoint enthalten sein, dass die URL zur Abfrage der unterstützten OpenID Provider enthält. [<=]
Hinweis: Der FQDN des Authorization Servers wird vom Anbieter des TI 2.0 Dienstes vergeben.
Die unterstützten OpenID Provider sind in der PU https://idp.app.ti-dienste.de/directory/fed_idp_list und in der RU https://idp-ref.app.ti-dienste.de/directory/fed_idp_list.
A_26090 - PEP Authorization Server, Well-known Erstellung
Die Komponente http Proxy MUSS für den Authorization Sever das Well-known json Dokument aus den Konfigurationsdaten des Zero Trust Clusters erzeugen.
[<=]
Beispiel Well-known json Dokument des Authorization Servers:
{
"issuer": "https://zerobin.zt.dev.ccs.gematik.solutions",
"authorization_endpoint": "https://zerobin.zt.dev.ccs.gematik.solutions/auth",
"token_endpoint": "https://zerobin.zt.dev.ccs.gematik.solutions/token",
"jwks_uri": "https://zerobin.zt.dev.ccs.gematik.solutions/jwks",
"nonce_endpoint": "https://zerobin.zt.dev.ccs.gematik.solutions/nonce"
"openid_providers_endpoint": "https://idp.app.ti-dienste.de/directory/fed_idp_list"
"scopes_supported": [
"zero:register",
"zero:manage"
],
"response_types_supported": [
"code"
],
"response_modes_supported": [
"query"
],
"grant_types_supported": [
"authorization_code"
],
"token_endpoint_auth_methods_supported": [
"none"
],
"token_endpoint_auth_signing_alg_values_supported": [
"ES256"
],
"service_documentation": "https://gihub.com/gemazik/zero-lab",
"ui_locales_supported": [
"de",
"en"
],
"code_challenge_methods_supported": [
"S256"
]
}
5.4.3.2 Ablauf der SM-B Authentifizierung mit DPoP
Die SM-B Authentifizierung wird für Nutzer und Clients angeboten, die nicht über andere geeignete Credentials verfügen, um sich als berechtigte TI-Teilnehmer auszuweisen. Die Authentifizierung erfolgt gemäß OAuth2 Client Authentifizierung [RFC7523] mit SM-B signiertem Client Assertion JWT. Replay-Attacken werden durch die Aufnahme einer server-generierten Nonce als JTI Claim in der Client-Assertion verhindert.
A_26091 - ZT Cluster, SM-B Authentifizierung mit DPoP
Der Zero Trust Cluster MUSS den Ablauf gemäß Abbildung SM-B_Authentisierung_mit_DPoP sowie gemäß [RFC7523] und [RFC9449] unterstützen.
[<=]