Jcaumanns am 18. November 2013 um 09:21 Uhr

2013-11-18T09:21:40Z

Jcaumanns: Die Seite wurde neu angelegt: „= IHE White Paper "Access Control" = ''Diese Seite gibt einen kurzen Überblick über die im IHE White Paper "Access Control" eingeführten Konzepte und Begri…“

2013-11-16T18:12:29Z

Die Seite wurde neu angelegt: „= IHE White Paper "Access Control" = ''Diese Seite gibt einen kurzen Überblick über die im IHE White Paper "Access Control" eingeführten Konzepte und Begri…“

Neue Seite

= IHE White Paper "Access Control" =

''Diese Seite gibt einen kurzen Überblick über die im IHE White Paper "Access Control" eingeführten Konzepte und Begrifflichkeiten, wie sie auch im IHE Cookbook und in der EFAv2-Spezifikation verwendet werden.''

== Access Control Subsysteme ==
Prinzipien Service-Orientierter Architekturen wie z.B. die Entkopplung von Diensten und die deklarative Steuerung von Abläufen über Diensten lassen sich auch auf Sicherheitsinfrastrukturen und Sicherheitsdienste abbilden.
Sicherheitsdienste zur Authentifizierung, Autorisierung, Nicht-Abstreitbarkeit, etc. können so voneinander entkoppelt als eigenständige, wiederverwendbare Subsysteme definiert und mit beliebigen Akteuren gruppiert werden.
Ein Access Control Subsystem (ACS) integriert dabei insbesondere die in einschlägigen Standards wie z.B. [http://www.ietf.org/rfc/rfc2753.txt RFC2753] und XACML definierten logische Komponenten zur Verwaltung, Entscheidung und Durchsetzung von Zugriffsregeln (Policies):
* Policy Authorities (technisch: Policy Administration Point, PAP) für die Verwaltung und Bereitstellung von Policies
* Attribute Services (auch: Policy Information Point, PIP) für die Verwaltung und Bereitstellung von Attributen, die zur Laufzeit für die Auswertung von Policies benötigt werden
* Policy Decision Points (PDP) und Policy Enforcement Points (PEP) für die Auswertung und Durchsetzung von Policies
Um Policies, Policy Entscheidungen, für Policy-Auswertungen benötigte Attribute, etc. sicher zwischen an verschiedene Akteure gebundene ACS austauschen zu können, werden sog. Sicherheitstoken verwendet, die von dedizierten Security Token Services (STS) ausgestellt werden.

Die nachfolgende Abbildung stellt den generischen Aufbau eines Access Control Subsystems im Überblick dar.

[[Datei:IHE_5_Domain_ACS_Components.png|480px]]

== 5-Domänen-Modell ==

Das IHE White Paper "Access Control" beschreibt eine Methodik zur Analyse, zum Design und zur Bewertung von Access Control Lösungen für eHealth-Anwendungen. Kern dieser Methodik ist das sog. 5-Domänen-Modell, das die verschiedenen Aspekte einer jeden Access Control Lösung auf von konkreten Anwendungsdiensten und Deployments unabhängige logische Domänen abbildet. An jede dieser Domänen ist an ACS gebunden, das domänenspezifische Ausprägungen der oben skizzierten logischen ACS-Komponenten kapselt:
* Die '''Context Domain''' bildet den Ausführungskontext des Nutzers ab. Hier werden z.B. Kontext-Attribute (z.B. Zweck eines Datenabrufs) verwaltet und die für eine Anwendung im aktuellen Kontext aktivierte Nutzerrolle festgelegt.
* Die '''Subject Domain''' kapselt alle Funktionalitäten zur Identifizierung, Beschreibung und Authentifizierung eines Nutzers.
* Die '''Resource Domain''' bildet die durch die Access Control Lösung zu schützende Ressource (z.B. medizinische Daten) ab. Der Zugang zu dieser Ressource wird durch einen vorgelagerten PEP abgesichert.
* In der '''Patient Domain''' werden alle direkt mit dem Patienten verknüpften Policies - insb. auch Einwilligungen - verwaltet und bereitgestellt.
* Die '''Application Domain''' kapselt alle mit einer Anwendung verknüpften Policies und Nutzungskonventionen. Da diese Policies nur selten explizit sind, repräsentiert diese Domäne für die meisten Anwendungen lediglich eine Sammlung von organisatorischen Vorgaben, die sich z.B. im Sicherheits- und Datenschutzkonzept der Anwendung widerspiegeln.

[[Datei:IHE_5_Domain_Overview.png|640px]]

== Nutzung des 5-Domänen-Modells ==

[[Datei:IHE_5_Domain_Sample_Flow.png|640px]]

@@ Zeile 1: / Zeile 1: @@
-= IHE White Paper "Access Control" =
+== IHE White Paper "Access Control" ==
 ''Diese Seite gibt einen kurzen Überblick über die im IHE White Paper "Access Control" eingeführten Konzepte und Begrifflichkeiten, wie sie auch im IHE Cookbook und in der EFAv2-Spezifikation verwendet werden.''
-== Access Control Subsysteme ==
+=== Access Control Subsysteme ===
 Prinzipien Service-Orientierter Architekturen wie z.B. die Entkopplung von Diensten und die deklarative Steuerung von Abläufen über Diensten lassen sich auch auf Sicherheitsinfrastrukturen und Sicherheitsdienste abbilden.
 Sicherheitsdienste zur Authentifizierung, Autorisierung, Nicht-Abstreitbarkeit, etc. können so voneinander entkoppelt als eigenständige, wiederverwendbare Subsysteme definiert und mit beliebigen Akteuren gruppiert werden.
@@ Zeile 16: / Zeile 16: @@
 [[Datei:IHE_5_Domain_ACS_Components.png|480px]]
-== 5-Domänen-Modell ==
+=== 5-Domänen-Modell ===
 Das IHE White Paper "Access Control" beschreibt eine Methodik zur Analyse, zum Design und zur Bewertung von Access Control Lösungen für eHealth-Anwendungen. Kern dieser Methodik ist das sog. 5-Domänen-Modell, das die verschiedenen Aspekte einer jeden Access Control Lösung auf von konkreten Anwendungsdiensten und Deployments unabhängige logische Domänen abbildet. An jede dieser Domänen ist an ACS gebunden, das domänenspezifische Ausprägungen der oben skizzierten logischen ACS-Komponenten kapselt:
@@ Zeile 27: / Zeile 27: @@
 [[Datei:IHE_5_Domain_Overview.png|640px]]
-== Nutzung des 5-Domänen-Modells ==
+=== Nutzung des 5-Domänen-Modells ===
 [[Datei:IHE_5_Domain_Sample_Flow.png|640px]]

cdaefa:IHE Access Control Domains - Versionsgeschichte

Jcaumanns am 18. November 2013 um 09:21 Uhr

Jcaumanns: Die Seite wurde neu angelegt: „= IHE White Paper "Access Control" = ''Diese Seite gibt einen kurzen Überblick über die im IHE White Paper "Access Control" eingeführten Konzepte und Begri…“