| ID
|
Author
|
Status
|
Section
|
Vote
|
Existing
|
Proposed
|
Comment
|
Comment Editor
|
Discussion
|
| 256
|
sh
|
included
|
Pziee.01 : EFA Sicherheitsstrategie
|
|
Zugriffsrechte werden vom Patienten vergeben
|
im Auftrag des Patienten vergeben
|
|
|
|
| 257
|
sh
|
included
|
Pziee.01 : EFA Sicherheitsstrategie
|
|
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.
|
der eGK benannten Anforderungen
|
|
|
|
| 258
|
ti
|
included
|
Pziee.02.01 : Synchronität von Behandlungsteam und Berechtigungen
|
|
|
|
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)
|
|
| 259
|
ti
|
included
|
Pziee.02.02 : Übertragbarer Sicherheitskontext
|
|
|
|
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. (jc)
|
|
| 260
|
ti
|
included
|
Pziee.02.04 : Policy Enforcement dicht an den Ressourcen
|
|
|
|
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. (jc)
|
|
