gemF_TI-Gateway_V1.0.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature:

TI-Gateway

    

     

      
Version
      
1.0.0
     
     

      
Revision
      
572642
     
     

      
Stand
      
15.02.2023
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemF_TI-Gateway
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

Die Schnittstelle zwischen der zentralen Infrastruktur der TI und der dezentralen Umgebung bildet derzeit die dezentrale Komponente Konnektor, die eine gesicherte Verbindung zum VPN-Zugangsdienst der TI aufbaut. Um im Sinne der TI2.0 Komplexität aus der dezentralen Umgebung zu entfernen, wurde das Produkt TI-Gateway definiert, welches die Funktion von Zugangsdienst und Teilfunktionen des Konnektors in einem Dienst zusammenfasst. Dieses Feature-Dokument beschreibt das TI-Gateway (Anbieter TI-Gateway, Produkt Zugangsmodul und Anpassungen am Produkt Highspeed-Konnektor) und beinhaltet Blattanforderungen, die nicht bereits Teil anderer Spezifikationen der gematik sind. Der vollständige Anforderungshaushalt ergibt sich aus den Steckbriefen für den Anbieter TI-Gateway und den Produkten, die Teil des TI-Gateway sind.

1.1 Zielsetzung

Dieses Dokument soll ein Verständnis für das TI-Gateway vermitteln und die Anforderungslage vervollständigen. Dadurch sollen Hersteller und Anbieter in die Lage versetzt werden, das Produkt herzustellen bzw. dessen Betrieb zu ermöglichen.

1.2 Zielgruppe

Hersteller, Anbieter, Nutzer und andere Stakeholder.

1.3 Abgrenzungen

Das Dokument beinhaltet nur neue bzw. geänderte Anforderungen. Die vollständige Anforderungslage für die Produkttypen des TI-Gateways und den Anbieter des TI-Gateways ergeben sich aus den Produkttypsteckbriefen, dem Anbietersteckbrief und den darin referenzierten Anforderungen.

1.4 Methodik Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte 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.

2 Einordnung in die Telematikinfrastruktur

Das TI-Gateway ist ein zentraler Dienst der Telematikinfrastruktur, der Leistungserbringern anstelle eines Konnektors ermöglicht,

• eHealth-Kartenterminals (und darüber TI-Smartcards) zu nutzen,
• Services zu nutzen, wie sie vom Anwendungskonnektor und den Fachmodulen des Konnektors angeboten werden und
• über das Netzwerk auf offene Fachdienste und WANDA zuzugreifen.

Anbieter des TI-Gateways können darüber hinaus ihren Kunden weitere Services anbieten, müssen dann jedoch transparent machen, dass diese nicht Teil des zugelassenen TI-Gateways sind. (siehe A_23472)

Durch die Verschiebung der Funktionalitäten, die heute vom Konnektor im lokalen Netz des Nutzers bereitgestellt werden, in einen im Rechenzentrum betriebenen Dienst stehen zwangsläufig gewisse Funktionen nicht mehr zur Verfügung. Dies sind konkret:

• Schutz des lokalen Netzes des Nutzers gegenüber Angriffen aus dem Internet (bei Konnektor ausschließlich bei Anbindung "in Reihe" gegeben)
• Sicherer Internet Service (SIS)
• Zeitdienst für das lokale Netz
• DHCP Server für das lokale Netz
• VSDM im Offline-Betrieb
• VSDM im Standalone-Betrieb (nur bei Nutzung von zwei Konnektoren gegeben)

Nutzer bzw. die von ihnen beauftragten IT-Dienstleister (DVO) müssen entsprechend alternative Lösungen für die Funktionen umsetzen, die zuvor über den Konnektor genutzt wurden (sofern die Funktionen benötigt werden). Dies gilt insbesondere für die Absicherung des lokalen Netzes gegen das Internet, falls vor der Nutzung des TI-Gateway ein Konnektor in Anbindungsart "in Reihe" installiert war.

3 Technisches Konzept

Die Anbieterzulassung für das TI-Gateway setzt eine Produktzulassung Zugangsmodul und eine Produktzulassung Highspeed-Konnektor (HSK) voraus. Die Komponente http-Proxy ist als Teil des Produkttyps HSK umzusetzen. Die Anbieterzulassung für das TI-Gateway umfasst die Produkte Intermediär-VSDM, wobei ein bereits unter der Anbieterzulassung VPN-Zugangsdienst betriebener Intermediär nachgenutzt werden kann.

Abbildung 1: Anbindung TI-Gateway 

Das Zugangsmodul ermöglicht und sichert

• den Zugriff für die fachliche Nutzung auf die HSK-Instanz
• den Zugriff für die Administration einer HSK-Instanz 
• den Zugriff auf offene Fachdienste und WANDA der Telematikinfrastruktur

Der HSK stellt bereit

• die Basisdienste der Telematikinfrastruktur für LE-Umgebungen
• die Fachmodule
• die Kartenterminalintegration für die LE-Umgebung

Die Produkte Intermediär und http-Proxy bieten Funktionalitäten, die bei Nutzung von Konnektoren durch den VPN-Zugangsdienst abgedeckt werden.

Die Anbindung an die Telematikinfrastruktur erfolgt über einen SZZP oder SZZP-light. Die Anbindung über ein SZZP-light-plus, die bei einer Anbieterzulassung HSK vorgeschrieben ist, wird für das TI-Gateway nicht unterstützt.

4 Rollenkonzept TI-Gateway

Die gematik lässt ein Unternehmen als Anbieter des TI-Gateways zu. Der Anbieter erbringt Betriebsleistung und Service unter Verwendung zugelassener Produkte. Der Anbieter kann dazu Unterauftragnehmer beauftragen (siehe auch gemKPT_Betr.) Die Beziehungen der Firmen untereinander wird im Rollenkonzept nicht betrachtet.

Damit Mitarbeiter des Anbieters oder seiner Unterauftragnehmer nicht auf medizinische Informationen oder unberechtigt auf personenbezogene Daten zugreifen, werden die betrieblichen Tätigkeit in verschiedenen Rollen zugeordnet und es wird geregelt, welche Rollen ein Mitarbeiter innehaben kann. 

Abbildung 2: Übersicht Rollen und Komponenten

4.1 Reseller

Der Reseller betreut den Kunden kaufmännisch und qualifiziert einen Neukunden bevor im Onboardingprozess dem Kunden einen HSK-Instanz erzeugt/zugeordnet wird.

Der Reseller steuert das Onboarding von LE-Institutionen inklusive dem Erzeugen von HSK-Instanzen im „Werkszustand“ (automatisiert) über die Onboarding- & Registrierungskomponente des Zugangsmoduls. Der Reseller beauftragt die Löschung von HSK-Instanzen durch den Infrastrukturbetreiber (4-Augen-Prinzip).

Im Rahmen des Onboardings werden auch automatisiert der Administrations-Zugang an den Leistungserbringer bzw. den von diesem beauftragen lokalen Administrator (DVO) vergeben (Zugangsdaten abrufbar über das Nutzer-Portal) und die HSK-Instanzen zugewiesen. Der Reseller hat auf diese Daten keinen Zugriff. Dieser Prozess ist automatisiert und erfordert keinen manuellen Eingriff des Resellers oder Betreibers.

Der Reseller hat keinen Zugriff auf medizinische Daten oder die fachliche Konfiguration von HSK-Instanzen.

Der Reseller kann am Zugangsmodul abrechnungsrelevante Information einsehen bzw. abrufen.

Der Reseller hat keinen Zugriff auf das HSK-Basissystem oder die HSK-Instanzen. 

4.2 Betreiber

Der Betreiber überwacht und steuert technische Komponenten des TI-Gateways inkl. der RZ-Infrastruktur darum.

Der Betreiber greift auf das HSK-Basissystem über die Admin-Rolle "Basissystem-Admin" zu. Dazu gehört die Installation von Softwareupdates und das Erzeugen und Wiederherstellen von Backups der HSK-Instanzen (Snapshots). Dabei hat der Betreiber keinen Zugriff auf den Inhalt und die Konfiguration der HSK-Instanzen und deren fachliche Logs und er hat ebenso keinen Zugriff auf medizinische Daten. Der Infrastrukturbetreiber führt die Löschaufträge des Resellers von HSK-Instanzen aus. 

Der Betreiber überwacht und administriert das Zugangsmodul.  

Der Infrastrukturbetreiber kann technische Parameter wie die Ressourcenauslastung überwachen und technische Parameter wie die Ressourcenzuweisung für HSK-Instanzen ändern. Diese Aufgabe kann auch an den Reseller für dessen jeweiliges Kontingent von HSK-Instanzen übertragen werden.

4.3 Hersteller des HSK

Der Hersteller interagiert mit dem HSK-Basissystem mit der Rolle Hersteller. In dieser Funktion konfiguriert er den HSK für die Betriebsart "TI-Gateway" und koppelt den HSK mit dem HSM.

Der Hersteller stellt Softwareupdates bereit und wird für 3rd-Level-Support/Debugging hinzugezogen.

Der Hersteller des HSK hat keinen Zugriff auf Logs aus den HSK-Instanzen. Wenn diese für den Support notwendig sind, müssen diese von einer Administrator-Rolle pseudonymisiert bereitgestellt werden.

4.4 HSK-Instanz Administrator z.B. Dienstleister vor Ort (DVO)

Die Administration der HSK-Instanz wird vom Leistungserbringer oder einem von ihm beauftragten Dienstleister durchgeführt (DVO). Diese Rolle entspricht somit dem lokalen Administrator, wie er auch beim Einboxkonnektor agiert.

Der DVO greift aus der Leistungserbringerumgebung oder über einen eigenständigen Zugang auf die Administrationsschnittstelle der HSK-Instanz zu. Im Fall des eigenständigen Zugangs steuert der LE über das Nutzer-Portal des Zugangsmoduls welche Person/Organisation(DVO) auf seine Instanz zugreifen kann. Der DVO authentifiziert sich in jedem Fall direkt am Admin-Interface der HSK-Instanz.

Der LE/DVO nimmt die initiale Anbindung der HSK-Instanz an die LEI vor (Pairing der KTs und Konfiguration der Primärsysteme, beidseitige Authentisierung). Auch ein späteres Hinzufügen von neuen Primärsystemen hat stets einen lokalen Anteil auf Grund der notwendigen Konfiguration in Clientsystem und HSK-Instanz für die beidseitige Authentisierung und Zugriffssteuerung (Infomodell).

Der lokale Administrator kann fachliche Logs der HSK-Instanz einsehen.

Die Erreichbarkeit der Administrations-Schnittstelle der HSK-Instanz muss für den LE von seinen Systemen aus jederzeit gegeben sein. Dabei müssen zwei unabhängige Sicherungsschichten umgesetzt werden, eine für den Zugang zum Administrations-Interface und eine durch Authentisierung an der HSK-Instanz.
Eine Erreichbarkeit der fachlichen Schnittstellen (SOAP, LDAP, CETP, SICCT) über ein anders Netz bzw. einen anderen Zugang als den VPN-Zugang ist ausgeschlossen. Der Nutzer kann einem DVO den Zugriff auf die Administrationsschnittstelle seine HSK-Instanz auch jederzeit wieder über das Nutzer-Portal entziehen.

4.5 Remote-Administrator

Der Remote-Administrator übernimmt kontinuierliche Überwachungs- und Wartungsaufgaben. Der Remote-Administrator ist eine eingeschränkte Administrator-Rolle, die nicht über alle Rechte verfügt. Insbesondere kann der Remote-Administrator keine neuen Clientsysteme anlegen oder bestehende Clientsystem-Identitäten ändern. Dadurch ist ausgeschlossen, dass ein Remote-Administrator als Innentäter sich selbst als Clientsystem konfiguriert und somit dauerhaft remote mittels der Identität der jeweiligen LEI auf die TI und ihre Fachdienste zugreifen kann (bspw. ePA).

Der Remote-Administrator darf keinen Zugriff auf die SOAP/CETP-Schnittstellen haben (Ausschluss durch Netzwerk und/oder Authentifizierung)

Die Rolle entspricht dem bisherigen Remote-Administrator bei Einboxkonnektoren. Die Rolle ist optional.

4.6 Kunde - Leistungserbringer

Der Kunde, also der Leistungserbringer ist der Nutzer der fachlichen Schnittstellen(SOAP, LDAP, CETP, SICCT) einer konkreten HSK-Instanz und Inhaber einer SMC-B-Identität. Der Kunde hat Administrativen Zugang zu seiner HSK-Instanz.

Der Nutzer des Zugangsmoduls mit der Rolle Kunde

• bezieht ein Zugangsprofile zum TI-Gateway und
• vergibt/entzieht den Remote-Zugang zum Admin-Interface seiner HSK-Instanz für DVO.

Der Kunde hat einen Vertrag mit dem Anbieter des TI-Gateway und beauftragt ggf. einen DVO.

Weitere Rollen

Die Hersteller von anderen Komponenten (Intermediär, Zugangsmodul) haben abgesehen von ggf. Support für die von ihnen entwickelten Komponenten keine Rolle im Betrieb.

4.7 Rollenkombinationen & Rollenausschlüsse

Durch die Beschränkung der Rollen, die ein Mitarbeiter eines Anbieters TI-Gateway und seiner Unterauftragnehmer innehat, soll der Zugang zu medizinischen und personenbezogenen Versichertendaten verhindert werden.

Personen können mehrere der oben genannten Rollen ausführen. Folgende Rollen können dabei kombiniert werden

Abbildung 3: Szenarien mit erlaubten Rollenkombinationen

Die Einschränkung aus den obigen Anforderung muss vertraglich zwischen Anbieter und seinen Unterauftragnehmern festgelegt werden. Die Unterauftragnehmer müssen diese Einschränkung vertraglich mit ihren Mitarbeitern festlegen.

5 Spezifikation Zugangsmodul

5.1 Onboarding und Registrierung

Abbildung 4: Onboarding und Registrierung

Der Anwender soll von dem System durch den Registrierungs- und Onboardingprozess geführt werden. Der Prozess soll in der Regel ohne Intervention eines Administrators auf Seiten des TI-Gateways durchgeführt werden. Im Folgenden wird der Prozess exemplarisch beschrieben. Die Konkrete Umsetzung darf davon abweichen, solange die formulierten Anforderungen erfüllt werden. Die Automatisierung manueller schritte ist ausdrücklich erwünscht.

Der Reseller oder im Falle einer Selbstregistrierung der Leistungserbringer startet den Registrierungsprozess.

Der Leistungserbringer richtet eine Zwei-Faktor-Authentisierung (2FA) für seinen Zugang ein.

Nach erfolgreicher Registrierung erfolgt das Onboarding:

1. Das Onboarding-Modul löst am HSK-Server die Erzeugung einer HSK-Instanz aus. Darauf erhält das Onboarding-Modul die virtuelle IP-Adresse der HSK-Instanz und das initiale Admin-Passwort.

2. Das Onboarding-Modul generiert die benötigten VPN-Profile mit Credentials und der Inner-IP für die LE-Umgebung. Der LE wählt, ob er ein VPN-Profile für ein VPN-Gateway, mehrere VPN-Profile für Software-VPN-Clients auf verschiedenen Rechnern oder separate VPN-Profile für Kartenterminals benötigt.

3. Das Onboarding-Modul konfiguriert den VPN-Server und das Routing für diese LE-Umgebung zu der zugehörigen HSK-Instanz. Wenn ein über VPN angeschlossener DVO auf die HSK-Instanz zugreifen soll, gibt der LE diesen Netzwerkzugriff frei.

4. Der Nutzer oder sein DVO lädt die Zugangsdaten für die initiale Einrichtung aus dem Onboarding-Modul. Er richtet die lokale Umgebung inkl. des VPN-Clients ein. Über eine VPN-Kanal konfiguriert der DVO die HSK-Instanz. Dabei prüft der DVO zunächst das HSK-AK.AUT-Zertifikat. Anschließend ändert der DVO das Passwort zum Administrations-Zugang der Instanz, prüft auf ein "sauberes" ( = leeres) Informationsmodell und erzeugt oder importiert eine individuelle TLS-Identität für die Instanz, welche dann in den Clientsystemen verteilt wird. Somit kann später bei jeder Server-Authentifizierung konkret die Instanz der LEI verifiziert werden (statt nur der HSK). Ansätze zur Authentifizierung der konkreten HSK-Instanz über eigene AK.AUT-Identitäten pro Instanz sind ebenso zulässig. Der DVO richtet initial mindestens das Informationsmodell für ein Kartenterminal mit einer SMC-B ein.

5. Das Onboarding-Modul prüft die SMC-B (Nutzung SMC-B über KT und HSK-Instanz; ggf. lokale Onboarding-Softwarekomponente notwendig, welche die Aufrufe der Konnektor-Operation steuert). Im Falle einer gültigen SMC-B schaltet das Onboarding-Modul das Routing aus dem LE-Netz zu WANDA und offenen Fachdiensten frei.

5.1.1 Nutzerportal

Das Zugangsmodul kann eine lokale Softwarekomponente umfassen. Das Zugangsmodul interagiert mit dem HSK über einen technischen User mit der Rolle Zugangsmodul.

Informationen zu Biometrie-Klassen unter Android sind unter https://source.android.com/docs/compatibility/cdd zu finden.

Dies kann bspw. über ein registriertes E-Mail-Konto des Nutzers geschehen, sofern dieses in dem Sinne als dritter Faktor fungiert, also nicht bereits in die 2FA eingebunden ist und jeweils nur ein Faktor zurückgesetzt werden kann, also nicht beide gleichzeitig.

Die obige Anforderung zielt darauf ab, dass neue Nutzer vertrieblich qualifiziert werden, bevor sie Zugang zu einer HSK-Instanz bekommen. Damit soll ausgeglichen werden, dass die technische Berechtigungsprüfung mit der SMC-B erst später im Onboardingprozess erfolgen kann.

Als Variante zur Zustellung des VPN-Profiles über das Nutzerportal kann auch ein Provisionierungssystem angebunden werden, wenn z.B. vorkonfigurierte VPN-Gateway-Hardware zum Einsatz kommt. 

Für den Fall, dass seine VPN-Schlüssel korrumpiert wurden, gilt:

Es ist zulässig, dass DVOs über ein VPN an das TI-Gateway angeschlossen werden und nach Freigabe durch den LE als Administrator auf die HSK-Instanz des LE zugreifen. (Siehe 5.3 Routing und Firewall)

5.1.2 Initiale Authentifizierung der HSK-Instanz

Im Rahmen der Ersteinrichtung der HSK-Instanz muss sich der Nutzer bzw. der vom Nutzer beauftragte DVO bei der ersten Verbindung mit der Management-Schnittstelle davon überzeugen, dass er tatsächlich mit einem echten TI-Highspeed-Konnektor kommuniziert. Dafür muss die Authentizität des HSK über dessen TI-Identitäten (AK.AUT) geprüft werden. Hierbei kann eine HSK-weit genutzte Identität verwendet werden, diese muss also nicht Instanz-individuell sein. Erst dem Etablieren dieser Vertrauensbeziehung können nachfolgende Prüfschritte und die Ersteinrichtung stattfinden, wobei dann bspw. auch individuelle Identitäten und Zertifikate für spätere Verbindungen zur SOAP- und Management-Schnittstelle erzeugt werden.

Der einfachste Fall - wie er auch bei Einbox-Konnektoren vorliegt - ist ein über den Webbrowser bediente Administrations-GUI. Diese hat für die Zertifikatsprüfung den Nachteil, dass Webbrowser keine TI-Zertifikate positiv validieren. Im Falle von Einboxkonnektoren können entsprechende Warnungen des Browsers durch die manuelle Prüfung von im Browser anzeigbaren Zertifikatsdaten sowie vor allem die gleichzeitige Kontrolle über Konnektor, Netzwerk und Client akzeptiert werden. Dies ist beim TI-Gateway nicht möglich. Es ist ein essentieller Schritt bei der ersten Verbindung die Authentizität technisch vollständig zu prüfen.

Allein mit einem Webbrowser ist dies also beim TI-Gateway nicht möglich (oder nur höchst umständlich). Daher ist ein zusätzlicher Software-Client notwendig, der mindestens die Prüfung des TI-Zertifikats übernimmt und entweder weiter gefasst ist und auch die Management-GUI umfasst oder zumindest eine Validierung des anschließend im Browser mit einer Warnung angezeigten Zertifikats ermöglicht (Abgleich von Fingerprint des im Software-Client geprüften Zertifikats gegen den im Browser anzeigbaren Fingerprint). Letztere Variante ermöglicht anschließend eine Nutzung des Browsers für die Administration. In der Minimal-Version ist der Software-Client ein Kommandozeilen-Tool.

Sofern ein Browser involviert ist, sind die dadurch gegebenen Implikationen von Herstellern und Anbietern zu berücksichtigen, wie die in Webbrowsern nicht vorhandene Unterstützung von Zertifikaten und Schlüsseln, die auf Brainpool-Kurven basieren. Auch wenn nur einmalig bei der initialen Verbindung das C.AK.AUT in Zusammenspiel mit einem Webbrowser verwendet werden soll (weil anschließend Instanz-individuelle self-signed-Zertifikate erzeugt oder importiert werden), ist dies technisch nicht möglich, wenn das C.AK.AUT auf Brainpool-Kurven basiert.

Die geschilderte Prüfung der Authentizität gegen eine TI-Identität muss lediglich einmalig als initialer Schritt stattfinden. Über die so gebildete Vertrauensbeziehung ist die Erzeugung oder der Import individueller Nicht-TI-Identitäten möglich, wie es auch Einbox-Konnektoren heute schon unterstützen. Diese Identitäten können dann in Form von Allow-Listen in die genutzten Clientsysteme importiert werden, sodass spätere Authentifizierungen gegen diese Prüfbasis durchgeführt werden. Erzeugung und Import individueller Nicht-TI-Identitäten kann für eine einfache Handhabung in das Tool Integriert werden.

Grundsätzlich ergibt sich somit initial folgender Ablauf:

• Nutzer bzw. DVO (im Folgenden nur DVO) hat VPN-Profil, Inititial-Passwort und Software-Client heruntergeladen
• DVO hat den VPN-Client installiert / eingerichtet und den VPN-Tunnel aufgebaut
• DVO kennt IP-Adresse seiner HSK-Instanz und kann diese von seinem Clientystem aus über den VPN-Tunnel erreichen
• DVO nutzt den Software-Client, welcher parametrisiert mit der IP-Adresse der HSK-Instanz einen TLS-Verbindungsaufbau zur Management-Schnittstelle der Instanz durchführt und das C.AK.AUT prüft
• Der Software-Client gibt im Positiv-Fall das Prüfergebnis sowie den SHA-256 Wert des geprüften C.AK.AUT aus
• DVO verbindet sich über Webbrowser mit der HSK-Instanz
• Der Webbrowser gibt eine Warnung zur unsicheren Verbindung aus
• DVO lässt sich über die weiteren Informationen das Zertifikat und dort den SHA-256 Wert anzeigen
• DVO vergleicht die SHA-256 Werte und akzeptiert im Positiv-Fall die Verbindung im Browser
• Es findet die Ersteinrichtung unter Berücksichtigung weiterer Prüfungen im Webbrowser statt (siehe A_23340*).

Da der Software-Client die Zertifikatsprüfung durchführt, muss genau dieser Aspekt durch einen Gutachter technisch geprüft werden (A_23341*).

Für den Highspeed-Konnektor ist in diesem Zusammenhang A_23469* und A_23470* in Kapitel  zu beachten.

Die Internet-Schnittstelle des OCSP-Responders der Komponenten-CA für die RU/TU finden sich hier:

• RSA: http://download-testref.crl.ti-dienste.de/ocsp
• ECC: http://download-testref.crl.ti-dienste.de/ocsp/ec

Die oben in A_23340* dargestellten Prüfungen sind wie bereits zu Beginn des Abschnitts geschildert einmalig beim initialen Verbindungsaufbau durchzuführen. Anschließende Zertifikats-Prüfungen erfolgen gegen eine Allowlist wie im letzten Punkt von A_23340* beschrieben.

5.1.3 Betriebsfunktionen für den Leistungserbringer

Umgesetzt werden kann diese Anforderung über das Nutzer-Portal oder über eine lokale Softwarekomponente. Bei einer lokalen Softwarekomponente muss die Internet-Verfügbarkeit mit überwacht werden, um nicht die Verfügbarkeit der TI-Gateway Services zu verzerren. Verfügbarkeitsdaten werden vom HSK ermittelt und dem Zugangsmodul bereitgestellt (siehe A_23446).

5.2 VPN

Der VPN-Service des TI-Gateway-Zugangsmoduls ermöglicht es Leistungserbringerumgebungen eine VPN-Verbindung zum TI-Gateway aufzubauen. Es sind unterschiedliche VPN-Lösungen und -Clients erlaubt, solange sie den folgenden Sicherheits-Mindestanforderungen genügen.

Als VPN-Protokolle sind aktuell IPsec/IKEv2 oder WireGuard vorgesehen.

Andere Protokolle sind nicht grundsätzlich ausgeschlossen, müssen jedoch mit der gematik abgestimmt werden. In Bezug auf das WireGuard-Protokoll siehe auch:

• "Whitepaper Wire Guard" https://www.wireguard.com/papers/wireguard.pdf
• "Mechanised Cryptographic Proof" https://hal.inria.fr/hal-02100345v3/document 

Es kann für eine LEI sowohl eine VPN-Verbindung zu einem VPN-Router aufgebaut werden, als auch mehrere VPN-Verbindungen zu einzelnen Rechnern und Kartenterminals. Dabei müssen unterschiedliche VPN-Client-Identitäten zum Einsatz kommen.

Die Prüfbasis hängt vom gewählten Authentifizierungsverfahren ab: Schlüssel, Zertifikat, CA-Zertifikat...

Idealer Weise können bestehende Sicherheitsnachweis zum VPN-Client nachgenutzt werden.

5.3 Routing und Firewall

Einem Kunden können mehrere HSK-Instanzen zugewiesen werden, aber einer HSK-Instanz kann nur einem Kunden zugewiesen sein. Siehe auch A_23390

Für den Zugang zum Administrationsinterface sind zwei unabhängige Sicherungsschichten umzusetzen. Eine Schicht kontrolliert den Zugang zum Administrationsinterface, die zweite Schicht ist die Authentisierung an der HSK-Instanz.

5.4 Sicherheit & Datenschutz

Die eigentliche Gültigkeitsprüfung der SM-B wird durch den HSK durchgeführt (A_23444). Die Freischaltung der offenen Fachdienste und Wanda wird durch A_23243* geregelt.

Empfehlungen des BSI zur Abwehr von DDoS-Angriffen sind unter https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Gefaehrdungen/DDoS/ddos_node.html und Kriterien für entsprechende Dienstleister sind unter https://www.allianz-fuer-cybersicherheit.de/Webs/ACS/DE/Informationen-und-Empfehlungen/Informationen-und-weiterfuehrende-Angebote/Qualifizierte-Dienstleister/qualifizierte-dienstleister_node.html zu finden.

Auch aus per VPN angeschlossenen Netzen von Leistungserbringerinstitutionen sowie ggf. DVOs dürfen nur erlaubte Kommunikationen/Protokolle/Funktionen möglich sein. Insbesondere kann vor der Prüfung der SMC-B nicht sicher davon ausgegangen werden, dass tatsächlich Leistungserbringer über einen VPN-Kanal mit dem TI-Gateway interagieren.

Es ist weiterhin möglich, dass Leistungserbringer bspw. in Gemeinschaftspraxen oder einem MVZ eine einzige HSK-Instanz gemeinsam verwenden. In diesem Fall treten die Leistungserbringer gegenüber dem TI-Gateway-Anbieter als ein einziger Nutzer auf. Dies ist analog zur Nutzung eines Einbox-Konnektors mit einem VPN-Zugang durch mehrere Leistungserbringer, wobei diese ebenso gegenüber dem VPN-Zugangsdienst-Anbieter als ein Nutzer erscheinen.
Die Nutzung mehrerer Instanzen durch einen einzigen Nutzer ist problemlos, solange die Nutzung jeder Instanz entsprechend A_23390* exklusiv durch diesen Nutzer stattfindet.

Die Administration des Zugangsmoduls lässt somit nur den Import der Clientsystem-Credentials zu, nicht jedoch das Auslesen dieser.

Die gematik muss den Zugang von Leistungserbringerinstitutionen bspw. für den Fall der Verwendung veralteter, schwachstellenbehafteter Versionen anderer TI-Komponenten sperren lassen können, da solche Komponenten eine Bedrohung für die gesamte TI darstellen können.

5.5 Rohdaten-Performance-Reporting

in [gemSpec_Perf#2.5.2] Rohdaten-Performance-Reporting (Rohdatenerfassung v.02)

Tabelle 1 : Tab_gemSpec_Perf_Produkte_Rohdatenerfassung_Version_v02

Die Zuweisungen der Anforderungen zu dem Produkttypen TI-Gateway-Zugangsmodul sowie zu dem entsprechenden Anbietertypen werden wie folgt vorgenommen:

A_22057 - Performance - Rohdaten - Verpflichtung des Anbieters (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Anbietertyp: Anb_TI_Gateway - org./betriebl. Eignung: Prozessprüfung

A_22482 - Performance - Rohdaten - Erfassung von Rohdaten (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Test Produkt/FA

5.5.1 Umfang

A_22002 - Performance - Rohdaten - Übermittlung (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Test Produkt/FA

A_22000 - Performance - Rohdaten - zu liefernde Dateien (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Test Produkt/FA

A_22429 - Performance - Rohdaten - Inhalt der Selbstauskunft (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Test Produkt/FA

A_22004 - Performance - Rohdaten - Korrektheit (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Test Produkt/FA

A_22005 - Performance - Rohdaten - Frist für Nachlieferung (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Herstellererklärung

A_22003-01 - Performance - Rohdaten - Nachlieferung auf Anforderung (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Anbietertyp:  Anb_TI_Gateway - org.-betr.: Anbietererklärung

A_22996 - Performance - Rohdaten - Zeitpunkte der Übermittlungen (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Anbietertyp:  Anb_TI_Gateway - org.-betr.: Anbietererklärung

5.5.2 Lieferintervalle

A_21976 - Performance - Rohdaten - Konfigurierbarkeit der Lieferintervalle (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Test Produkt/FA

A_22047 - Performance - Rohdaten - Änderung der Konfiguration der Lieferintervalle (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Test Produkt/FA

A_22620 - Rohdaten - Umsetzungszeit für Änderung der Lieferintervalle

hinzufügen der Zuordnung zu Anbietertyp: Anb_TI_Gateway - org.-betr.: Anbietererklärung

A_21978 - Performance - Rohdaten - Trennung der Lieferintervalle (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Herstellererklärung

A_21975 - Performance - Rohdaten - Default-Werte für Lieferintervalle (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Test Produkt/FA

A_21979 - Performance - Rohdaten - Bezug der Lieferverpflichtung (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Herstellererklärung

A_21980 - Performance - Rohdaten - Leerlieferung (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Test Produkt/FA

5.5.3 Format

A_22001-01 - Performance - Rohdaten - Name der Berichte (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Test Produkt/FA

A_21981-02 - Performance - Rohdaten - Format des Rohdaten-Performance-Berichtes (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Test Produkt/FA

A_22500-01 - Performance - Rohdaten - Status-Block (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Test Produkt/FA

A_21982-01 - Performance - Rohdaten - Message-Block (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul - funkt. Eignung: Test Produkt/FA

A_22513-01 - Performance - Rohdaten - Message-Block im Fehlerfall - JSON (Rohdatenerfassung v.02)

hinzufügen der Zuordnung zu Produkttyp: TI-Gateway-Zugangsmodul- funkt. Eignung: Test Produkt/FA

Neue Anforderungen in Kapitel "3.x.2.2 Format"

Tabelle 2: Tab_gemSpec_Perf_Berichtsformat_TI-Gateway-Zugangsmodul

5.6 Lastanforderungen

6 Änderungen am Highspeed-Konnektor

Es sind Anpassungen am Produkt Highspeed-Konnektor notwendig, damit dieses innerhalb eines TI-Gateways verwendet werden kann. Entsprechend ist nachzuweisen, dass eine für die Verwendung im TI-Gateway vorgesehene Produkttypversion durch die genutzten HSKs umgesetzt ist.

Es sind Anpassungen an den Administratorrollen des HSK notwendig. Konkret ersetzt die folgende beiden Anforderung die Anforderungen A_21882 und A_21883 [gemF_Highspeed-Konnektor] für einen HSK, der innerhalb eines TI-Gateway genutzt wird.

Da Updates des HSK (und somit auch der HSK-Instanzen) global durch den Anbieter des TI-Gateway durchgesetzt werden, bezieht sich die Konfiguration zum Auto-Update rein auf die Kartenterminals. Es kann weiterhin innerhalb jeder einzelnen Instanz durch den Nutzer festgelegt werden, wann automatische Updates der Kartenterminals durchgeführt werden.

Um den Zugang von HSK-Instanzen zur TI auf Institutionen mit gültiger SMC-B zu beschränken, wird nachfolgende Funktionalität neu eingeführt.

Hinweis zum Datenschutz: Der nutzende Leistungserbringer muss mit Vertragsabschluss einwilligen, dass die Daten über seine HSK-Instanzen zugreifbarer  SMC-B im TI-Gateway verarbeitet werden und dem Portal-Nutzer der zugeordneten HSK-Instanzen angezeigt werden. Die Daten anderer Karten dürfen vom HSK nicht an das Zugangsmodul gesendet werden.

Durch die obige Anforderung soll die Last auf den zentralen Diensten KSR, NTP und Namensdienst begrenzt werden.

6.1 HTTP-Forwarder

Der HSK muss auf Ebene des Basissystems oder als vorgelagerte Komponente einen http-Forwarder bereitstellen.

Der http-Forwarder dient zur Erschwerung einer Profilbildung unter Ausnutzung von Informationen aus OCSP-Anfragen und der IP-Adresse der HSK-Instanzen. Hierfür fungiert diese Komponente in der Funktion eines http-Forwarding-Proxy, der an ihn gerichtete OCSP-Anfragen an die entsprechenden OCSP-Responder weiterleitet sowie die zurückgelieferten OCSP-Antworten an den Absender sendet.

6.2 Anforderungen an den Hersteller des HSK

7 Anforderungshaushalt TI-Gateway

Dem Anbietertyp TI-Gateway sind Betriebliche Anforderungen aus den Spezifikationen gemSpec_DS_Anbieter, gemRL_Betr_TI, gemKPT_Betr, gemKPT_Test, gemSpec_Perf, gemSpec_Krypt und gemSpec_Net zugewiesen.

7.1 Neue Anforderungen

7.1.1 Anbietererklärung

Auf Grund der Informationsflüsse ist es sinnvoll das KIM-Clientmodul in das TI-Gateway zu Integrieren.

7.1.2 Sicherheitsgutachten

Es sind wie beschrieben Konstellationen möglich und zulässig, bei denen ein Anbieter TI-Gateway nicht selbst alle Anforderungen erfüllt, sondern in der Zusammenarbeit zwischen Reseller und Infrastrukturbetreiber Anforderungen von einer Partei erfüllt und nachgewiesen werden und von der anderen Partei dies im Rahmen der Anbieterzulassung nachgenutzt wird. Es muss jedoch stets nachgewiesen werden, dass in Summe alle Anforderungen erfüllt sind und keine Lücken durch gegenseitige Verweise auf die Verantwortung des anderen entstehen.

Die geeignete und robuste technische Umsetzung obliegt dem Anbieter (Firewalls, VLANs).

Der Anbieter muss dabei berücksichtigen, dass sowohl Bestandskunden, als auch Neukunden, deren SMC-B noch nicht geprüft wurde, möglicherweise ein Angreifer sind.

Der Hersteller muss die für sein Produkt erforderlichen Protokolle angeben wie in TIP1-A_4340-01.

7.2 Betrieb

7.2.1 Servicezerlegung

7.2.2 Mitwirkungsverpflichtung im TI-ITSM gemäß [gemRL_Betr_TI]

Tab_KPT_Betr_TI_003 Mitwirkungsverpflichtung im TI-ITSM 

Legende:

INC: Incident Management

PRO: Problem Management

CHG: Change Management

SKM: Servicekatalog Management

SLM: Service Level Management

RF: Request Fulfillment

Perf: Perfomance Management

CapM: Capacity Management

KM: Knowledge Management

CSI: Continual Service Improvement

CM: Configuration Management

NF: Notfall Management

A: Auslöser in INC, PRO, CHG

Auslöser (A) ist, wer Incidents, Problems oder Changes eröffnet.

E: Empfänger von INC, PRO, CHG

Empfänger (E) ist wer Incidents, Problems oder Changes zugewiesen bekommt und dessen vollständige Mitarbeit gewährleistet ist.

Auslöser und Empfänger im SKM

Auslöser (A) ist, wer Änderungen im Service Katalog Management einbringt.

Empfänger (E) ist, wer Änderungen im Service Katalog Management aufnimmt.

Portalanbieter (P) ist, wer das TI-Service-Portal zur Verfügung stellt und selbst Nutzer ist.

A/E: Auslöser und Empfänger im SLM

Auslöser (A) ist, wer Änderungen im Servicelevel Management einbringt.

Empfänger (E) ist, wer im Servicelevel Management an Servicelevel-Reviews teilnimmt.

A/E: Auslöser und Empfänger im RF

Auslöser (A) ist, wer Services bei anderen Anbietern abruft.

Empfänger (E) ist, wer einen Servicekatalog führt und Services anbietet.

A/E: Auslöser und Empfänger im Perf

Auslöser (A) ist, wer Performancereports bzw. Rohdaten-Performance-Berichte sendet.

Empfänger (E) ist die gematik.

A/E: Auslöser und Empfänger im CapM

Auslöser (A) ist, wer Kapazitätspläne führt und reportet.
Empfänger (E) ist die gematik (GTI).

A/E: Auslöser und Empfänger im KM

Auslöser (A) ist, wer Artikel in der Wissensdatenbank einstellt.

Empfänger (E) ist, wer Artikel aus der Wissensdatenbank bezieht.

A/E: Auslöser und Empfänger im CSI

Auslöser (A) ist, wer ein CSI-Register führt und reportet.
Empfänger (E) ist die gematik (GTI).

A/E: Auslöser und Empfänger im CM

Auslöser (A) ist, wer Reports sendet, in denen die Konfigurationen der verwendeten Produkte dargestellt werden.

Empfänger (E) ist, wer Konfigurationsvorgaben und deren Umsetzung dar z.B. im Zuge eines CRs oder Changes empfängt und umsetzt.

A/E: Auslöser und Empfänger im NM

Aktiv (A) ist, wer im Notfall zuarbeiten und unterstützen muss.

Empfänger (E) stellen einen Notfall-Ansprechpartner bereit.

7.2.3 Spezifische Ausprägungen und Verpflichtungen einzelner Rollen

Tab_KPT_Betr_Betriebliche Rolle_Anbieterkonstellationen

Anbieter TI-Gateway

Für die Anbieter TI-Gateway gelten die Konstellationen gemäß [gemKPT_Betrieb#3.4.4] abschließend. Der Anbieter kann sich zwischen diesen Konstellationen entscheiden und den Betrieb entweder selbst organisieren und alle Anforderungen des Anbietertypsteckbriefes selbst erfüllen. Alternativ kann er sich bereits im Zulassungsverfahren durch einen Unterauftragnehmer vertreten lassen und sich somit für die Konstellation II oder III entscheiden. Mit Abschluss des Zulassungsvertrages/Zulassungsbescheides verpflichtet sich dann der Anbieter sicherzustellen, dass sein Unterauftragnehmer gegenüber der gematik zur Abgabe aller erforderlichen Erklärungen sowie zur Durchführung aller tatsächlichen Handlungen berechtigt und verpflichtet ist, soweit diese zur Erbringung der Betriebsleistung erforderlich sind.

Die Veröffentlichung dieser Informationen durch den Anbieter kann über unterschiedliche Portale erfolgen, wie z.B. eigene Support-Portale oder die TI-Wissensdatenbank. Zielgruppe für die veröffentlichten Informationen sind sowohl die Leistungserbringer selbst als auch deren betreuende IT-Dienstleister.
Mit diesen Informationen sollen die lokalen Firewalls in den dezentralen Umgebungen der Leistungserbringer möglichst restriktiv konfiguriert werden können. Zeitgleich soll damit eine fehlerfreie Kommunikation von dezentral mit der TI über Ihr TI-Gateway sichergestellt werden.

7.2.4 Supportkonzept

7.2.4.1 Spezifische Ausprägungen

Tab_KPT_Betr_TI_Anbieter_UHD/VHD

Der Anbieter TI-Gateway stellt seinen Anwendern (Leistungserbringern) einen UHD zur Verfügung.

Spezifische Ausprägungen Anbieter TI-Gateway

7.2.4.2 Organisatorische Service Level

Tabelle x: Tab_gemKPT_Betr_OrgSL_Serviceleistung_Zeiten

Sind SL nur der Hauptzeit (H) zugeordnet, so kann die Bearbeitung in der Nebenzeit unterbrochen werden und wieder in der Hauptzeit aufgenommen werden. Die Einhaltung dieses SL wird nur in der Hauptzeit gemessen.

7.2.4.3 Technische Service Level / Performance-Kenngrößen

Anwendung Anwendung TI-Gateway-Zugangsmodul (PDT72)

Schnittstellen::Operation bzw. Anwendungsfall

Tab_gemKPT_Betr_TI-Gateway-Zugangsmodul_Operationen/Anwendungsfälle

Performance-Kenngrößen / SL-Werte

Der Erfassungszeitraum für die aufgeführten Soll-Werte beträgt ein Kalendermonat.

<< Standardsatz von Performance-Kenngrößen. Nicht verwendete bitte streichen. >>

Tab_gemKPT_Betr_TI-Gateway-Zugangsmodul_Performance-Kenngroessen

Tab_gemKPT_Betr_TI-Gateway-Zugangsmodul_Performance-Kenngroessen_Bildungsregeln

7.2.5 gemKPT_Betr: Anhang A

Tab_gemKPT_Betr_Produkttypen

7.2.6 gemSpec_Perf#3.x.1 Leistungsanforderungen TI-Gateway

7.2.6.1 gemSpec_Perf#3.x.1.1 Lastmodell TI-Gateway

keine Spezifischen Anforderungen zum Lastmodell

7.2.6.2 gemSpec_Perf#3.x.1.2 Bearbeitungszeiten TI-Gateway

keine Spezifischen Anforderungen zu Bearbeitungszeiten

7.2.6.3 gemSpec_Perf#3.x.1.3 Performancevorgaben TI-Gateway

Messung der Verfügbarkeit:

Die Messung könnte z.B. durch eine lokale Softwarekomponente des Zugangsmoduls erfolgen. Für Testaufrufe muss sich eine solche Probe authentifizieren und korrekte Context-Parameter verwenden.

Im Zuge des Zulassungsverfahrens hat der Anbieter des TI-Gateways der gematik gegenüber nachvollziehbar darzustellen, welche technischen Skalierungsmaßnahmen anhand welcher messbarer Parameter er für den Produktivbetrieb plant durchzuführen. Die Skalierungsmaßnahmen können dabei unterschiedliche Ausprägungen und Dimensionen umfassen. Beispielsweise eine automatisierte Ressourcenzuteilung oder eine Anpassung oder Änderung unterschiedlicher technischer Komponenten, die zu einer Produktänderung im Sinne der [gemSpec_OM] führt. Die Darstellung muss Verifikationsbeschreibungen enthalten, mit denen der Erfolg der Maßnahmen ermittelt werden kann.

8 Änderungen an gemILF_PS

Zertifikatsbasierte Clientsystemauthentifizierung muss jetzt vom Primärsystem unterstützt werden.

9 Beispiele und Referenzimplementierungen

<Optional: Beispiele für Aufrufsequenzen, ausgetauschte Daten, etc. zur Unterstützung der Implementierung>

10 Anhang A – Verzeichnisse

10.1 Abkürzungen

10.2 Referenzierte Dokumente

10.2.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

10.2.2 Weitere Dokumente