cdaefa Diskussion:Prinzipien für Datenschutz und Datensicherheit - Versionsgeschichte

Jcaumanns am 16. September 2014 um 11:43 Uhr

2014-09-16T11:43:01Z

Jcaumanns: Aktuelle Fassung der Kommentar-Tabelle eingefügt.

2014-01-24T13:57:54Z

Aktuelle Fassung der Kommentar-Tabelle eingefügt.

Jcaumanns: Die Seite wurde neu angelegt: „== Pziee.02.01: Synchronität von Behandlungsteam und Berechtigungen == === 32px Authentisierung, Autorisierung, Audit Trail === De…“

2013-09-05T20:17:24Z

Die Seite wurde neu angelegt: „== Pziee.02.01: Synchronität von Behandlungsteam und Berechtigungen == === 32px Authentisierung, Autorisierung, Audit Trail === De…“

Neue Seite

== Pziee.02.01: Synchronität von Behandlungsteam und Berechtigungen ==

=== [[Datei:Si-confirm.svg|32px]] Authentisierung, Autorisierung, Audit Trail ===

Der letzte Satz zur Granularität der Authentisierung verwirrt mich etwas. Ich bin davon ausgegangen dass auch bei Vergabe der Zugriffsrechte auf Organisationsgranularität der individuelle Benutzer in der Assertion mitgeliefert wird (auch wenn er nicht zentral geführt wird und somit nicht weiter verifiziert werden kann). Dies ermöglicht eine weitaus bessere Auditierung, da immer ein individueller Benutzerkontext vorhanden ist. Eine Klarstellung ob Informationen zum Benutzer für Auditzwecke trotzdem benötigt werden, wäre hier sinnvoll (auch wenn dies im späteren Text hoffentlich geklärt wird). (ti, 28.05.2013)

Der Absatz wurde umformuliert und erweitert, um klarzustellen, dass die zugreifende Person in jedem Fall im Authentisierungsnachweis benannt sein muss und auch im Audit Trail vermerkt wird. (jc, 05.09.2013)

== Pziee.02.02: Übertragbarer Sicherheitskontext ==

=== [[Datei:Si-confirm.svg|32px]] Policy Push ===

Das in 4. als default vorgegebene Policy Push Verfahren widerspricht dem im Cookbook verwendetem Verfahren, bei dem der Authorization Decision Provider als PDP die relevanten Policies vom Policy Repository (hier Policy Provider) abfragt. Die Entscheidung basierte auf dem Ziel die Implementierung von Clients zu vereinfachen und einen besseren Schutz der ggf. schützenswerten Policies zu ermöglichen (da beim Cookbook nur der PDP Policies abrufen muss und somit weniger Angriffsfläche besteht). Der Schutz der Policies ist im EFA Kontext wahrscheinlich weniger dringend als im PEPA Kontext (v.a. wegen Blacklisting und krankheitsspezifischen Restriktionen), aber die geringere Implementationslast für Clients sollte auch ein Anliegen des EFA Vereins sein. Die Vorteile des hier gewählten Ansatzes gegenüber dem Cookbook erchliessen sich mir hier noch nicht. (ti, 28.05.2013)

Die EFA macht keine Präferenz. Dementsprechend wurde die Formulierung neutralisiert. Zusätzlich wird nun in den [[cdaefa:EFA_Access_Control_System#Bindung_von_Policies_an_Schnittstellen||Vorgaben zur Nutzung von Policies]] explizit aufgeführt, dass jeder providerseitige EFA-Dienste "policy pull" und "policy push" unterstützen muss, während die Unterstützung von "policy push" für EFA-Clients optional ist.

== Pziee.02.04: Policy Enforcement dicht an den Ressourcen ==

=== [[Datei:Si-confirm.svg|32px]] Vertrauensbeziehung zwischen EFA-Providern ===

Was für Auswirkungen hat die Aussage: "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." Ein Provider muss sich ja schon auf die Aussagen von "vertrauenswürdigen" Systemen verlassen: Der Identity Provider kann vom EFA-Teilnehmer betrieben werden. Nicht elektronisch signierte Patientenzustimmungsdokumente die von einem EFA-Teilnehmer kommen werden auch als verlässlich akzeptiert. Ich würde hier einfach berücksichtigen, dass der EFA Provider mit seinen Teilnehmern vertraglich klärt, welches Verhalten von "vertrauenswürdigen" Systemen gefordert ist und wer die Verantwortung bei Abweichungen trägt (bzw. was die Folge von Abweichungen sind). (ti, 28.05.2013)

Text wurde entsprechend dem Vorschlag umformuliert.

== Namenskürzel ==
;jc
:[[Benutzer:Jcaumanns|Dr. Jörg Caumanns]], Fraunhofer FOKUS<br>joerg.caumanns@fokus.fraunhofer.de
;ti
: [[Benutzer:Tidris|Tarik Idris]], InterComponentWare AG<br>tarik.idris@icw.de

@@ Zeile 1: / Zeile 1: @@
-= Kommentierung =
+= Kommentare =
 {|class="wikitable" style="text-align: left; cellpadding: 10;"
 !Author
 !Status
 !Section
 !Existing
 !Proposed
@@ Zeile 9: / Zeile 11: @@
 !Comment Editor
 !Discussion
 |- style="vertical-align:top;"
 |style="background-color: white;"|sh
 |style="background-color: #89C35C;"|included
 |style="background-color: white;"|Pziee.01 : EFA Sicherheitsstrategie
 |style="background-color: white;"|Zugriffsrechte werden vom Patienten vergeben
 |style="background-color: white;"|im Auftrag des Patienten vergeben
@@ Zeile 18: / Zeile 23: @@
 |style="background-color: white;"|
 |style="background-color: white;"|
 |- style="vertical-align:top;"
 |style="background-color: white;"|sh
 |style="background-color: #89C35C;"|included
 |style="background-color: white;"|Pziee.01 : EFA Sicherheitsstrategie
 |style="background-color: white;"|Auch wenn die EFA selber keine Anwendung des § 291a SGB V darstellt, so gelten doch viele der für Anwendungen der eGK benannten Anforderungen gleichermaßen.
 |style="background-color: white;"|der eGK benannten Anforderungen
@@ Zeile 27: / Zeile 35: @@
 |style="background-color: white;"|
 |style="background-color: white;"|
 |- style="vertical-align:top;"
 |style="background-color: white;"|ti
 |style="background-color: #89C35C;"|included
 |style="background-color: white;"|Pziee.02.01 : Synchronität von Behandlungsteam und Berechtigungen
 |style="background-color: white;"|
 |style="background-color: white;"|
@@ Zeile 36: / Zeile 47: @@
 |style="background-color: white;"|Der Absatz wurde umformuliert und erweitert, um klarzustellen, dass die zugreifende Person in jedem Fall im Authentisierungsnachweis benannt sein muss und auch im Audit Trail vermerkt wird. (jc, 05.09.2013)
 |style="background-color: white;"|
 |- style="vertical-align:top;"
 |style="background-color: white;"|ti
 |style="background-color: #89C35C;"|included
 |style="background-color: white;"|Pziee.02.02 : Übertragbarer Sicherheitskontext
 |style="background-color: white;"|
 |style="background-color: white;"|
 |style="background-color: white;"|Das in 4. als default vorgegebene Policy Push verfahren widerspricht dem im Cookbook verwendetem Verfahren, bei dem der Authorization Decision Provider als PDP die relevanten Policies vom Policy Repository (hier Policy Provider) abfragt. Die Entscheidung basierte auf dem Ziel die Implementierung von Clients zu vereinfachen und einen besseren Schutz der ggf. schützenswerten Policies zu ermöglichen (da beim Cookbook nur der PDP Policies abrufen muss und somit weniger Angriffsfläche besteht). Der Schutz der Policies ist im EFA Kontext wahrscheinlich weniger dringend als im PEPA Kontext (v.a. wegen Blacklisting und krankheitsspezifischen Restriktionen), aber die geringere Implementationslast für Clients sollte auch ein Anliegen des EFA Vereins sein. Die Vorteile des hier gewählten Ansatzes gegenüber dem Cookbook erchliessen sich mir hier noch nicht. (ti, 28.05.2013)
-|style="background-color: white;"|Die EFA macht keine Präferenz. Dementsprechend wurde die Formulierung neutralisiert. Zusätzlich wird nun in den [[cdaefa:EFA_Access_Control_System#Bindung_von_Policies_an_Schnittstellen]] explizit aufgeführt, dass jeder providerseitige EFA-Dienste "policy pull" und "policy push" unterstützen muss, während die Unterstützung von "policy push" für EFA-Clients optional ist. (jc)
+|style="background-color: white;"|Die EFA macht keine Präferenz. Dementsprechend wurde die Formulierung neutralisiert. Zusätzlich wird nun in den [[cdaefa:EFA_Access_Control_System#Bindung_von_Policies_an_Schnittstellen||Vorgaben zur Nutzung von Policies]] explizit aufgeführt, dass jeder providerseitige EFA-Dienste "policy pull" und "policy push" unterstützen muss, während die Unterstützung von "policy push" für EFA-Clients optional ist. (jc)
 |style="background-color: white;"|
 |- style="vertical-align:top;"
 |style="background-color: white;"|ti
 |style="background-color: #89C35C;"|included
 |style="background-color: white;"|Pziee.02.04 : Policy Enforcement dicht an den Ressourcen
 |style="background-color: white;"|
 |style="background-color: white;"|
@@ Zeile 56: / Zeile 73: @@
 |}
-== Namenskürzel ==
+= Authors =
-;jc
+{|class="wikitable" style="text-align: left; cellpadding: 10;"
-:[[Benutzer:Jcaumanns|Dr. Jörg Caumanns]], Fraunhofer FOKUS<br>joerg.caumanns@fokus.fraunhofer.de
+!Kürzel
-;ti
+!Name
-: [[Benutzer:Tidris|Tarik Idris]], InterComponentWare AG<br>tarik.idris@icw.de
+!Organisation

@@ Zeile 1: / Zeile 1: @@
-== Pziee.02.01: Synchronität von Behandlungsteam und Berechtigungen  ==
+= Kommentierung =
+{|class="wikitable" style="text-align: left; cellpadding: 10;"
-=== [[Datei:Si-confirm.svg|32px]] Authentisierung, Autorisierung, Audit Trail ===
+!Author
+!Status
-Der letzte Satz zur Granularität der Authentisierung verwirrt mich etwas. Ich bin davon ausgegangen dass auch bei Vergabe der Zugriffsrechte auf Organisationsgranularität der individuelle Benutzer in der Assertion mitgeliefert wird (auch wenn er nicht zentral geführt wird und somit nicht weiter verifiziert werden kann). Dies ermöglicht eine weitaus bessere Auditierung, da immer ein individueller Benutzerkontext vorhanden ist. Eine Klarstellung ob Informationen zum Benutzer für Auditzwecke trotzdem benötigt werden, wäre hier sinnvoll (auch wenn dies im späteren Text hoffentlich geklärt wird). (ti, 28.05.2013)
+!Section
+!Existing
-Der Absatz wurde umformuliert und erweitert, um klarzustellen, dass die zugreifende Person in jedem Fall im Authentisierungsnachweis benannt sein muss und auch im Audit Trail vermerkt wird. (jc, 05.09.2013)
+!Proposed
+!Comment
+!Comment Editor
-== Pziee.02.02: Übertragbarer Sicherheitskontext  ==
+!Discussion
+|- style="vertical-align:top;"
-=== [[Datei:Si-confirm.svg|32px]] Policy Push ===
+|style="background-color: white;"|sh
+|style="background-color: #89C35C;"|included
-Das in 4. als default vorgegebene Policy Push Verfahren widerspricht dem im Cookbook verwendetem Verfahren, bei dem der Authorization Decision Provider als PDP die relevanten Policies vom Policy Repository (hier Policy Provider) abfragt. Die Entscheidung basierte auf dem Ziel die Implementierung von Clients zu vereinfachen und einen besseren Schutz der ggf. schützenswerten Policies zu ermöglichen (da beim Cookbook nur der PDP Policies abrufen muss und somit weniger Angriffsfläche besteht). Der Schutz der Policies ist im EFA Kontext wahrscheinlich weniger dringend als im PEPA Kontext (v.a. wegen Blacklisting und krankheitsspezifischen Restriktionen), aber die geringere Implementationslast für Clients sollte auch ein Anliegen des EFA Vereins sein. Die Vorteile des hier gewählten Ansatzes gegenüber dem Cookbook erchliessen sich mir hier noch nicht. (ti, 28.05.2013)
+|style="background-color: white;"|Pziee.01 : EFA Sicherheitsstrategie
+|style="background-color: white;"|Zugriffsrechte werden vom Patienten vergeben
-Die EFA macht keine Präferenz. Dementsprechend wurde die Formulierung neutralisiert. Zusätzlich wird nun in den [[cdaefa:EFA_Access_Control_System#Bindung_von_Policies_an_Schnittstellen||Vorgaben zur Nutzung von Policies]] explizit aufgeführt, dass jeder providerseitige EFA-Dienste "policy pull" und "policy push" unterstützen muss, während die Unterstützung von "policy push" für EFA-Clients optional ist.
+|style="background-color: white;"|im Auftrag des Patienten vergeben
+|style="background-color: white;"|
+|style="background-color: white;"|
-== Pziee.02.04: Policy Enforcement dicht an den Ressourcen  ==
+|style="background-color: white;"|
+|- style="vertical-align:top;"
-=== [[Datei:Si-confirm.svg|32px]] Vertrauensbeziehung zwischen EFA-Providern ===
+|style="background-color: white;"|sh
+|style="background-color: #89C35C;"|included
-Was für Auswirkungen hat die Aussage: "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." Ein Provider muss sich ja schon auf die Aussagen von "vertrauenswürdigen" Systemen verlassen: Der Identity Provider kann vom EFA-Teilnehmer betrieben werden. Nicht elektronisch signierte Patientenzustimmungsdokumente die von einem EFA-Teilnehmer kommen werden auch als verlässlich akzeptiert. Ich würde hier einfach berücksichtigen, dass der EFA Provider mit seinen Teilnehmern vertraglich klärt, welches Verhalten von "vertrauenswürdigen" Systemen gefordert ist und wer die Verantwortung bei Abweichungen trägt (bzw. was die Folge von Abweichungen sind). (ti, 28.05.2013)
+|style="background-color: white;"|Pziee.01 : EFA Sicherheitsstrategie
+|style="background-color: white;"|Auch wenn die EFA selber keine Anwendung des § 291a SGB V darstellt, so gelten doch viele der für Anwendungen der eGK benannten Anforderungen gleichermaßen.
-Text wurde entsprechend dem Vorschlag umformuliert.
+|style="background-color: white;"|der eGK benannten Anforderungen
 == Namenskürzel ==