EFA Security Informationsmodell
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
EFA Sicherheitskontext
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.01}
Alle Aufrufe einer EFA-Funktionalität erfolgen innerhalb eines definierten Sicherheitskontextes, der über den EFA Context Manager aufgebaut und verwaltet wird.
Grundsätzlich macht diese Spezifikation nur wenige Vorgaben, welche Sicherheitsobjekte im Sicherheitskontext abgelegt sind und wie diese Objekte in den Sicherheitskontext gelangen. Hierdurch entkoppelt der über ein context-Objekt gekapselte Sicherheitskontext die EFA-Anwendungsarchitektur von der darunter liegenden Sicherheitsarchitektur. EFA-Dienste erhalten mit jedem Operationsaufruf eine Kopie des lokalen context-Objekts und können anhand der darin enthaltenen Informationen die eigenen Sicherheitsdienste zur Authentisierung und Autorisierung ausführen.
PIM Data Structures
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.02}
Die nachfolgend beschriebenen Objektklassen werden im Rahmen des EFA Service Functional Model verwendet und bilden das Informationsmodel des Platform Independent Model der EFA Sicherheitsarchitektur.
context
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.02.01}
Die Klasse context entkoppelt Anwendungs- und Sicherheitsarchitektur der EFA. Jeder Aufruf einer EFA-Operation enthält eine Kopie des im lokalen EFA Context Manager des EFA-Clients verwalteten context-Objekts.
Während in der EFA-1.2-Spezifikation noch vier Sicherheitsnachweise über die Klasse context gekapselt wurden, sind in der EFA-2.0-Spezifikation zunächst nur zwei Nachweise normativ spezifiziert. Weitere Sicherheitsnachweise können für Ergänzungen dieser Spezifikation bzw. auch für einzelne Umsetzungen der EFA 2.0 definiert werden. Wesentlich ist lediglich, dass hierbei das logische Konstrukt des context zur Verwaltung und zum Austausch dieser Nachweise genutzt wird. Hierdurch sind die Interoperabilität auf der logischen Ebene sowie die grundsätzliche Migrationsfähigkeit in die Telematikinfrastruktur sichergestellt.
Die nebenstehende Abbildung stellt den Aufbau der context-Klasse dar:
- eine subjectIdentity kapselt die Identität des EFA-Teilnehmers und sichert bei Dienstaufrufen die Authentizität des EFA-Teilnehmers ab.
- eine subjectAccessPolicy beschreibt die Zugriffsberechtigungen des über die subjectIdentity identifizierten EFA-Teilnehmers.
In jedem Sicherheitskontext muss genau ein subjectIdentity-Objekt vorhanden sein. Dieses wird durch den EFA Context Manager im Rahmen der Identifizierung und Authentifizierung des EFA-Teilnehmers von einem Identity Provider ausgestellt. Die Umsetzung des Identity Providers kann flexibel ausgestaltet werden, wodurch nicht nur ein Single Sign-On aus einem Primärsystem heraus sondern auch eine Nutzung der Sicherheitsobjekte und -mechanismen der Telematikinfrastruktur unterstützt werden (siehe Optionen zur Authentifizierung von EFA-Teilnhemern).
Eine subjectAccessPolicy ist nur bei Verwendung eines Policy-Push Verfahrens Bestandteil des Sicherheitskontextes. Ansonsten erfolgt der Abruf von Berechtigungsregeln on demand über den EFA-Dienst, der die angefragte Ressource verwaltete.
Sofern weitere Sicherheitsnachweise über ein context-Objekt verwaltet und ausgetauscht werden sollen, müssen diese direkt oder indirekt an das subjectIdentity-Objekt gebunden sein, da nur so eine integre und authentische Nachweis-Kette aufgebaut werden kann.
subjectIdentity
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.02.02}
Dieses Sicherheitsobjekt fasst Informationen zu einem EFA-Teilnehmer zusammen. Es wird mit jeder Anfrage an einen EFA-Dienst übermittelt und soll es dem aufgerufenen Dienst ermöglichen, den Aufrufer zu authentisieren und dessen Berechtigungen anhand der verfügbar gemachten Informationen auszuwerten und durchzusetzen.
In einem subjectIdentity Nachweis müssen mindestens die folgenden Informationen enthalten sein:
- ID des EFA-Teilnehmers
- Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In der subjectIdentity muss ein eindeutiger Identifier des EFA-Teilnehmers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert (bzw. idealerweise sogar identisch ist).
- Name des EFA-Teilnehmers
- Anhand der im Audit Trail zu Datenschutzzwecken protokollierten Aktenzugriffe muss der Patient Information darüber erhalten können, wer wann und wieso auf welche Daten des Patienten zugegriffen hat. In der subjectIdentity muss der Klartextname des EFA-Teilnehmers (als Person) enthalten sein, da diese Information für das Schreiben eines auch für den Patienten nachvollziehbaren Zugriffsprotokoll benötigt wird.
- Art der Authentifizierung und authentifizierende Stelle
- Jeder EFA-Provider ist für den Schutz der bei ihm verwalteten Daten verantwortlich (siehe EFA Sicherheitsprinzipien). Hierzu gehört, dass der Provider die Vertrauenswürdigkeit einer ggf. an anderer Stelle vorgenommenen Authentifizierung bewerten können muss. Aus diesem Grund muss die subjectIdentity sichtbar machen, wie sich der EFA-Teilnehmer authentifiziert hat und welche Stelle die Richtigkeit und Sicherheit dieser Authentifizierung abgesichert hat.
- Prüfdaten zur Feststellung der Authentizität des EFA-Teilnehmers
- Ein EFA-Provider muss verifizieren können, dass die einen Dienst aufrufende Person der EFA-Teilnehmer ist, für den er/sie sich ausgibt. Entsprechende Prüfdaten müssen fest an die subjectIdentity gebunden sein.
- Prüfdaten zur Feststellung der Authentizität und Integrität der subjectIdentity
- Eine Verifizierbarkeit der Daten eines subjectIdentity ist nur gegeben, wenn die subjectIdentity selbst integer und authentisch ist. Daher muss jede subjectIdentity von der ausstellenden Stelle signiert werden.
 |
Hier besteht noch eine Inkonsistenz zum IHE Cookbook. Das Cookbook verlangt, dass eine Identity Assertion einen Verweis auf den Patienten enthält, um so bestehende Schwachstellen von IHE XDS auffangen zu können. Die EFA 2.0 Spezifikation schließt einen solchen Verweis zwar nicht aus, sieht diesen aber auch nicht als verpflichtenden Bestandteil einer subjectIdentity (logisches Pendant zur Identity Assertion). Die Gründe hierfür sind:
|
Sofern in der EFA-Einwilligung eines Patienten Organisationen bzw. Organisationseinheiten als EFA-Teilnehmer benannt sind, muss der subjectIdentity-Nachweis weiter Informationen enthalten, anhand derer eine einer Organisation zugehörige Person die für diese Person vergebenen Rechte instantiieren kann:
- Organisations-ID
- Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. Wenn der in der Einwilligung benannte berechtigte Teilnehmer eine Organisation(seinheit) ist, muss in der subjectIdentity ein eindeutiger Identifier der Organisation enthalten sein, der der Aufrufer angehört. Sofern sich diese IDs eindeutig aufeinander abbilden lassen (bzw. identisch sind) kann der Aufrufer die für seine Organisation(seinheit) definierten Rechte in Anspruch nehmen.
- Point of Care
- Zur Nachvollziehbarkeit der Instantiierung von an Organisationen vergebenen Berechtigungen muss in dem subjectIdentity Nachweis benannt sein, von wo aus der Zugriff auf Patientendaten erfolgt.
Ein subjectIdentity Nachweis kann weitere Nutzerattribute enthalten. Diese müssen jedoch - im Gegensatz zu den oben aufgeführten Informationen - von dem angefragten Dienst nicht verarbeitet werden.
subjectAccessPolicy
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.02.03}
Dieses Sicherheitsobjekt fasst Informationen zu den Berechtigungen eines EFA-Teilnehmers zusammen. Sofern für eine EFA-Umsetzung ein Policy-Push Verfahren genutzt wird, erfolgen Abruf und Austausch dieses Sicherheitsobjekts in folgender Sequenz:
- ein EFA-Provider oder ein EFA-Dienst gibt in seiner Schnittstellenbeschreibung an, dass die zum Zugriff zu überprüfenden Berechtigungen von einem dedizierten Sicherheitsdienst (EFA Policy Provider) verwaltet werden und als Teil des Dienstaufrufs vom EFA-Teilnehmer bereitgestellt werden müssen
- der Context Manager des EFA-Clients ruft die als subjectAccessPolicy kodierten Berechtigungen des über eine subjectIdentity identifizierten und authentisierten EFA-Teilnehmers vom EFA Policy Provider ab
- der Context Manager fügt jedem Dienstaufruf die subjectAccessPolicy bei.
- der aufgerufene Dienst wertet die subjectAccessPolicy unter Nutzung von Attributen der Ressource und des Nutzers (subjectIdentity) aus und setzt sie durch.
In einem subjectAccessPolicy Sicherheitsnachweis müssen mindestens die folgenden Informationen enthalten sein:
- Bindung an eine subjectIdentity
- Eine subjectAccessPolicy ist immer für einen bestimmten EFA-Teilnehmer gültig und kann auch nur von diesem für selbst veranlasste Zugriffe genutzt werden. Durch Bindung einer subjectAccessPolicy an eine subjectIdentity kann der aufgerufene Dienste verifizieren, dass die subjectAccessPolicy auch wirklich für den Aufrufer ausgestellt wurde und von diesem eingebracht wird.
- Prüfdaten zur Feststellung der Authentizität und Integrität der subjectAccessPolicy
- Eine Verifizierbarkeit der Daten einer subjectAccessPolicy ist nur gegeben, wenn die subjectAccessPolicy selbst integer und authentisch ist. Daher muss jede subjectAccessPolicy von der ausstellenden Stelle signiert werden.
Zusätzlich enthält die subjectAccessPolicy die Berechtigungen des EFA-Teilnehmers. Analog zum GDD Referenzmodell können diese Berechtigungen auf der Ebene der Anwendung oder auf der Ebene der Ressource definiert sein:
- Anwendungsberechtigungen: Die subjectAccessPolicy definiert die Berechtigungen eines Leistungserbringers im Kontext eines EFA-Providers. Hierzu zählen z.B. Berechtigungen zur Anlage von Fallakten, zum Einstellen von Daten bei diesem Provider oder zur Besetzung bestimmter Rollen (z.B. Berechtigung, als Fallaktenmanager zu agieren). Die Berechtigungen spiegeln damit die vertraglichen und organisatorischen Bindungen zwischen dem Leistungserbringer und einem EFA-Provider wider.
- Ressourceberechtigungen: Die subjectAccessPolicy definiert die Berechtigungen eines Leistungserbringers im Kontext einer konkreten Fallakte. Hierzu zählen insbesondere die aus der Einwilligung des Betroffenen abgeleiteten Zugriffsrechte auf dieser Fallakte. Die Berechtigungen spiegeln damit die vertraglichen Vereinbarungen zwischen dem Leistungserbringer und einem Patienten wider.
Grundsätzlich können beide Arten von Berechtigungen auch in einem Regelwerk kombiniert werden.
accessToken
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.02.04}
Diese Klasse beschreibt ein Token, das ein EFA-Teilnehmer einreichen kann, um Zugang zu einer Fallakte zu erhalten. Das Token ist eine Referenz auf eine Token Redeem Policy. Sie ist beim Aussteller des Token registriert und beschreibt, welcher EFA-Teilnehmer das Token innerhalb welches Zeitfensters einreichen darf und welche Berechtigungen auf die Fallakte damit verknüpft sind.
Die Struktur des Tokens ist in der EFA-1.2-Spezifikation eCR Offline Token - Service Architecture definiert.
