cdaefa Diskussion:Prinzipien für Datenschutz und Datensicherheit

Kommentierung

Author	Status	Section	Existing	Proposed	Comment	Comment Editor	Discussion
sh	included	Pziee.01 : EFA Sicherheitsstrategie	Zugriffsrechte werden vom Patienten vergeben	im Auftrag des Patienten vergeben
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
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)
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 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)
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)

Namenskürzel

jc

Dr. Jörg Caumanns, Fraunhofer FOKUS
joerg.caumanns@fokus.fraunhofer.de

ti

Tarik Idris, InterComponentWare AG
tarik.idris@icw.de