Technische Lösungsarchitektur (MOVI-Kernkomponenten)

Inhalt

Technische Architektur der MOVI-Kernkomponenten
Prämissen
Überblick
TSL-Abrufpunkt und OCSP-Responder
Reverse Proxy
Account Management Service
Identity Provider

Spezifikationsdetails
todo
todo

Technische Architektur

Die nachfolgenden Abschnitte beschreiben die technische Architektur des Systems. In diesem Zusammenhang wird jeweils die konkrete Funktionalität und Ausgestaltung einzelner Dienste und Komponenten beleuchtet sowie deren Interaktionen untereinander.

Prämissen

Der technischen Architektur sowie der prototypischen Realisierung liegen verschiedene Prämissen zugrunde, die im Folgenden kurz dargestellt werden:

• Nutzung von Standards - Die zu entwickelnde Lösung soll zur Realisierung der benötigten Funktionalität so weit wie möglich auf etablierte Standards aus dem Sicherheits- und E-Health-Umfeld zurückgreifen. Sofern eine Auswahl zwischen zwei funktional vergleichbaren Standards besteht, soll der Standard gewählt werden, der sich leichter in mobile Anwendungen integrieren lässt.
• Nutzung von Open-Source-basierten Softwarelösungen/Bibliotheken - Wo immer möglich, soll auf Softwarelösungen und -bibliotheken zurückgegriffen werden, die quelloffen zur Verfügung stehen. Sofern eine Auswahl zwischen zwei funktional vergleichbaren Lösungen/Komponenten besteht, soll die Lösung/Komponente genutzt werden, deren Lizenz eine komerzielle Nachnutzung ermöglicht.

Aus diesen Prämissen ergeben sich Grundsatzentscheidungen, die in die technische Architektur eingeflossen sind und sich somit in den nachfolgenden Darstellungen widerspiegeln:

• Verwenden von OpenID Connect - Die Basis für die Umsetzung von Authentifizierungsworkflows bildet OpenID Connect. Alternative Standards wie SAML 2.0 bieten aus funktionaler Sicht zwar einen vergelichbaren Leistungsumfang, lassen sich jedoch aufgrund ihrer XML-Lastigkeit schwerer durch mobile Anwendungen verarbeiten.

Überblick

Wie der Abbildung zu entnehmen ist, verteilt sich die Funktionalität auf verschiedene Dienste bzw. Komponenten. Die folgenden Abschnitte beschreiben die Abbildung bezogen auf die einzelnen Komponenten im Details.

TSL-Abrufpunkt und OCSP-Responder

Die Verwendung von X.509-Zertifikaten spielt auf verschiedenen Ebenen der Lösungsarchitektur eine besondere Rolle. Entsprechende Zertifikate kommen beispielsweise beim sicheren Datentransport über TLS (vgl. Reverse Proxy) zum Einsatz oder im Rahmen der Authentifizierung der Versicherten durch den Identity Provider (vgl. Identity Provider). Für beide Szenarien ist es unerlässlich die Validität der jeweils genutzten Zertifikate zu prüfen.

• Authentifizierung des Versicherten: Sämtliche Certification Authorities (CA), die für die Ausstellung der Authentifizierungszertifikate der elektronischen Gesundheitskarten genutzt werden, sind in der Trusted Service List (TSL) der gematik aufgeführt. Die im Rahmen der Authentifizierung der Versicherten notwendige Prüfung der entsprechenden Zertifikatsketten macht die korrekte Verarbeitung dieser Trusted Service List erforderlich. Die TSL kann über den definierten Abrufpunkt https://download.tsl.ti-dienste.de/TSL.xml bezogen werden. Detaillierte Vorgaben bezüglich der erforderlichen Validierungsschritte für TSL und Zertifikate werden in [gemSpec_PKI] erörtet. Die Validierung schließt u.a. auch die Online-Prüfung der Zertifikate über OCSP (Online Certificate Status Protocol) mit ein. Die Adressen der OCSP-Responder sind Bestandteil des Diensteintrags der TSL und zusätzlich im Zertifikat selbst enthalten.

• Sicherer Datentransport über TLS: Die Endpunkte für die genutzten Dienste werden über das öffentliche Internet erreichbar sein. Wo und wann immer möglich, soll TLS (Transport Layer Security) zum Schutz der mit diesen Diensten ausgetauschten Daten genutzt werden. Das TLS-Protokoll setzt in einer üblichen Konfiguration zumindest das Vorhandensein eines Serverzertifikats voraus. Dieses muss durch den Client validiert werden. In diesem Zusammenhang greifen vergleichbare Mechanismen wie bei der Validierung des Authentisierungszertifikates (z.B. Einbinden eines OCSP-Responders). Einzig die Verwendung einer Trusted Service List ist nicht erforderlich bzw. wird nicht von Hause aus unterstützt.

TSL-Abrufpunkt und OCSP-Responder sind keine Kernbestandteile der Lösungsarchitektur. Sie existieren bereits in produktiver Form und werden lediglich durch die verschiedenen Komponenten der Lösung (Identity Provider, Account Management Service, Client etc.) nachgenutzt. Aus diesem Grund wird in den folgenden Ausführungen nicht weiter auf die detaillierte Ausgestaltung der entsprechenden Dienste eingegangen. Es wird lediglich auf deren Nutzung verwiesen.

Reverse Proxy

Der Reverse Proxy leitet Anfragen von beliebigen Clients an die jeweiligen Dienste im Backend weiter. In diesem Zusammenhang kann er eine Reihe von weiteren Aufgaben übernehmen:

• Zentrale Terminierung von TLS-Verbindungen: Die TLS-Verbindung mit dem Client wird bereits am Reverse Proxy terminiert. Dies ermöglicht den Einsatz speziell gehärteter und auf Performance zugeschnittener Lösungen. Eine Härtung des TLS-Stacks der geschützten Dienste ist dann nur noch in geringerem Umfang erforderlich.
• Load Balancing: Sofern erforderlich kann der Reverese Proxy auch in der Rolle eines Load Balancers agieren und Anfragen gleichmäßig über verschiedene Dienstinstanzen hinweg verteilen.
• Fallback: Sofern erforderlich kann der Reverse Proxy ausgefallene oder gestörte Dienstinstanzen erkennen und den Datenverkehr auf Backup-Systeme umleiten.
• URL-Rewriting: Sofern erforderlich kann der Reverse Proxy angefragte URLs umschreiben und somit z.B. an die Anforderung der maskierten Backenddienste anpassen.
• Sicherheit: Speziell erweiterte Varianten eines Reverse Proxies können als Web Application Firewall (WAF) fungieren und den eingehenden und ausgehenden Datenverkehr bezüglich bestimmter Angriffe analysieren. Andere Erweiterungen erlauben die enge Verzahnung mit Identity Providern, um Clients/Nutzer zu authentifizieren und ggf. auch zu autorisieren.

Schnittstellen

Im Kontext des Projektes terminiert der Reverse Proxy die TLS-Verbindungen für folgende Dienste:

• Identity-Provider: Ausschließlich https-Traffic, der für die Realisierung der Authentifizierungsfunktionalität und für die Unterstützung des OpenId Connect Protokolls benötigt wird, ist zulässig. Ein Zugriff auf die Administrationsschnittstellen des Idenitty Providers ist über den Reverse Proxy hingegen nicht möglich. Die Steuerung der Weiterleitung erfolgt erfolgt auf Basis der URL des Aufrufs. (1)
• Account Management Service: Der Reverse-Proxy leitet ausschließlich https-Traffic weiter, (2)

Sofern der Reverse Proxy OCSP-Stapling unterstützt, kann eine zusätzliche Kommunikation mit den für die Serverzertifikate zuständigen OCSP-Respondern stattfinden. (5)

Anforderungen

Folgende Anforderungen müssen durch die Implementierung des Reverse Proxy umgesetzt werden:

• Sämtliche Datenverbindungen vom Client zum Reverse Proxy MÜSSEN über eine einseitig authentisierte TLS-Verbindung abgesichert werden.
• Die Vorgaben aus [BSI TR-02102-2] MÜSSEN berücksichtigt werden.

Prototypische Realisierung

TODO Die prototypische Realisierung nutzt traefik als Reverse Proxy. Detaillierte Informationen zur Ausgestaltung/Konfigurationen können der Realisierungsdokumentation entnommen werden.

Identity Provider

Die primäre Aufgabe des Identity Providers liegt im Bereich der Bereitstellung von Sicherheitstoken und Identitätsinformationen für angebundene Fachdienste. Um diese Aufgaben realisieren zu können, muss der Identity Provider verschiedene Funktionen erfüllen:

• Abbilden eines Leistungserbringerverzeichnisses: Leistungserbringer (z.B. Ärzte) sind wesentliche Akteure in den für die Umsetzung vorgesehenen Anwendungsfällen. Um auch ihnen den Zugang zu den benötigten Diensten und den Zugriff auf die von diesen Diensten vorgehaltenen Informationen und Funktionen zu ermöglichen, muss der Identity Provider für diese Nutzergruppe die Verwaltung der jeweiligen Identitätsattribute (z.B. Rollen) organisieren. Ohne eine entsprechende Funktionalität sind insbesondere Authentifizierung und Autorisierung kaum zu realisieren.
• Abbilden eines Patientenverzeichnisses: Neben den Leistungserbringern müssen auch die Patienten bzw. deren Identitätsattribute und Credentials durch den Identity Provider verwaltet werden. Auch für diese Akteursgruppe gilt, dass die benötigte Authentifizierungs- und Autorisierungsfunktionalität sonst kaum realisiert werden kann.
• Authentifizierung von Nutzern: Zentrale Aufgabe des Identity Providers ist die Authentifizierung von Nutzern. Im beschriebenen Anwendungsszenario bedeutet Authentfizierung speziell die verlässliche Überprüfung und Bestätigung der behaupteten Identität eines Nutzers. Die Überprüfung erfolgt dabei anhand von Credentials (Anwendung von Schlüsseln, Secrets etc.), die dem Nutzer zugeordnet sind. Die Bestätigung wird über die Ausstellung spezieller Authentifizierungsnachweise abgebildet.
• Autorisierung von Nutzern: Neben der Authentifizierung kommt dem Identity Provider ebenfalls die Aufgabe zu, Nutzer für den Zugriff auf spezielle Ressourcen zu autorisieren. Auch in diesem Zusammenhang kommen spezielle Nachweise zum Einsatz, die geeignet sind, den Zugriff anhand der bereitgestellten Informationen zu steuern.

Hinweis: Für ein leichteres Verständnis der folgenden Abschnitte bietet sich eine - zumindest grundlegende - Auseinandersetzung mit OpenID Connect an. Ein guter Ausgangspunkt ist die offizielle Webseite der OpenID Foundation: https://openid.net/connect/

Schnittstellen

Der Identity Provider besitzt Schnittstellen zu den folgenden Diensten:

• Client: Beim Client handelt es sich bezogen auf die Anwendungsfälle um die mobilen Endgeräte der Nutzer. Diese kontaktieren (vermittelt durch den Reverse Proxy) den Identity Provider, um den entsprechenden Nutzer zu authentisieren und Authentifizierungs- bzw Autorisierungsnachweise abzurufen. (1)
• OCSP Responder: Der OCSP Responder kommt insbesondere im Rahmen der Überprüfung von Versichertenzertifikaten (primär eGK.AUT) zum Einsatz. Über die durch den Responder bereitgestellte Funktionalität kann online geprüft werden, ob ein bestimmtes Zertifikat noch gültig ist oder bereits gesperrt wurde. (2)
• TSL Abrufpunkt: Der TSL Abrufpunkt spielt ebenfalls bezogen auf die Überprüfung der X.509-Zertifikate eine entscheidende Rolle. In der TSL finden sich alle relevanten Informationen, die für die Überprüfung der Versichertenzertifikate benötigt werden. Dazu gehören u.a. auch die Endpunktadressen der benötigten OCSP Responder. (3)
• Signalling Server: Im Rahmen der Authentifizierung der Clients muss der Signalling Server in die Lage versetzt werden, die für die Authentifizierung genutzten Credentials (OIDC-Token) zu validieren und zusätzliche Nutzerinformationen abzurufen. Dazu benötigt er Zugriff auf ausgewählte Endpunkte des Identity Provider (keysource, userinfo). (4)
• FHIR-Server: Im Rahmen der Authentifizierung der Clients muss der FHIR Server in die Lage versetzt werden, die für die Authentifizierung genutzten Credentials (OIDC-Token) zu validieren und zusätzliche Nutzerinformationen abzurufen. Dazu benötigt er Zugriff auf ausgewählte Endpunkte des Identity Provider (keysource, userinfo). (5)

OpenID Connect als Authentifizierungsprotokoll

OpenID Connect (OIDC) basiert auf dem Autorisierungsprotokoll OAuth 2.0 und dient als zusätzliche Schicht zur Abbildung von Authentifizierungsfunktionalität. Den das Protokoll nutzenden Clients wird es ermöglicht, die Identität von Nutzern verlässlich zu überprüfen und relevante Identitätsattribute abzufragen. Genau diese Funktionalität ist für die Absicherung der realisierten Dienste (Signalling, FHIR) zwingend erforderlich. OIDC und OAuth nutzen sogenannte Token (identity, access + refresh token), um Authentifizierungs- und Autorisierungsinformationen zu transportieren. OIDC bildet die Basis für die Umsetzung des Projektes. Konkret wird der OIDC Authorization Code Flow mit PKCE (Proof Key for Code Exchange) verwendet.

Hinweis: Eine Alternative zu OpenID Connect bildet SAML 2.0. Aufgrund der leichteren Integrierbarkeit von OpenID Connect und der besseren Unterstützung durch mobile Plattformen wurde sich bewusst gegen SAML 2.0 entschieden.

Das gewählte Protokoll (OpenID Connect) trifft grundsätzlich keine Vorgaben bezüglich der zu verwendenden Authentfizierungsmechanismen. Somit sind grundsätzlich beliebige Mechanismen/Verfahren vorstellbar, die durch den Identity Provider zur Überprüfung der Versichertenidentität genutzt werden können. Dies eröffnet u.a. die Möglichkeit, die elektronische Gesundheitskarte bzw. das auf ihr enthaltene Schlüsselmaterial zum Zwecke der Authentifizierung der Versicherten zu nutzen.