ZETA – Zero Trust Access

Policy

ZETA Guard – Policies 

Dienstübergreifend

Version
1.0.0
Revision
1657190
Stand
06.07.2026
Status
freigegeben
Klassifizierung
öffentlich
Referenzierung
gemPolicy_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

Es handelt sich um eine Erstveröffentlichung.

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

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

2 Dienstspezifische Berechtigungen / Einschränkungen

Neue Policies oder Anpassungen an Policies werden im Rahmen dieses Dokumentes kommuniziert. Die Verteilung dieses Dokumentes erfolgt anlassbezogen. 

2.1 Allowlists

Die hier beschriebenen Richtlinien funktionieren nach einem einfachen Prinzip: ein Zugriff wird nur dann erlaubt, wenn alle definierten Bedingungen erfüllt sind. Scheitert auch nur eine einzige Prüfung, wird der Zugriff verweigert und die Gründe für die Ablehnung werden protokolliert. Ein anfragender Client muss Prüfungen auf 

• Beruf oder Einrichtungsart 
  

• Client- Anwendung (product_id und product_version) 
  

• angeforderte Berechtigungen (scopes) 
  

• angeforderte Ziel- Ressource (audience) 
  

erfolgreich durchlaufen.  

Die zulässigen Parameter/Werte/Daten werden fachdienstspezifisch in separaten Allowlists definiert. 

2.2 Denylists

Parameter/Werte/Daten in Denylists werden differenziert definiert: 

• Statische Parameter/Werte/Daten (wie z.B. Betriebssystemversionen) in Absprache mit den Gesellschaftern 
  

• Dynamische Parameter/Werte/Daten durch die gematik nach internen Erkenntnissen/Auswertung der Bedrohungslage.

2.2.1 Betriebssystem-Versionen

Betriebssystemversionen werden initial nur reported. 

2.2.2 IP Bereiche

2.2.2.1 IP Adressen / IP Ranges

Diese Liste schafft die Möglichkeit zur Sperrung von IP-Adressen / IP Ranges. 
Die dynamische Sperrung von IP Ranges wird durch die gematik nach internen Erkenntnissen/Auswertung der Bedrohungslage vorgenommen. 
 
Eine Abstimmung mit den Gesellschaftern erfolgt nicht. 

2.2.2.2 TOR-Listen

Diese Liste schafft die Möglichkeit zur Sperrung von TOR-Listen. 
Die dynamische Sperrung von TOR-Listen wird durch die gematik nach internen Erkenntnissen/Auswertung der Bedrohungslage vorgenommen. 
 
Eine Abstimmung mit den Gesellschaftern erfolgt nicht. 

2.2.2.3 VPN-Listen

Diese Liste schafft die Möglichkeit zur Sperrung von VPN-Listen. 
Die dynamische Sperrung von VPN-Listen wird durch die gematik nach internen Erkenntnissen/Auswertung der Bedrohungslage vorgenommen. 
 
Eine Abstimmung mit den Gesellschaftern erfolgt nicht. 

2.2.2.4 Geo-IP-Listen

Diese Liste schafft die Möglichkeit zur Sperrung von IP-Adressen / IP Ranges, die außerhalb Deutschlands lokalisiert sind. 
Die dynamische Sperrung von Geo-IP-Listen wird durch die gematik nach internen Erkenntnissen/Auswertung der Bedrohungslage vorgenommen. 
 
Eine Abstimmung mit den Gesellschaftern erfolgt nicht. 

2.2.3 Gesperrte Benutzer

Diese Liste schafft die Möglichkeit zur Sperrung von Benutzern. 
Die dynamische Sperrung von Nutzern (TelematikID, KVNR) wird durch die gematik nach internen Erkenntnissen/Auswertung der Bedrohungslage vorgenommen. (Aktuell ist eine solche Sperrung nicht vorgesehen.) 
 
Eine Abstimmung mit den Gesellschaftern erfolgt nicht. 

2.2.4 Gesperrte Clients

Diese Liste schafft die Möglichkeit zur Sperrung von Clients. 
Die dynamische Sperrung von Clients (product_id und product_version) erfolgt basierend auf Herstellerangaben, oder wird durch die gematik nach internen Erkenntnissen/Auswertung der Bedrohungslage vorgenommen.  
 
Eine Abstimmung mit den Gesellschaftern erfolgt nicht. 

3 Anhang – Verzeichnisse

3.1 Abkürzungen

3.2 Glossar

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.

3.5.2 Weitere Dokumente

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)>