User Stories Versicherte

Zusammenfassung

Der Versicherte soll...

...sich selbst mit seiner Gesundheits-ID ein Konto einrichten können.

...sein Nutzerkonto wieder selbständig löschen oder eine Sperrung/Löschung in Auftrag geben können.

...sein Gerät möglichst einfach an der App registrieren und verwalten können.

...mit verschiedenen Frontends auf sein Nutzerkonto im Fachdienst zugreifen können.

Details

Als Versicherter 16+ möchte ich mein Nutzerkonto jederzeit einfach selbst einrichten können, um möglichst aufwandsarm die E-Rechnung nutzen zu können.

Als Versicherter 16+ möchte ich bei der Einrichtung oder Neueinrichtung eines FdV (z.B. Wechsel der App) mein bereits bestehendes Nutzerkonto verwenden können, um weiterhin auf meine bereits vorhandenen Daten zugreifen zu können.

Als Versicherter 16+ möchte ich mich unter Nutzung meiner Gesundheits-ID und der zugehörigen Authentisierungslösung meiner Krankenversicherung (z.B. Authenticator-App) am Fachdienst E-Rechnung anmelden können, um unabhängig von dem von mir genutzten E-Rechnung FdV meine Gesundheits-ID für die Anmeldung nutzen zu können. Hinweis: Dies zielt insbesondere auf die Nutzung einer Authenticator-App ab, die nicht dem E-Rechnung FdV entspricht.

Als Versicherter 16+ möchte ich mit verschiedenen FdV (z.B. App und Web-Portal) auf mein Nutzerkonto zugreifen können, um nicht an ein bestimmtes FdV gebunden zu sein.

Als Versicherter 16+ möchte ich mich jederzeit mit dem FdV vom Fachdienst E-Rechnung abmelden können, um meine Nutzer-Sitzung gezielt beenden zu können.

Als Versicherter 16+ möchte ich mein Nutzerkonto mit allen mich betreffenden Daten (inklusive Berechtigungen) jederzeit löschen können, um mein Recht auf informationelle Selbstbestimmung ausüben zu können.

Als Versicherter 16+ möchte ich mein Nutzerkonto jederzeit sperren oder auch löschen lassen können, um bei Verdacht auf Kompromittierung meines Nutzerkontos einen unautorisierten Zugriff auf meine Daten unterbinden zu können.

Gerätverwaltung

Als Versicherter möchte ich meine erste App mit meiner GesundheitsID und einem mir per Brief, Email, Anruf, SMS oder Push-Nachricht zugestellten Aktivierungscode nutzerfreundlich registrieren.

Als Versicherter möchte ich von meiner App bei der App- bzw. Geräteregistrierung und Verwaltung mittels Guide, Tutorial oder Wizard unterstützt werden.

Als Versicherter möchte ich in meiner App eine Übersicht aller von mir registrierten Apps und Geräte einsehen und Apps einzeln de-registrieren können.

Als Versicherter möchte ich in meiner App den App-Namen und den App-Hersteller erkennen können.

Als Versicherter möchte ich eine neue App registrieren können, indem ich eine bereits registrierte App für den Empfang des Aktivierungscodes verwende.

Als Versicherter möchte ich per Email, SMS, Anruf oder Push-Nachricht informiert werden, sobald eine Änderung an meiner Liste der registrierten Apps stattgefunden hat. 

Als Versicherter möchte ich in meiner App Einblick in das Zugriffsprotokoll meiner Geräteverwaltung nehmen können. 

Gestaltung der Architektur gemäß Zero Trust Ansatz

Die Internet-Schnittstellen der eRg für die Versicherten werden nach Prinzipien der Zero Trust Architektur abgesichert. Die Zero Trust Architektur für eRg zeichnet sich durch folgende Eigenschaften aus:

Registrierung der Clients

Der Begriff Client umfasst hier das vom Versicherten genutzte Endgerät (Client-Gerät) inklusive der darauf verwendeten Software, mit dem der Versicherte auf die Internet-Schnittstellen des eRg FD zugreift. Die Clients müssen im ersten Schritt einmalig durch ihre Nutzer registriert werden. Durch die Registrierung wird auf dem Client-Gerät eine Hardware-gebundene kryptografische Identität erzeugt, die beim nachfolgenden Zugriff auf die Schnittstellen verwendet wird. Diese Client-Identität ist an die Identität des Endanwenders gebunden. Auf diese Weise können die Endanwender kontrollieren, mittels welcher Clients mit ihrer Identität auf die eRg zugegriffen werden kann. Es wird damit ein kryptographischer Vertrauensraum für die eRg geschaffen, in dem nur bekannte Clients zugelassen sind. Die Registrierung erfolgt über den Geräte Management Service (GMS).

Attestation der Geräteeigenschaften

Für die Clients, die in der ersten Ausbaustufe der Lösung als mobile Apps entwickelt werden, muss eine Attestation der Geräteeigenschaften erfolgen. Zum Schutz der Nutzerdaten wird so sichergestellt, dass nur Geräte genutzt werden, die bestimmten Sicherheitsanforderungen entsprechen. Die Attestation erfolgt mit Hilfe der Plattformservices von Apple (App Attest API) und Google (Key & ID Attestation, Play Integrity API). Die Attestation Reports der Plattformanbieter werden durch den GMS auf Authentizität & Integrität geprüft. Der GMS erzeugt auf Basis der Reports interoperable Geräte-Token, die durch den eRg FD abgerufen werden. Falls die Geräteeigenschaften nicht attestiert werden können oder die attestierten Eigenschaften nicht den Mindestanforderungen entsprechen, wird entweder der Zugriff auf die eRg verweigert oder es werden zusätzliche Schritte zur Feststellung der Identität des Zugreifenden (bspw. kartenbasierte Authentifizierung) durch die Fachanwendung gefordert.

Dezentralisierte Zugriffsentscheidungen

Die Zugriffsentscheidungen in der TI Zero Trust Architektur werden dezentral durch die Fachanwendungen getroffen. Sie werden durch maschinell auswertbare Sicherheitsrichtlinien (Policy, siehe nächster Punkt) gesteuert. Hierfür werden im Aufbau der eRg die logischen Komponenten Policy Decision Point und Policy Enforcement Point als Teil des Autorisierungsdienstes bzw. Anwendungsdienstes umgesetzt. 

Bereitstellung einer maschinell interpretierbaren Policy durch die gematik

Für die eRg wird die Policy durch die gematik in einem maschinenlesbaren Format bereitgestellt. Hierfür werden mit dem Open Policy Agent (siehe [Open Policy Agent]) kompatible Policy Bundles verwendet. Die Policy Bundles werden durch die gematik erstellt und signiert. Die eRg muss regelmäßig prüfen, ob aktualisierte Policy Bundles vorliegen.

Autorisierungsdienst

Der Autorisierungsdienst benötigt zur Vergabe eines Access Tokens stets Identitätsattribute des Nutzers. Diese bezieht er vom jeweiligen Identity Provider. Darüber hinaus erfolgt die Gewährung des Zugriffs durch den Autorisierungsdienst bei den verschiedenen Nutzergruppen und deren Client-Systemen auf unterschiedliche Weise:

Institutionen

Hier verwendet der Autorisierungs-Dienst alleine das seitens des zentralen IDP bereitgestellte ID-Token, unter Verwendung der SMC-B (oder HSM-B) als Authentisierungsmittel (Nutzung als "Smartcard IDP").

Versicherte

Hier wird eine Autorisierung nach den Prinzipien von Zero Trust umgesetzt.

Bei beiden Nutzergruppen prüft der Autorisierungsdienst ggf. ergänzende, anwendungsspezifische Bedingungen, sofern diese nicht über den Autorisierungsdienst und die Sicherheitsrichtlinien abgedeckt sind.

Der Autorisierungsdient setzt somit Funktionen des Policy Decision Points um, denn er trifft auf Basis der genannten Informationen die abschließende Entscheidung, ob und in welchem Umfang eine angeforderte Zugriffsberechtigung gewährt wird.

Nur wenn alle erforderlichen Voraussetzungen gegeben sind, stellt der Autorisierungsdienst dem Client-System ein Access Token entsprechend den angeforderten Zugriffsberechtigungen bereit. Der Autorisierungsdienst setzt somit - im Zusammenspiel mit dem Anwendungsdienst, der die Token prüft - einen Teil des Policy Enforcement Points um.

Kostenträger

Als Institution möchte ich mein Nutzerkonto jederzeit selbst einrichten können, um möglichst einfach die E-Rechnung in Benutzung nehmen zu können.

Als Institution möchte ich mich unter Verwendung meiner digitalen ID für Institutionen mittels des zugehörigen Identity Providers am Fachdienst E-Rechnung anmelden können, um meine vorhandene digitale Identität für die Anmeldung nutzen zu können.

Ausbaustufe: 
Aktuell ist hier die Verwendung der SMC-B für Leistungserbringer-Institutionen, Abrechnungsdienstleister (SMC-B Org) bzw. Kostenträger (SMC-B KTR) vorgesehen, in Verbindung mit dem zentralen IDP der gematik. In einer zukünftigen Ausbaustufe werden die spezifischen IDPs der jeweiligen Nutzergruppe verwendet werden.

Als Institution möchte ich mich jederzeit vom Fachdienst E-Rechnung abmelden können, um meine Nutzer-Sitzung gezielt beenden zu können.

Als Institution möchte ich mein Nutzerkonto jederzeit sperren oder auch löschen lassen können, um bei Verdacht auf Kompromittierung meines Nutzerkontos einen unautorisierten Zugriff auf Daten unterbinden zu können oder um die Nutzung der E-Rechnung aus anderen Gründen beenden zu können.

Als Kostenträger möchte ich ergänzende Informationen meinem Nutzerkonto zuordnen können, die versicherte Nutzer (Versicherte 16+) einsehen können, um diesen bei Fragen zur Einreichung oder Leistungsabrechnung eine Hilfestellung, einen Kontaktweg oder sonstige weiterführende Informationen bereitzustellen.

Zugang zum Fachdienst in der TI

Der Zugang für die Nutzergruppen und die von ihnen genutzten Clientsysteme wird auf unterschiedliche Weise umgesetzt:

Institutionen (Rechnungsersteller und Kostenträger (KTR))

Diese müssen über einen sicheren Zugang zur Telematikinfrastruktur (TI) verfügen - d.h. der Zugriff muss gemäß TI 1.0 über eine Anbindung an das zentrale Netz mittels zugelassener dezentraler Komponenten erfolgen:

Für die Anwendung E-Rechnung (eRg) ist kein Fachmodul für den Konnektor oder den Basis/KTR-Consumer vorgesehen. Der Fachdienst E-Rechnung (eRg FD) ist somit ein offener Fachdienst gemäß der Systematik der TI 1.0.

Versicherte

Der Zugriff erfolgt über das Internet, hier erfolgt eine Absicherung nach Zero Trust Ansatz, siehe nächster Abschnitt.