Technische Unterstützung von Audits bei Cloud-Betreibern

Transkript

1 Thomas Kunz, Peter Niehues, Ulrich Waldmann Technische Unterstützung von Audits bei Cloud-Betreibern Automatisierte Kontrolle auf Basis sicherer -Daten Jährliche Audits reichen in Cloud-Umgebungen nicht aus. Die typischen Eigenschaften des Cloud Computing führen zu einer gemeinsamen Nutzung und dynamischen Zuordnung von Ressourcen und erfordern daher eine kontinuierliche und kundenspezifische Kontrolle. Dieser Artikel beschreibt das Konzept eines automatisierten Testats zur technischen Unterstützung eines Auditors und die Sicherung von - Daten, die als Datenbasis für die Kontrollen beim Cloud-Betreiber dienen sollen. 1 1 Hintergrund Die aus Effizienz- und Kostengründen attraktive Nutzung von Cloud-Diensten stellt Unternehmen vor die Problematik, auf der 1 Es handelt sich um einen Beitrag, der im Rahmen des Projekts CloudCycle entstanden ist. CloudCycle wird vom BMWi auf Grund eines Beschlusses des deutschen Bundestages im Förderschwerpunkt TrustedCloud gefördert. Thomas Kunz Wissenschaftlicher Mitarbeiter am Fraunhofer-Institut für Sichere Informationstechnologie. thomas.kunz@sit.fraunhofer.de Peter Niehues Projektleitung bei der regio it gesellschaft für informationstechnologie mbh Peter.Niehues@regioit.de Ulrich Waldmann Wissenschaftlicher Mitarbeiter am Fraunhofer-Institut für Sichere Informationstechnologie. ulrich.waldmann@sit.fraunhofer.de einen Seite für die Sicherheit und den Schutz ihrer Daten verantwortlich zu sein, aber auf der anderen Seite die Kontrolle über die Verarbeitung ihrer Daten zu verlieren. Cloud-Kunden beklagen insbesondere die mangelnde Transparenz hinsichtlich der beim Cloud-Betreiber eingesetzten Sicherheitsmaßnahmen und Abläufe. Als Lösung hierfür werden in diesem Zusammenhang oft Kontrollen von unabhängigen externen Auditoren genannt, die in Zertifikaten oder Testaten bestimmte (Sicherheits-) Eigenschaften beim Cloud-Betreiber bestätigen. Für die Auftragsdatenverarbeitung im Cloud-Umfeld hat die AG Rechtsrahmen des Technologieprogramms Trusted Cloud 2 beispielsweise eine Testat-Lösung als Alternative zur persönlichen Vor-Ort-Kontrolle des Auftraggebers vorgeschlagen, durch welche die notwendigen Datenschutzkontrollen an Hand einheitlicher Prüfkriterien von einer unabhängigen, akkreditierten Stelle (Auditor) vorgenommen würde. Dieser Vorschlag wurde in [5] vorgestellt und aus rechtlicher Sicht diskutiert. Der vorliegende Artikel greift diese Thematik auf und zeigt ein Konzept für eine technische Umsetzung. Der Bedarf nach unabhängigen Audits als Voraussetzung für die Nutzung von Cloud- Diensten wird am Beispiel von Bildungseinrichtungen gezeigt, zudem wird die technische Problematik von Audits in Cloud- Umgebungen beschrieben. Als Lösung wird das Konzept eines automatisierten Testats auf Basis sicherer -Daten als kontinuierlich anwendbare, technische Unterstützung für einen Auditor vorgestellt. 1.1 Beispiel: Bildungseinrichtungen Bildungseinrichtungen wie Schulen stellen neben der notwendigen IT-Infrastruktur zur Verwaltung des Schulbetriebs die Fachsoftware für die pädagogische Ausbildung der Schüler in den Klassenräumen zur Verfügung. Häufig wird die verwendete Software innerhalb der Schulen dezentral auf den Clients oder 2 Nähere Informationen unter DuD Datenschutz und Datensicherheit

2 maximal auf den Servern in den lokalen Schulnetzen betrieben. Selten erfolgt eine Betreuung durch regionale, kommunale Rechenzentren. Die IT-Infrastruktur wird oft durch den Lehrkörper selbst oder auch arbeitsteilig durch die EDV-Abteilung der Schulträger (Stadt- und Landkreise) betreut. Aus dieser Situationsbeschreibung werden bereits zwei grundlegende Problemstellungen sichtbar: Jede Schule betreibt ihre eigene, dezentrale IT-Infrastruktur, was IT-Insellösungen zur Folge hat, die untereinander nicht miteinander kommunizieren können. Jede IT-Insel beherbergt unterschiedliche Systemkomponenten und Anwendungen, die jeweils einzeln betreut und gepflegt werden müssen. Genau hier liegt das zweite Problem. Der Lehrkörper selbst übernimmt die Betreuung der IT-Infrastruktur, obwohl dies über sein originäres Aufgabengebiet hinausgeht und zusätzlichen Zeitaufwand erfordert. Die Abkehr von solchen lokal ausgerichteten IT-Konzepten hin zu einer flexiblen Nutzung von Ressourcen und einer Vernetzung der Schulen mittels Cloud Computing bietet die Möglichkeit, Effizienzpotenziale zu nutzen. Mit der Verlagerung in die Cloud müssen die Schulen allerdings gleichzeitig neue Herausforderungen meistern, die sich größtenteils auf den Bereich des Datenschutzes und der Compliance konzentrieren. In dem Moment, in dem eine Schule nicht mehr auf ihre eigene, dezentrale IT-Infrastruktur zurückgreift und Dienste des Cloud Computing in Anspruch nimmt, ist sie in besonderem Maße an die gesetzlichen Rahmenbedingungen zur Verarbeitung von personenbezogenen Daten im Auftrag gebunden. Im Extremfall muss die Schule für jede Fachsoftware aus der Cloud einen eigenen Vertrag zur Auftragsdatenverarbeitung abschließen und die Einhaltung des Vertrags kontrollieren. Das ist auf Grund der Vielfalt und Heterogenität der eingesetzten Schulsoftware praktisch unmöglich und könnte im Zweifelsfall mehr Aufwand erzeugen, als der Betrieb der Software im schuleigenen Netzwerk. Hinzu kommen neue Herausforderungen, die in den bisherigen IT-Konzepten als gelöst galten. Die Schulen sind an die landesspezifischen Verordnungen zum Datenschutz gebunden. Demnach ist gefordert, die Netzbereiche des pädagogischen Bereichs von denen des Verwaltungsbereichs logisch zu trennen. Im Rahmen des Forschungsprojektes CloudCycle 3 wurde hierzu eine rechtliche Einschätzung publiziert, die den Schulen als Orientierungshilfe dienen soll. 4 Die logische Trennung der beiden Netzbereiche muss auch im Fall der Nutzung von Cloud-Diensten eingehalten werden. Der Nachweis der Trennung wird insbesondere dann zu einer Herausforderung, wenn ein und derselbe Cloud-Betreiber unterschiedliche Cloud-Angebote für Pädagogik und Verwaltung anbietet. Die Einhaltung derartiger Anforderungen in der Cloud muss für die Schulen nachvollziehbar und nachweisbar sein. Vielversprechende Lösungsansätze sind hierbei die Konzepte der Audits und Testate. 1.2 Problematik von Audits Ein Audit in einer Cloud-Umgebung gestaltet sich aufgrund der spezifischen Eigenschaften von Cloud Computing als äußerst A. Selzer, J. Bergner: Rechtliche Stellungnahme zur physischen oder logischen Trennung von Schulverwaltungsnetz und pädagogischem Netz, www. cloudcycle.org/cms/wp-content/uploads/2013/01/trennung-von-lern-und-verwaltungsnetz1.pdf schwierig. Die Skalierbarkeit und Flexibilität des Cloud Computing führt durch die dynamische, am Bedarf orientierte Zuordnung von Computerressourcen zu komplexen und sich ständig wandelnden Systemstrukturen mit potentiell wechselnden Auftragnehmern. Das hocheffiziente gemeinsame Nutzen von Softund Hardware-Ressourcen durch viele Mandanten (Cloud-Kunden) erhöht die Komplexität zusätzlich. Zudem besteht die Problematik, dass unterschiedliche Cloud-Kunden auch unterschiedliche (Sicherheits-) Anforderungen an die von ihnen genutzten Cloud-Dienste und die Cloud-Betreiber haben können. Jährliche Audits beim Cloud-Betreiber durch einen externen Auditor sind daher nicht ausreichend, um die beim Cloud-Betreiber eingesetzten Sicherheitsmaßnahmen überprüfen und einschätzen zu können. In [2] wird daher eine kontinuierliche Kontrolle basierend auf Monitoring, Audits und Tests gefordert. Zudem ist ein Auditor nicht in der Lage, die Einhaltung spezifischer Anforderungen einzelner Cloud-Kunden gezielt zu überprüfen. Beispielsweise könnte ein Cloud-Kunde fordern, dass seine Daten ausschließlich in Deutschland verarbeitet werden, während andere Kunden den gesamten EWR als Verarbeitungsstandort zulassen könnten. Eine kontinuierliche und kundenspezifische Kontrolle durch einen externen Auditor ist nur mit Hilfe technischer Unterstützung auf Basis von automatisierbaren Überprüfungen möglich. 2 Testat In einem Testat bestätigt ein externer Auditor, dass bestimmte Sicherheitskriterien beispielsweise in den Rechenzentren eines Cloud-Betreibers erfüllt sind. Hierzu überprüft der Auditor, welche Sicherheitsmaßnahmen beim Cloud-Betreiber eingesetzt werden und ob diese als ausreichend angesehen werden, die vorgegebenen Sicherheitskriterien zu erfüllen. Das im Folgenden vorgestellte Konzept für ein Testat geht von zum Teil automatisierten Überprüfungen beim Cloud-Betreiber aus, deren Ergebnisse in einem automatisiert erstellten Testat festgehalten werden. Die Automatisierung der Prüfungen erlaubt jederzeit durchführbare Prüfungen und somit eine kontinuierliche Kontrolle, ohne dass ein Auditor vor Ort sein muss. Die automatisierten Überprüfungen eignen sich daher besonders für Kontrollen von Cloud-Diensten, weil die sich dynamisch ändernden Cloud-Systeme nur automatisiert erfasst und verfolgt werden können. Beispielsweise könnte der Verarbeitungsstandort von Kundendaten einer spezifischen kontinuierlich überprüft werden. Es können jedoch nicht alle Überprüfungen automatisiert durchgeführt werden. Dies gilt insbesondere für die Überprüfung von organisatorischen Maßnahmen und der Einschätzung von Schutzmaßnahmen von Gebäuden, wie Blitzschutz etc. Diese Überprüfungen obliegen nach wie vor dem Auditor und erfordern seine Präsenz beim Cloud-Betreiber. Das hier vorgestellte Testat besteht somit aus einem automatisiert erstellten Teil und den Testergebnissen des Auditors. Die Automatisierbarkeit von Kontrollen setzt voraus, dass automatisch auswertbare Daten für die Prüfungen zur Verfügung stehen, anhand derer die Einhaltung von Prüfkriterien beim Cloud- Betreiber überprüft werden kann. Die Daten, auf deren Basis das automatisierte Testat erstellt wird, müssen vollständig, authentisch und integer sein und die Abläufe im gesamten Lebenszyk- 522 DuD Datenschutz und Datensicherheit

3 Abbildung 1 Kundenspezifische Prüfkriterien 1. Auswahl eines Cloud-Dienstes und Vertragsabschluss Kunde 2. Setzen der kundenspezifischen Policy 3. Nutzen der T Testat 5. Ausstellen eines Testats wird überprüft, ob die in der Policy enthaltenen Anforderungen erfüllt werden. Wesentlich für eine automatisierte Durchführung der Überprüfungen ist, dass die Policy in einer formalen Sprache beschrieben ist. S PP P S Cloud-Dienste mit Policy (abstrakt) Cloud-Betreiber mit Policy (kundenspezifisch) lus einer Instanz eines Cloud-Dienstes wiedergeben. Im Folgenden werden die Herleitung der Prüfkriterien und die Erstellung eines Testats vorgestellt. 2.1 Prüfkriterien Die Prüfkriterien können einerseits aus gesetzlichen Regelungen, wie z. B. der Auftragsdatenverarbeitung, dem Finanz-, Gesundheits- oder Versicherungswesen, hergeleitet werden. Andererseits kann aber auch der Kunde individuelle Anforderungen an den Cloud-Betreiber oder an die von ihm genutzten Cloud-Dienste formulieren, welche ebenfalls als Grundlage für Prüfkriterien dienen können. Beispiele für Prüfkriterien können der Speicherstandort der Kundendaten (z. B. Deutschland, EWR, Schweiz) und der Grad der Kundentrennung (z. B. dedizierter Server oder gemeinsamer Server) sein. Abbildung 1 zeigt die Erzeugung kundenspezifischer Prüfkriterien. Die von den Cloud-Betreibern angebotenen Dienste verfügen jeweils bereits über eine Policy, welche Anforderungen z. B. an den Cloud-Betreiber oder die Laufzeitumgebung des Dienstes enthält. Diese Policy kann beispielsweise vom Hersteller des Cloud-Dienstes vorgegeben werden. Sie wird als abstrakte Policy bezeichnet, da sie nicht kundenspezifisch ist. Nachdem ein Kunde einen der angebotenen Cloud-Dienste ausgewählt und mit dem Cloud-Betreiber einen Vertrag bezüglich der Nutzung des Dienstes abgeschlossen hat, hat der Kunde die Möglichkeit, diese abstrakte Policy um eigene Anforderungen zu ergänzen. Denkbar ist auch, dass die Policy Wahlmöglichkeiten für den Kunden vorgibt. Beispielsweise könnte der Kunde zwischen verschiedenen Speicherstandorten für seine Daten wählen oder er könnte ein bestimmtes Sicherheitsniveau hinsichtlich der Verschlüsselung seiner Daten auswählen. Hat der Kunde auf diese Weise seine Anforderungen gesetzt, erzeugt der Cloud-Betreiber für ihn eine Instanz des Dienstes, die vom Kunden genutzt werden kann und die nun eine kundenspezifische Policy enthält. Wird nun zu einem späteren Zeitpunkt ein Auditor beauftragt, den Cloud-Betreiber und die des Kunden zu kontrollieren, bildet diese kundenspezifische Policy die Grundlage für die durchzuführenden Überprüfungen, d. h. es P S 4. Überprüfen der Dienst- Instanz Auditor 2.2 Erstellung eines Testats Die Erstellung des Testats könnte wie folgt ablaufen: Der Auditor initiiert die Durchführung der automatisierten Prüfungen. Hierfür benötigt der Auditor einen gesicherten Zugang zum Abruf der -Daten. Der Auditor berücksichtigt für die Prüfungen den Auswertungszeitraum, die zu prüfende und damit die zu überprüfenden Sicherheitsanforderungen (Policy der ). Nach Abschluss der Prüfungen werden die Prüfergebnisse in dem automatisierten Testat zusammengefasst und von der Testat-Erstellungseinheit elektronisch signiert. Der Auditor überprüft das automatisierte Testat hinsichtlich Vollständigkeit, Plausibilität, Integrität und Authentizität. Optional kann der Auditor selbst weitere Prüfungen beim Cloud-Betreiber vor Ort durchführen. Danach führt er das automatisierte Testat und seine eigenen Prüfergebnisse zusammen, fügt den Gültigkeitszeitraum des Testats hinzu und bestätigt die Gesamtergebnisse mit seiner elektronischen Signatur. 3 Sicheres ging In der hier beschriebenen Lösung werden die automatisierten Prüfungen beim Cloud-Betreiber auf Basis von -Daten durchgeführt. Dies hat den Vorteil, dass Daten verwendet werden, die innerhalb eines Rechenzentrums routinemäßig anfallen und die zur Herstellung von Transparenz und Nachvollziehbarkeit unverzichtbar sind. Über die -Daten muss der gesamte Lebenszyklus eines Cloud-Dienstes nachvollziehbar sein, d. h. das Anlegen, Konfigurieren, Starten, Stoppen, Skalieren und das Entfernen einer umfassen. In der potenziell unsicheren Umgebung eines Cloud-Betreibers müssen die Authentizität, Integrität und Vertraulichkeit der -Daten mittels eines spezifischen Verfahrens geschützt werden. 3.1 Sicheres -Verfahren Verbreitete -Verfahren wie syslog sind keineswegs imstande, eine vollständige und beweiskräftige Datenbasis zu schaffen, wie sie für die Erstellung eines automatisierten Testats notwendig ist. Das folgende -Verfahren erweitert daher das Verfahren von Schneier und Kelsey [4], das die von Bellare und Yee [1] definierte Forward Integrity selbst auf relativ ungesicherten Komponenten ermöglicht. Daten, die heute integer sind, dürfen auch durch zukünftige Angriffe nicht unentdeckt manipulierbar sein. Ein Angreifer, der beispielsweise die aktuellen Schlüssel zur Erzeugung von Prüfsummen auf einer ging-komponente unter DuD Datenschutz und Datensicherheit

4 S 4 S 4 S 4 S 4 S 4 S 4 AUFSÄTZE Abbildung 2 -System mit Treuhänder Cloud-Betreiber Treuhänder S 1 -Adapter S 2 -Adapter S 3 -Adapter Sicheres ging L Auth HSM / Auth Auditor / Kunde Hypervisor Hypercalls -Adapter Auth -Auswertung Server Netzkomponente... Datenbank S 1 S 2 S 3 S 4 Ungesicherte -Dateien Gesicherte -Dateien seine Kontrolle gebracht hat, darf dennoch nicht in der Lage sein, die zuvor verwendeten Schlüssel zu berechnen, um Einträge älteren Datums zu manipulieren. Jeder neue -Eintrag wird mit dem vorigen Eintrag über Verschlüsselung, Hash-Werte und Prüfsummen verkettet und in die aktuelle -Datei geschrieben. Neben der ging-komponente, die die gesicherten -Dateien anlegt, wird ein vertrauenswürdiger und vom Cloud-Betreiber unabhängiger Schlüsselspeicher benötigt. Die ging-komponente und der Schlüsselspeicher handeln für jede neue -Datei zwei symmetrische Startschlüssel aus. Die ging-komponente leitet daraus bzw. aus den Nachfolgeschlüsseln in jeder Runde für den aktuell zu erstellenden - Eintrag zwei symmetrische Arbeitsschlüssel für den zu erstellenden -Eintrag ab: Durch Hashen der vorigen Arbeitsschlüssel zusammen mit den Zugriffsrechten für den neuen -Eintrags werden daraus ein individueller Schlüssel zur Verschlüsselung der originären -Daten und ein Schlüssel zur Berechnung einer Prüfsumme erzeugt. Nach jeder Verwendung und dem Erzeugen neuer Arbeitsschlüssel werden die alten Schlüssel gelöscht. So setzt sich das Verfahren für jeden neuen -Eintrag fort. Die Startschlüssel stellen die Sicherheitsanker jeder gesicherten -Datei dar und verlassen niemals mehr den Schlüsselspeicher. Die Arbeitsschlüssel gesicherter -Einträge sind nirgendwo gespeichert und können ausschließlich im Schlüsselspeicher aus den Startschlüsseln und den kodierten Zugriffsrechten rekonstruiert werden. Der Schlüsselspeicher sendet bei Bedarf diese Arbeitsschlüssel an autorisierte externe Instanzen, damit diese die -Daten verifizieren, entschlüsseln und auswerten können. Ohne weitere Maßnahmen könnte eine solche Instanz anschließend mittels der Arbeitsschlüssel die -Daten nach Belieben ändern, neu verschlüsseln und schließlich mit neuen Prüfsummen versehen. Zum Schutz gegen eine nachträgliche Manipulation wird daher als letzter -Eintrag einer -Datei ein Hash-Baum [3] mit den Hash-Werten aller vorliegenden -Einträge und einem kryptografischen Zeitstempel des sicheren Schlüsselspeichers eingefügt. Für die Sicherheit sind somit die Registrierung der -Dateien und zugehörigen Zeitstempel im Schlüsselspeicher und das zuverlässige Zusammenspiel von ging-komponente, Schlüsselspeicher und prüfenden Instanzen wesentlich. Nur die ging-komponente darf sichere -Dateien erstellen und sie vom Schlüsselspeicher signieren lassen. 3.2 Sicheres -System Die Anpassung aller technischen Komponenten des Cloud-Betreibers an ein neues -Verfahren erscheint unrealistisch. Stattdessen können über geeignete -Adapter die -Einträge unterschiedlicher Quellen ausgelesen und an eine zentrale ging-komponente übergeben werden, siehe Abbildung 2. Dort werden die originären -Daten durch das oben beschriebene -Verfahren in ein einheitliches abgesichertes Format überführt. Idealerweise sortiert die zentrale ging-komponente die -Daten anhand späterer Zugriffsberechtigungen (z. B. - Daten des Kunden X) und fasst die -Daten eines bestimmten Berechtigten jeweils in einer gesicherten -Datei zusammen. Die -Dateien der virtuellen Dienstinstanzen stellen dabei einen guten Ausgangspunkt dar, weil sie in der Regel einem Berechtigten zugeordnet werden können. Der Hypervisor stellt eine weitere wichtige Quelle von -Daten dar. Ein -Adapter liest die -Daten des Hypervisor und der darunter liegenden Komponenten ein, ordnet sie den Dienstinstanzen zu und übergibt die Daten der ging-komponente. Eine wesentliche Eigenschaft des -Systems ist der Schutz der ging-komponente gegen interne Manipulation. Denn der Cloud-Betreiber kann nicht per se als vertrauenswürdig gelten, sondern hat unter Umständen ein Interesse daran, die -Daten vergangener Ereignisse in seinem Sinne zu verändern. Daher soll- 524 DuD Datenschutz und Datensicherheit

5 te der Schlüsselspeicher mit den sicherheitsrelevanten Funktionen in Form eines Hardware-Sicherheitsmoduls (HSM) realisiert werden, auf das der Cloud-Betreiber keinen direkten Zugriff hat. Abbildung 2 zeigt eine mögliche Konfiguration, in der das HSM bei einem unabhängigen Dritten, einem Treuhänder, betrieben wird. Ein solches separates ging-hsm wäre vermutlich leichter zertifizierbar als reine Software-Komponenten. In einer solchen Konfiguration verwaltet der Treuhänder nicht die eigentlichen -Daten, sondern mittels HSM ausschließlich die Sicherheitsanker und Metadaten (Schlüssel, Zertifikate, Zeitstempel, Authentisierungsdaten). Deshalb scheint es realistisch, dass sich Cloud-Betreiber und Kunden ohne Datenschutzbedenken auf ein solches Vorgehen einigen können. Der Cloud-Betreiber müsste lediglich die ging-komponente installieren und konfigurieren und Speicherplatz für die -Dateien zur Verfügung stellen. Cloud-Betreiber, Kunden, Auditoren und Treuhänder sollten diese Beziehungen vertraglich regeln. Interessanterweise bieten inzwischen große Cloud-Betreiber ihren Kunden HSM-Dienste an 5, auf deren kryptografische Schlüssel ausschließlich der Kunde Zugriff haben soll. Unter dieser Voraussetzung ist eine Konfiguration denkbar, in der der Treuhänder seine -Schlüsseldienste selbst wieder in die Cloud auslagert. 3.3 Zugriff auf gesicherte -Daten Externe Instanzen, wie z. B. ein Auditor, können nun -Dateien wie folgt verifizieren und auswerten. Der Auditor authentisiert sich mit Hilfe eines etablierten Autorisierungsprotokolls, z. B. OAuth 2.0, gegenüber dem Treuhänder, indem er einen Nachweis ( Authorization Code ) darüber präsentiert, dass er vom eigentlichen Inhaber der -Daten (in der Regel vom Kunden und Nutzer des Cloud-Dienstes) für den Zugriff auf die - Daten autorisiert ist. In der OAuth-Terminologie handelt es sich beim Kunden um den Resource Owner, der den Auditor ( Client ) mit der Bearbeitung seiner -Daten ( Ressource ) beauftragt. Die ging-komponente dient im OAuth-Protokoll als Resource Server und das HSM des Treuhänders als Authorization Server. Der Auditor erhält nun vom Treuhänder ein Berechtigungsobjekt ( Access Ticket ) und kann damit die -Daten des Kunden von der ging-komponente anfordern. Die ging-komponente des Cloud-Betreibers, der Auditor und der Treuhänder kommunizieren nach gegenseitiger Authentisierung schließlich über gesicherte SSL-Verbindungen. In den folgenden Schritten greifen wieder die Mechanismen des -Verfahrens: Der Auditor prüft anhand eines öffentlichen Zertifikats den Zeitstempel der -Datei und teilt dem HSM des Treuhänders die gewünschten -Einträge und die in den - Einträgen enthaltenen Zugriffsberechtigungen mit. Das HSM rekonstruiert aus den Startschlüsseln und den übermittelten Zugriffsrechten die individuellen Arbeitsschlüssel der -Einträge und sendet diese an den Auditor. Der Auditor kann nun mit den erhaltenen Schlüsseln die Prüfsummen verifizieren und die originären -Daten entschlüsseln und auswerten. Auf Basis der Auswertung kann der Auditor schließlich die Einhaltung der Prüfkriterien in einem Testat bestätigen. 4 Fazit Der vorliegende Artikel hat gezeigt, wie -Daten in einer potenziell unsicheren Umgebung so gesichert werden können, dass sie als Grundlage für die Sicherheitskontrollen bei Cloud- Betreibern herangezogen werden können. Das beschriebene Lösungskonzept ist dabei nicht nur für Bildungseinrichtungen, sondern auch für andere sensible Anwendungsbereiche wie Gesundheitswesen, Recht und Finanzen interessant. Eine sichere -Datenbasis könnte nicht nur der Erstellung von Testaten dienen, sondern auch für Zwecke der Forensik und des Monitoring eingesetzt werden. Ziel sollte es daher sein, gemäß der Common Criteria 6 ein Schutzprofil für ging-komponenten zu entwickeln. Ein Cloud-Betreiber, bei dem eine entsprechend zertifizierte ging-komponente installiert ist, könnte mit automatisiert auditierbaren Cloud-Diensten werben. So wären Online-Marktplätze denkbar, auf denen zertifizierte und auditierbare Cloud-Dienste angeboten werden. Die Auswertung der gesicherten -Daten ermöglicht Auskünfte über die tatsächlichen Abläufe, die beim Cloud-Betreiber stattgefunden haben. Die automatisierten und kontinuierlich durchführbaren Kontrollen ermöglichen es dem Auditor, nicht nur den aktuellen Stand der Umsetzung technischer Maßnahmen beim Cloud-Betreiber zu kontrollieren, sondern zusätzlich zu überprüfen, wie die Maßnahmen in der Vergangenheit tatsächlich umgesetzt wurden. Die automatisiert auswertbare kundenspezifische Policy der des Kunden ermöglicht zudem, diese Kontrollen gezielt für eine kundenspezifische durchzuführen. Bei Bedarf könnte der Kunde selbst stichprobenartig oder kontinuierlich automatisierte Kontrollen für seine durchführen. Bei der Auswertung der -Daten besteht die Herausforderung zum einen darin, mit einer Vielzahl von unterschiedlichen -Formaten umzugehen und zum anderen, -Einträge aus unterschiedlichen Quellen miteinander zu verknüpfen. Beispielweise müssen die Protokolleinträge von Authentisierungsservern mit den -Einträgen von administrativen Handlungen verknüpft und überprüft werden. Zukünftige Forschungsarbeiten sollten zudem die Definition von Metriken für den Grad der Erfüllung von Prüfkriterien (Policy) in Cloud-Anwendungen umfassen, um beispielsweise die Ergebnisse einer solchen -Auswertung vergleichbar zu machen. Literatur [1] Bellare, M. und Yee, B. S.: Forward Integrity for Secure Audit s, University of California at San Diego, [2] European Network and Information Security Agency (ENISA): Critical Cloud Computing - A CIIP perspective on cloud computing services, Version 1.0, Dezember [3] Merkle, R.: Protocols for Public Key Cryptosystems, Proceedings of the 1980 IEEE Symposium on Security and Privacy, Oakland, USA, April [4] Schneier, B. und Kelsey, J.: Secure audit logs to support computer forensics, ACM Transactions on Information and System Security (TISSEC) 1999, Band 2, S , ACM New York, USA, [5] Selzer, A.: Die Kontrollpflicht nach 11 Abs. 2 Satz 4 BDSG im Zeitalter des Cloud Computing, DuD 04/ z. B. das CloudHSM von Amazon Web Services, siehe com/cloudhsm 6 Common Criteria: DuD Datenschutz und Datensicherheit