latest

Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature:

TI-Gateway

    

     

      
Version
      
1.3.0
     
     

      
Revision
      
857709
     
     

      
Stand
      
23.02.2024
     
     

      
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. 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 nach 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 eine ü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, Initial-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 Clientsystem 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 [gemF_Highspeed-Konnektor] 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 Protokolle sind aktuell IPsec/IKEv2, TLS und 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 Sicherheitsnachweise zum VPN-Client nachgenutzt werden.

5.3 Routing und Firewall

Einem Kunden können mehrere HSK-Instanzen zugewiesen werden, aber eine 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

verschoben nach [gemSpec_Perf::2.5.2 Rohdaten-Performance-Reporting (Rohdatenerfassung v.02)]

5.5.1 Umfang

verschoben nach [gemSpec_Perf::2.5.2.1 Umfang]

5.5.2 Lieferintervalle

verschoben nach [gemSpec_Perf::2.5.2.2 Lieferintervalle]

5.5.3 Format

verschoben nach [gemSpec_Perf::2.5.2.3 Format]

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

verschoben nach [gemSpec_Perf::2.5.2.2 Format]

5.6 Lastanforderungen

verschoben nach [gemSpec_Perf::3.10.1.3 Performancevorgaben TI-Gateway]

6 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.

6.1 Neue Anforderungen

6.1.1 Anbietererklärung

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

6.1.1.1 Anbindung an das Transportnetz Internet

6.1.1.2 Anbindung an die TI

Der SZZP übernimmt die Sicherheitsleistung für diese Anbindung (siehe [gemSpec_Net]).

6.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.

6.2 Betrieb

6.2.1 Servicezerlegung

verschoben nach [gemKPT_Betr::3.5.2 Servicezerlegung]

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

verschoben nach [gemKPT_Betr::3.5.3 Mitwirkungsverpflichtung im TI-ITSM gemäß [gemRL_Betr_TI]]

6.2.3 Spezifische Ausprägungen und Verpflichtungen einzelner Rollen

verschoben nach [gemKPT_Betr::3.4.4 Spezifische Ausprägungen und Verpflichtungen einzelner Rollen]

6.2.4 Supportkonzept

6.2.4.1 Spezifische Ausprägungen

verschoben nach [gemKPT_Betr::3.6.3 Spezifische Ausprägungen]

6.2.4.2 Organisatorische Service Level

verschoben nach [gemKPT_Betr::5.2.2 Spezifische Ausprägungen]

6.2.4.3 Technische Service Level / Performance-Kenngrößen

verschoben nach [gemKPT_Betr::5.3.2.13 TI-Gateway-Zugangsmodul (PDT72)]

6.2.5 gemKPT_Betr: Anhang A

verschoben nach [gemKPT_Betr::7.1.1 Produkttypen (PDT-IDs)]

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

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

verschoben nach [gemSpec_Perf::3.10.1.3.1 Lastmodell TI-Gateway]

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

verschoben nach [gemSpec_Perf::3.10.1.3 Bearbeitungszeiten TI-Gateway]

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

verschoben nach [gemSpec_Perf::3.10.1.3 Performancevorgaben TI-Gateway]

6.2.7 Zugang und Verfügbarkeit

Für die Ermittlung der Verfügbarkeit des Anbieter TI-Gateway ist es erforderlich, dass die gematik eine Möglichkeit zum Probing des TI-Gateways erhält. Das Probing wird realisiert durch den Abruf der connectors.sds einer für diesen Zwecke bereitgestellten virtuellen HSK-Instanz alle 5min. Diese vHSK-Instanz wird nicht mittels einer SMC-B für den Zugang zur TI freigeschaltet.

7 Änderungen an gemILF_PS

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

8 Beispiele und Referenzimplementierungen

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

9 Anhang A – Verzeichnisse

9.1 Abkürzungen

9.2 Referenzierte Dokumente

9.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.

9.2.2 Weitere Dokumente