cdaefa:EFA Security Informationsmodell

Informationsmodell der EFA Sicherheitsobjekte

Informationsmodell der EFA Sicherheitsobjekte

Implementierungsleitfaden

vorgelegt von:
February 2013
Jörg Caumanns, Raik Kuhlisch

Draft

Version:	0.9
Datum:	March 2013
Status:	xxx
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2012-2013: HL7 Deutschland

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 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 Zugruffsberechtigungen 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 EWFA-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.

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}

Querverweise und Referenzen

• EFA-2.0-Spezifikation