Arslan Brömme, Torsten Eymann, Detlef Hühnlein, Heiko Roßnagel, Paul Schmücker (Hrsg.) perspegktive Digital Proceedings

Transkript

1 Arslan Brömme, Torsten Eymann, Detlef Hühnlein, Heiko Roßnagel, Paul Schmücker (Hrsg.) perspegktive 2011 Digital Proceedings Workshop Innovative und sichere Informationstechnologie für das Gesundheitswesen von morgen 7. September 2011 Darmstadt Fachgruppe BIOSIG, Gesellschaft für Informatik e.v. Das vorliegende Dokument stellt das digitale Begleitmaterial für die o.g. Veranstaltung dar. Die Autoren und zugleich Copyright-Inhaber haben ihr Einverständnis für diese digitale Zusammenstellung zur Verteilung an die Workshop-Teilnehmer erteilt. Bei Rückfragen wenden Sie sich bitte direkt an die Autoren, deren Kontaktdaten im jeweiligen Beitrag angegeben sind.

2

3 Inhaltsverzeichnis perspegktive 2011 Workshop-Beiträge Moaaz Madiesh, Paul C. Johannes, Jan Potthoff Beweissichere elektronische Labor-, Patienten- und Fallakten Michael Decker MimoSecco: Eine Middleware für sicheres Cloud Computing mit mobilen Endgeräten Sebastian Dünnebeil, Alexander Kaletsch, Siegfried Jedamzik, Ali Sunyaev, Jan Marco Leimeister, Helmut Krcmar Prozessdigitalisierung durch Mehrwertanwendungen der egk am Beispiel der elektronischen Überweisung Stefan Knipl, Ali Sunyaev Betrachtung des Sicherheitskonzepts der elektronischen Gesundheitskarte ID4health-Team ID4health - sicheres Identitätsmanagement für das Gesundheitswesen von morgen

4

5 Beweissichere elektronische Labor-, Patienten- und Fallakten Moaaz Madiesh 1, Paul C. Johannes 2, Jan Potthoff 3 1 Physikalisch-Technische Bundesanstalt (PTB) Bundesallee Braunschweig moaaz.madiesh@ptb.de 2 Projektgruppe für verfassungsverträgliche Technikgestaltung Universität Kassel Wilhelmshöher Allee Kassel 3 Steinbuch Centre for Computing (SCC) Karlsruher Institut für Technologie (KIT) Hermann-von- Helmholtz-Platz Eggenstein- Leopoldshafen jan.potthoff@kit.edu Abstract: Elektronische Laborbücher, Patienten- und Fallakten dienen u. a. der medienbruchfreien digitalisierten Nutzung, Aufbewahrung und Archivierung unterschiedlichster Daten, wie z. B. Messungen und Beobachtungen. Dabei ist die beweiswerterhaltende Sicherung auch bei einer elektronischen Langzeitarchivierung, zu gewährleisten. Dies dient sowohl der Erfüllung gesetzlicher Verpflichtungen als auch der Minderung von Haftungsrisiken. Durch die Verwendung von elektronischen Signaturen und Signaturkarten, wie z. B. dem Heilberufeausweis, kann eine Steigerung des Beweiswerts der elektronischen Falldokumentationen erreicht werden. 1 Einleitung Laborbücher und Patientenakten haben zum Teil einen vergleichbaren Zweck. Sie dienen der nachvollziehbaren und nachhaltigen Dokumentation von Daten, wie Messungen, Laborergebnissen und Beobachtungen. Mit diesen Aufzeichnungen sollen die Handlungen und Anweisungen des Eintragenden in Bezug auf den Patienten oder die Forschungstätigkeit verständlich dokumentiert werden. Beim Übergang zur digitalisierten Datenhaltung in elektronischen Laborbüchern (elab) und elektronischen Patientenakten (epa) muss dafür Sorge getragen werden, dass der Beweiswert dieser elektronischen Dokumente erhalten bleibt. Entsprechendes gilt für die elektronische Fallakte (efa), also die strukturierte Sammlung aller Dokumente, die zu dem medizinischen Fall eines Patienten verfügbar sind. Zusammengefasst sollen elab, epa und efa als elektronische Falldokumentationen (efd) bezeichnet werden. Im Folgenden werden Vorschläge für

6 die Gestaltung einer beweiswertehaltenden und Langzeitarchivierungstauglichen efd vorgestellt Rechtliche Anforderungen an die Aufbewahrung und Beweiswerterhaltung Die rechtlichen Anforderungen an die beweiswerterhaltende Sicherung von elektronischen Dokumenten und efd sind aus den Pflichten an die Aufbewahrung und aus den Beweisverwertungsregeln der Gerichte zu folgern: Pflichten zur Aufbewahrung sind anwendungs- und dokumentenspezifisch in verschiedenen Gesetzen geregelt. Bestehen gesetzliche Aufbewahrungspflichten schon für Papierdokumente, müssen die entsprechenden elektronischen Dokumente ebenso behandelt werden [Fi06]. Dies folgt im medizinischen Bereich etwa für ärztliche Dokumentationen, wie den Arztbrief, die Patientenkartei oder Medikamentenverschreibungen, aus den landesrechtlichen Berufsverordnungen für Ärzte, so z. B. nach 10 Absatz 3 Berufsordnung für die Ärztinnen und Ärzte in Hessen. Auch müssen z. B. nach 28 Absatz 4 Röntgenverordnung Aufzeichnungen zu Röntgenbehandlungen bis zu 30 Jahren aufbewahrt werden. Neben diesen Aufbewahrungspflichten kommt bei elektronischen Dokumenten für die Beweiswerterhaltung hinzu, dass diese dem Gesetzgeber (vgl. dazu [JKGE], S. 24) und den Gerichten grundsätzlich als flüchtig und leicht manipulierbar gelten [Fi06]. Sie sind nach 371 Absatz 1 Satz 2 Zivilprozessordnung (ZPO) nur Beweis des Augenscheins und unterliegen der freien Beweiswürdigung durch den Richter. Damit gelten die für den Beweisführer günstigen Beweisverwertungsregeln für Urkunden nach 415 ff. ZPO nicht. 1.2 Praktische Anforderungen Neben den vorgenannten rechtlichen Anforderungen ergeben sich eine Reihe praktischer Anforderungen an die Ausgestaltung einer beweiswerterhaltenden efd, welche sich aus den allgemeinen Anforderungen an die elektronische Langzeitarchivierung ableiten lassen (siehe dazu [HR08]). So ist die Vollständigkeit der Dokumente, d. h. der Gesamtzusammenhang mehrerer Dokumente eines Vorgangs, zu erhalten. Elektronische Signaturen, die über das gesamte Archiv gebildet werden, können dazu verwendet werden, um die Vollständigkeit der Dokumentation nachzuweisen. Neben der Vollständigkeit des gesamten Archivs ist die Integrität der einzelnen Dokumente sicherzustellen. Der Schutz der Integrität bedeutet, dass keine Möglichkeit der Veränderung besteht. Mit elektronischen Signaturen kann zwar eine Veränderung nicht verhindert werden, es kann aber nachgewiesen werden, ob ein Dokument verändert wurde. Daneben kann durch elektronische Signaturen bzw. dem dazugehörigen Zertifikat die Authentizität der Dokumente nachgewiesen werden. 1 Die Gestaltungsvorschläge wurden im Rahmen des Forschungsprojekt Beweissicheres elektronisches Laborbuch (BeLab) entwickelt. BeLab ist ein von der DFG gefördertes Projekt, welches sich mit der Beweiswerterhaltung von elektronischen Laborbüchern auseinandersetzt, siehe

7 Des Weiteren muss gewährleistet sein, dass ein Dokument langfristig lesbar ist. Im wissenschaftlichen Bereich werden beispielsweise Archivierungsfristen von 10 Jahren vorgeschrieben. Im medizinischen Bereich kann es der Aufbewahrung von Patientendaten über das gesamte Leben des Patienten und darüber hinaus bedürfen, woraus Archivierungsfristen von 100 Jahre und mehr folgen können [RS06]. Die langfristige Lesbarkeit kann durch zwei Maßnahmen erreicht werden: Die Speicherung in einem langfristig sicheren Format und die Abspeicherung des Dokuments auf einem Datenträger, der in einer professionellen IT-Umgebung betrieben wird, wo auch erforderlichenfalls die Transformation der Dokumente gewährleistet wird, bevor die notwendige Hard- und Software nicht mehr verfügbar ist (Migration). Zu beachten ist, dass ein Dokument nicht nur lesbar bleibt, sondern auch in einer angemessen Zeit zur Verfügung gestellt werden kann. Dazu muss das Dokument im Langzeitspeicher aufgefunden, in das Bearbeitungssystem geladen und visualisiert werden. Um die archivierten Dokumente zu einem späteren Zeitpunkt auch an einem anderen Ort verwenden zu können, müssen sie von einem Archivsystem zu einem anderen System (z. B. zu einem Computer des Gerichts) leicht zu transportieren sein. Dabei muss die Qualität des Dokumentes sowie seine Integrität und Authentizität nachweisbar bleiben. In diesem Zusammenhang wird von der Verkehrsfähigkeit der Daten gesprochen. Im medizinischen Bereich nimmt des Weiteren die Vertraulichkeit der Daten eine wesentliche Rolle ein, d. h. die Dokumente müssen vor unbefugtem Zugriff, z. B. durch Verschlüsselung, geschützt werden [Hü09]. 1.3 Allgemeines Anforderungsprofil an die vertrauenswürdige Datensicherung und Beweiswerterhaltung Aus den im Vorfeld beschriebenen rechtlichen und praktischen (technischen) Anforderungen kann ein allgemeines Anforderungsprofil an die beweiswerterhaltende efd wie folgt zusammengefasst werden: Zum einem sollte die Ergonomie der efd der ursprünglichen Dokumentensammlung entsprechen. Der Anwender sollte die efd nahezu in der gleichen Weise bearbeiten und verwalten können, wie sein herkömmliches Laborbuch oder die herkömmliche Patientenakte. Abweichungen und Einschränkungen sollten durch die bekannten Vorteile der elektronischen Datenhaltung (z. B. Suchfunktion, einfache Indexierung, Automatisierung) aufgewogen werden. Zum anderen muss die Authentizität und die Integrität der elektronischen Dokumente in der efd gesichert werden können. Idealerweise dienen dazu elektronische Signaturen. Deren Verwendung und Kontrolle muss auch über die gesamte Zeit der Aufbewahrungspflicht, gewährleistet werden können. Die elektronischen Dokumente müssen ferner in einer vollständigen, verkehrsfähigen, lesbaren und vertraulichen Art und Weise gesichert werden.

8 2 Beweiswerterhaltung durch elektronische Signaturen Den vorgenannten Problemen der Beweiswerterhaltung bei Verwendung einer efd kann durch den Einsatz geeigneter Sicherheitstechniken und Verfahren entgegengewirkt werden. Technische Sicherungsmittel, wie fortgeschrittene und qualifizierte elektronische Signaturen nach dem Signaturgesetz (SigG) und elektronische Zeitstempel, steigern den Beweiswert der mit ihnen versehenen elektronischen Dokumente, da die Authentizität des Unterzeichners und die Integrität der Daten selbst bewiesen werden können. Nach 371a ZPO gelten für elektronische Dokumente sogar die besonders vorteilhaften Beweisregeln für herkömmliche Urkunden, wenn sie mit einer qualifizierten elektronischen Signatur versehen sind [RS06]. Aber auch mit fortgeschrittenen elektronischen Signaturen, deren Schlüssel sicher nur einer Person zugeordnet ist, kann der Beweis über die Echtheit bzw. Integrität und Authentizität des elektronischen Dokuments angetreten werden [BS11]. Darüber hinaus ermöglichen elektronische Zeitstempel eine authentische und nicht verfälschbare Verknüpfung von Daten mit einer Zeitaussage. Sie dienen dazu, den unveränderten Zustand eines elektronischen Dokuments von einem bestimmten Zeitpunkt an nachweisen zu können. Im Forschungsprozess spielen Zeitstempel an mehreren Stellen eine besondere Rolle, z. B. beim Experiment selbst, beim Authentifizierungsprozess, bei Änderungen an den Daten (Korrigieren oder gar Stornieren), bei der Übersignatur und bei der Langzeitarchivierung [RS06]. Im medizinischen Bereich kann z. B. der Zeitpunkt der Eintragung einer Behandlung in die epa nachgewiesen werden, welcher wiederum Rückschlüsse über den Behandlungszeitpunkt zulässt. 3. Probleme der Langzeitarchivierung Bei der der Langzeitarchivierung (LZA) einer efd stellen sich insbesondere Fragen bezüglich der zu verwendenden Datenformate und der Sicherung eventuell verwendeter elektronischer Signaturen. 3.1 Datenformate und Standards für Metadaten Im Zusammenhang mit dem Erhalt der Lesbarkeit (Interpretierbarkeit) der Daten, siehe Abschnitt 1.2, ist das verwendete Datenformat von entscheidender Bedeutung. Auch wenn keine verlässliche Aussage darüber getroffen werden kann, welche Datenformate langfristig interpretierbar bleiben, können Formatspezifikationen anhand unterschiedlicher Kriterien, wie Offenheit des Formats, Selbstdokumentation, Robustheit und Komplexität, für ihre Eignung zur LZA bewertet werden [Lu11]. Mit dem Metadata Encoding and Transmission Standard (METS) wurde ein Konzept für ein XML-Dokument entworfen, das mithilfe von Metadaten die Verwaltung und den Austausch von digitalen Objekten ermöglichen soll [Me11]. Ein METS-Dokument besteht dabei aus sieben Hauptabschnitten, denen die Metadaten (deskriptive, strukturelle und administrative Metadaten) zugeordnet werden. Des Weiteren dienen zwei Abschnit-

9 te als Container für die digitalen Objekte selbst und als Strukturbeschreibung des digitalen Objekts. Vorteil des Standards ist die Flexibilität. So können zur Beschreibung der deskriptiven und administrativen Metadaten weitere Standards, wie beispielsweise Dublin Core, verwendet werden. Damit ist es beispielsweise möglich fehlende Angaben, die zur LZA benötigt werden, durch die zusätzliche Verwendung des Standards für Langzeitarchivierungsmetadaten für elektronische Ressourcen (LMER) zu ergänzen. LMER dient als Ergänzung zu existierenden Standards für bibliographische Metadaten. Er ist größtenteils auf Angaben, die automatisiert generiert werden können, beschränkt und beinhaltet Kernelemente, die für alle Dateikategorien (Dateiformat) gültig sind [St05]. Die automatische Metadatenerzeugung bietet den Vorteil der vereinfachten Metadatenpflege und fördert so die Akzeptanz des Anwenders. Das METS-Profile-Universelles-Objektformat (UOF) vereint die Standards METS und LMER. Es wurde im Rahmen des Projekts kopal [St06] entwickelt. Mit diesem ist es möglich digitale Objekte und die dazugehörigen Metadaten zusammen zu archivieren und zwischen Archivsystemen auszutauschen. Dazu werden die Paketformate ZIP oder TAR verwendet, in die bis zu 5000 Dateien aufgenommen werden können. Metadaten zum Archivobjekt werden innerhalb der mets.xml-datei angegeben, die im Hauptverzeichnis des Archivobjekts abgelegt wird. Durch die Verwendung des UOF können Teile der in Abschnitt 1.2 beschriebenen praktischen Anforderungen erfüllt werden. Durch die Möglichkeit der Angabe eines Hashwertes zu jeder Datei innerhalb der mets.xml und einer Signierung der XML-Datei kann die Vollständigkeit des Archivs jeder Zeit nachgewiesen werden. Zusätzlich ist die Authentizität des Archivs und die Verkehrsfähigkeit zwischen unterschiedlichen Archivsystemen gewährleistet. Ein weiterer Ansatz, der für die LZA entwickelt wurde, ist die im Zusammenhang mit der technischen Richtlinie des Bundesamtes für Sicherheit in der Informationstechnik (BSI TR-03125) entworfene XML Archival Information Package (XAIP) Spezifikation. Nach der TR [Hü09] besteht ein Langzeitarchiv aus dem ArchiSafe-, dem Archi- Sig-, dem Krypto- und dem Storage-Modul. Das ArchiSafe-Modul nimmt die Anfragen der Anwendungen (hier die Anfragen der BeLab-Middleware) entgegen. Die zu archivierenden Objekte müssen im XAIP Format vorliegen. Dadurch wird die Migration von einer Storage-Technologie zu einer anderen erleichtert. Wird durch eine Anwendung kein XAIP ausgegeben wird eine zusätzliche Komponente, genannt XML Adapter, notwendig. Der Adapter übernimmt die Konvertierung der Daten nach XAIP. Während das ArchiSafe-Modul die Steuerung der Verarbeitungsprozesse und der Rechteverwaltung übernimmt, dient das ArchiSig-Modul zum (Über-)Signieren der Dokumente und das Krypto-Modul zur Verifikation von bestehenden Signaturen. Das Storage-Modul bietet neben der Archivierung der Daten verschieden Funktionen, wie z. B. Suchen und Löschen von Dokumenten. 3.2 Elektronische Signaturen und LZA Für eine beweissichere LZA von efd sollten die im Vorfeld beschriebenen etablierten Sicherheitstechniken genutzt werden. Ein dies berücksichtigendes System überprüft in mehreren Schritten die vom Benutzer übergebenen Daten. Dabei werden sowohl bereits

10 verwendete Signaturen auf Gültigkeit, Datensammlungen auf Konsistenz als auch das Datenformat auf die Eignung zur LZA überprüft. Die abschließende Archivierung basiert auf der technischen Richtlinie des BSI TR [BSI11]. Ziel ist, die zu archivierenden Forschungsdaten in der Form aufzubereiten, dass sie dem ArchiSafe-Modul der BSI TR zur Ablage im Archiv übergeben werden können. Durch die Verwendung des ArchiSafe-Moduls in Kombination mit dem zur BSI TR gehörigem ArchiSigund Krypto-Modul ist eine langfristige Archivierung inklusive der eingesetzten Signaturen sichergestellt. BSI TR-03125, ArchiSafe und ArchiSig übernehmen die Spezifikationen der RFC 4810 Long-Term Archive Service Requirements [R4810] und RFC 4998 Evidence Record Syntax [R4998], der Internet Engineering Task Force (IETF) [Ha11]. Zertifikate verlieren aus Sicherheitsgründen je nach Zertifikatstyp nach drei oder fünf Jahren ihre Gültigkeit. Bevor das Zertifikat abläuft muss das entsprechende Dokument übersigniert werden, um weiterhin den Beweiswert sicherzustellen. Hierbei werden elektronische Zeitstempel genutzt, um den korrekten (rechtzeitigen) Zeitpunkt der Übersignatur zu belegen. Das ArchiSafe-Modul sorgt für eine Automatisierung des Prozesses [RS06]. 4. Gestaltungsvorschläge Auf Basis der vorgenannten Anforderungen wurden im Kontext der vorgestellten rechtlichen und technischen Rahmenbedingungen folgende Vorschläge für die Gestaltung einer beweiswertehaltenden und LZA-tauglichen efd entwickelt. 4.1 Generischer Ansatz Das Laborbuch ist eng mit der Arbeit von Wissenschaftlern verbunden. Es ist eine Art Tagebuch, in dem der Wissenschaftler in einer über den Tag hinausreichenden Form seine tägliche Arbeit und seine Forschungsergebnisse für die spätere Auswertung dokumentiert [Ha11]. Im Laborbuch werden möglichst alle Informationen zu den Forschungsprojekten festgehalten. Es enthält Angaben über Methoden, Ergebnisse, Literaturrecherchen, Beteiligung von Forschern und anderen relevanten Ereignissen und Daten. Über die Forschung hinaus werden Laborbücher auch in der Analytik, in medizinischen Laboren, der Lebensmittelkontrolle und anderen Anwendungsbereichen, wie staatlichen Zulassungs- und Kontrollverfahren verwendet [Ri11]. Die BeLab-Middleware bietet eine generische Schnittstelle für die Beweissicherheit und die LZA von elektronischen Dokumenten an. Die Schnittstelle zum BeLab-System wurde als Web Service realisiert, um so einerseits eine Unabhängigkeit zum elab zu erzielen und andererseits flexibel in den Forschungs- und Dokumentationsprozess integriert werden zu können [BS11]sowie anpassungsfähig gegenüber dem zu verwendendem elektronischen (Langzeit-)Archivsystem zu sein. Daten, die an die BeLab-Schnittstelle übergeben werden, müssen in der oben beschriebenen UOF-Definition vorliegen. Nach erfolgreicher Authentifizierung und Autorisie-

11 rung erfolgt eine Überprüfung der Daten. Dabei wird die Validität der verwendeten Formate und Konsistenz der übermittelten Inhalte geprüft. Zur Datenüberprüfung durch das BeLab-System können durch den Benutzer Strukturinformationen definiert werden, nach denen eine Überprüfung automatisiert durchgeführt werden kann. Beispielsweise könnte zu einer Serie von Bilddaten eine zugehörige Auswertungsdatei definiert werden, so dass die Vollständigkeit der Daten überprüft werden kann. Wurden die übergebenen Daten bereits signiert, erfolgt zusätzlich eine Überprüfung der Signatur. Das Prüfergebnis wird in Form einer Klassifizierung des Beweiswerts ausgegeben und durch eine elektronische Signatur des BeLab-Systems bestätigt. Bereits vorhandene Metadaten, die an das BeLab-System übergeben werden, werden durch das System übernommen und zu Validierungszwecken genutzt. Metadaten im BeLab-System entstehen im Wesentlichen durch das Protokollieren der Datenüberprüfung, der Klassifizierung und deren Ergebnisse. Anhand der gesammelten Metadaten kann der Beweiswert eingereichter Daten festgemacht werden. Abbildung 1: Verarbeitungsschritte des BeLab-Systems Die elektronische Signatur des BeLab-Systems bestätigt somit als unabhängige dritte Vertrauensinstanz die erfolgreiche Verarbeitung und Prüfung der Daten im BeLab-

12 System und wird zusammen mit den Daten an das angebundene Archiv-System übermittelt. Die einzelnen Arbeitsschritte des BeLab-Systems werden in Abbildung 1 dargestellt. 4.2 Die BeLab-Schnittstelle für medizinische Informationssysteme Um die Möglichkeit der Anbindung von medizinischen Informationssystemen an die BeLab-Schnittstelle festzustellen, wurden die Parallelen in der Datenrepräsentation zwischen Laborbüchern und sensorerweiterten elektronischen Patientendokumenten betrachtet [Pa10]. Zwischen den Laborbuch-Dokumenten und sensorerweiterten elektronischen Patientendokumenten bestehen auf aggregierter Ebene deutliche Parallelen, die sich in ähnlichen, teils identischen Datenkategorien ausdrücken (vgl. zu den Merkmalen von epa auch [Ha05], S. 185 ff.). Diese Gemeinsamkeiten beruhen auf der Tatsache, dass die verwendeten Daten an sich Ähnlichkeiten aufweisen und gleichartige Datenformate verwenden, was beiderseits zu Datenspeicherungsverfahren auf der Basis von XML führt. Vergleichbar sind beispielsweise typische Metadaten im Forschungsprozess, wie Projekt-Id, Name des Forschers, Datum und Uhrzeit des Experiments und Parametereinstellungen, mit den im medizinischen Bereich, bei der Diagnose und Behandlungsdokumentation anfallenden Metadaten, wie Name des Arztes, Patientenname und Behandlungsort (vgl. [Ha05], S. 135 ff.). Tabelle 1 stellt den Datenvergleich zwischen den beiden Dokumenten dar. Dokumente elektronischer Laborbücher - Kundendaten - Herstellerangaben - Verantwortlicher Wissenschaftler - Computergenerierte Daten - Rechnungsdaten - Messdaten / Kalibrierdaten - Messdaten / Kalibrierdaten - Solldaten - Experimentalverlauf - Prüfungsergebnis Sensorerweiterte elektronische Patientendokumente - Patientendaten - Stammdaten des Patienten - Verantwortlicher Arzt - Computergenerierte Daten - Rechnungsdaten - Allgemeine Untersuchungsergebnisse - Sensorische Untersuchungsergebnisse - Normwerte - Behandlungsverlauf - Diagnose Tabelle 1: Datenvergleich zw. Laborbuch-Dokumenten und Patientendokumenten Aufgrund des generischen Ansatzes der BeLab-Schnittstelle lassen sich unterschiedliche elabs anbinden. Möglich ist es daher auch Krankenhaus-Informations-Systeme (KIS) oder Telemedizin-Clients anzubinden und so Dokumente, die in einer efd vorhanden sind, an das BeLab-System zu übermitteln. Unterschiedlichste Softwaresysteme, wie Content Management Systeme, Systeme zum Daten-, Query- und Projektmanagement, die beispielsweise in klinischen Studien eingesetzt werden, tragen zu einer Vielzahl von Datenformaten bei [Ku06]. Die Daten müssen hierfür entsprechend der UOF-Strukturierung aufbereitet werden. Beispielsweise kann

13 dazu ein im Projekt kopal entwickelter Konverter (kolibri) für die Dateiformatierung genutzt werden. Durch ihn werden vom Nutzer ausgewählte Dateien zu einem UOF- Elemente verknüpft und eine mets.xml automatisch generiert. Metadaten, die auf der Basis der Dateiinformationen zur Verfügung stehen, werden automatisiert extrahiert und in die mets.xml übernommen [Fu11]. Die Integrität und Authentizität der Daten kann vor der Übergabe an das BeLab-System durch die Verwendung von elektronischen Signaturen sichergestellt werden. In diesem Fall wird eine Überprüfung der Signatur durch das BeLab-System vorgenommen, bevor die weitere Verarbeitung der Daten erfolgt. Ist die Signatur ungültig wird die Annahme der Daten verweigert. Des Weiteren soll durch die Verwendung von elektronischen Zeitstempeln der Zeitpunkt der Datenübernahme, -verarbeitung und Archivierung nachweißbar dargelegt werden. Die BeLab-Middleware adressiert Aspekte der Langzeitarchivierung und der Beweiswertsicherung und kann durch den generischen Ansatz mit geringem Aufwand in andere Systeme eingebunden werden. So kann sie als Mehrwert in der Telematik-Infrastruktur, die durch die Gesellschaft für Telematikanwendungen der Gesundheitskarte mbh entwickelt und in Deutschland eingeführt wird, dienen. 4.2 Einsatz elektronischer Signaturen und Zeitstempel Das efd-system muss zur Beweiswerterhaltung die Verwendung von elektronischen Signaturen vorsehen. Insbesondere personengebundene fortgeschrittene und qualifizierte Signaturen nach dem SigG ermöglichen es, den Beweis über die Integrität und Authentizität eines elektronischen Dokuments anzutreten. Dabei kann bei Verwendung von qualifizierten elektronischen Signaturen sogar der kodifizierte Anscheinsbeweis über die Echtheit der Unterschrift in 371a ZPO geführt werden. Es gelten die für den Beweisführer besonders vorteilhaften Regelungen zum Urkundenbeweis nach 415 ff. ZPO. Elektronische Zeitstempel sind Bescheinigungen, in Form eines elektronischen Dokuments, eines Dritten darüber, dass ihm bestimmte elektronische Daten zu einem bestimmten Zeitpunkt vorgelegen haben. Sie können ihrerseits wieder durch elektronische Signaturen gesichert sein, wie z. B. im Falle des qualifizierten elektronischen Zeitstempels nach 2 Nr. 14, 9 SigG. Zur Umsetzung muss das efd-system Anbindungen an Kartenlesegeräte und Zeitstempelgeber enthalten und die Verknüpfung von allen oder einzelnen elektronischen Dokumenten innerhalb der efd mit einer elektronischen Signatur oder einem elektronischem Zeitstempel ermöglichen. 4.3 Einbindung HBA und Patientenkarte Der Heilberufeausweis (HBA) und die Patientenkarte oder elektronische Gesundheitskarte (egk) wurden entworfen, um eine Infrastruktur für die Telemedizin zu schaffen. Beide Karten bieten verschiedene Funktionen wie Signatur-, Authentifizierungs- und Verschlüsselungsfunktionen, die als Basis für die Datensicherheit verwendet werden könnten.

14 egk und HBA werden zum Authentifizieren und zum Datenzugriff auf die egk gemeinsam benötigt [HW07]. Beide Karten können aufgrund ihrer Funktion zur qualifizierten elektronischen Signatur als Teil der Public-Key-Infrastruktur (PKI) für die Be- Lab-Middleware verwendet werden (andere dazu einsetzbare Signaturkarten sind z. B. der elektronische Personalausweis und speziell ausgestatte Dienstausweise der Verwaltungsbehörden). Aufgrund ihrer tatsächlichen bzw. zu erwartenden Verbreitung in der Medizin, lösen sie auf der Infrastrukturebene ein Implementierungsproblem eines auf elektronischem Signaturen basierenden efd-systems. 4.4 Datenschutz Ein efd-system muss immer auch das Recht auf informationelle Selbstbestimmung berücksichtigen, welches im allgemeinen (z. B. Bundesdatenschutzgesetz) und bereichsspezifischen (z. B. Datenschutzregelungen in den Sozialgesetzbüchern) Datenschutzrecht konkretisiert wurde. In der Regel ist jede Erhebung, Verarbeitung und Nutzung personenbezogener Daten geschützt. Besonders zu schützen sind daher z. B. die Daten von Patienten und von Probanden in der medizinischen Forschung. Ein datenschutzgerechtes efd-system muss daher so gestaltet sein, dass es bei der Erhebung, Verarbeitung und Nutzung personenbezogener Daten, so wenig personenbezogene Daten wie möglich erhobenen, verarbeitet oder genutzt werden. Insbesondere sind personenbezogene Daten zu anonymisieren oder zu pseudonymisieren, soweit dies nach dem Verwendungszweck möglich ist [Ha05]. Des Weiteren hat ein solches System auch die Vertraulichkeit und Integrität informationstechnischer Systeme zu gewährleisten. Denn informationstechnische Systeme können mittlerweile personenbezogene Daten des Betroffenen in einem Umfang und in einer Vielfalt enthalten, dass ein Zugriff auf das System es ermöglicht, einen Einblick in wesentliche Teile der Lebensgestaltung einer Person zu gewinnen oder gar ein aussagekräftiges Bild der Persönlichkeit zu erhalten, so dass deren Schutz sogar einen grundrechtlichen Anspruch darstellt [Bv08]. Der Schutz erstreckt sich auf komplexe, informationstechnische Systeme, die der Betroffene in eigener Weise nutzt. Geschützt müssen daher auch die Anwender einer efd- Lösung, etwa durch ein zweckmäßiges Mandantensystem mit einem geeigneten Rechtemanagement, welches gegebenenfalls die Möglichkeit zur Anonymisierung und Pseudonymisierung der Nutzer bietet. 4.5 Bewertungssystem für Beweiswerterhaltung und Archivierung Eine allgemeingültige Bewertung der Eignung eines elektronischen Dokuments zum Zwecke der Beweisführung ist schwierig bis nahezu unmöglich. Denn bei der Bewertung eines Beweismittels kommt es stets auf den Einzelfall an. Dabei ist entscheidend darauf abzustellen, wer die Beweislast trägt, also wer eine Tatsachenbehauptung beweisen muss, weil sie bestritten wurde, und ob das angebotene Beweismittel zum Beweis der Tatsache überhaupt geeignet ist (vgl. [Sc07], S. 477 ff.). Will sich der Verwender elektronischer Dokumente auf den Eventualfall einer gerichtlichen Auseinandersetzung vor-

15 bereiten, bei der seine elektronischen Dokumente als Beweismittel herangezogen werden könnten, muss er zur Beurteilung ihres Beweiswerts eine Risikoanalyse anstellen. Anknüpfungspunkte dafür sind, welche Tatsachen und welche materiell-rechtlichen Ansprüche damit möglicherweise bewiesen werden sollen, wer die Beweislast trägt und welche rechtlichen Anforderungen bei der Erstellung und Aufbewahrung der Dokumentation und Dokumente zu erfüllen waren und sind. Daneben kommt es entscheidend darauf an, wie sich die Echtheit der elektronischen Dokumente verifizieren lässt und schließlich, ob sich deren Beweiswert erhalten lässt (vgl. entsprechende Überlegungen zum Beweiswert von s bei [Ro03]). Der Anwender einer efd muss sich hier konkret fragen, welchen gesetzlichen Auflagen zur Dokumentation und Aufbewahrung er nachkommen muss, welche rechtlichen Ansprüchen er möglicherweise verfolgen möchte (z. B. Honorarforderungen), welche Ansprüche gegen ihn gerichtet werden könnten (z. B. Schadensersatzansprüche) und welchen (insbesondere finanziellen) Aufwand er zur Risikoabsicherung einsetzen will. Eine Risikoanalyse zum Beweiswert ist damit der Schnittpunkt zwischen den rechtlichen Verpflichtungen und Ansprüchen sowie dem ökonomischen Interessen des Anwenders, auf deren Grundlage er Entscheidung über Investitionen zur Sicherung seiner elektronischen Dokumente anstellen muss und bei einem möglichem Gerichtsverfahren Einschätzungen zum Prozessrisiko anstellen kann [BS11]. Deswegen bietet es sich an, dem Anwender ein verständliches System zur Bewertung der Echtheit und Sicherheit der eingestellten Daten an die Hand zu geben. So soll ihm ermöglicht werden, dass vorgenannte Risiko einzuschätzen und seine Position noch rechtzeitig durch zusätzliche Sicherungsmaßnahmen zu stärken. Durch eine Klassifizierung der Daten anhand der Datenformate, erhobenen Metadaten und verwendeten elektronischen Signaturen erhält der Nutzer einen Hinweis auf den Grad der Beweissicherheit und mögliche Risiken bei der Langzeitarchivierung der Daten. In einem erstem Schritt wird zunächst geprüft, ob und welche Art von elektronischer Signatur eingesetzt wurde. Je nach Art (einfach, fortgeschritten oder qualifiziert) lassen sich Aussagen zur Beweisbarkeit der Datenauthentizität, also wer das elektronische Dokument erstellt hat, und zur Datenintegrität, also ob das elektronische Dokument manipuliert wurde, treffen. Festzustellen ist auch, welche Art elektronischer Zeitstempel verwendet wurde, da mit einem solchen Beweis über die Datenintegrität allgemein und ab einem bestimmten Zeitpunkt geführt werden kann. In einem zweiten Schritt ist zu prüfen, wie die Datenerzeugung (z. B. den Messungen, der Übertragung an Auswertungsgeräte und Programme, der Übertragung der Daten in das elab) dokumentiert und gesichert wurde. Wird kein besonderer Schutz der Datenintegrität durch automatisierte Verschlüsselung/Signierung am Messgerät sichergestellt, erfolgt die Datenerzeugung ungesichert. Eine gesicherte Datenerzeugung bedeutet dagegen, dass die Sicherung der Datenintegrität durch die automatische Übernahme der erzeugten Daten vom Messgerät zum elab, einer Prüfung der Datenkonsistenz innerhalb des Untersuchungsfalls und der Signierung dieser Daten belegt werden kann. Zu beachten ist, dass Klassifizierung und Signierung aufeinander rekurrieren. Die Klassifizierung wird aufgrund der Signatur mitbestimmt und auch mit verschlüsselt.

16 Im dritten Schritt basiert die Bewertung der LZA-Tauglichkeit auf dem Datenformat der übergebenen Datei. Ungeeignet ist ein Datenformat, wenn die übergebene Datei nach einigen Jahren wahrscheinlich nicht mehr interpretiert werden kann. Bedingt geeignet ist es, wenn das Datenformat wahrscheinlich nach einigen Jahren noch interpretiert werden kann. Geeignet ist das Datenformat, wenn für das gewählte Datenformat angenommen werden kann, dass es auf lange Zeit interpretierbar bleibt [BS11]. Ein solches Bewertungssystem könnte die in Abbildung 2 vorgeschlagenen Klassen zur Einschätzung der Beweissicherheit verwenden. Beweiswert Datenerzeugung LZA-Tauglichkeit Keine: keine oder einfache elektr. Signatur. Fortgeschritten: fortgeschrittene elektr. Signatur und elektr. signierter Zeitstempel vom Archivsystem Qualifiziert: qualifizierte elektr. Signatur und elektr. signierter Zeitstempel vom Archivsystem Qualifiziert+: wie Qualifiziert und qualifizierter elektr. Zeitstempel Akkreditiert: qualifizierter elektr. Signatur eines akkreditierten Zertifikatdiensteanbieters und elektr. signierter Zeitstempel Akkreditiert+: wie Akkreditiert und qualifizierter elektr. Zeitstempel. ungesicherte Datenerzeugung: keine besondere Sicherung der Datenintegrität durch automatisierte Signierung am Messgerät bei der Datenerzeugung. gesicherte Datenerzeugung: automatische Übernahme der erzeugten Daten vom Messgerät und Sicherung der Datenintegrität durch digitale Signaturverfahren Ungeeignet: proprietäre und nicht weit verbreitete Datenformate Geeignet: Eine in dem Datenformat übergebene Datei kann wahrscheinlich nach einigen Jahren noch interpretiert werden. Beispiele: PDF, TIFF sowie Archive im ZIP Format, die diese Formate enthalten Empfohlen: Für das gewählte Datenformat kann angenommen werden, dass es auf lange Zeit interpretierbar bleibt. Beispiele: ASCII, XML, PDF/Asowie Archive im TAR Format, die diese Formate enthalten Abbildung 2: Klassen eines Bewertungssystems des Beweiswerts Beispiel: Eine efd wird vom Nutzer mit einer qualifizierten elektronischen Signatur versehen. Zur Dokumentation des Sicherungszeitpunkts wird der elektronische Zeitstempel des Archivsystems benutzt. Die Daten wurden nicht automatisch, d. h. ohne Sicherung von den Messgeräten händisch in die efd übertragen. Das Datenformat PDF wird verwendet. Die Eigenschaft der efd zur Beweiswerterhaltung wird als qualifiziert eingestuft. Die Datenerzeugung ist ungesichert. Die Sicherung ist zur Langzeitarchivierung geeignet. In der Ausgestaltung einzelner efd könnten die Klassen (insbesondere der Kategorie Beweiswert) noch mit stärker wertenden Bezeichnungen (z. B. unsicher, noch sicher, sicher, empfohlen) belegt werden, um dem Nutzer eine schnellere Einschätzung zu ermöglichen. Auch könnte das Bewertungssystem vereinheitlicht werden, etwa durch Vergabe bestimmter Punktwerte zu einzelnen Klassen. Ziel dabei wäre es, dem Nutzer eine zusammengefasste Wertung aller vergeben Klassen zu präsentieren. Bei einer solchen Ausgestaltung sind im Einzelfall jedoch die Rahmenbedingungen und der Verwen-

17 dungszweck der jeweiligen efd zu beachten und es ist auf die Bedürfnisse der Nutzer einzugehen. 5. Fazit und Ausblick Elektronische Falldokumentationen dienen der medienbruchfreien digitalisierten Nutzung und Archivierung unterschiedlichster Daten. Bei der Realisierung der efd ist die beweiswerterhaltende LZA sicherzustellen. Dies dient sowohl der Erfüllung gesetzlicher Verpflichtungen als auch der Minderung von Haftungsrisiken. Zur Erfüllung der Anforderungen an den Beweiswerterhalt können elektronische Signaturen verwendet werden, welche den Beweiswert steigern und eine Äquivalenz zum Beweiswert von herkömmlichen Urkunden begründen können. Gleichsam muss dann bei der LZA die gegebenenfalls notwendige Übersignatur adressiert und umgesetzt werden können. Hierfür kann auf vom BSI erstellte Richtlinien zurückgegriffen werden [BSI11]. Daneben sind für die LZA geeignete Datenformate und Metadatenstandards zu wählen. Darüber hinaus spielen aber die Sektor-spezifischen Besonderheiten eine Rolle. Denn bei der Verwendung der egk bzw. der HBA als Teil der PKI kommen qualifizierte elektronische Signaturen zum Einsatz. Mithilfe dieser Technik, die als Basis für die Datensicherheit innerhalb dieser Infrastruktur verwendet wird, ist es möglich, die im Medizinbereich anfallenden Daten von ihrer Entstehung bis zur Ablage im elektronischen Langzeitspeicher für die Dauer der Aufbewahrungsfrist beweiswerterhaltend zu verarbeiten und zu archivieren. Sodann ist bei der konkreten Ausgestaltung einer beweiswerterhaltenden und LZAtauglichen efd ein generischer Ansatz zu verfolgen, die Metadatenaufbereitung sicherzustellen und möglichst ein für den Anwender verständliches Bewertungssystem für die Beweiswerterhaltung und Archivierung zu gestalten. Beschrieben wurde die generische Schnittstelle des BeLab-Systems, welche für die Beweissicherheit und die Langzeitarchivierung von elektronischen Laborbüchern verwendet wird und auch für die epa bzw. efa genutzt werden kann. Mithin konnte gezeigt werden, dass es bei elabs auf aggregierter Ebene um ähnliche Datenformen handelt wie bei der epa und die BeLab- Schnittstelle mit geringem Anpassungsaufwand genutzt werden. Bezüglich der Vertraulichkeit der Daten bedarf es jedoch weitere Arbeiten, die das Sicherheitskonzept des BeLab-System um geeignete Verschlüsselungstechniken erweitern. Literaturverzeichnis Alle Online Ressourcen wurden zuletzt am abgerufen. [BS11] Projektgruppe Beweissicheres elektronisches Laborbuch (BeLab): Schnittstellenpapier V.1.2 vom ; /belab/fileadmin/templates/mm_dam_fe/belabschnittstellenpapierv1.1_doc_01.pdf [BSI11] Bundesamt für Sicherheit in der Informationstechnik (BSI): BSI Technische Richtlinie 03125: Beweiswerterhaltung kryptographisch signierter Dokumente v.1.1, Stand vom

18 , Bonn, 2011; TechnischeRichtlinien/tr03125/index_htm.html [Bv08] Bundesverfassungsgericht, Urteil vom 27. Februar 2008, Aktenzeichen 1 BvR 370/07 und 1 BvR 595/07. In BVerfGE 120; S [Fi06] Fischer-Dieskau, S.: Das elektronisch signierte Dokument als Mittel zur Beweissicherung. Nomos, Baden-Baden, [Fu11] Funk, S. E.: Die kopal Library for Retrieval and Ingest (kolibri). In (Neuroth, H. et. al Hrsg.): Nestor Handbuch, Eine kleine Enzyklopädie der digitalen Langzeitarchivierung (Version 2.3), Kapitel 13.4; /nestorhandbuch_23.pdf [Ha05] Haas, P.: Medizinische Informationssysteme und Elektronische Krankenakten. Springer, Berlin (u.a.), [HR08] Hackel, S., Roßnagel, A.: Langfristige Aufbewahrung elektronischer Dokumente. In (Klumpp, D. et al Hrsg.): Informationelles Vertrauen für die Informationsgesellschaft. Springer, Berlin (u.a.), 2008; S [Ha11] Hackel S. et al: Scientific Data Lifecycle - Beweiswerterhaltung und Techniken. In (BSI Hrsg.): Sicher in die Digitale Welt von Morgen Tagungsband zum 12. Deutschen IT- Sicherheitskongress. SecuMedia, Gau-Algesheim, 2011; S [HW07] Häber, A., Werner, D.: Einführung der elektronischen Gesundheitskarte in Krankenhäusern. In (Koschke et al, Hrsg.): Informatik 2007 Beiträge der 37. Jahrestagung der Gesellschaft für Informatik e.v.(gi), Band P-110 von Lecture Notes in Informatics, Bremen, Köllen, Bonn, 2007; S [Ku06] [Hü09] Hühnlein, D. et al.: A Comprehensive Reference Architecture for Trustworthy Long- Term Archiving of Sensitive Data. In (Al-Agha, K.; Badra, M.; Newby, G. Hrsg.): Proceedings 3rd International Conference on New Technologies, Mobility and Security (NTMS), Kairo, IEEE, 2009; [JKGE] Regierungsentwurf zum Gesetz über die Verwendung elektronischer Kommunikationsformen in der Justiz (JKomG), veröffentlicht in BTDrs. 15/4067. Kuchinke, W., Drepper, J., Ohmann, C.: Einsatz des CDISC-Standards für die vernetzte klinische Forschung in der Telematikplattform für medizinische Forschungsnetze. In (Jäckel, A. Hrsg.): Telemedizinführer Deutschland Minerva, Bad Nauheim, 2006; S [Lu11] Ludwig, J.: Formate Auswahlkriterien, in Heike Neuroth et. al: Nestor Handbuch Eine kleine Enzyklopädie der digitalen Langzeitarchivierung (Version 2.3) (Kap.7.3), abzurufen unter [Me11] Library of Congress: Metadata Encoding and Transmission Standard, Stand vom [Pa10] ; Paasche, T.: Parallelen in der Datenrepräsentation zwischen Laborbüchern und sensorerweiterten elektronischen Patientendokumenten. Bachelorarbeit, TU Braunschweig, September [R4810] Wallace, C. et al: Long-Term Archive Service Requirements, 2007; [R4998] Gondrom, T. et al: Evidence Record Syntax (ERS), 2007; [Ri11] Rieger, S. et al: Elektronisches Laborbuch: Beweiswerterhaltung und Langzeitarchivierung in der Forschung. In (Schomburg, S. et al Hrsg.): Digitale Wissenschaft - Stand und Entwicklung digital vernetzter Forschung in Deutschland, 20./21. September 2010, Köln, Beiträge der Tagung, hbz, Köln, 2011; S ; [Ro03] Roßnagel, A., Pfitzmann, A.: Der Beweiswert von , NJW 2003, Jg. 56, Heft 17; S [RS06] Roßnagel, A., Schmücker, P.: Beweiskräftige elektronische Archivierung - Bieten elektronische Signaturen Rechtssicherheit?. Economica, Bonn [Sc07] Schneider, E: Die Klage im Zivilprozess. Verlag Otto Schmidt, Köln, [St05] [St06] Steinke, S.: Langzeitarchivierungsmetadaten für elektronische Ressourcen, v.1.2, Stand vom ; Steinke, S.: Universelles Objektformat - Ein Archiv- und Austauschformat für digitale Objekte. Projekt kopal, Frankfurt a. M., 2006;

19 MimoSecco: Eine Middleware für sicheres Cloud Computing mit mobilen Endgeräten 1 Michael Decker AIFB, Karlsruher Institut für Technologie (KIT) m.decker(at)kit.edu Abstract: Der vorliegende Kurzbeitrag stellt die Grundidee des Projektes Mimo- Secco vor, welches im Rahmen der Trusted Cloud -Initiative des BMWi gefördert wird. Das Projekt will insbesondere einen sicheren Zugriff mit mobilen Computern wie z.b. Smartphones oder Netbooks auf in der Cloud befindliche Daten ermöglichen. Weiter sollen die bei den Cloud-Providern gespeicherten Daten selbst gegen Insiderangriffe abgesichert werden. Eine wichtige Komponente für die Realisierung dieser Sicherheitsanforderung ist der sowohl client- als auch serverseitige Einsatz von speziellen Security-Smartcards. 1 Einleitung Unter Cloud-Computing (CC) verstehen wir die Bereitstellung von virtualisierten IT- Ressourcen wie Speicherplatz oder Rechenleistung über eine Internetverbindung, wobei gemäß des Ansatzes des Utility Computing die Ressourcen vom Nutzer selbst gebucht / konfiguriert werden können und nur die tatsächlich in Anspruch genommenen Kapazitäten bezahlt werden müssen [BKNT11]. Naturgemäß gehen mit der Nutzung von CC Datenschutzbedenken einher, da hierfür zum Teil vertrauliche Daten (z.b. Kundenadressen, Dokumente mit technischen Details) außer Haus gegeben werden müssen. Der naive Ansatz, die Daten vor dem Auslagern einfach vollständig zu verschlüsseln, ist höchstens für Backup-Anwendungen gangbar, da bei sonstigen Cloud-Diensten der Provider die Daten lesen können muss, um diese sinnvoll zu verarbeiten, z.b. um bestimmte Berechnungen auszuführen oder bestimmte Datensätze zu suchen. Das Ziel des Projektes MimoSecco Middleware for Mobile and Secure Cloud Computing ist es deshalb, einen pragmatischen Ansatz zu entwickeln, um das grundsätzliche Datenschutzproblem von CC anzugehen. Ein zweiter wichtiger Aspekt des Projekts ist die Verwendung von mobilen Endgeräten (z.b. Smartphones, Netbooks) für den Zugriff auf die in der Cloud gespeicherten Daten. Dieses mobile CC kann durch verschiedene Gründe motiviert sein: Da von jedem Internet-PC auf die Daten in der Cloud zugegriffen werden kann, soll dies natürlich auch mit mobilen Endgeräten möglich sein. Weiter verfügen mobile Computer typischerweise über eingeschränkte Ressourcen (z.b. Speicher, CPU-Kapazität, Batterie-Kapazität, Netzwerkanbindung), weshalb Berechnungen und Daten in die Cloud ausgelagert werden können (z.b. 1 Das diesem Bericht zugrunde liegende Vorhaben wird mit Mitteln des Bundesministeriums für Wirtschaft und Technologie (BMWi) aufgrund eines Beschlusses des Deutschen Bundestages unter dem Förderkennzeichen 01MS10002 gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt beim Autor.

20 [SBCD09]). Da ein Nutzer üblicherweise mit mehreren Endgeräten arbeitet (z.b. Desktop-PC, dienstl. & privates Smartphone, Spezialgeräte wie e-book-reader oder Navigationsgerät), kann über Cloud-Dienste auch erreicht werden, dass auf allen Geräten derselbe Datenbestand (z.b. Kontakte, Dokumente, Notizen) verfügbar ist. Der verbleibende Teil des vorliegenden Artikels ist wie folgt aufgebaut: Es wird zunächst die Gesamtarchitektur von MimoSecco vorgestellt. Darauf aufbauend werden verschiedene Mechanismen für den Schutz von in die Cloud ausgelagerte Daten skizziert. Ein weiteres Kapitel ist dem Einsatz von Security-Smartcards gewidmet, bevor ein Ausblick auf zukünftige Arbeiten gegeben wird. 2 Gesamtarchitektur In Abbildung 1 ist die Gesamtarchitektur von MimoSecco aus der Sicht eines Klein- und Mittelständischen Unternehmens (KMU) dargestellt. Das links dargestellte KMU greift hierbei für den Betrieb einer Unternehmensanwendung auf Cloud-Dienste zurück. Hierfür kommt die als Kreuz dargestellte Middleware-Komponente sowohl bei dem KMU als auch bei allen Cloud-Providern zum Einsatz. In der Grafik ist ebenfalls zu erkennen, dass die einzelnen Middleware-Installationen mit verschiedenen Modulen ausgestattet sind. Zur Erhöhung der Sicherheit werden die Daten auf verschiedene voneinander unabhängige Provider an verschiedenen Standorten aufgeteilt. Auch auf dem mobilen Endgerät ist eine spezielle Version dieser Middleware notwendig. Sowohl client- als auch serverseitig kann die Security-Smartcard über die Middleware- Komponente zum Einsatz kommen. Provider 1 Provider KMU Provider 2 Abbildung 1: Gesamtarchitektur

21 3 Sicherheitsmechanismen Eine wichtige Eigenschaft der MimoSecco-Architektur ist es, dass für eine Geschäftsanwendung die Verwendung mehrerer Cloud-Provider vorgesehen ist, um die Daten so zu verteilen, dass selbst bei einem Insider-Angriff durch einen Mitarbeiter im Rechenzentrum des Cloud-Providers kein wirklicher Schaden entsteht [AGH11]. Wenn etwa Kundendaten in der Cloud gespeichert werden sollen, so könnte jeder Datensatz auf mehrere Cloud-Provider verteilt sein (z.b. Vorname und Stadt bei Provider 1, Nachname und Umsatz bei Provider 2). Wird eine geschickte Partitionierung der Daten vorgenommen, so sind die bei einem Provider vorgehaltenen Daten für sich alleine nahezu wertlos. Datenfelder, die nicht für Suchoperationen und Berechnungen benötigt werden, können auch symmetrisch verschlüsselt werden. Für Suchoperationen ist oftmals eine Bereichssuche ausreichend, so dass dem Cloud-Provider z.b. nur der Umsatz- oder PLZ-Bereich eines Datensatzes im Klartext vorliegen muss. Zahlenwerte (z.b. Gehalts-/ Umsatzwerte) können vor dem Speichern in der Cloud in zufällige Komponenten zerlegt werden. Um sog. statistische Angriffe zu vereiteln kann es sinnvoll sein, Dummy-Datensätze mit zu speichern; so kann der Cloud-Provider nicht einmal statistische Auswertungen auf den ihm überlassenen (Teil-)Daten ausführen (z.b. Anzahl Kunden in Darmstadt). Unter der Verwendung der weiter unten beschrieben Security-Smartcard kann zudem verhindert werden, dass sich ein Provider einen Komplettabzug der Datenbank macht oder die Daten auch nach Vertragsende noch weiter verwendet. Ein weiterer Ansatz zur Erhöhung der Sicherheit beim mobilen Zugriff auf Unternehmensanwendungen ist die sog. kontextsensitive Zugriffkontrolle [CoSa06]. Hierbei wird nicht nur anhand der Nutzeridentität entschieden, ob eine bestimmte Operation (z.b. Lesen / Schreiben) auf einer Ressource ausgeführt werden darf, sondern es werden darüber hinaus weitere Informationen ausgewertet (Kontext), die die Situation des Nutzers beschreiben. Beispiele sind der aktuelle Aufenthaltsort (z.b. über GPS oder Zell-Ortung ermittelt, [Deck11]), die Ortszeit, die Ausstattung des aktuell verwendeten Endgeräts oder aktuelle Kalendereinträge (z.b. Kundentermin oder Urlaub). Weitere Sicherheitsmechanismen für den mobilen Zugriff auf Unternehmensdaten werden durch die im nächsten Kapitel beschriebenen Security-Smartcards realisiert. 4 Einsatz von Security-Smartcards Eine besondere Rolle für die Realisierung der Sicherheitsanforderungen spielen Security-Smartcards, die im Gesamtsystem nicht nur client-, sondern auch serverseitig eingesetzt werden. Diese Smartcards kapseln verschiedene sicherheitsrelevante Funktionen (z.b. Ver-/ Entschlüsselung, digitales Signieren, Speicherung von Schlüsselmaterial) und sind gegen physische Manipulationen gesichert. Insbesondere sind diese Smartcards gegen Angriffe mit Laborausrüstung resistent, bei denen etwa ein geheimer Schlüssel für kryptografische Funktionen extrahiert werden soll. Im Projekt kommen konkret die in verschiedenen Bauformen (z.b. als USB-Stick oder Micro-SDCard) vorliegenden Smartcards der CodeMeter-Produktlinie zum Einsatz 2, die vom Industrie-Partner WIBU 2 siehe

22 SYSTEMS AG zur Verfügung gestellt werden und unabhängig vom Projekt entwickelt wurden. Serverseitig kommt die CodeMeter-Smartcard z.b. als USB-Stick in Zusammenarbeit mit der MimoSecco-Middleware zum Einsatz, um ausgelagerte Daten abzusichern: Dies kann zum einen durch Schaffung eines künstlichen Flaschenhalses geschehen, bei dem die Datensätze (teil-)verschlüsselt in die Cloud ausgelagert werden und nur eine bestimmte Anzahl pro Zeiteinheit (z.b. Tag) durch die Smartcard entschlüsselt werden können. Hierdurch kann verhindert werden, dass der Cloud-Provider einen Komplettabzug der ihm überlassen Daten erstellt. Der CodeMeter überprüft anhand einen geschützten Zählregisters und einer internen Uhr für jeden Datensatz, ob dieser entschlüsselt werden darf. Über ein spezielles Internet-Protokoll kann der CodeMeter auch aus der Ferne vom Besitzer der Daten die Erlaubnis bekommen, weitere oder zusätzliche Entschlüsselungen vorzunehmen. Weiter können im geschützten Speicher des CodeMeters auch manipulationsresistente Logfiles über administrative Zugriffe durch den Cloud- Provider gespeichert werden (Secure Logging). Clientseitig wird die Security-Smartcard zur Absicherung des mobilen Zugriffs eingesetzt, indem sie im Rahmen eines Challenge-Response-Verfahrens für die Authentifizierung eingesetzt wird. Eine solche Authentifizierung bringt ein erhebliches Mehr an Sicherheit im Vergleich zu der herkömmlichen rein Passwort-basierten Authentifizierung, da Passwörter oft erraten werden können und einen geringeren Informationsgehalt als ein auf einer Smartcard gespeicherten Schlüssel haben. Auf der Smartcard können auch sensitive Daten sicher gespeichert werden (Secure Caching), wenn etwa neu erfasste Aufträge wegen eines Funklochs nicht sofort in die Cloud hochgeladen werden können. 5 Ausblick Die in MimoSecco erarbeiteten Resultate sollen insbesondere für KMU mit ihren typischerweise eingeschränkten personellen und finanziellen Ressourcen einsetzbar sein. Bei der Evaluation des Gesamtsystems wird neben der technischen Sicherheit auch die gefühlte Sicherheit der Fachanwender (z.b. mobile Servicetechniker, Vertriebsmitarbeiter) eine wichtige Rolle spielen, da diese für die Akzeptanz von CC und mobilen Computern gerade im Mittelstand eine wichtige Rolle spielt. Das Gesamtsystem soll anhand der beiden Szenarien Technischer Vor-Ort-Kundendienst und Beratung für Technologietransfer in Zusammenarbeit mit in den entsprechenden Bereichen tätigen Industriepartnern erprobt werden.