Momentan sind Chipkarten mit 32 bzw. 64 KB Speicher im Gespräch, d.
h. es werden mit Sicherheit nicht alle Daten auf die Karte passen.
Dies ist aber nicht der Hauptgrund dafür, dass Daten auf dem Server
gespeichert werden. Wesentliche Argumente für eine serverbasierte
Datenhaltung sind vielmehr:
- Sicherheitsüberlegungen: Die Gesundheitskarte unterstützt keine
X.509 Authentifizierung der zugreifenden Person. Selbst wenn dies
technisch möglich wäre, würde es nicht allzu viel bringen, da die
Karte immer auf eine Dritten angewiesen wäre, der die Authentizität
z. B. von Sperrlisten garantiert. Dieser "Dritte" kann der Karte aber
mit einem selbstgebastelten Lesegerät oder einem manipulierten
Konnektor relativ problemlos vorgegaukelt werden. Aus diesem Grund
werden sog. CV-Zertifikate eingesetzt, über die bei Datenzugriff
durch die Karte selber eine Rollenüberprüfung stattfinden kann (d. h.
die zugreifende Person authentifiziert sich über ihren
Heilberufsausweis der Gesundheitskarte gegenüber als Arzt. Dieser
Vorgang läuft allein zwischen den Karten ab, d.h. es wird keine
weitere Instanz benötigt und aufgrund des zwischen den Karten
aufgebauten sicheren Kanals ist auch keine Einflussnahme über das
Lesegerät möglich). Für besonders sensible Daten wie z. B. die
Patientenakte ist dieses Schutzniveau jedoch nicht ausreichend, da
Heilberufsausweise auch gestohlen werden können und in vielen Fällen
die Einschränkung auf eine Rolle nicht ausreichend ist, sondern man
die Zugriffsrechte auf einzelne Ärzte beschränken will. Aus diesen
Gründen wird in der Lösungsarchitektur ein Konzept vorgeschlagen, in
dem viele Daten auf Servern verwaltet werden, der Zugriff und die
Entschlüsselung der Daten aber nur über auf der Gesundheitskarte
gespeicherte Zugangsschlüssel (sog. Tickets) möglich ist. Dieses
Konzept vereint die Stärken der Karte (physikalischer Besitz der
Zugangsschlüssel) und der Server (individuelle Rechteüberprüfung,
Zugriffsprotokollierung, etc.), so dass letztendlich ein höheres
Sicherheitsniveau erreichbar ist, als wenn die Daten auf der Karte
liegen würden.
- fachliche Anforderungen wie z. B. die Ausstellung von Folgerezepten
(erneute Ausstellung eines Rezepts - z. B. für chronisch Kranke -
ohne dass der Versicherte dazu extra in die Arztpraxis kommen muss)
und die Weiterleitung von Entlassungsdokumenten vom Krankenhaus an
den Hausarzt erfordern, dass bestimmte Aktionen möglich sind, ohne
dass dazu auch auf die Karte geschrieben werden muss. Auch hierbei
kann jedoch durch Nutzung asymmetrischer Verschlüsselungsverfahren
sichergestellt werden, dass ein Zugriff auf die Daten nur mit der
Karte des Versicherten möglich ist.
Die Spezifikation der technischen Umsetzung des Sicherheitskonzepts
ist unter
http://www.dimdi.de/de/ehealth/karte/technik/loesungsarchitektur/erge
bnisse/index.htm im Dokument "Gesamtsicht" beschrieben.
h. es werden mit Sicherheit nicht alle Daten auf die Karte passen.
Dies ist aber nicht der Hauptgrund dafür, dass Daten auf dem Server
gespeichert werden. Wesentliche Argumente für eine serverbasierte
Datenhaltung sind vielmehr:
- Sicherheitsüberlegungen: Die Gesundheitskarte unterstützt keine
X.509 Authentifizierung der zugreifenden Person. Selbst wenn dies
technisch möglich wäre, würde es nicht allzu viel bringen, da die
Karte immer auf eine Dritten angewiesen wäre, der die Authentizität
z. B. von Sperrlisten garantiert. Dieser "Dritte" kann der Karte aber
mit einem selbstgebastelten Lesegerät oder einem manipulierten
Konnektor relativ problemlos vorgegaukelt werden. Aus diesem Grund
werden sog. CV-Zertifikate eingesetzt, über die bei Datenzugriff
durch die Karte selber eine Rollenüberprüfung stattfinden kann (d. h.
die zugreifende Person authentifiziert sich über ihren
Heilberufsausweis der Gesundheitskarte gegenüber als Arzt. Dieser
Vorgang läuft allein zwischen den Karten ab, d.h. es wird keine
weitere Instanz benötigt und aufgrund des zwischen den Karten
aufgebauten sicheren Kanals ist auch keine Einflussnahme über das
Lesegerät möglich). Für besonders sensible Daten wie z. B. die
Patientenakte ist dieses Schutzniveau jedoch nicht ausreichend, da
Heilberufsausweise auch gestohlen werden können und in vielen Fällen
die Einschränkung auf eine Rolle nicht ausreichend ist, sondern man
die Zugriffsrechte auf einzelne Ärzte beschränken will. Aus diesen
Gründen wird in der Lösungsarchitektur ein Konzept vorgeschlagen, in
dem viele Daten auf Servern verwaltet werden, der Zugriff und die
Entschlüsselung der Daten aber nur über auf der Gesundheitskarte
gespeicherte Zugangsschlüssel (sog. Tickets) möglich ist. Dieses
Konzept vereint die Stärken der Karte (physikalischer Besitz der
Zugangsschlüssel) und der Server (individuelle Rechteüberprüfung,
Zugriffsprotokollierung, etc.), so dass letztendlich ein höheres
Sicherheitsniveau erreichbar ist, als wenn die Daten auf der Karte
liegen würden.
- fachliche Anforderungen wie z. B. die Ausstellung von Folgerezepten
(erneute Ausstellung eines Rezepts - z. B. für chronisch Kranke -
ohne dass der Versicherte dazu extra in die Arztpraxis kommen muss)
und die Weiterleitung von Entlassungsdokumenten vom Krankenhaus an
den Hausarzt erfordern, dass bestimmte Aktionen möglich sind, ohne
dass dazu auch auf die Karte geschrieben werden muss. Auch hierbei
kann jedoch durch Nutzung asymmetrischer Verschlüsselungsverfahren
sichergestellt werden, dass ein Zugriff auf die Daten nur mit der
Karte des Versicherten möglich ist.
Die Spezifikation der technischen Umsetzung des Sicherheitskonzepts
ist unter
http://www.dimdi.de/de/ehealth/karte/technik/loesungsarchitektur/erge
bnisse/index.htm im Dokument "Gesamtsicht" beschrieben.