cdaefa Diskussion:EFA Sicherheitsanforderungen: Unterschied zwischen den Versionen

Aus Hl7wiki
Wechseln zu: Navigation, Suche
(Die Seite wurde neu angelegt: „== Eierf.01 == ;Author :sh ;Existing :bereitstellung ;Proposed :Bereitstellung == Eierf.01 == ;Author :sh ;Existing :bennennen ;Propo…“)
 
K (Aktuelle Fassung der Kommentar-Tabelle eingefügt.)
Zeile 1: Zeile 1:
−
== Eierf.01 ==
+
= Kommentierung =
−
           
+
{|class="wikitable" style="text-align: left; cellpadding: 10;"
−
;Author
+
!Author
−
:sh
+
!Status
−
;Existing
+
!Section
−
:bereitstellung
+
!Existing
−
;Proposed
+
!Proposed
−
:Bereitstellung
+
!Comment
−
== Eierf.01 ==
+
!Comment Editor
−
           
+
!Discussion
−
;Author
+
|- style="vertical-align:top;"
−
:sh
+
|style="background-color: white;"|gematik
−
;Existing
+
|style="background-color: #89C35C;"|included
−
:bennennen
+
|style="background-color: white;"|Eierf.01 : Identifizierung und Authentifizierung von EFA-Teilnehmern
−
;Proposed
+
|style="background-color: white;"|Stabilität des Vertrauensverhältnis zum ausstellenden Dienst
−
:benennen
+
|style="background-color: white;"|
−
== Eierf.01 ==
+
|style="background-color: white;"|Was bedeutet hier konkret Stabilität?
−
           
+
|style="background-color: white;"|Gemeint ist das Vorhandensein des Vertrauensverhältnisses zum ausstellenden Dienst. Technisch bedeutet das: Das Zertifikat des Dienstes muss valide und nicht zurückgezogen sein, der Zertifikataussteller muss vertrauenswürdig sein.
−
;Author
+
|style="background-color: white;"|
−
:sh
+
|- style="vertical-align:top;"
−
;Existing
+
|style="background-color: white;"|sh
−
:identifikation
+
|style="background-color: #89C35C;"|included
−
;Proposed
+
|style="background-color: white;"|Eierf.01 : Identifizierung und Authentifizierung von EFA-Teilnehmern
−
:Identifikation
+
|style="background-color: white;"|bereitstellung
−
== Eierf.01 ==
+
|style="background-color: white;"|Bereitstellung
−
           
+
|style="background-color: white;"|
−
;Author
+
|style="background-color: white;"|
−
:sh
+
|style="background-color: white;"|
−
;Existing
+
|- style="vertical-align:top;"
−
:Athentisierung
+
|style="background-color: white;"|sh
−
;Proposed
+
|style="background-color: #89C35C;"|included
−
:Authentisierung
+
|style="background-color: white;"|Eierf.01 : Identifizierung und Authentifizierung von EFA-Teilnehmern
−
== Eierf.01 ==
+
|style="background-color: white;"|bennennen
−
           
+
|style="background-color: white;"|benennen
−
;Comment
+
|style="background-color: white;"|
−
:Was bedeutet hier konkret Stabilität?
+
|style="background-color: white;"|
−
;Author
+
|style="background-color: white;"|
−
:gematik
+
|- style="vertical-align:top;"
−
;Existing
+
|style="background-color: white;"|sh
−
:Stabilität des Vertrauensverhältnis zum ausstellenden Dienst
+
|style="background-color: #89C35C;"|included
−
;Comment Editor
+
|style="background-color: white;"|Eierf.01 : Identifizierung und Authentifizierung von EFA-Teilnehmern
−
:Gemeint ist das Vorhandensein des Vertrauensverhältnisses zum ausstellenden Dienst. Technisch bedeutet das: Das Zertifikat des Dienstes muss valide und nicht zurückgezogen sein, der Zertifikataussteller muss vertrauenswürdig sein.
+
|style="background-color: white;"|identifikation
−
== Eierf.01 ==
+
|style="background-color: white;"|Identifikation
−
           
+
|style="background-color: white;"|
−
;Comment
+
|style="background-color: white;"|
−
:Ich würde empfehlen das Thema Haftung hier nicht zu erwähnen. Die Haftungsregelung zwischen Identity Provider und EFA Provider sind ein eigenes Thema, das an dieser Stelle nicht ausgiebig behandelt werden kann. Ich würde daher nur vom "ausstellendem Dienst" sprechen, nicht vom "ausstellenden (und haftenden)". (ti, 29.05.2013)
+
|style="background-color: white;"|
−
;Author
+
|- style="vertical-align:top;"
−
:ti
+
|style="background-color: white;"|sh
−
== Eierf.02 ==
+
|style="background-color: #89C35C;"|included
−
           
+
|style="background-color: white;"|Eierf.01 : Identifizierung und Authentifizierung von EFA-Teilnehmern
−
;Author
+
|style="background-color: white;"|Athentisierung
−
:sh
+
|style="background-color: white;"|Authentisierung
−
;Existing
+
|style="background-color: white;"|
−
:berechtig
+
|style="background-color: white;"|
−
;Proposed
+
|style="background-color: white;"|
−
:berechtigt
+
|- style="vertical-align:top;"
−
== Eierf.02 ==
+
|style="background-color: white;"|ti
−
           
+
|style="background-color: #89C35C;"|included
−
;Author
+
|style="background-color: white;"|Eierf.01 : Identifizierung und Authentifizierung von EFA-Teilnehmern
−
:sh
+
|style="background-color: white;"|
−
;Existing
+
|style="background-color: white;"|
−
:Patienteinwilligung
+
|style="background-color: white;"|Ich würde empfehlen das Thema Haftung hier nicht zu erwähnen. Die Haftungsregelung zwischen Identity Provider und EFA Provider sind ein eigenes Thema, das an dieser Stelle nicht ausgiebig behandelt werden kann. Ich würde daher nur vom "ausstellendem Dienst" sprechen, nicht vom "ausstellenden (und haftenden)". (ti, 29.05.2013)
−
;Proposed
+
|style="background-color: white;"|OK, insbesondere da ja auch der Besitzer der zur Authentisierung genutzten Objekte in bestimmten Fällen haftet (und die Spannbreite hier recht groß sein kann, wenn man sich hier auf der einen Seite die Gepflogeheiten im Onine-Banking und auf der anderen Seite die weitgehende Haftung des Bürgers bei der schweizerischen SuisseID anschaut).
−
:Patienteneinwilligung
+
|style="background-color: white;"|
−
== Eierf.02 ==
+
|- style="vertical-align:top;"
−
           
+
|style="background-color: white;"|gematik
−
;Author
+
|style="background-color: #89C35C;"|included
−
:sh
+
|style="background-color: white;"|Eierf.02 : Autorisierung von EFA-Teilnehmern
−
;Existing
+
|style="background-color: white;"|Unvollständige oder fehlende Informationen über qualifizierte Rolle und/oder Zugriffskontext SOLLTEN eine eventuelle Datenanfrage unterbinden.
−
:muster
+
|style="background-color: white;"|
−
;Proposed
+
|style="background-color: white;"|Wer soll was und wie unterbinden?
−
:Muster
+
|style="background-color: white;"|Die dem Fachdienstes vorgelagerte Komponente zur Sicherheitsprüfung (Policy Enforcement Point) darf nicht solche Datenanfragen verarbeiten. Stattdessen muss schon bei der Sicherheitsprüfung der Vorgang abgebrochen und eine Fehlernachricht an den Aufrufer übermittelt werden. Da dies aber durch die Verzahnung der Anwendungs- und Sicherheitsdienste implizit gewährleistet ist, kann der Satz entfallen.
−
== Eierf.02 ==
+
|style="background-color: white;"|
−
           
+
|- style="vertical-align:top;"
−
;Author
+
|style="background-color: white;"|sh
−
:sh
+
|style="background-color: #89C35C;"|included
−
;Existing
+
|style="background-color: white;"|Eierf.02 : Autorisierung von EFA-Teilnehmern
−
:legetime
+
|style="background-color: white;"|berechtig
−
;Proposed
+
|style="background-color: white;"|berechtigt
−
:legitime
+
|style="background-color: white;"|
−
== Eierf.02 ==
+
|style="background-color: white;"|
−
           
+
|style="background-color: white;"|
−
;Author
+
|- style="vertical-align:top;"
−
:sh
+
|style="background-color: white;"|sh
−
;Existing
+
|style="background-color: #89C35C;"|included
−
:fallbezogen und und zum Ziel
+
|style="background-color: white;"|Eierf.02 : Autorisierung von EFA-Teilnehmern
−
;Proposed
+
|style="background-color: white;"|Patienteinwilligung
−
:fallbezogen und zum Ziel
+
|style="background-color: white;"|Patienteneinwilligung
−
== Eierf.02 ==
+
|style="background-color: white;"|
−
           
+
|style="background-color: white;"|
−
;Author
+
|style="background-color: white;"|
−
:sh
+
|- style="vertical-align:top;"
−
;Existing
+
|style="background-color: white;"|sh
−
:qualifizierter
+
|style="background-color: #89C35C;"|included
−
;Proposed
+
|style="background-color: white;"|Eierf.02 : Autorisierung von EFA-Teilnehmern
−
:qualifizierten
+
|style="background-color: white;"|muster
−
== Eierf.02 ==
+
|style="background-color: white;"|Muster
−
           
+
|style="background-color: white;"|
−
;Author
+
|style="background-color: white;"|
−
:sh
+
|style="background-color: white;"|
−
;Existing
+
|- style="vertical-align:top;"
−
:obiegt
+
|style="background-color: white;"|sh
−
;Proposed
+
|style="background-color: #89C35C;"|included
−
:obliegt
+
|style="background-color: white;"|Eierf.02 : Autorisierung von EFA-Teilnehmern
−
== Eierf.02 ==
+
|style="background-color: white;"|legetime
−
           
+
|style="background-color: white;"|legitime
−
;Author
+
|style="background-color: white;"|
−
:sh
+
|style="background-color: white;"|
−
;Existing
+
|style="background-color: white;"|
−
:Sichehreitsrichtlinie
+
|- style="vertical-align:top;"
−
;Proposed
+
|style="background-color: white;"|sh
−
:Sicherheitsrichtlinie
+
|style="background-color: #89C35C;"|included
−
== Eierf.02 ==
+
|style="background-color: white;"|Eierf.02 : Autorisierung von EFA-Teilnehmern
−
           
+
|style="background-color: white;"|fallbezogen und und zum Ziel
−
;Author
+
|style="background-color: white;"|fallbezogen und zum Ziel
−
:sh
+
|style="background-color: white;"|
−
;Existing
+
|style="background-color: white;"|
−
:datenverarebitende
+
|style="background-color: white;"|
−
;Proposed
+
|- style="vertical-align:top;"
−
:datenverarbeitende
+
|style="background-color: white;"|sh
−
== Eierf.02 ==
+
|style="background-color: #89C35C;"|included
−
           
+
|style="background-color: white;"|Eierf.02 : Autorisierung von EFA-Teilnehmern
−
;Comment
+
|style="background-color: white;"|qualifizierter
−
:Wer soll was und wie unterbinden?
+
|style="background-color: white;"|qualifizierten
−
;Author
+
|style="background-color: white;"|
−
:gematik
+
|style="background-color: white;"|
−
;Existing
+
|style="background-color: white;"|
−
:Unvollständige oder fehlende Informationen über qualifizierte Rolle und/oder Zugriffskontext SOLLTEN eine eventuelle Datenanfrage unterbinden.
+
|- style="vertical-align:top;"
−
;Comment Editor
+
|style="background-color: white;"|sh
−
:Die dem Fachdienstes vorgelagerte Komponente zur Sicherheitsprüfung (Policy Enforcement Point) darf nicht solche Datenanfragen verarbeiten. Stattdessen muss schon bei der Sicherheitsprüfung der Vorgang abgebrochen und eine Fehlernachricht an den Aufrufer übermittelt werden.
+
|style="background-color: #89C35C;"|included
−
== Eierf.02 ==
+
|style="background-color: white;"|Eierf.02 : Autorisierung von EFA-Teilnehmern
−
           
+
|style="background-color: white;"|obiegt
−
;Comment
+
|style="background-color: white;"|obliegt
−
:Falls deny-biased im Sinne von XACML (d.h. ein "deny-biased PEP") gemeint ist, ist die Definition nicht korrekt. Jeder PEP führt bei eventuellen Negativindikatoren zu einer Negativentscheidung (nicht zum Abbruch der Entscheidungsfindung!). Nur ein "deny-biased PEP" führt auch ohne Negativindikatoren, sondern einzig durch das Ausbleiben von "Positivindikatoren" zu einer Negativentscheidung. Wenn es hier um die Kombination unterschiedlicher Regeln geht, sprechen wir eher von einem "deny-override". Ggf. wären hier ein paar Beispiele für Negativindikatoren sinnvoll, um den Text verständlicher zu machen. (ti, 29.05.2013)
+
|style="background-color: white;"|
−
;Author
+
|style="background-color: white;"|
−
:ti
+
|style="background-color: white;"|
−
;Comment Editor
+
|- style="vertical-align:top;"
−
:Formulierung kann entfallen.
+
|style="background-color: white;"|sh
−
== Eierf.03 ==
+
|style="background-color: #89C35C;"|included
−
           
+
|style="background-color: white;"|Eierf.02 : Autorisierung von EFA-Teilnehmern
−
;Author
+
|style="background-color: white;"|Sichehreitsrichtlinie
−
:sh
+
|style="background-color: white;"|Sicherheitsrichtlinie
−
;Existing
+
|style="background-color: white;"|
−
:korrete
+
|style="background-color: white;"|
−
;Proposed
+
|style="background-color: white;"|
−
:korrekte
+
|- style="vertical-align:top;"
−
== Eierf.03 ==
+
|style="background-color: white;"|sh
−
           
+
|style="background-color: #89C35C;"|included
−
;Author
+
|style="background-color: white;"|Eierf.02 : Autorisierung von EFA-Teilnehmern
−
:sh
+
|style="background-color: white;"|datenverarebitende
−
;Existing
+
|style="background-color: white;"|datenverarbeitende
−
:muss
+
|style="background-color: white;"|
−
;Proposed
+
|style="background-color: white;"|
−
:müssen
+
|style="background-color: white;"|
−
== Eierf.03 ==
+
|- style="vertical-align:top;"
−
           
+
|style="background-color: white;"|ti
−
;Comment
+
|style="background-color: #89C35C;"|included
−
:Semantikfrei? Würde ja auch den Informationstypen ausschließen, der als Metadatum am Informationsobjekt hängt.
+
|style="background-color: white;"|Eierf.02 : Autorisierung von EFA-Teilnehmern
−
;Author
+
|style="background-color: white;"|
−
:sh
+
|style="background-color: white;"|
−
;Existing
+
|style="background-color: white;"|Falls deny-biased im Sinne von XACML (d.h. ein "deny-biased PEP") gemeint ist, ist die Definition nicht korrekt. Jeder PEP führt bei eventuellen Negativindikatoren zu einer Negativentscheidung (nicht zum Abbruch der Entscheidungsfindung!). Nur ein "deny-biased PEP" führt auch ohne Negativindikatoren, sondern einzig durch das Ausbleiben von "Positivindikatoren" zu einer Negativentscheidung. Wenn es hier um die Kombination unterschiedlicher Regeln geht, sprechen wir eher von einem "deny-override". Ggf. wären hier ein paar Beispiele für Negativindikatoren sinnvoll, um den Text verständlicher zu machen. (ti, 29.05.2013)
−
:Die zur Übertragung benötigten personenbezogenen und/oder medizinische Informationen und deren potenzielle Offenbarung außerhalb der Fallakte (wie beispielsweise durch Metadaten) sind auf das zwingend notwendige Minimum zu beschränken. Eventuelle Metadaten sind idealerweise semantikfrei zu gestalten und sollten keine Rückschlüsse auf die innerhalb der Fallakte gekapselten personenbezogenen und/oder medizinische Informationen zulassen.
+
|style="background-color: white;"|Satz wurde eim Sinne des Kommentars klargestellt.
−
== Eierf.03 ==
+
|style="background-color: white;"|
−
           
+
|- style="vertical-align:top;"
−
;Author
+
|style="background-color: white;"|gematik
−
:sh
+
|style="background-color: #89C35C;"|included
−
;Existing
+
|style="background-color: white;"|Eierf.03 : Vertraulichkeit
−
:ausgetauschet
+
|style="background-color: white;"|Eventuelle Metadaten sind idealerweise semantikfrei zu gestalten
−
;Proposed
+
|style="background-color: white;"|
−
:ausgetauscht
+
|style="background-color: white;"|Inhalte / Werte so ablegen, dass keine Rückschlüsse …,. Ist das damit gemeint?
−
== Eierf.03 ==
+
|style="background-color: white;"|Satz wurde umformuliert, um deutlich zu machen, dass es hier lediglich darum geht, dass in Bezug zu einem identifizierbaren Patienten stehende Metadaten keine für Unberechtigte zugänglichen medizinischen oder sozialen Informationen enthalten sollen.
−
           
+
|style="background-color: white;"|
−
;Comment
+
|- style="vertical-align:top;"
−
:Inhalte / Werte so ablegen, dass keine Rückschlüsse …,. Ist das damit gemeint?
+
|style="background-color: white;"|sh
−
;Author
+
|style="background-color: #89C35C;"|included
−
:gematik
+
|style="background-color: white;"|Eierf.03 : Vertraulichkeit
−
;Existing
+
|style="background-color: white;"|korrete
−
:Eventuelle Metadaten sind idealerweise semantikfrei zu gestalten
+
|style="background-color: white;"|korrekte
−
;Comment Editor
+
|style="background-color: white;"|
−
:"Eventuell" streichen. Metadaten, sowohl die beim Transport ungeschützten als die gespeicherten, sollten keine Rückschlüsse auf einen Patienten zulassen.
+
|style="background-color: white;"|
−
== Eierf.03 ==
+
|style="background-color: white;"|
−
           
+
|- style="vertical-align:top;"
−
;Comment
+
|style="background-color: white;"|sh
−
:"außerhalb der Fallakte (wie beispielsweise durch Metadaten)" Dies würde andeuten dass die Dokumentenmetadaten in der Registry nicht als Teil der Fallakte zu verstehen sind. Dies entspricht aber nicht der vorherigen Definition einer Fallakte (z.B. beim Einstellen von Daten werden sowohl das Dokument als auch die Metadaten einer Partition zugeordnet, die Teil der Fallakte ist. Wenn es hier um eine abgestufte Handhabe von Dokumenten und deren Metadaten geht, um z.B. eine Verschlüsselung der Dokumente ohne eine Verschlüsselung der Metadaten zu begründen, verstehe ich den Beweggrund, würde aber eine andere Darstellung bevorzugen (d.h. Metadaten sind - ähnlich wie demografische Daten des Patienten - ein weniger schützenswerter Teil der Fallakte als die Dokumenteninhalte). (ti, 29.05.2013)
+
|style="background-color: #89C35C;"|included
−
;Author
+
|style="background-color: white;"|Eierf.03 : Vertraulichkeit
−
:ti
+
|style="background-color: white;"|muss
−
== Eierf.03.01 ==
+
|style="background-color: white;"|müssen
−
           
+
|style="background-color: white;"|
−
;Comment
+
|style="background-color: white;"|
−
:Auch mit mehreren Vertrauensräumen möglich?
+
|style="background-color: white;"|
−
;Author
+
|- style="vertical-align:top;"
−
:gematik
+
|style="background-color: white;"|sh
−
;Existing
+
|style="background-color: #89C35C;"|included
−
:Die datenhaltende Stelle muss ... authentisieren (Mutual Node Authentication)
+
|style="background-color: white;"|Eierf.03 : Vertraulichkeit
−
;Comment Editor
+
|style="background-color: white;"|Die zur Übertragung benötigten personenbezogenen und/oder medizinische Informationen und deren potenzielle Offenbarung außerhalb der Fallakte (wie beispielsweise durch Metadaten) sind auf das zwingend notwendige Minimum zu beschränken. Eventuelle Metadaten sind idealerweise semantikfrei zu gestalten und sollten keine Rückschlüsse auf die innerhalb der Fallakte gekapselten personenbezogenen und/oder medizinische Informationen zulassen.
−
:Ja. Secure Channels kommen jeweils zwischen Kommunikationspartnern zum Einsatz. Es wird eine Punkt-zu-Punkt, allerdings keine Ende-zu-Ende-Sicherheit gefordert.
+
|style="background-color: white;"|
−
== Eierf.03.01 ==
+
|style="background-color: white;"|Semantikfrei? Würde ja auch den Informationstypen ausschließen, der als Metadatum am Informationsobjekt hängt.
−
           
+
|style="background-color: white;"|Satz wurde umformuliert, um deutlich zu machen, dass es hier lediglich darum geht, dass in Bezug zu einem identifizierbaren Patienten stehende Metadaten keine für Unberechtigte zugänglichen medizinischen oder sozialen Informationen enthalten sollen.
−
;Comment
+
|style="background-color: white;"|
−
:Erläuterung der Motivation, Zielgruppe?
+
|- style="vertical-align:top;"
−
;Author
+
|style="background-color: white;"|sh
−
:gematik
+
|style="background-color: #89C35C;"|included
−
;Existing
+
|style="background-color: white;"|Eierf.03 : Vertraulichkeit
−
:durchgängig unbelauschbar, durchgängig isoliert, davor bewahrt werden, Rückschlüsse zu ermöglichen
+
|style="background-color: white;"|ausgetauschet
−
;Comment Editor
+
|style="background-color: white;"|ausgetauscht
−
:Motivation: Transportverschlüsselung, Zielgruppe: alle Kommunikationspartner
+
|style="background-color: white;"|
−
== Eierf.04 ==
+
|style="background-color: white;"|
−
           
+
|style="background-color: white;"|
−
;Comment
+
|- style="vertical-align:top;"
−
:Welche Szenarien gibt es konkret?
+
|style="background-color: white;"|ti
−
;Author
+
|style="background-color: #89C35C;"|included
−
:gematik
+
|style="background-color: white;"|Eierf.03 : Vertraulichkeit
−
;Existing
+
|style="background-color: white;"|
−
:gesicherte Informationen über Identität der datenvermittelten Stelle (beispielsweise ein Zwischenspeicher-Szenario)
+
|style="background-color: white;"|
−
;Comment Editor
+
|style="background-color: white;"|"außerhalb der Fallakte (wie beispielsweise durch Metadaten)" Dies würde andeuten dass die Dokumentenmetadaten in der Registry nicht als Teil der Fallakte zu verstehen sind. Dies entspricht aber nicht der vorherigen Definition einer Fallakte (z.B. beim Einstellen von Daten werden sowohl das Dokument als auch die Metadaten einer Partition zugeordnet, die Teil der Fallakte ist. Wenn es hier um eine abgestufte Handhabe von Dokumenten und deren Metadaten geht, um z.B. eine Verschlüsselung der Dokumente ohne eine Verschlüsselung der Metadaten zu begründen, verstehe ich den Beweggrund, würde aber eine andere Darstellung bevorzugen (d.h. Metadaten sind - ähnlich wie demografische Daten des Patienten - ein weniger schützenswerter Teil der Fallakte als die Dokumenteninhalte). (ti, 29.05.2013)
−
:XCA-Gateway im P2P-Szenario
+
|style="background-color: white;"|Satz wurde umformuliert, um deutlich zu machen, dass es hier lediglich darum geht, dass in Bezug zu einem identifizierbaren Patienten stehende Metadaten keine für Unberechtigte zugänglichen medizinischen oder sozialen Informationen enthalten sollen.
−
== Eierf.05 ==
+
|style="background-color: white;"|
−
           
+
|- style="vertical-align:top;"
−
;Comment
+
|style="background-color: white;"|gematik
−
:Was bedeutet nachträglich und lückenlos im Kontext?
+
|style="background-color: #89C35C;"|included
−
;Author
+
|style="background-color: white;"|Eierf.03.01 : EFA Secure Channels
−
:gematik
+
|style="background-color: white;"|Die datenhaltende Stelle muss ... authentisieren (Mutual Node Authentication)
−
;Existing
+
|style="background-color: white;"|
−
:nachträgliche lückenlose Rekonstruktion der Kommunikation und des Kontexts möglich
+
|style="background-color: white;"|Auch mit mehreren Vertrauensräumen möglich?
−
;Comment Editor
+
|style="background-color: white;"|Ja. Secure Channels kommen jeweils zwischen Kommunikationspartnern zum Einsatz. Es wird eine Punkt-zu-Punkt, allerdings keine Ende-zu-Ende-Sicherheit gefordert. Satz klarer formuliert.
−
:Nachträglich: nach erfolgtem Zugriff auf einen Fachdienst, Lückenlos: alle Transaktionen auf der EFA-Anwendungsebene
+
|style="background-color: white;"|
−
== Eierf.05 ==
+
|- style="vertical-align:top;"
−
           
+
|style="background-color: white;"|gematik
−
;Comment
+
|style="background-color: #89C35C;"|included
−
:Zu welchem Zweck?  Wer ist direkt betroffen? Der Patient, die Ärzte…?
+
|style="background-color: white;"|Eierf.03.01 : EFA Secure Channels
−
;Author
+
|style="background-color: white;"|durchgängig unbelauschbar, durchgängig isoliert, davor bewahrt werden, Rückschlüsse zu ermöglichen
−
:gematik
+
|style="background-color: white;"|
−
;Existing
+
|style="background-color: white;"|Erläuterung der Motivation, Zielgruppe?
−
:Sollten lediglich Minimalaufbewahrungsfristen gewahrt werden, so sind alle direkt Betroffenen über diesen Umstand geeignet zu unterrichten.
+
|style="background-color: white;"|Motivation: Transportverschlüsselung, Zielgruppe: alle Kommunikationspartner. Satz wurde klarer formuliert.
−
;Comment Editor
+
|style="background-color: white;"|
−
:Patienten und Ärzte sind zu unterrichten.
+
|- style="vertical-align:top;"
−
== Eierf.05 ==
+
|style="background-color: white;"|gematik
−
           
+
|style="background-color: #89C35C;"|included
−
;Comment
+
|style="background-color: white;"|Eierf.04 : Authentizität und Integrität von EFA Daten
−
:Prinzipiell?
+
|style="background-color: white;"|gesicherte Informationen über Identität der datenvermittelten Stelle (beispielsweise ein Zwischenspeicher-Szenario)
−
;Author
+
|style="background-color: white;"|
−
:gematik
+
|style="background-color: white;"|Welche Szenarien gibt es konkret?
−
;Existing
+
|style="background-color: white;"|XCA-Gateway im P2P-Szenario. Ausführungen wurden entsprechend konkretisiert.
−
:medizinischen Daten vor Zugriffen unberechtigter Dritter zu schützen und verfügen prinzipiell über den gleichen Schutzbedarf wie die darin enthaltenen Daten
+
|style="background-color: white;"|
−
;Comment Editor
+
|- style="vertical-align:top;"
−
:"Prinzipiell" streichen.
+
|style="background-color: white;"|gematik
−
== Eierf.06 ==
+
|style="background-color: #89C35C;"|included
−
           
+
|style="background-color: white;"|Eierf.05 : Nicht-Abstreitbarkeit, Dokumentation und Audit-Trail
−
;Comment
+
|style="background-color: white;"|nachträgliche lückenlose Rekonstruktion der Kommunikation und des Kontexts möglich
−
:Genauer Formulieren
+
|style="background-color: white;"|
−
;Author
+
|style="background-color: white;"|Was bedeutet nachträglich und lückenlos im Kontext?
−
:gematik
+
|style="background-color: white;"|Nachträglich: nach erfolgtem Zugriff auf einen Fachdienst, Lückenlos: alle Transaktionen auf der EFA-Anwendungsebene
−
;Existing
+
|style="background-color: white;"|
−
:Eventuelle Providencefehler und/oder Unvollständigkeiten bezüglich der in der Datenübertragung kommunizierten Daten sind stets zu Nachweiszwecken unfänglich von allen beteiligten Kommunikationspartnern zu eigenständig dokumentieren.
+
|- style="vertical-align:top;"
 +
|style="background-color: white;"|gematik
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eierf.05 : Nicht-Abstreitbarkeit, Dokumentation und Audit-Trail
 +
|style="background-color: white;"|Sollten lediglich Minimalaufbewahrungsfristen gewahrt werden, so sind alle direkt Betroffenen über diesen Umstand geeignet zu unterrichten.
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|Zu welchem Zweck?  Wer ist direkt betroffen? Der Patient, die Ärzte…?
 +
|style="background-color: white;"|Konkretisiert: Patienten und Ärzte sind zu unterrichten.
 +
|style="background-color: white;"|
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|gematik
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eierf.05 : Nicht-Abstreitbarkeit, Dokumentation und Audit-Trail
 +
|style="background-color: white;"|medizinischen Daten vor Zugriffen unberechtigter Dritter zu schützen und verfügen prinzipiell über den gleichen Schutzbedarf wie die darin enthaltenen Daten
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|Prinzipiell?
 +
|style="background-color: white;"|"Prinzipiell" gestrichen
 +
|style="background-color: white;"|
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|gematik
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eierf.06 : Verfügbarkeit von EFA-Teilnehmern und EFA-Daten
 +
|style="background-color: white;"|Eventuelle Providencefehler und/oder Unvollständigkeiten bezüglich der in der Datenübertragung kommunizierten Daten sind stets zu Nachweiszwecken unfänglich von allen beteiligten Kommunikationspartnern zu eigenständig dokumentieren.
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|Genauer Formulieren
 +
|style="background-color: white;"|Hinweis auf die zusätzlich zu protokolliernenden Informationen eingefügt.
 +
|style="background-color: white;"|
 +
|}

Version vom 24. Januar 2014, 15:40 Uhr

Kommentierung

Author Status Section Existing Proposed Comment Comment Editor Discussion
gematik included Eierf.01 : Identifizierung und Authentifizierung von EFA-Teilnehmern Stabilität des Vertrauensverhältnis zum ausstellenden Dienst Was bedeutet hier konkret Stabilität? Gemeint ist das Vorhandensein des Vertrauensverhältnisses zum ausstellenden Dienst. Technisch bedeutet das: Das Zertifikat des Dienstes muss valide und nicht zurückgezogen sein, der Zertifikataussteller muss vertrauenswürdig sein.
sh included Eierf.01 : Identifizierung und Authentifizierung von EFA-Teilnehmern bereitstellung Bereitstellung
sh included Eierf.01 : Identifizierung und Authentifizierung von EFA-Teilnehmern bennennen benennen
sh included Eierf.01 : Identifizierung und Authentifizierung von EFA-Teilnehmern identifikation Identifikation
sh included Eierf.01 : Identifizierung und Authentifizierung von EFA-Teilnehmern Athentisierung Authentisierung
ti included Eierf.01 : Identifizierung und Authentifizierung von EFA-Teilnehmern Ich würde empfehlen das Thema Haftung hier nicht zu erwähnen. Die Haftungsregelung zwischen Identity Provider und EFA Provider sind ein eigenes Thema, das an dieser Stelle nicht ausgiebig behandelt werden kann. Ich würde daher nur vom "ausstellendem Dienst" sprechen, nicht vom "ausstellenden (und haftenden)". (ti, 29.05.2013) OK, insbesondere da ja auch der Besitzer der zur Authentisierung genutzten Objekte in bestimmten Fällen haftet (und die Spannbreite hier recht groß sein kann, wenn man sich hier auf der einen Seite die Gepflogeheiten im Onine-Banking und auf der anderen Seite die weitgehende Haftung des Bürgers bei der schweizerischen SuisseID anschaut).
gematik included Eierf.02 : Autorisierung von EFA-Teilnehmern Unvollständige oder fehlende Informationen über qualifizierte Rolle und/oder Zugriffskontext SOLLTEN eine eventuelle Datenanfrage unterbinden. Wer soll was und wie unterbinden? Die dem Fachdienstes vorgelagerte Komponente zur Sicherheitsprüfung (Policy Enforcement Point) darf nicht solche Datenanfragen verarbeiten. Stattdessen muss schon bei der Sicherheitsprüfung der Vorgang abgebrochen und eine Fehlernachricht an den Aufrufer übermittelt werden. Da dies aber durch die Verzahnung der Anwendungs- und Sicherheitsdienste implizit gewährleistet ist, kann der Satz entfallen.
sh included Eierf.02 : Autorisierung von EFA-Teilnehmern berechtig berechtigt
sh included Eierf.02 : Autorisierung von EFA-Teilnehmern Patienteinwilligung Patienteneinwilligung
sh included Eierf.02 : Autorisierung von EFA-Teilnehmern muster Muster
sh included Eierf.02 : Autorisierung von EFA-Teilnehmern legetime legitime
sh included Eierf.02 : Autorisierung von EFA-Teilnehmern fallbezogen und und zum Ziel fallbezogen und zum Ziel
sh included Eierf.02 : Autorisierung von EFA-Teilnehmern qualifizierter qualifizierten
sh included Eierf.02 : Autorisierung von EFA-Teilnehmern obiegt obliegt
sh included Eierf.02 : Autorisierung von EFA-Teilnehmern Sichehreitsrichtlinie Sicherheitsrichtlinie
sh included Eierf.02 : Autorisierung von EFA-Teilnehmern datenverarebitende datenverarbeitende
ti included Eierf.02 : Autorisierung von EFA-Teilnehmern Falls deny-biased im Sinne von XACML (d.h. ein "deny-biased PEP") gemeint ist, ist die Definition nicht korrekt. Jeder PEP führt bei eventuellen Negativindikatoren zu einer Negativentscheidung (nicht zum Abbruch der Entscheidungsfindung!). Nur ein "deny-biased PEP" führt auch ohne Negativindikatoren, sondern einzig durch das Ausbleiben von "Positivindikatoren" zu einer Negativentscheidung. Wenn es hier um die Kombination unterschiedlicher Regeln geht, sprechen wir eher von einem "deny-override". Ggf. wären hier ein paar Beispiele für Negativindikatoren sinnvoll, um den Text verständlicher zu machen. (ti, 29.05.2013) Satz wurde eim Sinne des Kommentars klargestellt.
gematik included Eierf.03 : Vertraulichkeit Eventuelle Metadaten sind idealerweise semantikfrei zu gestalten Inhalte / Werte so ablegen, dass keine Rückschlüsse …,. Ist das damit gemeint? Satz wurde umformuliert, um deutlich zu machen, dass es hier lediglich darum geht, dass in Bezug zu einem identifizierbaren Patienten stehende Metadaten keine für Unberechtigte zugänglichen medizinischen oder sozialen Informationen enthalten sollen.
sh included Eierf.03 : Vertraulichkeit korrete korrekte
sh included Eierf.03 : Vertraulichkeit muss müssen
sh included Eierf.03 : Vertraulichkeit Die zur Übertragung benötigten personenbezogenen und/oder medizinische Informationen und deren potenzielle Offenbarung außerhalb der Fallakte (wie beispielsweise durch Metadaten) sind auf das zwingend notwendige Minimum zu beschränken. Eventuelle Metadaten sind idealerweise semantikfrei zu gestalten und sollten keine Rückschlüsse auf die innerhalb der Fallakte gekapselten personenbezogenen und/oder medizinische Informationen zulassen. Semantikfrei? Würde ja auch den Informationstypen ausschließen, der als Metadatum am Informationsobjekt hängt. Satz wurde umformuliert, um deutlich zu machen, dass es hier lediglich darum geht, dass in Bezug zu einem identifizierbaren Patienten stehende Metadaten keine für Unberechtigte zugänglichen medizinischen oder sozialen Informationen enthalten sollen.
sh included Eierf.03 : Vertraulichkeit ausgetauschet ausgetauscht
ti included Eierf.03 : Vertraulichkeit "außerhalb der Fallakte (wie beispielsweise durch Metadaten)" Dies würde andeuten dass die Dokumentenmetadaten in der Registry nicht als Teil der Fallakte zu verstehen sind. Dies entspricht aber nicht der vorherigen Definition einer Fallakte (z.B. beim Einstellen von Daten werden sowohl das Dokument als auch die Metadaten einer Partition zugeordnet, die Teil der Fallakte ist. Wenn es hier um eine abgestufte Handhabe von Dokumenten und deren Metadaten geht, um z.B. eine Verschlüsselung der Dokumente ohne eine Verschlüsselung der Metadaten zu begründen, verstehe ich den Beweggrund, würde aber eine andere Darstellung bevorzugen (d.h. Metadaten sind - ähnlich wie demografische Daten des Patienten - ein weniger schützenswerter Teil der Fallakte als die Dokumenteninhalte). (ti, 29.05.2013) Satz wurde umformuliert, um deutlich zu machen, dass es hier lediglich darum geht, dass in Bezug zu einem identifizierbaren Patienten stehende Metadaten keine für Unberechtigte zugänglichen medizinischen oder sozialen Informationen enthalten sollen.
gematik included Eierf.03.01 : EFA Secure Channels Die datenhaltende Stelle muss ... authentisieren (Mutual Node Authentication) Auch mit mehreren Vertrauensräumen möglich? Ja. Secure Channels kommen jeweils zwischen Kommunikationspartnern zum Einsatz. Es wird eine Punkt-zu-Punkt, allerdings keine Ende-zu-Ende-Sicherheit gefordert. Satz klarer formuliert.
gematik included Eierf.03.01 : EFA Secure Channels durchgängig unbelauschbar, durchgängig isoliert, davor bewahrt werden, Rückschlüsse zu ermöglichen Erläuterung der Motivation, Zielgruppe? Motivation: Transportverschlüsselung, Zielgruppe: alle Kommunikationspartner. Satz wurde klarer formuliert.
gematik included Eierf.04 : Authentizität und Integrität von EFA Daten gesicherte Informationen über Identität der datenvermittelten Stelle (beispielsweise ein Zwischenspeicher-Szenario) Welche Szenarien gibt es konkret? XCA-Gateway im P2P-Szenario. Ausführungen wurden entsprechend konkretisiert.
gematik included Eierf.05 : Nicht-Abstreitbarkeit, Dokumentation und Audit-Trail nachträgliche lückenlose Rekonstruktion der Kommunikation und des Kontexts möglich Was bedeutet nachträglich und lückenlos im Kontext? Nachträglich: nach erfolgtem Zugriff auf einen Fachdienst, Lückenlos: alle Transaktionen auf der EFA-Anwendungsebene
gematik included Eierf.05 : Nicht-Abstreitbarkeit, Dokumentation und Audit-Trail Sollten lediglich Minimalaufbewahrungsfristen gewahrt werden, so sind alle direkt Betroffenen über diesen Umstand geeignet zu unterrichten. Zu welchem Zweck? Wer ist direkt betroffen? Der Patient, die Ärzte…? Konkretisiert: Patienten und Ärzte sind zu unterrichten.
gematik included Eierf.05 : Nicht-Abstreitbarkeit, Dokumentation und Audit-Trail medizinischen Daten vor Zugriffen unberechtigter Dritter zu schützen und verfügen prinzipiell über den gleichen Schutzbedarf wie die darin enthaltenen Daten Prinzipiell? "Prinzipiell" gestrichen
gematik included Eierf.06 : Verfügbarkeit von EFA-Teilnehmern und EFA-Daten Eventuelle Providencefehler und/oder Unvollständigkeiten bezüglich der in der Datenübertragung kommunizierten Daten sind stets zu Nachweiszwecken unfänglich von allen beteiligten Kommunikationspartnern zu eigenständig dokumentieren. Genauer Formulieren Hinweis auf die zusätzlich zu protokolliernenden Informationen eingefügt.
Abgerufen von „https://wiki.hl7.de/index.php?title=cdaefa_Diskussion:EFA_Sicherheitsanforderungen&oldid=16982“