Prinzipien für Datenschutz und Datensicherheit
K |
K (Typo) |
||
(22 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
{{DocumentPart}} | {{DocumentPart}} | ||
− | ''Anmerkung: Die | + | ''Anmerkung: Die unter 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.<br>Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".'' |
---- | ---- | ||
− | == | + | == Prinzipien für Datenschutz und Datensicherheit == |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | == | + | === EFA Sicherheitsstrategie === |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Pziee.01}</tt> | |
− | |||
− | |||
− | |||
− | |||
+ | Die EFA ist eine zweckgebundene Akte. Der Zugriff auf die Akte ist auf Leistungserbringer beschränkt, die vom Patienten als Behandlungsteilnehmer benannt wurden und die im Kontext dieser Behandlung Patientendaten zu dem an die Akte gebundenen Zweck verarbeiten. | ||
− | + | Maßnahmen des Datenschutzes und der IT-Sicherheit müssen daher sicherstellen, dass eine Offenbarung von über die Akte vermittelten Daten nur | |
+ | * gegenüber in die Behandlung einbezogenen Personen und nur | ||
+ | * zu dem benannten Zweck erfolgt. | ||
+ | Darüber hinaus bedingt der Charakter der Akte als behandlungsbegleitende Kommunikationsplattform und Grundlage einer gemeinsamen Behandlungsdokumentation, dass | ||
+ | * über die Akte nur die für die Behandlung und die Behandlungsdokumentation relevanten Informationen ausgetauscht werden und | ||
+ | * die in der Akte enthaltenen Dokumente verlässlich sind in dem Sinne, als dass Urheber und Status der Dokumente für die Nutzer erkennbar ist. | ||
+ | Diese primären Zielstellungen der EFA-Sicherheit werden durch eine von den konkreten Umsetzungsmaßnahmen unabhängige Sicherheitsstrategie aufgefangen. Diese Strategie wiederum wird auf einige wenige elementare und implementierungsunabhängige Sicherheits-Kernkonzepte heruntergebrochen, die jeweils mit im EFA-Sicherheitskonzept oder der EFA-Sicherheitsarchitektur verankerten Maßnahmen hinterlegt sind. | ||
− | + | Abgeleitet aus diesen Zielstellungen wird in der EFA eine aus sechs Kernaussagen bestehende Sicherheitsstrategie verfolgt: | |
+ | ;Zusammenspiel von Sicherheitskonzept und Sicherheitsarchitektur | ||
+ | :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. | ||
+ | ;Lose Kopplung der Sicherheitsdienste untereinander und an die abzusichernden Anwendungsdienste | ||
+ | :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. <br>Sicherheit (z. B. Integrität, Vertraulichkeit, Verbindlichkeit) wird auf der Anwendungsebene als Teil der Kontroll- und Datenflüsse umgesetzt. Kontroll- und Datenflüsse werden gestuft aufgesetzt, um die Integration von Verteidigungslinien entlang der Abläufe zu unterstützen. 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. 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. | ||
+ | Sicherheitsdienste sind nicht von Eigenschaften der verwendeten Kommunikationsmechanismen abhängig. | ||
+ | ;Patienteneinwilligung und Needs-To-Know Prinzip als Grundlage aller Berechtigungen | ||
+ | :Mechanismen zum Zugriffsschutz basieren auf Identitäten (Individuen und Organisationen). Zugriffsrechte werden ausschließlich an die vom Patienten benannten Behandlungsteilnehmer 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. | ||
+ | ;EFA-Policy als Grundlage des Datenaustauschs zwischen autonomen EFA-Netzwerken | ||
+ | :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 Absicherung des Zugriffs auf medizinische Daten | ||
+ | :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. | ||
+ | ;Nutzung der Sicherheitsobjekte, -mechanismen und -maßnahmen der Telematikinfrastruktur | ||
+ | :Auch wenn die EFA selber keine Anwendung des § 291a SGB V darstellt, so gelten doch viele der für Anwendungen nach § 291a Absatz 3 SGB V benannten Anforderungen gleichermaßen. Um die parallele und idealerweise integrierte Nutzung von EFA und Anwendungen des § 291a SGB V zu ermöglichen, kann die EFA auf den Basis-Sicherheitsobjekten und -mechanismen der Telematikinfrastruktur (Karten, Kartenleser, Zertifikate, Algorithmen, etc.) aufgesetzt werden. Auch sind weite Teile der Datenschutz- und Sicherheitskonzepte der Telematikinfrastruktur auf die EFA abbildbar und erleichtern so den synergetischen Betrieb und die verzahnte Nutzung von EFA und Telematik-Diensten. | ||
− | [[Datei:EFA Assertion Chain.png| | + | === Kernkonzepte === |
+ | |||
+ | <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Pziee.02}</tt> | ||
+ | |||
+ | Aus der Sicherheitsstrategie wurden eine Reihe von technisch abgesicherten Kernkonzepten in Bezug auf die Architektur von Fallakten, deren technische Umsetzung und operative Nutzung abgeleitet. Die nachfolgende Abbildung stellt diese Konzepte im Kontext der Sicherheitsstrategie im Überblick dar. | ||
+ | |||
+ | [[Datei:Sicherheitsstrategie.png|480px]] | ||
+ | ==== Synchronität von Behandlungsteam und Berechtigungen ==== | ||
+ | |||
+ | <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Pziee.02.01}</tt> | ||
+ | |||
+ | Als Plattform für eine Behandlungskooperation und gemeinsame Behandlungsdokumentation muss eine Fallakte für alle an der Behandlung aktiv teilnehmenden Personen gleichermaßen zugreifbar sein. Ein Verbergen von Dokumenten für einzelne Teilnehmer oder eine differenzierende Berechtigungsvergabe stehen im Widerspruch zu dieser Zielsetzung der Fallaktennutzung. | ||
+ | |||
+ | Aus diesem Grund erhalten alle vom Patienten in seiner Einwilligungserklärung benannten aktiven Behandlungsteilnehmer die Berechtigung, auf alle in der Akte enthaltenen medizinischen Daten zuzugreifen und auch neue Daten in die Akte einzustellen. | ||
+ | |||
+ | Differenzierte Rollen und Berechtigungen können lediglich für passive Teilnehmer definiert werden, die Sonderrollen - z.B. durch rein administrative Aufgaben in der Verwaltung von Fallakten - ausfüllen. Beispiele hierfür sind im Abschnitt "[[cdaefa:Akteure und Rollen der EFA|Akteure und Rollen]]" aufgeführt. | ||
+ | |||
+ | Zugriffsberechtigungen sind immer an eine komplette Fallakte geknüpft und werden an alle Objekte innerhalb der Fallakte vererbt. Der Patient kann sowohl Einzelpersonen als auch Organisationen bzw. Organisationseinheiten als Behandlungsteilnehmer benennen. Dieses wird 1:1 auf das interne Berechtigungsmangement der EFA abgebildet, d.h. Zugriffsrechte werden dementsprechend entweder an Individuen oder Organisationen als EFA-Teilnehmer gebunden. Im Fall der Berechtigungsvergabe an eine Organisation(seinheit) muss die Zuordnung eines auf die Akte zugreifenden Individuums zu einer berechtigten Organisation und zum Behandlungskontext der Fallakte mit Hilfe eines dezentralen (technisch oder organisatorisch realisierten) Berechtigungsmanagements erreicht werden. Mit der Registrierung bei einem EFA-Provider verpflichtet sich eine Organisation, dieses sicherzustellen. | ||
+ | |||
+ | Die Granularität der für einen EFA-Provider technisch verifizierbaren Authentisierung (Individuum bzw. Organisation) muss auf die Granularität der Zugriffsrechte, die für eine Fallakte definiert sind, abgebildet werden können. Wenn z. B. eine Organisation für den Zugriff auf eine Fallakte autorisiert ist, muss die Zugehörigkeit eines Arztes zu dieser Organisation geprüft werden können, um ihm den Zugang zu gestatten. Dies kann z.B. dadurch erfolgen, dass eine vom EFA-Provider als vertrauenswürdig anerkannte Organisation die Zugehörigkeit des Mitarbeiters zu dieser Organisation in einer Form bestätigt, die vom EFA-Provider als authentisch und nachvollziehbar verifizierbar ist. | ||
+ | |||
+ | Ungeachtet dessen muss jede Authentisierung auf eine natürliche Person rückführbar sein, die auch im an die EFA-Dienste übermittelten Authentisierungsnachweis benannt sein muss und auch im Audit Trail vermerkt wird. D.h. auch wenn eine Autorisierung auf Ebene einer Organisation erfolgt, so bedeutet dies nicht, dass die handelnde natürliche Person gegenüber der EFA anonym bleibt. | ||
+ | |||
+ | ==== Übertragbarer Sicherheitskontext ==== | ||
+ | |||
+ | <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Pziee.02.02}</tt> | ||
+ | |||
+ | Der Sicherheitskontext eines EFA-Teilnehmers wird durch dessen Identitätsdaten, einen Nachweis der Authentizität und die im aktuellen Nutzungsszenario geltenden Zugangs- und Zugriffsberechtigungen des Teilnehmers beschrieben. Ein im aktuellen Zugriffsszenario gültiger Sicherheitskontext wird über eine Menge von aufeinander aufbauenden Sicherheitsnachweisen (Assertions) kodiert. Die nachfolgende Grafik veranschaulicht dieses Prinzip: | ||
+ | # der EFA-Teilnehmer authentisiert sich gegenüber einem vertrauenswürdigen lokalen oder als dediziertem Plattformdienst aufgesetzten Identity Provider. | ||
+ | # der Identity Provider fasst die vom EFA Berechtigungsmanagement benötigten Identitätsdaten des Teilnehmers zu einem Sicherheitsnachweis (''HP Identity Assertion'') zusammen und versieht diesen mit einer für alle EFA-Dienste verifizierbaren Signatur. | ||
+ | # sofern die Option der Pseudonymisierung von Registerdaten aktiviert ist, wird im nächsten Schritt eine sog. ''Admission Assertion'' erzeugt, die benötigt wird, um das für den Datenzugang benötigte Pseudonym des Patienten aufzulösen. Die zuvor ausgestellte ''HP Identity Assertion'' wird nicht nur für die Generierung des Pseudonyms benötigt, sondern dient auch der Absicherung, dass die bei der Pseudonymgenerierung verwendeten Daten authentisch sind. | ||
+ | # die EFA unterstützt u.a. das sog. "Policy Push" Verfahren, bei dem der EFA-Teilnehmer von einem dedizierten Dienst seine aktuell gültigen Berechtigungen abruft. Die Authentisierung und Identifizierung gegenüber diesem Dienst erfolgt über die ''HP Identity Assertion'' bzw. im Fall pseudonymer Registerdaten über die ''Admission Assertion''. Die Berechtigungen werden in einem Berechtigungsnachweis (''Policy Assertion'')zusammengefasst, der fest mit der ''HP Identity Assertion'' verknüpft ist. Ein Berechtigungsnachweis ist nur zusammen mit einem auf den selben Nutzer ausgestellten authentischen Identitätsnachweis gültig. | ||
+ | # Alle entlang der Kette eingesammelten und miteinander verknüpften Assertions werden beim AUfruf eines Fachdiensts übergeben. Dieser prüft die Authentizität der Assertions, die Authentizität des EFA-Teilnehmers und setzt anschließend die in der ''Policy Assertion'' kodierten Berechtigungen des Nutzers durch. | ||
+ | |||
+ | Durch diese Verkettung von Sicherheitsnachweisen wird faktisch der beim Aufrufer gültige Sicherheitskontext an einen Fachdienst übermittelt und kann dort zur Prüfung und Durchsetzung von Berechtigungen rekonstruiert werden. | ||
+ | |||
+ | [[Datei:EFA Assertion Chain.png|640px]] | ||
+ | |||
+ | ==== Deklarative Sicherheit ==== | ||
+ | |||
+ | <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Pziee.02.03}</tt> | ||
− | |||
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. | 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. | ||
Zeile 45: | Zeile 84: | ||
* 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 | * 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 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 | + | * Die umgesetzten Sicherheitsmechanismen und die genutzten Objekte werden an der Schnittstelle der Dienste sichtbar und damit überprüfbar. |
Die Sicherheitsdienste der EFA v2.0 setzen wo immer machbar und sinnvoll Konzepte einer deklarativen Sicherheit um. | Die Sicherheitsdienste der EFA v2.0 setzen wo immer machbar und sinnvoll Konzepte einer deklarativen Sicherheit um. | ||
− | === | + | ==== Policy Enforcement dicht an den Ressourcen ==== |
+ | |||
+ | <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Pziee.02.04}</tt> | ||
+ | |||
+ | Sofern die Organisation eines EFA-Teilnehmers nicht selbst als EFA-Provider fungiert, erfolgt die Bereitstellung von Daten dieses Teilnehmers über einen Provider den Tatbestand einer Auftragsdatenverarbeitung. Dieses legt dem Teilnehmer besondere Pflichten in der Auswahl des Providers auf; gleichzeitig muss der Provider für die im Auftrag verwalteten Daten ein den regulativen Vorgaben genügendes Niveau an Datenschutz und Datensicherheit sicherstellen. | ||
+ | |||
+ | Insbesondere in einem weitgehend auf gegenseitigem Vertrauen der EFA-Peers basierenden Verbund stellt dies große Herausforderungen, da letzten Endes jeder Provider nur die Sicherheitszusagen machen kann, die er auch selbst technisch, organisatorisch und/oder juristisch durchsetzen kann. | ||
+ | |||
+ | Um den Provider entsprechend zu befähigen, gilt für die EFA, dass jeder Provider für die bei ihm vorgehaltenen Daten für die Prüfung und Durchsetzung der aus der Patienteneinwilligung abgeleiteten Zugriffsberechtigungen verantwortlich ist und diese auch selbst durchführen muss. Zusätzlich ist jeder Provider für die korrekte Abbildung der Angaben aus der Patienteneinwilligung (insb. berechtigte Teilnehmer) auf sein Zugriffskontrollsystem verantwortlich. Da hierzu eine Verarbeitung von potenziell über andere Akteure erhobene Daten unabdingbar ist (z.B. von einem anderen Provider bestätigter Nachweise einer Nutzer-Authentisierung oder gegenüber einem Arzt gegebene Einwilligung) ist es unabdingbar, dass die Systemteilnehmer untereinander die gegenseitige Vertrauensstellung ausreichend absichernde vertragliche Bindungen eingehen. | ||
+ | |||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | {{NoteBox|'''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]] | ||
+ | <nowiki></nowiki> | ||
+ | }} |
Aktuelle Version vom 27. Januar 2015, 12:28 Uhr
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
Anmerkung: Die unter 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".
Inhaltsverzeichnis
Prinzipien für Datenschutz und Datensicherheit
EFA Sicherheitsstrategie
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Pziee.01}
Die EFA ist eine zweckgebundene Akte. Der Zugriff auf die Akte ist auf Leistungserbringer beschränkt, die vom Patienten als Behandlungsteilnehmer benannt wurden und die im Kontext dieser Behandlung Patientendaten zu dem an die Akte gebundenen Zweck verarbeiten.
Maßnahmen des Datenschutzes und der IT-Sicherheit müssen daher sicherstellen, dass eine Offenbarung von über die Akte vermittelten Daten nur
- gegenüber in die Behandlung einbezogenen Personen und nur
- zu dem benannten Zweck erfolgt.
Darüber hinaus bedingt der Charakter der Akte als behandlungsbegleitende Kommunikationsplattform und Grundlage einer gemeinsamen Behandlungsdokumentation, dass
- über die Akte nur die für die Behandlung und die Behandlungsdokumentation relevanten Informationen ausgetauscht werden und
- die in der Akte enthaltenen Dokumente verlässlich sind in dem Sinne, als dass Urheber und Status der Dokumente für die Nutzer erkennbar ist.
Diese primären Zielstellungen der EFA-Sicherheit werden durch eine von den konkreten Umsetzungsmaßnahmen unabhängige Sicherheitsstrategie aufgefangen. Diese Strategie wiederum wird auf einige wenige elementare und implementierungsunabhängige Sicherheits-Kernkonzepte heruntergebrochen, die jeweils mit im EFA-Sicherheitskonzept oder der EFA-Sicherheitsarchitektur verankerten Maßnahmen hinterlegt sind.
Abgeleitet aus diesen Zielstellungen wird in der EFA eine aus sechs Kernaussagen bestehende Sicherheitsstrategie verfolgt:
- Zusammenspiel von Sicherheitskonzept und Sicherheitsarchitektur
- 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.
- Lose Kopplung der Sicherheitsdienste untereinander und an die abzusichernden Anwendungsdienste
- 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.
Sicherheit (z. B. Integrität, Vertraulichkeit, Verbindlichkeit) wird auf der Anwendungsebene als Teil der Kontroll- und Datenflüsse umgesetzt. Kontroll- und Datenflüsse werden gestuft aufgesetzt, um die Integration von Verteidigungslinien entlang der Abläufe zu unterstützen. 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. 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.
Sicherheitsdienste sind nicht von Eigenschaften der verwendeten Kommunikationsmechanismen abhängig.
- Patienteneinwilligung und Needs-To-Know Prinzip als Grundlage aller Berechtigungen
- Mechanismen zum Zugriffsschutz basieren auf Identitäten (Individuen und Organisationen). Zugriffsrechte werden ausschließlich an die vom Patienten benannten Behandlungsteilnehmer 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.
- EFA-Policy als Grundlage des Datenaustauschs zwischen autonomen EFA-Netzwerken
- 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 Absicherung des Zugriffs auf medizinische Daten
- 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.
- Nutzung der Sicherheitsobjekte, -mechanismen und -maßnahmen der Telematikinfrastruktur
- Auch wenn die EFA selber keine Anwendung des § 291a SGB V darstellt, so gelten doch viele der für Anwendungen nach § 291a Absatz 3 SGB V benannten Anforderungen gleichermaßen. Um die parallele und idealerweise integrierte Nutzung von EFA und Anwendungen des § 291a SGB V zu ermöglichen, kann die EFA auf den Basis-Sicherheitsobjekten und -mechanismen der Telematikinfrastruktur (Karten, Kartenleser, Zertifikate, Algorithmen, etc.) aufgesetzt werden. Auch sind weite Teile der Datenschutz- und Sicherheitskonzepte der Telematikinfrastruktur auf die EFA abbildbar und erleichtern so den synergetischen Betrieb und die verzahnte Nutzung von EFA und Telematik-Diensten.
Kernkonzepte
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Pziee.02}
Aus der Sicherheitsstrategie wurden eine Reihe von technisch abgesicherten Kernkonzepten in Bezug auf die Architektur von Fallakten, deren technische Umsetzung und operative Nutzung abgeleitet. Die nachfolgende Abbildung stellt diese Konzepte im Kontext der Sicherheitsstrategie im Überblick dar.
Synchronität von Behandlungsteam und Berechtigungen
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Pziee.02.01}
Als Plattform für eine Behandlungskooperation und gemeinsame Behandlungsdokumentation muss eine Fallakte für alle an der Behandlung aktiv teilnehmenden Personen gleichermaßen zugreifbar sein. Ein Verbergen von Dokumenten für einzelne Teilnehmer oder eine differenzierende Berechtigungsvergabe stehen im Widerspruch zu dieser Zielsetzung der Fallaktennutzung.
Aus diesem Grund erhalten alle vom Patienten in seiner Einwilligungserklärung benannten aktiven Behandlungsteilnehmer die Berechtigung, auf alle in der Akte enthaltenen medizinischen Daten zuzugreifen und auch neue Daten in die Akte einzustellen.
Differenzierte Rollen und Berechtigungen können lediglich für passive Teilnehmer definiert werden, die Sonderrollen - z.B. durch rein administrative Aufgaben in der Verwaltung von Fallakten - ausfüllen. Beispiele hierfür sind im Abschnitt "Akteure und Rollen" aufgeführt.
Zugriffsberechtigungen sind immer an eine komplette Fallakte geknüpft und werden an alle Objekte innerhalb der Fallakte vererbt. Der Patient kann sowohl Einzelpersonen als auch Organisationen bzw. Organisationseinheiten als Behandlungsteilnehmer benennen. Dieses wird 1:1 auf das interne Berechtigungsmangement der EFA abgebildet, d.h. Zugriffsrechte werden dementsprechend entweder an Individuen oder Organisationen als EFA-Teilnehmer gebunden. Im Fall der Berechtigungsvergabe an eine Organisation(seinheit) muss die Zuordnung eines auf die Akte zugreifenden Individuums zu einer berechtigten Organisation und zum Behandlungskontext der Fallakte mit Hilfe eines dezentralen (technisch oder organisatorisch realisierten) Berechtigungsmanagements erreicht werden. Mit der Registrierung bei einem EFA-Provider verpflichtet sich eine Organisation, dieses sicherzustellen.
Die Granularität der für einen EFA-Provider technisch verifizierbaren Authentisierung (Individuum bzw. Organisation) muss auf die Granularität der Zugriffsrechte, die für eine Fallakte definiert sind, abgebildet werden können. Wenn z. B. eine Organisation für den Zugriff auf eine Fallakte autorisiert ist, muss die Zugehörigkeit eines Arztes zu dieser Organisation geprüft werden können, um ihm den Zugang zu gestatten. Dies kann z.B. dadurch erfolgen, dass eine vom EFA-Provider als vertrauenswürdig anerkannte Organisation die Zugehörigkeit des Mitarbeiters zu dieser Organisation in einer Form bestätigt, die vom EFA-Provider als authentisch und nachvollziehbar verifizierbar ist.
Ungeachtet dessen muss jede Authentisierung auf eine natürliche Person rückführbar sein, die auch im an die EFA-Dienste übermittelten Authentisierungsnachweis benannt sein muss und auch im Audit Trail vermerkt wird. D.h. auch wenn eine Autorisierung auf Ebene einer Organisation erfolgt, so bedeutet dies nicht, dass die handelnde natürliche Person gegenüber der EFA anonym bleibt.
Übertragbarer Sicherheitskontext
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Pziee.02.02}
Der Sicherheitskontext eines EFA-Teilnehmers wird durch dessen Identitätsdaten, einen Nachweis der Authentizität und die im aktuellen Nutzungsszenario geltenden Zugangs- und Zugriffsberechtigungen des Teilnehmers beschrieben. Ein im aktuellen Zugriffsszenario gültiger Sicherheitskontext wird über eine Menge von aufeinander aufbauenden Sicherheitsnachweisen (Assertions) kodiert. Die nachfolgende Grafik veranschaulicht dieses Prinzip:
- der EFA-Teilnehmer authentisiert sich gegenüber einem vertrauenswürdigen lokalen oder als dediziertem Plattformdienst aufgesetzten Identity Provider.
- der Identity Provider fasst die vom EFA Berechtigungsmanagement benötigten Identitätsdaten des Teilnehmers zu einem Sicherheitsnachweis (HP Identity Assertion) zusammen und versieht diesen mit einer für alle EFA-Dienste verifizierbaren Signatur.
- sofern die Option der Pseudonymisierung von Registerdaten aktiviert ist, wird im nächsten Schritt eine sog. Admission Assertion erzeugt, die benötigt wird, um das für den Datenzugang benötigte Pseudonym des Patienten aufzulösen. Die zuvor ausgestellte HP Identity Assertion wird nicht nur für die Generierung des Pseudonyms benötigt, sondern dient auch der Absicherung, dass die bei der Pseudonymgenerierung verwendeten Daten authentisch sind.
- die EFA unterstützt u.a. das sog. "Policy Push" Verfahren, bei dem der EFA-Teilnehmer von einem dedizierten Dienst seine aktuell gültigen Berechtigungen abruft. Die Authentisierung und Identifizierung gegenüber diesem Dienst erfolgt über die HP Identity Assertion bzw. im Fall pseudonymer Registerdaten über die Admission Assertion. Die Berechtigungen werden in einem Berechtigungsnachweis (Policy Assertion)zusammengefasst, der fest mit der HP Identity Assertion verknüpft ist. Ein Berechtigungsnachweis ist nur zusammen mit einem auf den selben Nutzer ausgestellten authentischen Identitätsnachweis gültig.
- Alle entlang der Kette eingesammelten und miteinander verknüpften Assertions werden beim AUfruf eines Fachdiensts übergeben. Dieser prüft die Authentizität der Assertions, die Authentizität des EFA-Teilnehmers und setzt anschließend die in der Policy Assertion kodierten Berechtigungen des Nutzers durch.
Durch diese Verkettung von Sicherheitsnachweisen wird faktisch der beim Aufrufer gültige Sicherheitskontext an einen Fachdienst übermittelt und kann dort zur Prüfung und Durchsetzung von Berechtigungen rekonstruiert werden.
Deklarative Sicherheit
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Pziee.02.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 Schnittstelle der Dienste sichtbar und damit überprüfbar.
Die Sicherheitsdienste der EFA v2.0 setzen wo immer machbar und sinnvoll Konzepte einer deklarativen Sicherheit um.
Policy Enforcement dicht an den Ressourcen
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Pziee.02.04}
Sofern die Organisation eines EFA-Teilnehmers nicht selbst als EFA-Provider fungiert, erfolgt die Bereitstellung von Daten dieses Teilnehmers über einen Provider den Tatbestand einer Auftragsdatenverarbeitung. Dieses legt dem Teilnehmer besondere Pflichten in der Auswahl des Providers auf; gleichzeitig muss der Provider für die im Auftrag verwalteten Daten ein den regulativen Vorgaben genügendes Niveau an Datenschutz und Datensicherheit sicherstellen.
Insbesondere in einem weitgehend auf gegenseitigem Vertrauen der EFA-Peers basierenden Verbund stellt dies große Herausforderungen, da letzten Endes jeder Provider nur die Sicherheitszusagen machen kann, die er auch selbst technisch, organisatorisch und/oder juristisch durchsetzen kann.
Um den Provider entsprechend zu befähigen, gilt für die EFA, dass jeder Provider für die bei ihm vorgehaltenen Daten für die Prüfung und Durchsetzung der aus der Patienteneinwilligung abgeleiteten Zugriffsberechtigungen verantwortlich ist und diese auch selbst durchführen muss. Zusätzlich ist jeder Provider für die korrekte Abbildung der Angaben aus der Patienteneinwilligung (insb. berechtigte Teilnehmer) auf sein Zugriffskontrollsystem verantwortlich. Da hierzu eine Verarbeitung von potenziell über andere Akteure erhobene Daten unabdingbar ist (z.B. von einem anderen Provider bestätigter Nachweise einer Nutzer-Authentisierung oder gegenüber einem Arzt gegebene Einwilligung) ist es unabdingbar, dass die Systemteilnehmer untereinander die gegenseitige Vertrauensstellung ausreichend absichernde vertragliche Bindungen eingehen.
Referenzen und Querverweise |