cdaefa Diskussion:EFA Sicherheitsanforderungen

Aus Hl7wiki
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…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

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.