Informationen für Fachdienst-Hersteller

Fachdienst-Hersteller stellen die Software her, die zur Bereitstellung und Betrieb eines Fachdienstes nötig ist. Dies können zum Beispiel Hersteller von VSDM 2.0 Diensten, oder des PoPP-Dienstes sein. In späteren Ausbaustufen der TI 2.0 können weitere Fachdienste hinzukommen.

Betrachtete Nutzungsszenarien

Für den Fachdienst-Hersteller werden im Wesentlichen Szenarien betrachtet, in denen die ZETA-Komponenten zum Test der Interaktion mit dem Fachdienst genutzt werden.

Dazu wird angenommen, dass die ZETA-Komponenten als “Black Box” betrachtet werden wollen, die, einmal installiert, den Zugriff absichern und ggf. nur in unterschiedlichen Konfigurationen bzgl. Fachdienst-Endpunkten o.ä. betrieben werden.

Das folgende Diagram zeigt ein solches angenommenes Szenario:

Setup für Fachdienst-Hersteller

Hierbei wird Folgendes angenommen:

  • Es existiert ein Fachdienst-Test-Client, der den Fachdienst via HTTPS aufrufen kann, um Funktionalität fachlich zu testen.
  • Dieser Fachdienst-Test-Client ist konfigurierbar und insbesondere kann ein veränderter Basis-Pfad für die Aufrufe der Fachdienst-API genutzt werden.

Deployment-Szenario für FD-Hersteller

Die ZETA-Komponenten – inklusive des ZETA-Testdriver-Clients – werden als Container-Images geliefert und in einem Kubernetes-Cluster betrieben.

Der ZETA-Testdriver wirkt damit mit der Ausnahme des Pfades als transparenter Proxy zwischen Fachdienst-Test-Client und Fachdienst. Der am ZETA-Testdriver-Proxy aufzurufende Pfad erhält dabei das Präfix /proxy, nur die Pfadsegmente hinter proxy werden an den Fachdienst weitergereicht. Dies erlaubt weitere API Funktionen am Testdriver, mehr Details dazu in der Anleitung zum Testdriver.

Systemvoraussetzungen

Als Systemvoraussetzungen werden hier nur die notwendigen Voraussetzungen genannt, die für die ZETA-Komponenten – und nicht für die Fachdienst-Komponenten – benötigt werden.

Zugänge

  • Container images

  • TI Dienste (für Testsysteme)

    • MUSS:
      • OCSP Responder der TI TSL (! d.h. der Responder im Internet nicht der im TI 1.0 Netz)
      • Federation Master (ab Stufe 2)
      • TI-Monitoring
      • TI-SIEM
      • PIP/PAP Repository
    • Abhängig vom Fachdienst, ab Umsetzungsstufe 2:
      • Federated IDP bzw. Sektorale IdPs

Eigene Dienste

  • eigenes container repository (MUSS)
    • für die Bereitstellung der PIP/PAP images
  • anbietereigene Dienste (Abhängig vom Fachdienst, ab Umsetzungsstufe 2)
    • Clientsystem Notification Service(s) – Apple Push Notifications, Firebase

    • Email Confirmation-Code – Mailversand

    • Optional:
      • Dienstanbieter-Monitoring (OpenTelemetry Collector)
      • Dienstanbieter-SIEM

Infrastruktur

Die Infrastrukturanforderungen sind im Detail beschrieben in der Anleitung, einen ZETA-Guard im Kubernetes zu konfigurieren.

Tooling

  • Kubernetes - kubectl
  • Terraform
  • Helm 4

Konfiguration, Keys

  • Das ZETA-SDK benötigt zum Testen eine valide SM-B Datei aus dem verwendeten Vertrauensraum im p12 Format, wie sie von der gematik bezogen werden kann. Diese kann im Testdriver (proxy) Client konfiguriert werden, um SM-B-basierte Authentifizierung vornehmen zu können, und wird dann im PDP gegen den TI Vertrauensanker (Federation Master, TSL) geprüft.
  • Für ASL-Betrieb des PEP muss ein ECC-Schlüssel (Kurve P256) erstellt und ein entsprechendes Signatur-Zertifikat (Profil C.FD.AUT, technische Rolle oid_zeta-guard) von der gematik bestellt werden. Ferner wird das zugehörige KOMP-CA-Zertifikat benötigt, es wird normalerweise zusammen mit dem Signatur-Zertifikat ausgeliefert.

Die genaue Art der Zertifikatsprüfung – z.B. über Federation Master und/oder Vertrauensanker-Container ist noch in Ausarbeitung der Spezifikation.

Sicherheitsleistungen

Der ZETA-Guard wird als Softwarepaket geliefert, welches durch den Fachdienst-Hersteller in den Fachdienst integriert und durch den Fachdienst-Betreiber betrieben werden muss.

Aus den gematik-Anforderungen ergeben sich (u.a.) Sicherheitsleistungen, die, je nach vertraglichem Verhältnis zwischen Fachdienst-Hersteller und -Betreiber von diesen zu leisten sind.

Diese Sicherheitsleistungen sind in Sicherheitsleistungen Betreiber dargelegt.

Relevante Anleitungen und Referenzen

Die relevanten Anleitungen und Referenzen sind hier verlinkt:

Für den produktiven Betrieb des ZETA-Guard empfehlen sich zusätzlich folgende Dokumente:

Optionale Informationen:

  • Für das Bauen des ZETA-Testdrivers (ein ZETA-Client, der als Proxy dient). Dies sollte bei Nutzung des Testdriver container images nicht nötig sein, ist aber bei eigenen Anpassungen nötig. Wie Sie den Testdriver bauen
  • Wie Sie einen Ende-zu-Ende-Integrationstest ausführen – hier werden der Test-Fachdienst und die ZETA-Komponenten mit der Tiger-Testsuite getestet. Dies kann – bei Bedarf vom Fachdienst-Hersteller an den eigenen Fachdienst angepasst werden. Wie Sie einen Ende-zu-Ende-Integrationstest ausführen
  • Leitszenarien des Deployments des ZETA-Guard für unterschiedliche Fachdienste: Deploymentszenarien

Known Issues und Fehleranalysen

Besonderer Fehlersituationen

  • Server-Fehler mit HTTP-Response-Code 500 (Internal Server Error) müssen mithilfe der Logs aus Kubernetes analysiert werden. Dazu kannkubectl logs genutzt werden.
  • Bei der Nutzung des testdriver als Test-Client für den Fachdienst ist zu beachten, dass der testdriver die Host, die er im Request an sich bekommt eins zu eins weiterleitet. Diese Funktionalität wird für den Betrieb mit dem Tiger-Proxy verwendet, kann aber in Infrastrukturen, in denen ein Host Header automatisch gesetzt wird zu Problemen führen. Der Fehler zeigt sich dann erst beim ersten eigentlichen Aufruf des Fachdienstes (ohne wie auch mit ASL), typischerweise durch einen 404 Not Found Fehler. Analog die X-Forwarded Header, insb. auch X-Forwarded-Host. Dieser wird im PEP für die Ermittlung des Ziel-Hosts (PEP Endpunkt) verwendet, mit dem die Audience und HTU DPoP claims verifiziert werden. Ein Fix dafür könnte sein, beim selbst-gebautem testdriver container, in der Klasse zeta-testdriver/src/main/kotlin/de.gematik.zeta.driver/DriverUtils.kt, in der statischen Variable notForwardedHeaders die entsprechenden Header einzufügen wie HttpHeaders.Host.

Weitere Hinweise

  • Die URL des Testdriver-Proxys enthält für alle Anfragen an den Fachdienst das Präfix /proxy. Dies ist zu berücksichtigen.
  • Die Art der gegenseitigen Authentifizierung des ZETA-Guard mit dem Fachdienst ist noch nicht spezifiziert.

Wartung

Ein definierter Wartungsprozess ist vor Meilenstein 4 aktuell nicht umgesetzt. Updates werden über die Image- bzw. git-Repositories verbreitet.

This site uses Just the Docs, a documentation theme for Jekyll.