cdaefa Diskussion:EFA Sicherheitsanforderungen
Version vom 17. September 2013, 16:15 Uhr von Jcaumanns (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „== Eierf.01 == ;Author :sh ;Existing :bereitstellung ;Proposed :Bereitstellung == Eierf.01 == ;Author :sh ;Existing :bennennen ;Propo…“)
Inhaltsverzeichnis
- 1 Eierf.01
- 2 Eierf.01
- 3 Eierf.01
- 4 Eierf.01
- 5 Eierf.01
- 6 Eierf.01
- 7 Eierf.02
- 8 Eierf.02
- 9 Eierf.02
- 10 Eierf.02
- 11 Eierf.02
- 12 Eierf.02
- 13 Eierf.02
- 14 Eierf.02
- 15 Eierf.02
- 16 Eierf.02
- 17 Eierf.02
- 18 Eierf.03
- 19 Eierf.03
- 20 Eierf.03
- 21 Eierf.03
- 22 Eierf.03
- 23 Eierf.03
- 24 Eierf.03.01
- 25 Eierf.03.01
- 26 Eierf.04
- 27 Eierf.05
- 28 Eierf.05
- 29 Eierf.05
- 30 Eierf.06
Eierf.01
- Author
- sh
- Existing
- bereitstellung
- Proposed
- Bereitstellung
Eierf.01
- Author
- sh
- Existing
- bennennen
- Proposed
- benennen
Eierf.01
- Author
- sh
- Existing
- identifikation
- Proposed
- Identifikation
Eierf.01
- Author
- sh
- Existing
- Athentisierung
- Proposed
- Authentisierung
Eierf.01
- Comment
- Was bedeutet hier konkret Stabilität?
- Author
- gematik
- Existing
- Stabilität des Vertrauensverhältnis zum ausstellenden Dienst
- Comment Editor
- 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.
Eierf.01
- Comment
- 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)
- Author
- ti
Eierf.02
- Author
- sh
- Existing
- berechtig
- Proposed
- berechtigt
Eierf.02
- Author
- sh
- Existing
- Patienteinwilligung
- Proposed
- Patienteneinwilligung
Eierf.02
- Author
- sh
- Existing
- muster
- Proposed
- Muster
Eierf.02
- Author
- sh
- Existing
- legetime
- Proposed
- legitime
Eierf.02
- Author
- sh
- Existing
- fallbezogen und und zum Ziel
- Proposed
- fallbezogen und zum Ziel
Eierf.02
- Author
- sh
- Existing
- qualifizierter
- Proposed
- qualifizierten
Eierf.02
- Author
- sh
- Existing
- obiegt
- Proposed
- obliegt
Eierf.02
- Author
- sh
- Existing
- Sichehreitsrichtlinie
- Proposed
- Sicherheitsrichtlinie
Eierf.02
- Author
- sh
- Existing
- datenverarebitende
- Proposed
- datenverarbeitende
Eierf.02
- Comment
- Wer soll was und wie unterbinden?
- Author
- gematik
- Existing
- Unvollständige oder fehlende Informationen über qualifizierte Rolle und/oder Zugriffskontext SOLLTEN eine eventuelle Datenanfrage unterbinden.
- Comment Editor
- 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.
Eierf.02
- Comment
- 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)
- Author
- ti
- Comment Editor
- Formulierung kann entfallen.
Eierf.03
- Author
- sh
- Existing
- korrete
- Proposed
- korrekte
Eierf.03
- Author
- sh
- Existing
- muss
- Proposed
- müssen
Eierf.03
- Comment
- Semantikfrei? Würde ja auch den Informationstypen ausschließen, der als Metadatum am Informationsobjekt hängt.
- Author
- sh
- Existing
- 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.
Eierf.03
- Author
- sh
- Existing
- ausgetauschet
- Proposed
- ausgetauscht
Eierf.03
- Comment
- Inhalte / Werte so ablegen, dass keine Rückschlüsse …,. Ist das damit gemeint?
- Author
- gematik
- Existing
- Eventuelle Metadaten sind idealerweise semantikfrei zu gestalten
- Comment Editor
- "Eventuell" streichen. Metadaten, sowohl die beim Transport ungeschützten als die gespeicherten, sollten keine Rückschlüsse auf einen Patienten zulassen.
Eierf.03
- Comment
- "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)
- Author
- ti
Eierf.03.01
- Comment
- Auch mit mehreren Vertrauensräumen möglich?
- Author
- gematik
- Existing
- Die datenhaltende Stelle muss ... authentisieren (Mutual Node Authentication)
- Comment Editor
- Ja. Secure Channels kommen jeweils zwischen Kommunikationspartnern zum Einsatz. Es wird eine Punkt-zu-Punkt, allerdings keine Ende-zu-Ende-Sicherheit gefordert.
Eierf.03.01
- Comment
- Erläuterung der Motivation, Zielgruppe?
- Author
- gematik
- Existing
- durchgängig unbelauschbar, durchgängig isoliert, davor bewahrt werden, Rückschlüsse zu ermöglichen
- Comment Editor
- Motivation: Transportverschlüsselung, Zielgruppe: alle Kommunikationspartner
Eierf.04
- Comment
- Welche Szenarien gibt es konkret?
- Author
- gematik
- Existing
- gesicherte Informationen über Identität der datenvermittelten Stelle (beispielsweise ein Zwischenspeicher-Szenario)
- Comment Editor
- XCA-Gateway im P2P-Szenario
Eierf.05
- Comment
- Was bedeutet nachträglich und lückenlos im Kontext?
- Author
- gematik
- Existing
- nachträgliche lückenlose Rekonstruktion der Kommunikation und des Kontexts möglich
- Comment Editor
- Nachträglich: nach erfolgtem Zugriff auf einen Fachdienst, Lückenlos: alle Transaktionen auf der EFA-Anwendungsebene
Eierf.05
- Comment
- Zu welchem Zweck? Wer ist direkt betroffen? Der Patient, die Ärzte…?
- Author
- gematik
- Existing
- Sollten lediglich Minimalaufbewahrungsfristen gewahrt werden, so sind alle direkt Betroffenen über diesen Umstand geeignet zu unterrichten.
- Comment Editor
- Patienten und Ärzte sind zu unterrichten.
Eierf.05
- Comment
- Prinzipiell?
- Author
- gematik
- Existing
- medizinischen Daten vor Zugriffen unberechtigter Dritter zu schützen und verfügen prinzipiell über den gleichen Schutzbedarf wie die darin enthaltenen Daten
- Comment Editor
- "Prinzipiell" streichen.
Eierf.06
- Comment
- Genauer Formulieren
- Author
- gematik
- Existing
- 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.