Zusammenf¨ uhrung von Patientendaten

Im vorhergehenden Abschnitt erfolgte die Beschreibung der technischen Alternativen f¨ur die Gew¨ahrleistung einer sicheren Arbeitsumgebung. Die Sicherheit der Arbeitsumgebung ist insbesondere f¨ur die vertrauliche Zusammenf¨uhrung von PatientendatenIDAT undMDAT im Behandlungszusammenhang von Bedeutung. Die technischen Aspekte der w¨ahrend der Erstellung dieser Arbeit aufgetretenen Fragestellung nach der Zusammenf¨uhrung der Daten im Clienten werden in diesem Abschnitt untersucht. Die Zielsetzung ist der Vergleich von Ajax, Java und der Terminal Server-Technologie in Bezug auf ihre Eignung, die Anforderungen der Datenprozessierung in den klinisch fokussierten medizinischen Forschungsnetzen zu erf¨ullen. Der Vergleich bezieht sich auf die Einsatzpotenziale der o. g.

Technologien und bewertet nicht die tats¨achliche Sicherheit einer m¨oglichen konkreten Umsetzung. Mit der gleichen Technologie sind viele besser oder schlechter geeignete Konfi-gurationen denkbar; auch die Entwicklungs-, Implementierungs- und Einsatzaspekte der Anwendung m¨ussen ber¨ucksichtigt werden. Schließlich werden nicht die drei Technologien nach dem

”Stiftung Warentest-Prinzip“ bewertet, um die

”ultimative“ Siegertechnologie zu ermitteln. Vielmehr werden die potenziellen Kombinationsm¨oglichkeiten dieser Techno-logien untersucht, denn diese k¨onnen sich im Rahmen einer L¨osung sinnvoll erg¨anzen, um eine sichere Zusammenf¨uhrung vonIDAT und MDAT zu gew¨ahrleisten.

3.5.2.1. Sicherheit von Ajax

In den letzten Jahren ersetzt zunehmend die Ajax-Technologie die klassischen Desktop-Anwendungen. Dabei realisiert man mithilfe der Webtechnologie Desktop-¨ahnliche Ap-plikationen. Als Grundlage f¨ur Ajax dienen HTML/XHTML, DOM, JavaScript und XMLHttpRequest.

Die Basis f¨ur die Sicherheit von Ajax bilden die asynchrone Daten¨ubertragung und das zugrunde liegende JavaScript. Ajax-Anwendungen bestehen aus der Client- und Serverseite sowie dem Transportweg und geh¨oren somit zu den verteilten Systemen. Die Ajax-Skripte werden in einer Sandbox-¨ahnlichen Umgebung im Browser des Nutzers ausgef¨uhrt, die den Aufbau von Verbindungen zu den anderen Skripten via XMLHttpRequest und die Manipulation der lokalen Benutzer-Ressourcen verhindern soll.

Bei unzureichender Validierung von GET- und POST-Parametern kann eine solche An-wendung gegen¨uber von Cross-Site Scripting-Angriffen (XSS) anf¨allig sein. Die Zusam-menf¨uhrung der Patientendaten auf dem Client-Rechner setzt jedoch die Freischaltung dieser unsicheren Technologie voraus, was die Vertrauensw¨urdigkeit des gesamten Ansatzes negativ beeintr¨achtigt.

Die in der letzten Zeit stattgefundene starke Verbreitung der XSS-Angriffe f¨uhrte zu der Aufr¨ustung auf der Seite der Sicherheitsexperten. Moderne Browser erkennen viele XSS-Angriffe zuverl¨assig, sodass es wahrscheinlich ist, dass die Operation der Datenzusam-menf¨uhrung auf dem Client mithilfe von XSS als Angriff erkannt wird. Es ist denkbar, dass der gleichzeitige Datenabruf von zwei Servern in einer Websitzung von den Sicherheitsme-chanismen des Browsers als ein Angriff gewertet und nicht zugelassen wird. Dies kann die Umsetzbarkeit der Ajax-L¨osungen in der Praxis und ihre Verbreitung zwecks Datenzu-sammenf¨uhrung im Clienten nach dem Vorschlag des generischen Datenschutzkonzeptes einschr¨anken.

Bei einer Kompromittierung des Systems erleichtert Ajax die Durchf¨uhrung weiterer Angriffe, da der Datenaustausch via XMLHttpRequest f¨ur den Benutzer transparent im Hintergrund erfolgt. Diese potenzielle Sicherheitsl¨ucke ist jedoch keine Besonderheit der Ajax-Anwendungen und kann auch auf JavaScript-Applikationen zutreffen. F¨ur die untersuchte Fragestellung ist es wichtig, zu analysieren, auf welche Art und Weise die o. g.

Komponenten einer Ajax-Anwendung angegriffen werden k¨onnen. Die Untersuchungser-gebnisse der m¨oglichen Angriffsszenarien auf die Ajax-basierte Datenzusammenf¨uhrung sind im Abschnitt C.3.3.1 zusammengefasst.

Eine Erh¨ohung der Sicherheit einer Anwendung kann durch die Verwendung von Ajax-Frameworks⁵⁴ erreicht werden. Die Vorteile von solchen Frameworks bestehen in den von professionellen Entwicklern aufbereiteten Funktionen. Es liegt im Interesse der Entwickler, die popul¨aren Frameworks im Hinblick auf die Sicherheitsaspekte zu pr¨ufen. Ein Beispiel daf¨ur, dass die Ajax-Frameworks auf ihre Sicherheit systematisch untersucht werden, ist das OWASP AJAX Security-Projekt.⁵⁵Das Projekt wurde mit dem Ziel gegr¨undet, die g¨angigen Ajax-Frameworks auf ihre Sicherheitsaspekte zu untersuchen. Auf der Basis der OWASP Top Zehn-Liste k¨onnen Sicherheitsmetriken entwickelt werden (vgl. [owa12], [NP07]). Die Verwendung von Frameworks kann jedoch auch zu einem Sicherheitsproblem werden, wenn das Framework Sicherheitsl¨ucken aufweist. Die auf diesem Framework aufsetzenden Implementierungen erben die Sicherheitsl¨ucken des Frameworks, was die Attraktivit¨at der Suche nach den Framework-Exploits erh¨oht; denn ein Angreifer kann durch die Ausnutzung

54Zum Beispiel ASP.NET Ajax Framework, XAJAX, SAJAX etc. In diesem Abschnitt steht der Framework-Begriff f¨ur ein Programmierger¨ust, das als Rahmen f¨ur die Softwareentwicklung verwendet wird und dem Entwickler bestimmte Bausteine zur Designstruktur zur Verf¨ugung stellt bzw. die Erstellung diverser Applikationen erm¨oglicht. Eine abweichende Framework-Definition in Verbindung mit dem Sicherheits-und Risikomanagement befindet sich im Glossar.

55OWASP: Open Web Application Security Project.

einer Sicherheitsl¨ucke in der Framework-Implementierung eine Vielzahl von den auf dem betroffenen Framework basierenden Anwendungen kompromittieren.

Um die Sicherheit der Ajax-basierten Applikationen zu pr¨ufen, k¨onnten Penetrations-Tests durchgef¨uhrt werden. Da die einer Ajax-Applikation zugrunde liegenden Strukturen denen einer gew¨ohnlichen Webanwendung ¨ahneln, gelten hier grunds¨atzlich dieselben Pr¨ufroutinen bzw. -punkte. So ist z. B. auf die Verwendung einer m¨oglichst aktuellen Browser-Version bzw. potenzielle Fehler in der JavaScript-Implementierung des Browsers zu achten.

3.5.2.2. Sicherheit von Java Die Bezeichnung

”Java“ ist vielschichtig, sodass es falsch w¨are, allgemein von der Java-Sicherheit zu schreiben. Die Java-Sicherheit eines Java-Applets kann kaum mit der Java-Sicherheit einer Java-Servlet-Anwendung verglichen werden, die ihrerseits nicht mit der Sicherheit eines Standalone-Java-Programms gleichgestellt werden kann. Um die Java-Sicherheit im Kontext der Datenzusammenf¨uhrung bewerten zu k¨onnen, muss daher eine Eingrenzung der f¨ur die Fragestellung relevanten Java-Technologie erfolgen. Diese vorgenommene Eingrenzung darf jedoch nicht zu einem konkreten Implementierungskonzept werden, da sonst die Sicherheit einer bestimmten Konfiguration und nicht die allgemeine Sicherheit der Java-Plattform im Zusammenhang mit der Zusammenf¨uhrung von Patientendaten bewertet w¨are.

Die Basissicherheitsfunktionen der Java-Technologie werden im Abschnitt C.3.3.2

”Nutzung der Java-Sicherheitsfunktionen f¨ur die Datenzusammenf¨uhrung“ er¨ortert. Im gleichen Abschnitt wird beispielhaft das Szenario einer Java-basierten Datenzusammenf¨uhrung aufgezeigt.

F¨ur den dargestellten Aufbau und den Ablauf der Datenzusammenf¨uhrung gelten die gleichen Angriffe wie in Falle der Ajax-Technologie: Die Angriffe k¨onnen auf dem Client, dem Server oder dem Transportweg erfolgen. Die grundlegenden Angriffsszenarien werden im Zusammenhang mit der Ajax-Sicherheit im Abschnitt C.3.3.1 beschrieben, sodass an dieser Stelle keine explizite Analyse der Angriffsarten erfolgt.

3.5.2.3. Sicherheit der Terminalserver-Technologie

Beim Einsatz der Terminal Services-Technologie f¨ur die Datenzusammenf¨uhrung soll zuerst die Frage beantwortet werden, ob die Daten nun auf dem Client oder doch zentral zusam-mengef¨uhrt werden. F¨ur die clientseitige Datenzusammenf¨uhrung spricht die Tatsache, dass die Logik der Datenzusammenf¨uhrung auf den Clients abgebildet ist, die durchaus unterschiedliche Beschaffenheit haben k¨onnen. F¨ur die Klassifizierung als einen zentrali-sierten Ansatz spricht dagegen, dass die kritischen Anwendungen an einer zentralen Stelle einfacher kontrolliert und gesch¨utzt werden k¨onnen.

Die Sicherheit der Terminalserver-Technik wird im Abschnitt 3.5.1

”Sichere Arbeits-umgebung“ er¨ortert. Kennzeichnend f¨ur das zu untersuchende Anwendungsfeld ist die Tatsache, dass die Patientendaten an einer zentralen Stelle – dem Terminal Server zusam-mengef¨uhrt werden. Dies gew¨ahrleistet einerseits eine h¨ohere Sicherheit, da die zentralen Dienste i. d. R. einfacher abzusichern sind, als die inhomogenen verteilten Client-Ressourcen.

Gleichzeitig stellt die Zentralisierung besondere Anforderungen an die Sicherheitsvorkeh-rungen, da die zentralen Dienste lukrativere Angriffsziele darstellen. Die Kompromittierung des zentralen Terminal Service-Dienstes w¨are vermutlich schwerwiegender als die Kompro-mittierung eines einzelnen Clients.

Um die Sicherheitseigenschaften der Terminal Services-Technologie zusammenzufassen, bleibt festzuhalten, dass die Beschaffenheit der Clients und der Laufzeitumgebungen zwar unterschiedlich sein k¨onnte, man sich jedoch aus administrativen Gr¨unden wahrscheinlich f¨ur eine gemeinsame Zielplattform entscheiden w¨urde. Ein Angreifer, der den Terminal Server ¨ubernimmt, h¨atte Zugriff auf die Sessions mehrerer Clients, sodass hier die Aufteilung der Daten aus der sicherheitstechnischen Perspektive nicht so vorteilhaft w¨are wie im Falle des ”echten“ clientbasierten Ansatzes.

Sowohl aktive als auch passive Angriffe w¨aren auch bei diesem Einsatzszenario denkbar.

Durch die Verwendung eines Standard-Pakets als Terminal-Services ergeben sich einerseits die Vorteile durch den Hersteller-Support und eine (hoffentlich) schnelle Fehlerbehebung.

Andererseits k¨onnten die Terminal-L¨osungen ebenfalls eine Reihe von Sicherheitsl¨ucken aufweisen, die ein Angreifer dann ausnutzen k¨onnte. Zu ber¨ucksichtigen ist auch, dass zwischen den Clients und dem Terminal Server nicht die Patientendaten, sondern die Daten der Terminal-Sessions ¨ubertragen werden. Da die g¨angigen Produkte bereits in der Standardkonfiguration Verschl¨usselung einsetzen, bleibt die Wahrscheinlichkeit f¨ur einen erfolgreichen Angriff auf dem Transportweg relativ gering.

3.5.2.4. Kombination der Technologien

Am Anfang des Abschnitts 3.5.2 wurde erw¨ahnt, dass die drei beschriebenen Technologien nicht als Konkurrenz zueinander verstanden werden m¨ussen. Vielmehr existieren Szenarien, in denen die Vorteile der Technologien miteinander kombiniert werden. Ein Beispiel f¨ur eine solche Symbiose ist der parallele serverseitige Einsatz von Terminal-Services und Java.

Die Abbildung 5 veranschaulicht den Einsatz von Terminal-Services, um dem Nutzer eine abgesicherte vertrauensw¨urdige Umgebung mit einem eingeschr¨ankten Umfang an Applikationen zur Verf¨ugung zu stellen. Dies kann z. B. nur ein bestimmter Browser sein, mit dessen Hilfe man auf den dahinter platzierten Webserver zugreifen kann, oder die vom medizinischen Personal verwendete Client-Applikation. Der Vorteil eines solchen Aufbaus liegt darin, dass die zentralisierte Integrit¨at der Terminal Server-Umgebung einfacher und zuverl¨assiger erreicht werden kann als die Integrit¨at der sich in der

”Benutzer-Gewalt“

befindenden Systeme. Die vom Terminal-Server aus auf dem Webserver erfolgenden Zugriffe

EJB-Container Behandelnder Arzt

EJB-Container

Patientenliste

IDAT PID-DBs

Role-DB

Web-Container EJB-Container

MDAT*

TS-Lockdown

Environment VPN-Gateway

TS2WebContainer-Regelwerk

Terminal-Server

Abbildung 5.:Kombination aus Terminal-Services und Java-Technologie: Die Client-Zugriffe erfolgen aus einer kontrollierten – auf Terminal-Services basierenden – Umgebung.

k¨onnen auf einen mindest notwendigen Maß reduziert werden.⁵⁶ Zus¨atzlich kann die Einhaltung des aufgestellten Sicherheitsregelwerks vor dem Zugriff auf den Webserver kontrolliert werden. Dadurch wird sichergestellt, dass gegen den Webserver keine direkten Angriffe von den Clients aus erfolgen k¨onnen. Als ein – beim reinen clientseitigen Webserver-Zugriff nicht existierender – Nachteil der Zusammenlegung beider Technologien gilt das bereits bei den Terminal-Services erw¨ahnte Argument, dass die Fehler in der Terminal-Software dem Angreifer Einblick in die Sessions anderer Benutzer offenbaren k¨onnen.