Prinzipien für Datenschutz und Datensicherheit
Foemig (Diskussion | Beiträge) K |
Foemig (Diskussion | Beiträge) K |
||
Zeile 12: | Zeile 12: | ||
== Kernkonzepte == | == Kernkonzepte == | ||
Aus der Sicherheitsstrategie wurden eine Reihe von Kernkonzepten in Bezug auf die Architektur von Fallakten, deren Betrieb und ihre technische Umsetzung abgeleitet. Wesentliche Konzepte und damit zugleich Umsetzungsvorgaben für die Systemarchitektur sind: | Aus der Sicherheitsstrategie wurden eine Reihe von Kernkonzepten in Bezug auf die Architektur von Fallakten, deren Betrieb und ihre technische Umsetzung abgeleitet. Wesentliche Konzepte und damit zugleich Umsetzungsvorgaben für die Systemarchitektur sind: | ||
− | * Sicherheit (z. B. Integrität, Vertraulichkeit, Verbindlichkeit) wird auf der Anwendungsebene als Teil der Kontroll- und Datenflüsse umgesetzt. Sicherheitsdienste sind nicht von Eigenschaften der verwendeten Kommunikationsmechanismen abhängig. Verteidigungslinien | + | * Sicherheit (z. B. Integrität, Vertraulichkeit, Verbindlichkeit) wird auf der Anwendungsebene als Teil der Kontroll- und Datenflüsse umgesetzt. Sicherheitsdienste sind nicht von Eigenschaften der verwendeten Kommunikationsmechanismen abhängig. Verteidigungslinien entlang der Abläufe ermöglichen es datenhaltenden Diensten die Integrität von Nachrichten und Daten sowie die Gültigkeit von Autorisierungen auf Basis lokal verfügbarer Informationen zu verifizieren. |
* Durch die Föderation von eFA-Anbietern können unterschiedliche Sicherheitsrichtlinien, operationale Modelle und Zugriffssemantiken parallel genutzt werden. Es wird kein allumfassendes Zugriffsmodell vorgegeben. Stattdessen stellt die Architektur ausschließlich Kernmechanismen zur Verfügung, die durch Implementierungen erweitert werden können. Anbieter müssen jedoch die gegenseitige Abbildbarkeit ihrer Zugriffsregeln sicherstellen. | * Durch die Föderation von eFA-Anbietern können unterschiedliche Sicherheitsrichtlinien, operationale Modelle und Zugriffssemantiken parallel genutzt werden. Es wird kein allumfassendes Zugriffsmodell vorgegeben. Stattdessen stellt die Architektur ausschließlich Kernmechanismen zur Verfügung, die durch Implementierungen erweitert werden können. Anbieter müssen jedoch die gegenseitige Abbildbarkeit ihrer Zugriffsregeln sicherstellen. | ||
* Sicherheits- und Anwendungsarchitektur werden von einander entkoppelt, um die Komplexität der Systemarchitektur und ihrer Implementierungen zu reduzieren. Alle Sicherheitsdienste müssen anwendungsunabhängig sein. Anwendungsdienste dürfen sich nicht auf bestimmte Implementierungen von Sicherheitsdiensten beziehen. | * Sicherheits- und Anwendungsarchitektur werden von einander entkoppelt, um die Komplexität der Systemarchitektur und ihrer Implementierungen zu reduzieren. Alle Sicherheitsdienste müssen anwendungsunabhängig sein. Anwendungsdienste dürfen sich nicht auf bestimmte Implementierungen von Sicherheitsdiensten beziehen. |
Version vom 20. März 2013, 08:03 Uhr
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
Inhaltsverzeichnis
EFA Sicherheitsstrategie
Kernaussagen der realisierungsunabhängigen Sicherheitsstrategie sind:
- Mechanismen zum Zugriffsschutz basieren auf Identitäten (Individuen und Organisationen). Zugriffsrechte werden vom Patienten vergeben, sind synchron zu den fachlichen Zugriffserfordernissen aufgesetzt und gelten immer für eine Fallakte als Ganzes. Berechtigungen werden mit Identitäten verknüpft, indem Rollen des Fachkontextes mit Personen und/oder Organisation instanziiert werden.
- Um die spezifizierten Sicherheitsziele zu erreichen, müssen sowohl organisatorische als auch technische Umsetzungswege in Betracht gezogen werden. Wünschenswert sind ein integriertes, stringentes Sicherheitskonzept und eine von der Anwendung entkoppelte, einfach aufgebaute Sicherheitsarchitektur nach den Vorgaben von ISO-7498-2. Nutzungseinschränkungen und Restriktionen in Bezug auf die Umsetzung der funktionalen Anforderungen können zur Vermeidung technischer Komplexität in Kauf genommen werden.
- Kontroll- und Datenflüsse werden gestuft aufgesetzt, um die Integration von Verteidigungslinien entlang der Abläufe zu unterstützen. Der Zugang zur eFA-Anwendung, die Suche nach Fallakten eines Patienten, das Öffnen einer Fallakte und er Zugang zu einem medizinischen Datenobjekt werden dabei als entkoppelte Aktionen aufgefasst, die über jeweils eigene, entlang der Navigation abgeleitete Sicherheits-Token autorisiert werden. Das Ziel hierbei ist, Sicherheit möglichst vollständig auf der Anwendungsschicht anzusiedeln, um eine hohe Flexibilität in Bezug auf die Umsetzung der tieferen Schichten zu erreichen.
- Die Vermittlung von Vertrauen, die Abbildung von Sicherheitsrichtlinien und die Weitergabe von Identitätsinformationen zwischen eng integrierten EFA-Netzwerken werden durch eine Föderation dieser Netzwerke realisiert.
- Ein Mechanismus, um Sicherheitsziele in Bezug auf den Schutz von Vertraulichkeit umzusetzen, besteht in der Nutzung von Pseudonymen für Patienten und deren Akten. Assoziationen zwischen Fallakten (Daten) und Patienten können so nur durch autorisierte Ärzte und unter Einhaltung stark strukturierter Abläufe hergestellt werden.
- Ende-zu-Ende-Integrität und Ende-zu-Ende-Vertraulichkeit wird zwischen den Endpunkten "EFA Teilnehmer" und "EFA Datenspeicher (Repository)" hergestellt. Integrität wird nicht als statischer Zustand eines Objektes betrachtet, sondern als Eigenschaft, die entlang der Kontroll- und Datenflüsse propagiert wird. Vertraulichkeit wird nur hergestellt, wenn sie erforderlich ist.
Kernkonzepte
Aus der Sicherheitsstrategie wurden eine Reihe von Kernkonzepten in Bezug auf die Architektur von Fallakten, deren Betrieb und ihre technische Umsetzung abgeleitet. Wesentliche Konzepte und damit zugleich Umsetzungsvorgaben für die Systemarchitektur sind:
- Sicherheit (z. B. Integrität, Vertraulichkeit, Verbindlichkeit) wird auf der Anwendungsebene als Teil der Kontroll- und Datenflüsse umgesetzt. Sicherheitsdienste sind nicht von Eigenschaften der verwendeten Kommunikationsmechanismen abhängig. Verteidigungslinien entlang der Abläufe ermöglichen es datenhaltenden Diensten die Integrität von Nachrichten und Daten sowie die Gültigkeit von Autorisierungen auf Basis lokal verfügbarer Informationen zu verifizieren.
- Durch die Föderation von eFA-Anbietern können unterschiedliche Sicherheitsrichtlinien, operationale Modelle und Zugriffssemantiken parallel genutzt werden. Es wird kein allumfassendes Zugriffsmodell vorgegeben. Stattdessen stellt die Architektur ausschließlich Kernmechanismen zur Verfügung, die durch Implementierungen erweitert werden können. Anbieter müssen jedoch die gegenseitige Abbildbarkeit ihrer Zugriffsregeln sicherstellen.
- Sicherheits- und Anwendungsarchitektur werden von einander entkoppelt, um die Komplexität der Systemarchitektur und ihrer Implementierungen zu reduzieren. Alle Sicherheitsdienste müssen anwendungsunabhängig sein. Anwendungsdienste dürfen sich nicht auf bestimmte Implementierungen von Sicherheitsdiensten beziehen.
- Zugriffsberechtigungen sind immer an den (virtuellen) Wurzelknoten einer Fallakte geknüpft. Berechtigungen werden an alle Informationsobjekte innerhalb der Fallakte vererbt. Rechte werden entweder an Individuen oder Organisationen vergeben. Die Zuordnung eines Individuums zu einer Organisation wird mit Hilfe eines dezentralen Identitätsmanagements erreicht.
- Autorisierungsnachweise sind nur in Verbindung mit Authentisierungsnachweisen gültig. Verifizierbare Authentisierungen können für verschiedene Dienste genutzt werden und können an mehrere Zugangsberechtigungen gebunden sein (Single Sign-On). Autorisierungstoken sind nur während eines einzigen Schritts innerhalb des Navigationsmodells gültig. Dies führt zu Schutzebenen, die sich nicht nach technischen Schichten richten, sondern in den Objekt- und Kontrollfluss eingebettet sind.
- Innerhalb der Objekt- und Kontrollflüsse werden Pseudonyme an Stelle von personenbezogenen Identifikationen verwendet. Die Zugriffsinformationen, Strukturinformationen und Metadaten einer Fallakte sowie alle Nachrichten zur Navigation innerhalb der eFA enthalten keine Informationen zur Identität des Patienten.
- Identitätsinformationen zu jedem Arzt bzw. jeder Organisation werden von einem einzelnen Provider verwaltet, um Redundanzen und damit Synchronisationsprobleme zu vermeiden. Jeder Arzt und jede Organisation ist einem Single Point of Access zugeordnet, an dem deren Authentisierung und die Zuordnung von Identitätsdaten stattfinden.
- Die Granularität der Authentisierung (Individuum bzw. Organisation) sollte mit der Granularität der Zugriffsrechte, die für eine Fallakte definiert sind, übereinstimmen. Wenn z. B. eine Organisation für den Zugriff auf eine Fallakte autorisiert ist, muss nur die Zugehörigkeit eines Arztes zu dieser Organisation geprüft werden, um ihm den Zugang zu gestatten.
Elementare Sicherheitsmaßnahmen der EFA
Grundlage von Datenschutz und Datensicherheit bei der EFA und damit der Umsetzung der oben skizzierten Kernkonzeote sind vier elementare Maßnahmen, die ein angemessenes Schutzniveau realisieren ohne dass hierdurch die Interaktion von Arzt und Patient beeinflusst oder verkompliziert würde:
- Synchronität von Behandlungsteam und Berechtigungen
- Kryptografische Absicherung des EFA-Zugangs
- Übertragbarer Sicherheitskontext
- Deklarative Sicherheit
Synchronität von Behandlungsteam und Berechtigungen
Kryptografische Absicherung des EFA-Zugangs
Übertragbarer Sicherheitskontext
Deklarative Sicherheit
Sicherheitsfunktionen zur Erfüllung von Anforderungen an die Vertraulichkeit und Authentizität von geschützten Daten folgen oftmals dem gleichen Muster: Eine die geschützte Ressource kapselnde Anwendung erhält einen Dienstaufruf. Der Aufrufende muss authentisiert und anschließend autorisiert werden. Dies führt zum Zugriff auf entsprechende Ressourcen oder eben nicht. Hier liegt es nahe, solche wiederkehrende Aufgaben in Security Frameworks auszulagern und zu beschreiben (deklarieren), welche Sicherheitsfunktionen zu aktivieren sind, um einer übergeordneten Sicherheitsstrategie gerecht zu werden. Die Ausübung dieser Sicherheitsfunktionen ist dann Sache des Frameworks. Dieser Schutzziele und Sicherheitsdienste betonende deklarative Sicherheitsansatz steht im Gegensatz zur programmierten Sicherheit, bei der konkrete Sicherheitsmechanismen und –objekte fest an die Implementierung der Anwendungslogik gebunden werden. Ziel ist es hierbei immer, die für eine Komponente oder Kommunikationsbeziehung geltenden Sicherheitsziele zu beschreiben und die Auswahl des geeigneten Mechanismus dem Framework zu überlassen.
Die Nutzung deklarativer Sicherheit bietet eine Reihe von Vorteilen:
- Sicherheitsdienste und –mechanismen können ohne Änderungen am Code der Anwendungsdienste weiterentwickelt und an neue Anforderungen angepasst werden
- In einem Framework enthaltene Stubs der Sicherheitsdienste können sehr einfach an bestehenden Anwendungen angebunden werden. Hierdurch wird eine Entkopplung von Sicherheitsdiensten - z. B. für Authentifizierung und Autorisierung – unterstützt
- Die Kongruenz der Umsetzung von Sicherheit zu ihrer Spezifikation und einer übergeordneten Sicherheitsrichtlinie ist explizit gegeben, d. h. deklarative Sicherheit kann unmittelbar aus dem Sicherheitskonzept abgeleitet werden
- Die umgesetzten Sicherheitsmechanismen und die genutzten Objekte werden an der Schnittselle der Dienste sichtbar und damit überprüfbar.
Die Sicherheitsdienste der EFA v2.0 setzen wo immer machbar und sinnvoll Konzepte einer deklarativen Sicherheit um.
- zurück zur EFA-2.0-Spezifikation