cdaefa Diskussion:Prinzipien für Datenschutz und Datensicherheit

Kommentare

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)

Authors

Kürzel	Name	Organisation	E-Mail
fh	Frank Oemig	Agfa Healthcare
ti	Tarik Idris	InterComponentWare AG
mr	Michael Rübener	X-tension
sh	Salima Houta	Fraunhofer ISST
jc	Jörg Caumanns	Fraunhofer FOKUS
bk	Ben Kraufmann	Fraunhofer FOKUS
iw	Ingo Wolf	gematik
mk	Marcel Klötgen	CompuGroup Medical