gemPolicy_ZETA_PoPP_V1.0.0






ZETA – Zero Trust Access





Policy

ZETA Guard – Policies 

PoPP





Version1.0.0
Revision1657166
Stand06.07.2026
Statusfreigegeben
Klassifizierungöffentlich
ReferenzierunggemPolicy_ZETA_PoPP

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

Es handelt sich um eine Erstveröffentlichung.

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 06.07.2026 initiale Erstellung (Policies_26_1) gematik

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Ziel der Policies

Sicherheitsrichtlinien in Zero Trust Umgebungen werden durch Policies definiert, die innerhalb des ZETA Guard durch den Open Policy Agent verarbeitet und durch PDP/PEP durchgesetzt werden. 
Die Policies stellen sicher, dass nur autorisierte Institutionen, Personen und Geräte Zugriff auf geschützte Ressourcen und Dienste erhalten. Sie definieren Regeln, um die Berechtigungen - beispielsweise basierend auf den Institutionstypen und angefragten Berechtigungen - zu gewähren oder abzulehnen. 
Die Policies bestehen grundsätzlich aus Regeln und dazugehörenden Daten. Die Regeln können sowohl allgemeingültig als auch dienstspezifisch sein; das gilt ebenso für die dazugehörenden Daten. 
Nach Auswertung der Policies durch den Open Policy Agent werden im Positiv- Fall Access Token erstellt. Die Gültigkeitsdauer für Access Token wird durch den jeweiligen Fachdienst festgelegt. 
Die Policies überprüfen die folgenden Aspekte. Bei Verstoß gegen eine der unten genannten Regeln wird der Zugriff verweigert und entsprechende Fehlermeldungen zurückgegeben: 

1.1.1 Scopes und Audiences

Es wird geprüft, ob die angefragten Berechtigungen (scopes) und Zielressourcen (audience) mit den erlaubten Berechtigungen und Zielressourcen übereinstimmen. 

1.1.2 Client-Version

Die Software- Version des Clients muss den erlaubten Versionen entsprechen.  
Nur bei der gematik registrierte Clients (product_id und product_version) erhalten Zugriff auf die TI 2.0. 

1.1.3 Profession

Der Institutionstyp muss in der Liste der erlaubten Institutionstypen enthalten sein.  
Eine detaillierte Festlegung erlaubter OID’s erfolgt in Allowlists fachdienstspezifischer Policies. 

1.2 Zielgruppe

Dieses Dokument dient der Information und Abstimmung der Regeln. 
Die dazugehörenden Daten werden durch die gematik definiert.

1.3 Abgrenzung des Dokuments

Die Beschreibungen der generellen Funktionalitäten des ZETA Guard und des Open Policy Agent sind nicht Bestandteil dieses Dokuments.

Wichtiger Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

Hinweis auf offene Punkte

Offener Punkt: Das Kapitel wird in einer späteren Version des Dokumentes ergänzt.

2 Dienstspezifische Berechtigungen / Einschränkungen

Für den PoPP-Service gibt es keine Einschränkung bezüglich der OIDs des Gesundheitswesens. Der Zugriff auf den PoPP Service ist für alle Institutionen, die eine SM(C-)B haben, erlaubt. 

2.1 Allowlists

Die erteilten Berechtigungen umfassen die folgenden Dienste und Funktionen: 

Tabelle 1: Allowlist – scopes/audiences

Berechtigung 
Erläuterung 
PoPP- Token-Erstellung 
Der Zugriff auf die api-popp erfolgt über I_PoPP_Token_Generation. 
Diese Schnittstelle wird vom PS (PoPP‑Client) der LEI genutzt, um beim PoPP‑Service einen PoPP‑Token abzurufen. Dabei werden die Daten der Institution und des Versicherten im PoPP‑Token zusammengeführt. 

2.1.1 Berechtigte Leistungserbringerinstitutionen

Tabelle 2: Allowlist – professionOID‘s

Institutionstyp 
OID 
Alle Institutionen mit SM(C)-B  
Alle im Gesundheitswesen erlaubten OIDs gemäß gemSpec_OID. 
 

2.1.2 Erlaubte Zugriffsmethoden

Tabelle 3 : Allowlist – Zugriffsmethoden

Methode 
Erläuterung 
Websocket 
Dieser Endpunkt erlaubt dem PoPP-Client, eine Websocket Verbindung zum Server aufzubauen und Nachrichten zu senden, um mit Hilfe einer eGK ein PoPP-Token zu generieren. 

2.2 Denylists

Tabelle 4 : Denylist

Einschränkung 
Erläuterung 
keine 
 

3 Anhang – Verzeichnisse

3.1 Abkürzungen

Kürzel
Erläuterung
PDP Policy Decision Point
PEP Policy Enforcement Point
PS Primärsystem
LEI Leistungserbringerinstitution
PoPP Proof of Patient Presence

3.2 Glossar

Begriff
Erläuterung

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

3.3 Abbildungsverzeichnis

    3.4 Tabellenverzeichnis

    3.5 Referenzierte Dokumente

    3.5.1 Dokumente der gematik

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

    [Quelle]
    Herausgeber: Titel
    [gemGlossar] gematik: Einführung der Gesundheitskarte – Glossar
    https://fachportal.gematik.de/fileadmin/Fachportal/Glossar/gemGlossar_V5.2.0.pdf 
    [gemSpec_ZETA] Gematik: Spezifikation Zero Trust Access 
    https://gemspec.gematik.de/docs/gemSpec/gemSpec_ZETA/latest/ 
    [gemSpec_OID] gematik: Spezifikation Festlegung von OIDs 
    https://gemspec.gematik.de/docs/gemSpec/gemSpec_OID/latest/  
    [gemSpec_PoPP-Service] gematik: Spezifikation Proof of Patient Presence (PoPP)-Service (Stufe 1) 
    https://gemspec.gematik.de/docs/gemSpec/gemSpec_PoPP_Service/latest/ 
    [Open Policy Agent] https://www.openpolicyagent.org/ 

    3.5.2 Weitere Dokumente

    [Quelle]
    Herausgeber (Erscheinungsdatum): Titel

    3.6 Offene Punkte/Klärungsbedarf <optional>


    <hier werden offene Punkte vermerkt, die bereits in Klärung sind, aber noch nicht in Form einer "offiziellen" Stellungnahme" vorliegen (z.B. bereits erstellte Entscheidungsvorlagen)> 
     

    Kap. 
    Offener Punkt 
    Zuständig