cdaefa:EFA Security Informationsmodell

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 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".

---

EFA Sicherheitsinformationsmodell

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.

ecrParticipant

Dieses Sicherheitsobjekt fasst Informationen zu einem EFA-Teilnehmer zusammen und dient dessen eindeutiger Identifizierung im Kontext eine konkreten Fallakte. Ein EFA-Teilnehmer ist dabei immer eine Organisation oder eine einer Organisation zugeordnete Person.

In der Klasse ecrParticipantwerden die folgenden Informationen zu einem EFA-Teilnehmer zusammengefass:

ID des EFA-Teilnehmers

Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In einem ecrParticipant-Nachweis muss ein eindeutiger Identifier des EFA-Teilnehmers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert.

Name des EFA-Teilnehmers

Zur besseren Nachvollziehbarkeit der Überführung einer Papier-Einwilligung auf eine elektronische Einwilligungsdokumentation, muss dort der Name des berechtigten Teilnehmers wie in der Einwilligung angegeben enthalten sein.

ecrAuthenticatedUser

Die Nutzung einer EFA ist nur für identifizierte und authentifizierte Personen möglich. Zum Zugriff auf eine konkrete EFA muss diese Person entweder

• in der Einwilligung benannt oder
• einer dort als berechtigt benannten Organisation angehören und gemäß den Regularien dieser Organisation zum Zugriff auf diese EFA berechtigt sein.

Die Klasse ecrAuthenticatedUser fasst Informationen zu einem EFA-Nutzer 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 ecrAuthenticatedUser 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 einem ecrAuthenticatedUser-Objekt muss ein eindeutiger Identifier des EFA-Nutzers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert (siehe oben).

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 jedem ecrAuthenticatedUser-Objekt muss der Klartextname des EFA-Teilnehmers 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 ein ecrAuthenticatedUser-Objekt sichtbar machen, wie sich der EFA-Nutzer authentifiziert hat und welche Stelle die Richtigkeit und Sicherheit dieser Authentifizierung abgesichert hat.

Prüfdaten zur Feststellung der Authentizität des EFA-Nutzers

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 ein ecrAuthenticatedUser-Objekt gebunden sein.

Prüfdaten zur Feststellung der Authentizität und Integrität des ecrAuthenticatedUser-Objekts

Eine Verifizierbarkeit der Daten eines ecrAuthenticatedUser-Objekt ist nur gegeben, wenn die subjectIdentity selbst integer und authentisch ist. Daher muss jedes ecrAuthenticatedUser-Objekt von der ausstellenden Stelle signiert werden.

Point of Care

Zur Nachvollziehbarkeit der Instantiierung von an Organisationen vergebenen Berechtigungen muss in dem ecrAuthenticatedUser-Nachweis benannt sein, von wo aus der Zugriff auf Patientendaten erfolgt.

Ein ecrAuthenticatedUser-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:

1. 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
2. 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
3. der Context Manager fügt jedem Dienstaufruf die subjectAccessPolicy bei.
4. 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.

---