Prinzipien für Datenschutz und Datensicherheit

Aus Hl7wiki
(Teildokument von CDA für die elektronische Fallakte)
Wechseln zu: Navigation, Suche
K (EFA Sicherheitsstrategie {Pzie.01})
(Referenzen und Querverweise)
Zeile 50: Zeile 50:
 
=== Referenzen und Querverweise ===
 
=== Referenzen und Querverweise ===
  
 +
* [http://www.fallakte.de/images/stories/pdf/spezifikationen/eFA1.2-Sicherheit_und_Datenschutz/090701-eFA2-Datenschutzkonzept-V1.2.3.4_eFAVerein.pdf Datenschutzkonzept der EFA Version 1.2]
 +
* [http://www.fallakte.de/images/stories/pdf/spezifikationen/eFA1.2-Sicherheit_und_Datenschutz/eFA1.2-Sicherheitskonzept-v1.2.0.12.pdf Sicherheitskonzept der EFA Version 1.2]
 
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
 
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

Version vom 12. April 2013, 05:27 Uhr

Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die hinter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".


EFA Sicherheitsstrategie {Pzie.01}

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 Organisationen instanziiert werden.
  • Um die spezifizierten Sicherheitsziele zu erreichen, müssen sowohl organisatorische als auch technische Umsetzungswege in Betracht gezogen werden. Basis der IT-Sicherheit der EFA 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, der Abruf digitaler Identitäten, der Zugang zu einer Fallakte und der Zugriff auf medizinische Datenobjekte werden als entkoppelte Aktionen aufgefasst, die über unterschiedliche, möglichst voneinander unabhängige Maßnahmen abgesichert werden.
  • 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.
  • Ende-zu-Ende-Integrität und Ende-zu-Ende-Vertraulichkeit wird zwischen den Endpunkten "EFA Teilnehmer" und "EFA Datenspeicher (Repository)" hergestellt, um einen sicheren Austausch medizinischer Datenobjekte zu realisieren.

Kernkonzepte {Pzie.02}

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 {Pzie.03}

Grundlage von Datenschutz und Datensicherheit bei der EFA und damit der Umsetzung der oben skizzierten Kernkonzeote sind drei 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
  • Übertragbarer Sicherheitskontext
  • Deklarative Sicherheit


Synchronität von Behandlungsteam und Berechtigungen {Pzie.03.01}

Übertragbarer Sicherheitskontext {Pzie.03.02}

EFA Assertion Chain.png

Deklarative Sicherheit {Pzie.03.03}

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.

Referenzen und Querverweise