Initiative»Elektronische Fallakte«

Transkript

1 Deklarative Sicherheit zur Spezifikation und Implementierung der elektronischen FallAkte Workshop»Sichere Informationstechnologie für das Gesundheitswesen von morgen«gmds Jahrestagung 2010, Mannheim R. Kuhlisch, J. Caumanns, O. Boehm Fraunhofer ISST, Berlin Initiative»Elektronische Fallakte«Träger: ca. 30 Klinken und Ärztenetze ca. 10 laufende Pilotprojekte in Deutschland Etablierung einer interoperablen Lösung für effizienten, einrichtungs- und sektorübergreifenden Austausch von medizinischen Daten in diagnosebezogenen Versorgungsnetzen Paradigma eines Peer-Daten-Management-Systems Aktuell: Migration als Mehrwertanwendung in der Telematikinfrastruktur (Foto: MEV-Verlag) 2

2 efa Sicherheits-Mix Die Sicherheitsdienste und deren Zusammenspiel werden soweit als möglich deklarativ gesteuert! Preventive Controls (reduce exposure) Pseudonymisierung End-to-End-Kanäle für Abruf medizinischer Daten Absicherung von RBAC über DAC PEPs direkt an den Ressourcen Horizontale Verteidigungslinien DMZ und klar abgegrenzte Sicherheitszonen Deterrent Controls (reduce the likehood of an attack) Dezentrales Identity Management Anwendungsspezifisches Rollenkonzept Sicherheitskonzept und Datenschutzkonzept Detective Controls (discover attacks and trigger other controls) Protokollierung aller Zugriffe Corrective Controls (reduce the impact of a successful attack) Schmaler Zugang (Admission Codes) Dezentrale Datenhaltung 3 Deklarative Sicherheit Service-übergreifende Sicherheitsfunktionen werden in Security Frameworks ausgelagert Für jeden Service (und ggf. auch jedes Interface) wird beschrieben (deklariert), welche Sicherheitsfunktionen zu aktivieren sind, um einer übergeordneten Sicherheitsstrategie gerecht zu werden. Ausübung dieser Sicherheitsfunktionen ist dann Sache des Frameworks Dieser Schutzziele und Sicherdienste betonende deklarative Sicherheitsansatz steht im Gegensatz zur programmierten Sicherheit, bei der konkrete Sicherheitsmechanismen und objekte fest an die Implementierung der Anwendungslogik gebunden werden 4

3 Vorteile deklarativer Sicherheit Sicherheitsdienste und mechanismen können ohne Änderungen am Code der Anwendungsdienste weiterentwickelt und an neue Anforderungen angepasst werden In einem Security Framework enthaltene Sicherheitsdienste können sehr einfach an bestehenden Anwendungen angebunden werden. Entkopplung von Sicherheitsdiensten (z. B. für Authentifizierung und Autorisierung) Deklarative Sicherheit kann unmittelbar aus dem Sicherheitskonzept abgeleitet werden Die Kongruenz der Umsetzung von Sicherheit zu ihrer Spezifikation und einer übergeordneten Sicherheitsrichtlinie ist explizit gegeben Die umgesetzten Sicherheitsmechanismen und die genutzten Objekte werden an der Schnittselle der Dienste sichtbar und damit überprüfbar. 5 Deklarative Sicherheit Deklarative Sicherheit bietet viele Vorteile gegenüber programmierter Sicherheit: Unabhängigkeit vom Programmcode Flexibilität und Autonomie Enge Bindung zwischen Konzept und Umsetzung Reifegrad der Umsetzung (Prozessoren) Verifizierbarkeit Aber: Deklarationen als zu schützende Sicherheitsobjekte Deklarative Sicherheit bei der efa SAML Assertion Chaining WS (Security) Policies pro Port XACML zur RBAC-Umsetzung XACML zur Verifizierung von SAML Assertions 6

4 Deklarative Sicherheit bei der Schnittstellenspezifikation Entkopplung der Anwendungs- und Sicherheitsarchitektur Entkopplung Authentisierung / Autorisierung Festlegung eines Navigationsmodells Zugriff auf Datenspeicher erfordert festen Ausführungspfad unter Berücksichtigung von Zugangs- und Zugriffskontrolle Erweiterte Schnittstellenspezifikation mittels WS-Policy / WS- SecurityPolicy Securit Token, Signaturen, Algorithmen,... Forderung von Security Token auf Anwendungsebene SAML Token als Repräsentation von Authentisierungs- und Autorisierungsnachweisen von vertrauten Security Token Services X509 Token für gegenseitige Zertifikatsbasierte Dienstauthentisierung 8 Vertrauensbeziehungen im Circle-of-Trust 9

5 Web Service Schnittstellen mit differenzierten Security Policies 10 WS-SecurityPolicy: Beispiel ecr Folder Registry PT Protection Token ST Supporting Token EST Endorsing ST Port Dedicated Client Trusted Client Input Message [PT] IssuedToken: Identity Assertion DedicatedIP [ST] SAMLToken: Access Assertion AccTS, + (Policy Assertion PolTS )? [PT] X.509Token TrustedFReg [EST] X.509Token DedicatedFReg Output Message [PT] IssuedToken: Identity Asssertion DedicatedIP [PT] X.509Token DedicatedFReg [EST] X.509Token TrustedFReg Dedicated Service [ST] SAMLToken: Access Assertion AccTS, + (Policy Assertion PolTS )? [PT] X.509Token DedicatedFReg [EST] X.509Token DedicatedDReg [PT] X.509Token DedicatedDReg [EST] X.509Token DedicatedFReg Trusted Service [ST] SAMLToken: Access Assertion AccTS, + (Policy Assertion PolTS )? [PT] X.509Token DedicatedFReg [EST] X.509Token TrustedDReg [PT] X.509Token TrustedDReg [EST] X.509Token DedicatedFReg [ST] SAMLToken: Access Assertion AccTS, + (Policy Assertion PolTS )? 11

6 Deklarative Autorisierung Festlegung der Zugriffsrechte einzelner Rollen auf Fallakten in Zugriffsrichtlinien und -regeln (Access Policies) Dedizierter Sicherheitsdienst (efa Access Token Service) kann Zuweisung einer Access Policy zu gegebenen Rollen ermitteln Autorisierung Erweiterung der Assertion-Kette um weiteren Nachweis Prüfung eines Ressourcenzugriffs XACML-basiert 12 Abbildungsnachweis: OASIS: extensible Access Control Markup Language - (XACML) Version 2.0, 1 February 2005 Zuweisung von Zugriffsrechten Vorteil: Implizite und explizite Access Policies möglich 13

7 Zugriffsprüfung Principal Operation Reference monitor Resource Access Control Dataflow à la XACML PEP Context Handler PDP PAP 14 Abbildungsnachweis: Benantar M.: Access Control Systems : Security, Identity Management and Trust Models Access Control System Deklarative Sicherheit 17

8 Zusammenfassung Die elektronische Fallakte basiert auf stark entkoppelten Sicherheitsdiensten, deren Zusammenspiel deklarativ konfigurierbar ist Nutzbarkeit für weitere Anwendungen Zusammenspiel verschiedener Maßnahmen efa hat keine zentralen Durchlaufstellen für identifizierbare Daten und extrem schmale Zugänge efa eröffnet keine neuen Angriffspotenziale; die immer bestehenden Risiken können aber nur organisatorisch adressiert werden: Identitätsdiebstahl Innentäter bei unzureichender interner Zugriffskontrolle 20 Vielen Dank für Ihre Aufmerksamkeit Internetpräsenz Download der Spezifikationen Präsentationen & Publikationen IHE ITI TF White Paper zur Zugriffskontrolle bei Gesundheitsdatendiensten ork/upload/ihe_iti_tf_whitepaper_ac cesscontrol_ pdf +49 (0) 30 /