Elektronische Patientenakte gemäß 291a SGB V. Sicherheitsarchitektur Spezifikation der Sicherheitsdienste. Version 1.0

Transkript

1 Elektronische Patientenakte gemäß 291a SGB V Sicherheitsarchitektur Spezifikation der Sicherheitsdienste Version 1.0

2

3 Projekt Elektronische Patientenakte gemäß 291a SGB V Sicherheitsarchitektur: Spezifikation der Sicherheitsdienste Ergebnisdokument 2012 Autoren Levona Eckstein, Fraunhofer SIT Raik Kuhlisch, Fraunhofer FOKUS Thomas Kunz, Fraunhofer SIT Olaf Rode, Fraunhofer FOKUS Ursula Viebeg, Fraunhofer SIT Jörg Caumanns, Fraunhofer FOKUS Ben Kraufmann, Fraunhofer FOKUS

4

5 Inhalt 1 Einleitung Abgrenzung Inhalt Verwandte Dokumente Verwendung von Schlüsselwörtern Konventionen 3 2 Kernkonzepte Architekturüberblick Fachdienste epa-kommunikationskomponente LE-Postfach-Komponente Föderiertes Vertrauen Föderiertes Identitätsmanagement Vertrauens- und Kommunikationsbeziehungen Generisches Schnittstellen-Design Deklarative Sicherheit Aufbau sicherer Session-orientierter Kommunikationskanäle Policy- und Attribute Supply-Modelle Genutzte Standards und Profile X.509-basierte Public-Key-Infrastruktur (PKIX) Security Assertion Markup Language (SAML) Web Services Security (WS-Security) Web Services Trust Language (WS-Trust) WS-SecurityPolicy WS-SecureConversation extensible Access Control Markup Language (XACML) 23 3 Zugriffsszenarien und Abläufe Grundannahmen und Prinzipien Zugriffsszenarien Standardabläufe Asynchrones Anfordern von Daten aus einer Komfortakte Asynchrones Bereitstellen von Daten für eine Komfortakte Synchrones Anfordern von Daten aus einer Basisakte Synchrones Bereitstellen von Daten für eine Basisakte 43 4 SAML Assertions 47

6 4.1 Motivation Assertion-Typen Guarantor Assertion Identity Assertion Access Assertion Struktur der SAML Assertions 56 5 Sicherheitsdienste Grundannahmen Sicherheitstoken Guarantor Token Service Einbettung von Attributen in die Guarantor Assertion Identity Provider (IdP) Aufbau eines sicheren Kommunikationskanals Authentisierung Einbettung von Attributen in den Authentisierungsnachweis Access Token Service 72 6 Sicherung von Fachdiensten Grundannahmen epa-kommunikationskomponente Aufbau eines sicheren Kommunikationskanals Sicherung der Fachoperationen LE-Postfach Aufbau eines sicheren Kommunikationskanals Sicherung der Fachoperationen 78 7 Verschlüsselung von Dokumenten 79 8 Abkürzungsverzeichnis 81 9 Literaturverzeichnis 83 A SAML Assertion-Profile 87 A.1 Allgemeine Festlegungen 87 A.2 Guarantor Assertion 88 A.3 Identity Assertion 89 A.4 Access Assertion 91 B Beispiele für SAML Assertions (nicht normativ) 93 B.1 Guarantor Assertion 93 B.2 Identity Assertion (Szenario: HBA-basierte Authentisierung) 94 B.3 Access Assertion 96

7 C Vorgaben zur Ausgestaltung von XACML Policies 99 D E Attributkatalog für SAML Assertions (nicht normativ) 101 Standardreferenzen für Access Policies (exemplarisch) 103 F SAML Assertion-Validierung (informativ) 105

8

9 1 Einleitung Das vorliegende Dokument beschreibt die Sicherheitsarchitektur der elektronischen Patientenakte gemäß 291a SGB V (epa-291a). Es werden technische Konzepte und Mechanismen dargestellt, die geeignet sind, Integrität, Vertraulichkeit und Authentizität der über die Leistungserbringer-Schnittstelle (LE- Schnittstelle) ausgetauschten Daten umfassend sicherzustellen. In diesem Zusammenhang kommt insbesondere der Beschreibung von Sicherheitsdiensten und Sicherheitsnachweisen sowie deren Verwendung zur Sicherung der in der Facharchitektur beschriebenen Fachdienste eine besondere Bedeutung zu. 1.1 Abgrenzung Die beschriebenen Konzepte und Mechanismen adressieren primär die Anforderungen, die sich aus der direkten Nutzung der epa-291a über die LE-Schnittstelle (vgl. das Dokument [FuE-ePA-Facharchitektur]) ergeben. Sowohl die Absicherung der Zugriffe auf die Patientenakte über die Bürger- Schnittstelle als auch über eine spezielle Administrationsschnittstelle wird NICHT betrachtet. Innerhalb des Projekts werden ausschließlich generische (Sicherheits-)Anforderungen für diese Schnittstellen erhoben. Die spezifische Umsetzung dieser Anforderungen und somit auch die konkrete Ausgestaltung der entsprechenden Schnittstelle obliegen allein dem Aktenanbieter. Die Protokollierung von Zugriffen liegt ebenfalls außerhalb des Fokus dieses Dokuments. 1.2 Inhalt Das vorliegende Dokument gliedert sich in die folgenden Kapitel: Kapitel 2 beschreibt Kernkonzepte, die einen wesentlichen Einfluss auf die konkrete Ausgestaltung der Sicherheitsarchitektur besitzen. Die Schwerpunkte der Darstellung liegen in den Bereichen föderiertes Vertrauen, föderiertes Identitätsmanagement, Policy Push/Pull im Kontext der Zugriffsberechtigung, deklarative Sicherheit, Aufbau von sicheren Kommunikationskanälen sowie relevante Standards und Profile. Kapitel 3 gibt einen Überblick über die konkreten (Sicherheits-)Abläufe im Kontext der Nutzung der LE-Schnittstelle. Die Darstellung und Beschreibung erfolgt anhand von Sequenzdiagrammen der Unified Modeling Language (UML). 1

10 In Kapitel 4 wird die Nutzung spezieller Sicherheitsnachweise auf Basis von Security Assertion Markup Language (SAML) Assertions motiviert. Zusätzlich wird ein Überblick über deren Erzeugung, Ausgestaltung und Verwendung gegeben. Kapitel 5 spezifiziert die für das Projekt benötigten Sicherheitsdienste und deren spezifische Eigenschaften in Bezug auf das Ausstellen von Sicherheitstoken als Nachweise für Fachdienste. Kapitel 6 gibt einen umfassenden Überblick über Maßnahmen zur Absicherung der einzelnen Fachdienste der LE-Schnittstelle. In Kapitel 7 wird die Abbildung des Verschlüsselungskonzept [FuE-ePA-Enc- Concept] auf konkrete Verfahren, Abläufe und Standards dargestellt. Die Anhänge geben einen weiterführenden Einblick in die verbindliche Ausgestaltung der in Kapitel 4 eingeführten Sicherheitstoken. 1.3 Verwandte Dokumente Das vorliegende Dokument basiert in einem gewissen Umfang auf den Inhalten anderer, im Rahmen des Projekts erstellter Dokumente. Zum besseren Verständnis der nun folgenden Ausführungen wird empfohlen, die Dokumente zur Facharchitektur [FuE-ePA-Facharchitektur], zur Autorisierung durch den Bürger [FuE-ePA-Autorisierung], zur verschlüsselten Datenhaltung [FuE-ePA-EncConcept] sowie zur Schutzbedarfsanalyse [FuE-ePA-Schutzbedarf] und zum Datenschutzkonzept [FuE-ePA-Datenschutz] zur Kenntnis zu nehmen. 1.4 Verwendung von Schlüsselwörtern Bei der Definition von Anforderungen werden die in [RFC2119] definierten Schlüsselwörter verwendet: MUST (MUSS) bedeutet, dass es sich um eine absolut gültige und normative Festlegung bzw. Anforderung handelt. MUST NOT (DARF NICHT) bezeichnet den absolut gültigen und normativen Ausschluss einer Eigenschaft. SHOULD (SOLL) beschreibt eine dringende Empfehlung. Abweichungen zu diesen Festlegungen sind in begründeten Fällen möglich. Wird die Anforderung nicht umgesetzt, müssen die Folgen analysiert und abgewogen werden. 2

11 SHOULD NOT (SOLL NICHT) kennzeichnet die dringende Empfehlung, eine Eigenschaft auszuschließen. Abweichungen sind in begründeten Fällen möglich. Wird die Anforderung nicht umgesetzt, müssen die Folgen analysiert und abgewogen werden. MAY (KANN) bedeutet, dass die Eigenschaften fakultativ oder optional sind. Diese Festlegungen haben keinen Normierungs- und keinen allgemeingültigen Empfehlungscharakter. 1.5 Konventionen In diesem Dokument zur Verdeutlichung des Aufbaus von Sicherheitsobjekten und zur Darstellung von Ablaufsequenzen genutzte UML-Diagramme wurden mit dem Programm Sparx Systems Enterprise Architect erzeugt. Über XML Schemata spezifizierte Typen sowie einzelne Elemente und Attribute dieser Typen werden im Text in kursiver Schrift gekennzeichnet. Sofern auf einzelne Abschnitte aus XML Dokumenten referenziert wird, erfolgt dies in der XPath- Syntax [XPath]. XML Namespace-Präfixe werden in diesem Dokument gemäß der nachfolgenden Tabelle als Substitute für die entsprechenden Namensräume genutzt. Präfix ds soapenv saml xacml xs xsi Namensraum urn:oasis:names:tc:saml:2.0:assertion urn:oasis:names:tc:xacml:2.0:policy:schema:os 3

12 4

13 2 Kernkonzepte 2.1 Architekturüberblick Grundlage für die Sicherheitsarchitektur ist die in Abbildung 1 gezeigte Systemarchitektur 1 und ihre Verteilung über verschiedene Sicherheitszonen. Die einzelnen Komponenten werden im Folgenden kurz vorgestellt. Abbildung 1 Systemüberblick In der dezentralen Zone der Leistungserbringer-Institutionen (LEI) dient der epa-le-client als Interaktionskomponente (ggf. als Bestandteil des Primärsystems) zur Kommunikation mit der epa-kommunikationskomponente und der LE-Postfach-Komponente. Die Schnittstelle des epa-le-clients zur epa-291a hin adressiert aus funktionaler Sicht lediglich Aspekte der Aktennutzung (Lese- 1 Die Motivation für diese Systemarchitektur wird im Dokument [FuE-ePA-Facharchitektur] erläutert. 5

14 operationen) sowie das Bereitstellen von (medizinischen) Informationen für den Bürger. Zur Unterstützung stehen dem epa-le-client folgende dezentralen Sicherheitsdienste zur Verfügung: Der Guarantor Token Service (s. a. Abschnitt 5.3) ist ein Authentifizierungsdienst innerhalb der dezentralen Zone des LE. Er dient der Authentifizierung der in der LEI beschäftigten Heilberufler (insbesondere dann, wenn diese über keinen eigenen Heilberufsausweis (HBA) verfügen). Zu diesem Zweck stellt er als Nachweis der Authentifizierung sogenannte Guarantor Assertions aus und signiert sie mit der Security Module Card Typ B (SMC-B) der Institution. Diese wiederum werden zur Authentisierung an einem zentralen Identity Provider (IdP) genutzt. Bei dem Access Token Service (vgl. Abschnitt 5.5) handelt es sich um einen Autorisierungsdienst für den LE. Er erzeugt die vom Bürger an den LE vergebenen Ad-hoc-Autorisierungsrichtlinien (siehe das Dokument [FuE-ePA-Autorisierung]). In der zentralen Infrastruktur sind die LE-Postfach-Komponente und die epa-kommunikationskomponente als Komponenten des Aktengesamtsystems angesiedelt. Die LE-Postfach-Komponente ist eine Komponente des LE und dient der Zwischenspeicherung von durch die epa-291a bereitgestellten (medizinischen) Informationen oder Informationsanforderungen. Durch diese Komponente werden asynchrone Nachrichtenflüsse ermöglicht, bei denen der epa-le-client nicht auf die von ihm angeforderten Informationen warten muss, sondern sie zu einem späteren Zeitpunkt über die LE-Postfach-Komponente abrufen kann. Die epa-kommunikationskomponente ist Teil des Aktensystems und dient der Vermittlung von Nachrichten zwischen epa-le-client, epa- Kernsystem und LE-Postfach-Komponente. Eingehende Nachrichten werden von der epa-kommunikationskomponente immer angenommen, was eine differenzierte Überprüfung von Zugriffsberechtigungen ausschließt. Die weitere Ausgestaltung dieser Komponente ist aktenspezifisch. Zu ihren Aufgaben kann das Abbilden der eingehenden Nachrichten auf ein aktenspezifisches Nachrichtenformat, das Adaptieren von Sicherheitsmechanismen und das Zwischenspeichern von Nachrichten für das epa-kernsystem gehören. Die Infrastruktur stellt weiterhin mit dem IdP einen zentralen Authentifizierungsdienst zur Verfügung. Jeder Nutzer der epa-291a muss sich gegenüber diesem Dienst mit Hilfe eines Sicherheitstokens (X.509-Zertifikat oder Guarantor Assertion) authentisieren. Für jeden erfolgreich authentifizierten Nutzer stellt der IdP einen vom ihm signierten Authentifizierungsnachweis aus. Des Weiteren wird davon ausgegangen, dass innerhalb der zentralen Infrastruktur weitere Sicherheitsdienste zur Statusüberprüfung von X.509-Zertifikaten (Dienste einer Public-Key-Infrastruktur, PKI-Dienste) sowie Verzeichnisdienste zum Abruf von Attributen, die LE oder LEI zugeordnet werden können, betrieben werden. In der Zone des Aktensystems wird das epa-kernsystem betrieben. Das epa- Kernsystem ist die Komponente der Patientenakte, die für die Verwaltung und Speicherung der medizinischen Informationen zuständig sowie für die Verarbeitung von Informationsanforderungen und Bereitstellungen verantwortlich ist. Die genaue Ausgestaltung dieser Komponente obliegt mit Ausnahme einiger 6

15 Basisanforderungen allein dem epa-betreiber. Der epa-bürger-client ist eine Interaktionskomponente zur Aktennutzung, -führung und/oder Wahrnehmung der Aktenhoheit durch den Bürger und/oder Dritte. Diese Komponente ist optional: Erforderliche Steuerinformationen zur Entscheidung über die Rechtmäßigkeit von Zugriffen müssen nicht zwingend über den epa-bürger-client in das Gesamtsystem eingespielt werden. Vielmehr müssen hierzu auch alternative Optionen bereitgestellt werden. Diese Komponente kann eng mit dem epa- Kernsystem gekoppelt sein, da hier herstellerspezifische Implementierungen gelten können. Der epa-sicherheitsarchitektur liegen die im Dokument [BCFP08] näher beschriebenen Architekturprinzipien zugrunde. Sicherheitsfunktionalitäten werden mithin strikt voneinander getrennt. 2.2 Fachdienste Die epa-kommunikationskomponente und die LE-Postfach-Komponente stellen die Fachdienste der Gesamtarchitektur dar. Die Kommunikation mit den Fachdiensten erfolgt über die im Dokument [FuE-ePA-Facharchitektur] beschriebene, auf dem Retrieve, Locate, And Update Service (RLUS) basierende LE-Schnittstelle. Die Kommunikation mit den Fachdiensten erfolgt grundsätzlich über sichere Kommunikationskanäle (Transportsicherung mithilfe von Transport Layer Security (TLS) sowie Absicherung der Kommunikation auf Anwendungsebene, siehe auch Abschnitt 2.8) epa-kommunikationskomponente Die Anfragen, die die epa-kommunikationskomponente entgegennimmt, kommen ausschließlich aus der dezentralen Zone der LEI. Die epa-kommunikationskomponente bietet folgende Operationen der LE-Schnittstelle an: - Anforderung von Bereitstellungsobjekten (BO) durch einen LE: RLUS- Put(AO) - Zustellung von BO durch einen LE: RLUS-Put(BO) - Anforderung von BO durch einen LE mit unmittelbarer Zustellung: RLUS- List(Parameter): MDO 2 2 Diese Abkürzung steht für Medizinisches Datenobjekt. 7

16 - Zustellung von BO durch LE mit unmittelbarer Verarbeitung: RLUS- Put(MDO) - Anforderung der Capability List: RLUS-List(Parameter):Capability List LE-Postfach-Komponente Die LE-Postfach-Komponente nimmt sowohl Anfragen aus der dezentralen Zone der LEI als auch Anfragen aus der zentralen Infrastruktur entgegen. Folgende Operationen der LE-Schnittstelle werden angeboten: - Zustellung von BO durch einen Bürger: RLUS-Put(BO) - Zustellung von Anforderungsobjekten (AO) durch einen Bürger: RLUS- Put(AO) - Abrufen von AO und BO durch einen LE: RLUS-List(Parameter):Informationsobjekte 2.3 Föderiertes Vertrauen Aus dem Architekturüberblick in Abschnitt 2.1 geht hervor, dass aus Sicht des IT-Systems eines LE verschiedene Sicherheitszonen den Zugriff auf das epa- Kernsystem regeln. Die Sicherheitsdienste in diesen Zonen stellen eine funktionale Dekomposition auf Basis der Konzepte Service-orientierter Architekturen dar und etablieren verschiedene Vertrauensstellungen untereinander. Als Vertrauen wird hierbei die Eigenschaft angesehen, dass ein (Sicherheits-)Dienst bereit ist, aufbauend auf Aussagen Dritter eine Dienstleistung zu erbringen. Als Mechanismen zur Etablierung von Vertrauensverhältnissen werden kryptografische Techniken eingesetzt, welche in den durch die Sicherheitsdienste ausgestellten Sicherheitstoken ihre Anwendung finden. Ausprägungen dieser Token sind bspw. X.509-Zertifikate [RFC5280] oder SAML Assertions [SAML- Core]. Letzterer stellt einen Standard für transportierbare Authentisierungs- und Autorisierungsnachweise dar. Den aufeinander aufbauenden Nachweisen liegt die Idee zugrunde, dass aus einem sicheren Nachweis durch Hinzunahme weiterer Informationen wiederum ein sicherer und damit unversehrter und authentischer Nachweis erzeugt werden kann. Bei Betrachtung des Architekturüberblicks in Abschnitt 2.1 ist ersichtlich, dass Autorisierungsnachweise dezentral beim LE und Authentisierungsnachweise in der zentralen Infrastruktur erzeugt werden. Der epa-kommunikationsdienst repräsentiert einen ersten Baustein für die Konsumierung solcher Nachweise und nimmt erste Prüfungen (z. B. der Signaturen) vor. Für das epa-kernsystem stellen die von dem epa- 8

17 Kommunikationsdienst zur Verfügung gestellten Nachweise die Bezugspunkte für das föderierte Vertrauen dar. 2.4 Föderiertes Identitätsmanagement Innerhalb der Telematikinfrastruktur (TI) können zur sicheren Identifizierung und Authentifizierung von Heilberuflern und LEIs die ausgegebenen HBAs bzw. SMC-Bs genutzt werden. Die Ausgabe von HBAs beschränkt sich dabei momentan noch ausschließlich auf Ärzte und Apotheker. Andere in Heilberufen tätige Personen sowie berufsmäßig tätige Gehilfen verfügen nicht über einen entsprechenden Ausweis und somit auch nicht über eine eigene (digitale) Identität innerhalb der TI. Auch diesen Personenkreisen soll es unter bestimmten Bedingungen ermöglicht werden, auf die epa-291a eines Bürgers zuzugreifen. Die über die SMC-B verfügbare Identität der entsprechenden LEI muss somit stellvertretend für diese Personen verwendet werden können. In diesem Zusammenhang ergibt sich jedoch das Problem, dass Nutzer-individuelle Attribute (Name, Berufsgruppe etc.) bei ausschließlicher Verwendung der SMC-B nicht nach außen (gegenüber der TI) sichtbar gemacht werden können. Innerhalb des Projekts wird zur Lösung dieses Problems der folgende Ansatz vorgeschlagen: Im Sinne der in den Abschnitten 2.3 und 2.5 beschriebenen Grundsätze trifft die LEI Aussagen über den zugreifenden Nutzer und bürgt (gegenüber der TI) mithilfe einer digitalen Signatur auf Basis der SMC-B für diese. Die technische Umsetzung erfolgt über eine sogenannte Guarantor Assertion (vgl. Abschnitt 4.2.1). Diese Assertion kann zur Anmeldung an den entsprechenden Authentifizierungsdiensten (vgl. Abschnitt 5.4) der TI genutzt werden. Es ist nicht vorgesehen, dass ein Fachdienst eine Guarantor Assertion konsumiert. Das vorgeschlagenen Modell basiert auf der Grundannahme, dass ausschließlich die durch die SMC-B repräsentierte LEI (z. B. Arztpraxis) bzw. der durch sie repräsentierte Teil einer Institution (z. B. Fachabteilung im Krankenhaus) in der Lage ist, verlässliche Aussagen (aktuelle Tätigkeit/Rolle/Berufsgruppe) über den zugreifenden Nutzer zu treffen. Aus dem vorgeschlagenen Modell ergeben sich für die LEI diverse Anforderungen: Die LEI verfügt über die notwendigen Informationen, um verpflichtende Attribute vollständig zu befüllen. Die LEI ist in der Lage, sicherzustellen (und gegenüber der TI zu garantieren), dass die interne Systemlandschaft es ausschließlich angemessen authentisierten und autorisierten Heilberuflern ermöglicht, diesen Mechanismus zu verwenden. 9

18 Das vorgeschlagene Modell lässt sich ebenfalls auf HBA-Inhaber ausweiten. Auch für diese gilt, dass bestimmte Aussagen (z. B. aktuelle Tätigkeit) ausschließlich durch die LEI, in der sie tätig sind, getroffen werden können. 2.5 Vertrauens- und Kommunikationsbeziehungen Die untereinander agierenden Dienste realisieren verschiedene Vertrauens- und Kommunikationsbeziehungen. Das folgende Vertrauensmodell definiert, welche Vertrauensbeziehungen zwischen ihnen bestehen und wie diese hergestellt, vermittelt und kontrolliert werden können. Das Vertrauen wird durch erworbene Sicherheitstoken durch die Client-Systeme an die Fachdienste (LE-Postfachdienst und epa-kommunikationsdienst) vermittelt. Zur Unterscheidung der verschiedenen Sicherheitsanforderungen an die Dienste in der zentralen Infrastruktur werden die folgenden Ports definiert: Trusted Client: Ein Client stammt aus einer vertrauten Sicherheitszone (in diesem Fall, repräsentiert durch den epa-le-client, aus der dezentralen Sicherheitszone). Dedicated Service: Ein Dienst aus derselben Sicherheitszone nutzt einen Dienst. Hier sind es die Beziehungen zwischen dem LE-Postfach- Dienst und dem epa-kommunikationsdienst. Abbildung 2 verdeutlicht die Vertrauensbeziehungen mittels gestrichelter Linien; Kommunikationsbeziehungen werden mit durchgehenden Linien dargestellt. 10

19 Abbildung 2 Vertrauens- und Kommunikationsbeziehungen Dezentrale Zone (Leistungserbringerinstitution) Zentrale Infrastruktur Aktensystem Guarantor Token Service Access Token Service Primärsystem epa-le-client Trusted Client Identity Provider LE-Postfachdienst Dedicated Service epa-kommunikationsdienst epa-kernsystem 2.6 Generisches Schnittstellen-Design Um die obigen Vertrauens- und Kommunikationsbeziehungen auf Operationen abzubilden, werden in Abbildung 3 zwei verschiedene Schnittstellen definiert. Abbildung 3: Generisches Schnittstellen-Design für die Dienste Truststore_TrustedClient TrustedClient_Policy Truststore_DedicatedService DedicatedService_Policy Interface_TrustedClient: Operation_a(functional param) Operation_b() TrustedClient_Port Web Service DedicatedService_Port Interface_DedicatedService: Operation_c() Keystore Diese beiden Schnittstellen werden im Dokument [W3C-WSDL] durch unterschiedliche Ports beschrieben. Dies ermöglicht es, verschiedene zulässige Operationen mit entsprechenden Web Service Policies und akzeptierten Zertifikaten für die Kommunikationsbeziehungen (Client/Service) und die Vertrauensstellungen (dedicated/trusted) zu definieren. 11

20 2.7 Deklarative Sicherheit Die verschiedenen Fach- und Sicherheitsdienste besitzen je nach Aufgabe und Kommunikationsbeziehung (vgl. Abschnitt 2.6) sehr spezifische Anforderungen hinsichtlich der Absicherung der durch sie unterstützten Operationen. Dazu gehören u. a.: Verpflichtend zu verwendende Elemente innerhalb der ausgetauschten Nachrichten (Timestamps etc.) Verpflichtend zu schützende Teile innerhalb der ausgetauschten Nachrichten sowie der zu nutzende Schutzmechanismus (Signatur/Verschlüsselung) Form und Umfang der Verwendung von Sicherheitstoken (Zertifikate, SAML Assertions etc.) Aufbau von sicheren Kommunikationskanälen Verpflichtend zu verwendende Algorithmen bzw. Algorithmenfamilien Im Rahmen des Projekts wird angestrebt, diese spezifischen Anforderungen in Form von XML-basierten Sicherheitsrichtlinien zu formulieren und diese direkt an die einzelnen Dienste zu binden. Dies ermöglicht die automatisierte Verarbeitbarkeit durch die einzelnen Clients und verringert somit den notwendigen Implementierungsaufwand (Konfigurieren statt Implementieren). Darüber hinaus garantiert die leichte Erweiterbarkeit und Anpassbarkeit der entsprechenden Sicherheitsrichtlinien eine hohe Flexibilität in Bezug auf sich ändernde Rahmenbedingungen. Die Realisierung erfolgt auf Basis des etablierten Standards WS-SecurityPolicy [OASIS-WS-SecPol-2]. 2.8 Aufbau sicherer Session-orientierter Kommunikationskanäle Es existieren verschiedene Ansätze, um den Austausch von auf dem Simple Object Access Protocol (SOAP) basierenden Nachrichten zwischen einem Web Service und einem Web Service Client abzusichern. Diese Ansätze unterscheiden sich im Hinblick auf die genutzten Mechanismen und Abläufe zum Teil grundlegend voneinander. Der folgende Abschnitt konzentriert sich primär auf die Unterschiede im Hinblick auf die Absicherung der Kommunikation auf Schicht 7 (WS-Security) des Open Systems Interconnection (OSI) Model. Das Vorhandensein einer darunterliegenden Transportsicherung mithilfe von TLS wird vorausgesetzt. Grundsätzlich bestehen auf der Anwendungsebene mehrere Möglichkeiten, um den Austausch von Nachrichten abzusichern. Dazu gehören u. a.: 12

21 Nachrichten-basierte Sicherheit Jede einzelne Nachricht, die Dienst und Client austauschen, wird individuell abgesichert. D. h. die initial auf Client- und Dienstseite vorhandenen Sicherheitstoken (z. B. X.509-Zertifikate und zugehöriges Schlüsselmaterial) werden für die Sicherung der Nachrichten bzw. ausgewählter Teile der Nachrichten verwendet. Session-basierte Sicherheit Dienst und Client handeln mithilfe der initial vorhandenen Sicherheitstoken (z. B. X.509-Zertifikate und zugehöriges Schlüsselmaterial) ein neues Sicherheitstoken aus. Das zu diesem Sicherheitstoken gehörende Schlüsselmaterial oder aus diesem abgeleitete Schlüssel werden für die Sicherung aller zwischen Dienst und Client ausgetauschten Nachrichten verwendet. Das ursprüngliche Schlüsselmaterial wird im Kontext der Session nicht erneut verwendet. Beide Verfahren besitzen eine Reihe von Vor- und Nachteilen. Die folgende Tabelle gibt einen kurzen Überblick. Nachrichtenbasierte Sicherheit Session-basierte Sicherheit PRO - Dienste können zustandslos implementiert werden. - Abbildung der initial vorhandenen Sicherheitstoken auf performante Token - Im Vergleich zur Nachrichten-basierten Sicherheit hohe Performanz beim Austausch multipler Nachrichten CONTRA - Grundlage der Sicherung sind immer die initial vorhandenen Sicherheitstoken. Diese können beim Durchführen kryptografischer Operationen potenziell inperformant sein. - Im Vergleich zur Session-basierten Sicherheit geringe Performanz beim Austausch multipler Nachrichten - Dienste müssen die (Security-)Session verwalten können und ggf. die zum Aufbau verwendeten Token zwischenspeichern. Im Rahmen des Projekts wird angestrebt, die Kommunikation zu sämtlichen Diensten Session-basiert abzusichern. Die nachfolgend beschriebenen Faktoren haben zu dieser Entscheidung beigetragen. Als (initiale) Sicherheitstoken auf Seite der Clients kommen derzeit ausschließlich die auf HBA, SMC-B und elektronischer Gesundheitskarte (egk) gespeicherten X.509-Zertifikate und das zugehörige Schlüsselmaterial in Betracht. Grundsätzlich gilt, dass die mithilfe der Karten durchgeführten kryptografischen Operationen nur mit begrenzter Geschwindigkeit ausgeführt werden können. Um den Datendurchsatz bei der Kommunikation zwischen Client und Service zu optimieren, sollten Kartenoperationen auf ein absolutes Minimum reduziert werden. Die Verwendung der Hardware-gebundenen X.509-Token zur Sicherung einzelner Nachrichten verbietet sich daher im Zusammenhang mit der Übertragung einer potenziell großen Anzahl von Nachrichten. 13

22 Grundsätzlich muss jedoch beachtet werden, dass beim Aufbau einer Session die gleichen Sicherheitstoken angewendet werden wie bei der Absicherung einzelner Nachrichten. Kapitel 5 und 6 beschreiben daher Dienst-individuell die zum Session-Aufbau zu nutzenden Sicherheitstoken. Darüber hinaus wird in diesen Kapiteln auch auf den individuellen Lebenszyklus der jeweiligen Session eingegangen. Dabei wird beispielsweise definiert, wie lange eine Session gültig ist sowie, ob und wie sie erneuert werden kann. Für den Aufbau von Sessions wird als WS*-Standard WS-SecureConversation [OASIS-WS-SecConv] (vgl. Abschnitt ) verwendet. Abbildung 4 Ablauf des Session-Aufbaus ST 1 ST 2 requestsecuritytoken() 1 requestsecuritytokenresponse() SCT Client SCT request() ST 3 Service request() ST 3 2 response() SCT... response() 1. In einem ersten Schritt wird die Security Session zwischen Client und Service aufgebaut. Zur Sicherung des Aufbaus wird Security Token 1 (ST 1) genutzt. Dies kann beispielsweise ein Zertifikat des Diensts sein. Optional können weitere unterstützende Token (z. B. ST 2) in die Nachricht eingebettet werden. Als Ergebnis wird durch den Dienst ein Security Context Token (SCT) ausgestellt und zurückgegeben. Die Session ist nun etabliert. 2. Das Security Context Token (SCT) wird ab sofort zur Sicherung aller Dienstaufrufe genutzt. Optional können weitere Token (z. B. ST 3) in die einzelnen Nachrichten integriert werden. 14

23 Hinweis: Weiterführende Festlegungen zum Lebenszyklus (Aufbau, Abbruch Erneuerung etc.) dienstspezifischer WS-SecureConversation Sessions können den Kapiteln 5 und 6 entnommen werden. 2.9 Policy- und Attribute Supply-Modelle Autorisierungsrichtlinien (Security Access Policies) 3 dienen als Grundlage für das Treffen von Zugriffsentscheidungen durch die Entscheidungskomponente eines Access Control-Systems. Grundsätzlich ist die Entscheidungskomponente darauf angewiesen, dass ihr die Policy im Kontext des Treffens einer Zugriffsentscheidung zur Verfügung steht. Es existieren unterschiedliche Wege, diese Policy zu beschaffen. Dazu gehören: Policy Pull Die zuständige Komponente des Access Control-Systems muss sich eigenständig um den Abruf der Autorisierungsrichtlinie von den entsprechenden Policy Administration Points (PAPs) kümmern. Abbildung 5 Policy Pull Abruf der Autorisierungsrichtlinie von einem separaten PAP Client Aufruf ACS (PEP, PDP) Service AC-Policy ACS (PAP) Das Policy-Pull-Szenario spielt im Kontext der epa-zugriffssteuerung ausschließlich im Zusammenhang mit der Verarbeitung von Vorab-Berechtigungen [FuEePA-Autorisierung] eine Rolle. Die Kodierung der entsprechenden Autorisierungsrichtlinien und deren Übermittlung zwischen den Komponenten des innerhalb der Akte angesiedelten Access Control-Systems weist somit nur einen indirekten Bezug zur LE-Schnittstelle auf. Die Spezifikation der an die Fachdienstschnittstelle übermittelten Nachrichten (Aufruf) ist NICHT betroffen. Eine weiterführende Betrachtung erfolgt im Rahmen dieses Dokuments daher nicht. Policy Push Die Autorisierungsrichtlinie wird vom Client zusammen mit dem Aufruf (z. B. im Security Header einer SOAP-Nachricht) an den entsprechenden 3 Im Folgenden vereinfacht Policy genannt. 15

24 Fachdienst übermittelt und steht den Komponenten des Access Control- Systems somit direkt im Rahmen der Verarbeitung zur Verfügung. Abbildung 6 Policy Push Übermittlung der Autorisierungsrichtlinie als Bestandteil des Fachdienstaufrufs Client Aufruf + AC-Policy ACS (PEP, PDP) Service Dem Policy-Push-Szenario kann in Bezug auf die Vergabe von Ad-hoc-Berechtigungen (vgl. das Dokument [FuE-ePA-Autorisierung]) eine besondere Bedeutung beigemessen werden. Hier ergeben sich sehr klare Fragestellungen in Bezug auf die Ausgestaltung der über die LE-Schnittstelle ausgetauschten Nachrichten. Dazu gehören u. a.: - Welcher Standard kommt zur Kodierung der übermittelten Ad-hoc-Autorisierungsrichtlinien zum Einsatz? Wie wird dieser Standard profiliert (zulässige Elemente, Attribute etc.)? - Wie wird die Autorisierungsrichtlinie angemessen gesichert (Integritätssicherung etc.)? - Wie und in welcher Form muss/kann die Autorisierungsrichtlinie in die Fachdienstaufrufe eingebettet werden? Eine detaillierte Auseinandersetzung mit diesen Fragestellungen erfolgt innerhalb dieses Dokuments. Neben der Policy benötigt die Entscheidungskomponente weitere Informationen zum Treffen einer fundierten Zugriffsentscheidung. Dazu gehören neben der eigentlichen Zugriffsanfrage insbesondere Attribute, die u. a. das zugreifende Subjekt und/oder die Ressource näher beschreiben. Auch hier gilt, dass diese Informationen auf unterschiedlichen Wegen beschafft werden können: Attribute Pull Die zuständige Komponente des Access Control-Systems muss sich eigenständig um den Abruf der für das Treffen der Zugriffsentscheidung benötigten Attribute von den entsprechenden Policy Information Points (PIPs) kümmern. Das Attribute-Pull-Szenario wird im Rahmen dieses Dokuments nicht weiter betrachtet. Attribute Push Attribute werden vom Client zusammen mit dem Aufruf (z. B. im (Security) Header einer SOAP-Nachricht) an den entsprechenden Fach- 16

25 dienst übermittelt und steht den Komponenten des Access Control-Systems somit direkt im Rahmen der Verarbeitung zur Verfügung. Das Attribute-Push-Szenario wird im Rahmen der Betrachtung von Guarantor und Identity Assertion (Kapitel 4) erneut aufgegriffen. Für weiterführende Informationen zur Problematik des Policy und Attribute Push sei auf [CKPR09] verwiesen Genutzte Standards und Profile Die in diesem Dokument spezifizierte Sicherheitsarchitektur berücksichtigt existierende Standards aus dem Sicherheitsumfeld. Im Folgenden werden die wichtigsten technischen Standards und Profilierungen einer Token-basierten Sicherheitsarchitektur als Steckbrief vorgestellt. Im Umfeld der Token-basierten Sicherheitsarchitekturen sind die folgenden Standards etabliert: Standards zu X.509-basierten Public-Key-Infrastrukturen (PKIX) SAML Web-Services-Standards, wie z. B. WS-Trust und WS-SecureConversation (WS*) sowie extensible Access Control Markup Language (XACML) X.509-basierte Public-Key-Infrastruktur (PKIX) PKIs halten grundlegende Sicherheitsmechanismen (z. B. zur Verschlüsselung und zur digitalen Signatur) bereit, auf die eine Sicherheitsarchitektur aufbauen kann. Der Zweck einer PKI ist es, öffentliche Schlüssel zu verwalten und vertrauenswürdig in der Form von Zertifikaten an Identitäten zu binden sowie die öffentlichen Schlüssel für Anwendungen (z. B. Sicherheitsdienste) bereitzustellen. Unter der Bezeichnung PKIX entwickelt die Internet Engineering Task Force (IETF) Internetstandards für eine auf X.509-Zertifikaten basierende PKI [RFC5280]. Neben dem Zertifikatformat definiert PKIX Betriebs- und Verwaltungsprotokolle sowie Zertifizierungsrichtlinien. 17

26 Abbildung 7 Modell einer PKI Verzeichnisdienste werden innerhalb einer PKI dazu genutzt, Zertifikate zu veröffentlichen und diese für PKI-Anwendungen bereitzustellen. Die Verzeichnisdienste verwalten die Attribute und Zertifikate der PKI-Teilnehmer telefonbuchartig, sodass Anwendungen über den Namen oder den eindeutigen Bezeichner eines PKI-Teilnehmers dessen Zertifikat abrufen können. Mithilfe des Online Certificate Status Protocol (OCSP) [RFC2560] kann eine PKI-Anwendung über einen OCSP-Responder den Status der Zertifikate ermitteln Der OCSP-Responder kann dazu auf die von einem Verzeichnisdienst der PKI verwaltete Zertifikatsperrliste zugreifen. Systembaustein PKI-Teilnehmer PKI-Anwendung OCSP-Responder Verzeichnisdienst Beschreibung Eine Person, Anwendung oder Komponente, deren/dessen Identität von einer Zertifizierungsstelle vertrauenswürdig festgestellt wurde. Ein PKI-Teilnehmer kann seine Identität mithilfe eines privaten Schlüssels nachweisen. Eine Anwendung, die PKI-Dienste nutzt, um die Schutzziele Integrität, Authentizität, Vertraulichkeit und Nicht-Abstreitbarkeit bei der Verarbeitung von kommunizierten Daten zu gewährleisten. Eine PKI-Anwendung kann (muss aber nicht zwingend) ein PKI-Teilnehmer sein. Ein Dienst, der den aktuellen Status eines Zertifikats liefern kann. Verwaltet Identitätsmerkmale und Zertifikate von PKI-Teilnehmern sowie Zertifikatsperrlisten. 18

27 Security Assertion Markup Language (SAML) SAML spezifiziert einen Rahmen, in dem vertrauenswürdige Aussagen zu Identitäten dargestellt und ausgetauscht werden können. Die primären Anwendungsszenarien, in denen SAML eingesetzt wird, sind Single Sign-On sowie Identity Federation. Den zentralen Bestandteil des Standards bilden die in Version 2.0 der SAML- Spezifikation [SAML-Core] spezifizierten abstrakten Assertions und Protokolle. Während die Assertions vertrauenswürdige Aussagen zur Authentifizierung und Autorisierung einer Identität sowie einer Identität zuordenbare Attribute kapseln, erlauben es die Protokolle, solche Assertions anzufragen und zu transportieren. Die SAML-Protokolle und deren Nachrichten werden in Version 2.0 der SAML-Spezifikation [SAML-Core] zunächst abstrakt spezifiziert sind allerdings für die epa-sicherheitsarchitektur nicht relevant. SAML Assertions werden als Sicherheitstoken mittels [OASIS-WS-Trust] kommuniziert. SAML Zuständigkeit Organization for the Advancement of Structured Information Standards (OASIS) Version 2.0, März 2005 Zweck Abstrakte, XML-basierte Darstellung von vertrauenswürdigen Aussagen in Form von SAML-Assertions Abstrakte Protokolle für den Transport der SAML-Assertions SAML unterscheidet drei Arten von Assertions, welche in Statements ausgedrückt werden: Authentifizierung (AuthnStatement): Der Aussteller bezeugt zu einem Zeitpunkt, dass ein Subjekt aufgrund übergebener valider Benutzeranmeldeinformationen authentifiziert wurde. Attributierung (AttributeStatement): Der Aussteller bezeugt, dass ein Subjekt mit erweiterten Eigenschaften (Attributen) identifiziert wurde. Autorisierung (AuthzDecisionStatement): Der Aussteller bezeugt, dass ein Subjekt Zugriff auf bestimmte Ressourcen erhält bzw. dass einem Subjekt dieser Zugriff verweigert wird. Im Projekt wird nur von den ersten beiden Statements Gebrauch gemacht. Die Zuweisung von Zugriffsrechten erfolgt mit XACML. In [SAML-XACML] wurde eine Erweiterung spezifiziert, sodass das XACMLAuthzDecisionStatement diese Informationen transportiert. 19

28 2.11 Web Services Security (WS-Security) WS-Security [OASIS-WS-Sec] erlaubt es, SOAP-Nachrichten auf der Nachrichtenebene zu signieren und zu verschlüsseln. Es bietet außerdem einen Rahmen, in dem verschiedenste Sicherheitstoken übertragen werden können. Der Standard wird daher von weiteren Token-Profilen begleitet, die etwa die Nutzung von X.509-basierten Zertifikaten, SAML-Tokens oder Kerberos-Tickets als Sicherheitstokens spezifizieren. WS-Security Zuständigkeit OASIS Version 1.1, Februar 2006 Zweck Nachrichtensicherheit auf Nachrichtenebene, Bereitstellung von Mechanismen für höhere Sicherheitsprotokolle Erweiterungen Tokenprofile: Username Token Profile 1.1 X.509 Token Profile 1.1 SAML Token Profile 1.1 Kerberos Token Profile 1.1 Für WS-Security ist lediglich die abstrakte Rolle eines SOAP-Nachrichten verarbeitenden Systembausteins relevant. Die konkrete Ausprägung muss hier nicht berücksichtigt werden, da WS-Security lediglich einen Rahmen bietet, in dem höhere, spezifische Sicherheitsprotokolle entwickelt werden können. Abbildung 8 WS-Security-Modell Web Services Trust Language (WS-Trust) [OASIS-WS-Trust] erweitert WS-Security um ein Nachrichten-basiertes Protokoll, das das Anfragen und Ausstellen von Sicherheitstoken sowie die Delegation von Vertrauensbeziehungen erlauben. WS-Trust führt dazu ein aus drei Rollen bestehendes Modell ein, in dem ein Web-Service-Nutzer bei einem Security Token Service (STS) ein Sicherheitstoken anfragt, welches dieser anschließend bei 20

29 einem Web-Service-Anbieter einlösen kann. Die vom Web-Service-Nutzer so vorgelegten Behauptungen sind durch die Vertrauensbeziehung zwischen Web- Service-Anbieter und STS mithilfe von kryptografischen Methoden verifizierbar. WS-Trust ist funktional dem SAML-Protokoll sehr ähnlich, wobei SAML eher in Browser-basierten Lösungen zum Einsatz kommt und WS-Trust vorwiegend in Fat-Client-Umgebungen genutzt wird. Hersteller von Identity- und Access Management Lösungen unterstützen üblicherweise beide Protokolle. WS-Trust Zuständigkeit OASIS Version 1.3, März 2007 Zweck Anfragen und Ausstellen von Sicherheitstoken (z. B. SAML Assertions), Konzept des direkt vermittelten Vertrauens Systembaustein Beschreibung Security Token Requester STS Security Token Consumer Fragt Sicherheitstoken bei einem STS an und legt diese einem Security Token Consumer vor. Ein Security Token Requester ist in der Regel ein Web- Service-Nutzer. Stellt Sicherheitstoken aus. Ein STS besitzt das direkte Vertrauen eines Security Token Consumer und kann so Vertrauen zum Security Token Requester vermitteln. Verarbeitet Sicherheitstoken und setzt diese als Zugriffskontrolle auf eine bestimmte Ressource voraus. 21

30 Abbildung 9 WS-Trust-Modell WS-SecurityPolicy WS-SecurityPolicy [OASIS-WS-SecPol-1] spezifiziert eine Erweiterung von WS- Policy [W3C-WS-Pol]. Diese erlaubt es, die Sicherheitsrichtlinien eines Web- Services als Teil des Dienstvertrags abzubilden. Mit dieser Erweiterung ist es beispielsweise möglich, die zu verwendenden Sicherheitstoken festzulegen oder anzuzeigen, welche Nachrichtenteile zu signieren oder zu verschlüsseln sind. WS-SecurityPolicy gibt dafür die Syntax und Semantik von sogenannten Policy Assertions vor, die auf die Standards WS-Security, WS-Trust sowie WS- SecureConversation abgestimmt sind. WS-SecurityPolicy Zuständigkeit OASIS Version 1.2, Juli 2007 Zweck Beschreibung von Sicherheitsrichtlinien im Dienstvertrag WS-SecureConversation WS-SecureConversation [OASIS-WS-SecConv] erlaubt es, mehrere Nachrichten in einen Sicherheitskontext eingebettet auszutauschen. Aus einem solchen Sicherheitskontext können die Kommunikationspartner ein Geheimnis ableiten, mit dem der sichere Nachrichtenaustausch effizienter abgewickelt werden kann. Eine Effizienzsteigerung ergibt sich beispielsweise dann, wenn nicht wiederholt Sicherheitstoken rechenaufwändig neu ausgestellt und ausgewertet werden. Ein Sicherheitskontext wird als ein weiteres, in einem Token-Profil beschriebenes Sicherheitstoken dargestellt. Wie WS-Security auch betrachtet WS- 22

31 SecureConversation keine konkreten Rollen für SOAP-Nachrichten verarbeitende Systembausteine. WS-SecureConversation Zuständigkeit OASIS Version 1.3, März 2007 Zweck Einbettung von Nachrichten in einen Sicherheitskontext extensible Access Control Markup Language (XACML) [XACML] erlaubt die XML-basierte Beschreibung von Regeln für den Zugriff auf Ressourcen und spezifiziert Protokolle, mit denen Autorisierungsentscheidungen angefordert und ausgegeben werden können. Der Standard verfolgt einen generischen Ansatz, sodass mit XACML verschiedenartige Ansätze für Berechtigungssysteme (z. B. Rollen-basierte Berechtigungen) realisiert werden können. XACML Zuständigkeit OASIS Version 2.0, Februar 2005 Zweck Autorisierung Beschreibung von Zugriffsregeln Protokoll zur Anforderung und Herausgabe von Autorisierungsentscheidungen Der Standard besteht in seinem Kern aus den Systembausteinen Policy Enforcement Point (PEP), Policy Decision Point (PDP), PIP sowie PAP. Diese Systembausteine werden durch weitere periphere Informationssysteme (z. B. Verzeichnisdienste) unterstützt. Weitere von OASIS herausgegebene Profile adressieren das Zusammenspiel mit anderen Standards (z. B. SAML) oder die Implementierung spezifischer Berechtigungsmodelle über die Konstrukte von XACML. 23

32 Abbildung 10 Szenario einer Autorisierung mit XACML Der PEP kontrolliert den Zugriff auf eine Menge von Ressourcen. Er ist der Ressource, beispielsweise einem Web-Service, vorgeschaltet und lässt den Zugriff abhängig von einer Autorisierungsentscheidung zu oder verweigert diesen. Die Autorisierungsentscheidung holt der PEP bei einem PDP ein. Der PDP holt sämtliche für die Bewertung des Zugriffs nötigen Attribute der zugreifenden Identität, der Ressourcen sowie der gewünschten Aktion ein und gibt auf dieser Grundlage eine Autorisierungsentscheidung aus. Die Richtlinien, nach denen die Attribute zu bewerten sind, werden beim PAP verwaltet und dem PDP bereitgestellt. Die Quelle der benötigten Attribute ist der PIP. Dieser ist mit peripheren Informationssystemen der IT-Infrastruktur verknüpft, von denen die benötigten Attribute abgerufen werden können. XACML spezifiziert ebenso wie SAML zunächst lediglich die Schemata für Protokollnachrichten. Der Transport dieser Nachrichten wird vom Standard nicht adressiert und ist Gegenstand einer Profilierung. 24

33 Systembaustein PEP PDP PIP PAP Beschreibung Setzt Zugriffsrichtlinien für eine Ressource gegenüber einer Identität oder Anwendung durch. Berechnet Autorisierungsentscheidungen. Stellt die für die Berechnung von Autorisierungsentscheidungen nötigen Attribute bereit. Verwaltet Zugriffsrichtlinien und stellt diese bereit. 25

34 26

35 3 Zugriffsszenarien und Abläufe Dieses Kapitel nennt zunächst Grundannahmen und Prinzipien als Basis für die Zugriffskontrolle einer epa-291a. Anhand von verschiedenen Szenarien werden die jeweiligen (Sicherheits-)Abläufe beim Zugriff auf die epa-291a im Detail beschrieben. Hierbei werden alle relevanten Schritte von der Authentifizierung des Nutzers, der Anwendung von Autorisierungsrichtlinien, dem Zugriff auf die Daten in der epa-291a bis zur Übernahme in das jeweilige System (LE-System oder epa-291a) betrachtet. 3.1 Grundannahmen und Prinzipien Folgende Grundannahmen und Prinzipien liegen den verschiedenen Zugriffsszenarien zu Grunde: Die Zugangskontrolle erfolgt ausschließlich über den Bürger: Der Bürger hat die Kontrolle darüber, welche LEs bzw. LEIs er darüber informiert, dass er über eine epa-291a verfügt und wie diese adressiert werden kann. Die zur Adressierung der epa-291a notwendige die Identifikationsnummer (epa-id) wird aus der egk des Bürgers gelesen oder einem AO (siehe KM-03 aus dem Dokument [FuE-ePA-Kommunikationsmuster]) des Bürgers entnommen. Pseudonymisierung: Der Zugriff auf die epa-291a erfolgt ausschließlich über pseudonymisierte Informationen, wie z. B. die epa-id. Dem aktenhaltenden System ist die Zuordnung Bürger <--> epa-id nicht bekannt. Der Bürger hat die Aktenhoheit: Dem Bereitstellen von Informationen aus einer epa-291a an einen LE sowie der Übernahme von Informationen in die Patientenakte geht eine bewusste Handlung des Bürgers voraus (z. B. direkte Interaktion, Vorabdefinition von Regeln). Autorisierung und Zugriffskontrolle: Das Aktensystem verfügt über ein Zugriffskontrollsystem, das die im Dokument [FuE-ePA-Autorisierung] aufgestellten Anforderungen erfüllt, d. h. die epa-291a verarbeitet nur Anfragen von authentifizierten und vom Bürger berechtigten LEs bzw. LEIs. Die Autorisierung zum Zugriff auf die epa-291a erfolgt wie im Dokument [FuE-ePA-Autorisierung] beschrieben. 27

36 Nutzerzentrierte Verschlüsselung: Die MDOs in der epa-291a sind für den Bürger und für LEs bzw. LEIs, die vom Bürger vorab berechtigt wurden, (hybrid) verschlüsselt (siehe das Dokument zum Verschlüsselungskonzept [FuE-ePA-EncConcept]). Zentrale Infrastruktur: Es existiert eine zentrale Infrastruktur, wie z. B. die TI der gematik, die ausgewählte Infrastrukturdienste (z. B. PKI) zentral zur Verfügung stellt. IdP: Innerhalb der zentralen Infrastruktur existiert mindestens ein IdP, der Authentifizierungen von Identitäten durchführen und mittels Authentifizierungsnachweisen bestätigen kann. Diesem Dienst wird innerhalb der Infrastruktur vertraut. egk, HBA und SMC-B: Es wird angenommen, dass der Bürger als Besitzer der epa über eine egk verfügt. Weiterhin wird angenommen, dass jeder LE über einen HBA verfügt und jede LEI mit einer SMC-B ausgestattet ist. 3.2 Zugriffsszenarien Im folgenden Abschnitt werden ausschließlich Zugriffe zum Zwecke der Aktennutzung von LEs oder aus LEIs heraus betrachtet. Zur Aktennutzung gehören das Anfordern von Daten von der epa-291a, um diese Daten innerhalb der LEI zu nutzen, sowie das Bereitstellen von Daten aus der LEI für die epa-291a. Die Anforderung eines Bürgers, die einer Bereitstellung des LE vorausgehen kann, wird nicht betrachtet. Es wird davon ausgegangen, dass es unterschiedliche Ausprägungen einer epa- 291a geben wird, die sich hinsichtlich der Autorisierungs- und Zugriffsmöglichkeiten unterscheiden können. Bei den folgenden Zugriffsszenarien wird daher zwischen einer Basisakte und einer Komfortakte unterschieden. In den einzelnen Szenarien wird auf die Eigenschaften der jeweils betrachteten Aktenausprägung näher eingegangen. Folgende Vorbedingungen gelten bei den beschriebenen Zugriffsszenarien als erfüllt: Die epa-291a, auf die zugegriffen werden soll, ist angelegt und betriebsbereit. Es existiert eine epa-id, über die die epa-291a adressiert werden kann. 28

37 In der epa-291a ist ein Aktenschlüsselpaar installiert, dessen öffentlicher Teil von einem beliebigen LE oder vom Bürger selbst signiert wurde. Der private Teil des Aktenschlüssels ist für den Bürger verschlüsselt in der epa-291a abgelegt. Die vom LE angeforderten Informationen sind in der epa-291a vorhanden. Alle Komponenten und Dienste des Gesamtsystems (auf LE-Seite, in der Sicherheitsinfrastruktur und auf Aktensystem-Seite) sind verfügbar und online. Zu den Diensten werden sichere Kanäle (Authentizitäts- und Vertraulichkeitssicherung der Nachrichten) aufgebaut. In den folgenden Zugriffsszenarien wird zudem davon ausgegangen, dass alle durchgeführten Prüfungen positive Ergebnisse liefern Standardabläufe Die folgenden beiden Abläufe werden in fast allen Zugriffsszenarien durchlaufen Ablauf 1: Authentifizierung des Nutzers über den IdP Der Nutzer einer epa-291a muss sich authentifizieren lassen. Ein Nutzer ist immer ein Mitarbeiter einer LEI, die über eine SMC-B verfügt. Der Mitarbeiter selbst ist entweder ein Arzt und verfügt somit über einen HBA oder er gehört einer anderen Berufsgruppe an und besitzt selbst keinen HBA. Die Authentifizierung der jeweiligen Nutzergruppe kann daher unterschiedlich erfolgen: 1. Die Authentifizierung eines LE mit HBA basiert ausschließlich auf den X.509- Zertifikaten des HBA (C.HP.AUT) und der SMC-B (C.HCI.OSIG). 2. Der Nutzer ohne HBA benötigt eine Guarantor Assertion, die mit der SMC-B der LEI signiert wird. Hiermit bestätigt die LEI, dass die betreffende Person in der LEI mit der angegebenen Authentifizierungsmethode erfolgreich authentifiziert wurde und über die in der Guarantor Assertion angegebenen Eigenschaften, z. B. Mitarbeiter dieser LEI zu sein, verfügt. Eine Guarantor Assertion kann auch für einen LE mit HBA ausgestellt werden, um ihm bestimmte Eigenschaften zuzuordnen, z. B. kurzfristig Mitarbeiter einer anderen Abteilung zu sein. Die LEI muss sicherstellen, dass die 29

38 Guarantor Assertion (Näheres siehe Abschnitt 4.2) auch später eindeutig einer Person zugeordnet werden kann. Abbildung 11 Authentifizierung des Nutzers über den IdP (Ablauf 1) Der Ablauf der Authentifizierung (siehe Abbildung 11) stellt sich wie folgt dar: Der Nutzer meldet sich am LE-System an und wird authentifiziert. In der LEI wird wie oben beschrieben optional eine Guarantor Assertion für den Nutzer einer epa-291a ausgestellt. Das LE-System beantragt bei einem IdP die Ausstellung eines Authentifizierungsnachweises, der den Nutzer berechtigen soll, den Fachdienst epa zu nutzen. Die zum Antrag gehörenden Authentisierungsdaten basieren entweder auf den X.509-Zertifikaten des HBA und der SMC-B oder der Guarantor Assertion. Der IdP prüft die Signatur des Antrags und das jeweilige X.509-Zertifkat mit Hilfe von PKI-Diensten. Im Falle positiver Prüfungsergebnisse stellt der IdP einen Authentifizierungs- 30