cdaefa:Prinzipien für Datenschutz und Datensicherheit - Versionsgeschichte

Jcaumanns: Typo

2015-01-27T12:28:47Z

Typo

Jcaumanns: Markup-Fehler behoben

2015-01-26T15:32:21Z

Markup-Fehler behoben

Jcaumanns: Querverweise

2015-01-13T16:42:48Z

Querverweise

Jcaumanns: Ebenen der Überschriften für transclude.

2014-09-16T18:25:52Z

Ebenen der Überschriften für transclude.

Jcaumanns: /* Policy Enforcement dicht an den Ressourcen */

2013-09-05T20:15:47Z

‎Policy Enforcement dicht an den Ressourcen

Jcaumanns: /* Übertragbarer Sicherheitskontext */

2013-09-05T19:53:25Z

‎Übertragbarer Sicherheitskontext

Jcaumanns: /* Synchronität von Behandlungsteam und Berechtigungen */

2013-09-05T19:35:22Z

‎Synchronität von Behandlungsteam und Berechtigungen

Jcaumanns: /* EFA Sicherheitsstrategie */

2013-09-05T19:21:06Z

‎EFA Sicherheitsstrategie

Jcaumanns: /* EFA Sicherheitsstrategie */

2013-09-05T19:18:57Z

‎EFA Sicherheitsstrategie

Jcaumanns am 21. April 2013 um 20:09 Uhr

2013-04-21T20:09:06Z

@@ Zeile 84: / 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
 * 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 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.

@@ Zeile 107: / Zeile 107: @@
 * [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]]
 }}

@@ Zeile 98: / Zeile 98: @@
 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.
 * [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]]

@@ Zeile 4: / Zeile 4: @@
 ----
-== EFA Sicherheitsstrategie ==
+== Prinzipien für Datenschutz und Datensicherheit ==
 <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Pziee.01}</tt>
@@ Zeile 33: / Zeile 36: @@
 :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 ==
+=== Kernkonzepte ===
 <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Pziee.02}</tt>
@@ Zeile 39: / Zeile 43: @@
 [[Datei:Sicherheitsstrategie.png|480px]]
 <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Pziee.02.01}</tt>
@@ Zeile 56: / Zeile 59: @@
 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 ===
+==== Übertragbarer Sicherheitskontext ====
 <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Pziee.02.02}</tt>
@@ Zeile 70: / Zeile 74: @@
 [[Datei:EFA Assertion Chain.png|640px]]
-=== Deklarative Sicherheit ===
+==== Deklarative Sicherheit ====
 <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Pziee.02.03}</tt>
@@ Zeile 83: / Zeile 88: @@
 Die Sicherheitsdienste der EFA v2.0 setzen wo immer machbar und sinnvoll Konzepte einer deklarativen Sicherheit um.
-=== Policy Enforcement dicht an den Ressourcen ===
+==== 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>

@@ Zeile 90: / Zeile 90: @@
 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. In der Summe bedeutet dies, dass sich ein Provider niemals auf eine Zugriffskontrollentscheidung oder Auswertung einer Einwilligung verlassen darf, die er nicht selbst verantwortet und durchgeführt hat.
+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 ===

@@ Zeile 63: / Zeile 63: @@
 # 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 verwendet per default 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.
+# 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.

@@ Zeile 52: / Zeile 52: @@
 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 Authentisierung (Individuum bzw. Organisation) kann auf die Granularität der Zugriffsrechte, die für eine Fallakte definiert sind, abgebildet werden. 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.
+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.
 === Übertragbarer Sicherheitskontext ===

@@ Zeile 31: / Zeile 31: @@
 :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 der eGK benannte 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.
+: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 ==

@@ Zeile 25: / Zeile 25: @@
 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 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.
+: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.
@@ Zeile 31: / Zeile 31: @@
 :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 der eGK benannte 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 ==

@@ Zeile 1: / Zeile 1: @@
 {{DocumentPart}}
-''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.<br>Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".''
+''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]]".''
 ----
 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.
@@ Zeile 15: / Zeile 18: @@
 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.
-== EFA Sicherheitsstrategie {Pzie.01} ==
+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.
@@ Zeile 32: / Zeile 33: @@
 :Auch wenn die EFA selber keine Anwendung des § 291a SGB V darstellt, so gelten doch viele der für Anwendungen der eGK benannte 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 {Pzie.02} ==
+== Kernkonzepte ==
 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.
@@ Zeile 38: / Zeile 41: @@
-=== Synchronität von Behandlungsteam und Berechtigungen {Pzie.02.01} ===
+=== Synchronität von Behandlungsteam und Berechtigungen ===
 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.
@@ Zeile 50: / Zeile 54: @@
 Die Granularität der Authentisierung (Individuum bzw. Organisation) kann auf die Granularität der Zugriffsrechte, die für eine Fallakte definiert sind, abgebildet werden. 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.
-=== Übertragbarer Sicherheitskontext {Pzie.02.02} ===
+=== Übertragbarer Sicherheitskontext ===
 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:
@@ Zeile 63: / Zeile 68: @@
 [[Datei:EFA Assertion Chain.png|640px]]
-=== Deklarative Sicherheit {Pzie.02.03} ===
+=== Deklarative Sicherheit ===
 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 74: / Zeile 81: @@
 Die Sicherheitsdienste der EFA v2.0 setzen wo immer machbar und sinnvoll Konzepte einer deklarativen Sicherheit um.
-=== Policy Enforcement dicht an den Ressourcen {Pzie.02.04} ===
+=== Policy Enforcement dicht an den Ressourcen ===
 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.