Foto: Computacenter
Die technologischen Security-Ansätze im Cloud Computing ähneln denen herkömmlicher Infrastrukturen. Änderungen sind jedoch aufgrund der Cloud-Architektur, des Betriebsmodells und der daraus resultierenden, immanenten Besonderheiten notwendig, um ein angemessenes Schutzniveau etablieren und aufrechterhalten zu können. Die eigentliche Schwierigkeit besteht daher vor allem darin, das Cloud-Konzept mit den diversen Compliance-Anforderungen in Einklang zu bringen.
Bei einer Analyse der Gefährdungen im Cloud-Computing fällt auf, dass diese zu vergleichbaren Ergebnissen wie eine Analyse traditioneller Rechenzentren führt. Einen guten Überblick gibt das Cloud Computing Risk Assessment der European Network and Information Security Agency. Die Risiken lassen sich auf die klassischen Schutzziele Vertraulichkeit, Verfügbarkeit und Integrität zurückführen: Integritätsverletzungen der Informationen, nicht autorisierte Datenzugriffe oder Einschränkungen der Verfügbarkeit etwa durch Viren sowie Fehlfunktionen dienstrelevanter Komponenten.
Aus rein technologischer Sicht bietet Cloud-Security nichts wesentlich Neues. Komplex wird Cloud-Computing erst dadurch, dass oft nicht eindeutig definiert ist, bis zu welcher Ebene der Cloud-Infrastruktur der Provider, und ab welcher Ebene der Kunde verantwortlich ist. Hinzu kommen weitere ungeklärte Fragen: Welchen Schutz kann der Kunde vom Provider verlangen? Welche Schutzmechanismen bietet der Provider für seine Dienste? Wie ist die technische und organisatorische Security-Schnittstelle zwischen Provider und Kunde definiert?
Sicherheitsanforderungen für Provider
Kunden sollten vom Provider ein etabliertes Sicherheits-Management, eine angepasste Sicherheitsarchitektur, ein funktionierendes Notfall-Management und Angaben zu seiner Mitarbeitersicherheit erwarten können. Auf der anderen Seite sind Provider gut beraten, diese Informationen offensiv zu publizieren, um sich gegenüber dem Wettbewerb positiv zu differenzieren. Die Realität sieht jedoch häufig anders aus: Viele Provider glänzen in diesen Bereichen durch Intransparenz und mangelndes Verständnis für die Sicherheitsbelange ihrer Kunden. Die AGBs der Provider enthalten keine expliziten Service Level Agreements (SLAs) und keine Aussagen zur Sicherheit, auf die sich Kunden berufen oder auf denen sie mit der eigenen Security-Strategie aufsetzen können. Im Gegenteil, oft wird in den AGBs ausdrücklich darauf hingewiesen, dass der Dienst keine garantierte Verfügbarkeit bietet. Aussagen zur Verfügbarkeit oder der Security der Cloud-Dienste und ihrer zugrundeliegenden Infrastruktur finden sich nur in Produkt-Datenblättern und Whitepapers, die aber nicht Vertragsbestandteil sind. In diesem Punkt unterscheidet sich Cloud-Computing signifikant vom klassischen Outsourcing, bei dem Auftraggeber und Auftragnehmer im Due-Diligence-Prozess Parameter mit bindendem Charakter für SLAs und Security aushandeln können.
Kritische Stimmen zum Cloud Computing argumentieren oft mit einem zwangsläufigen Kontrollverlust bei der Verlagerung von Informationen oder Diensten in eine fremdbetriebene Cloud. Diesem Argument liegt die Fehlannahme zugrunde, dass Unternehmen heutzutage überhaupt noch die Kontrolle über ihre IT haben. Tatsächlich zeigt die Erfahrung, dass kaum ein Unternehmern weiß, welche Applikationen es tatsächlich nutzt, wie kritisch diese sind oder welche Informationen wo verarbeitet und gespeichert sind. Die Dispersion der Daten in den Unternehmen, die Webifizierung der internen Applikations-Landschaft und die ubiquitäre Verfügbarkeit großer und günstiger Speicher haben über die Jahre zu einem schleichenden Kontrollverlust über die Informationen und Applikationslandschaft geführt. Dazu trägt auch das wieder in Mode gekommene Bring your own Device bei. Das Modell fordert explizit, dass Mitarbeiter auf ihrer privaten, eventuell subventionierten, Hardware im Unternehmen arbeiten können. Vor diesem Hintergrund kann der Schritt in die Cloud zum Anlass genommen werden, die Kontrolle zumindest in Teilen zurückzugewinnen.
Bekanntschaft mit der eigenen IT schließen
Bevor eine effiziente Security-Strategie von einem Provider eingefordert wird, sollten Cloud-interessierte Unternehmen vor der eigenen Haustür kehren. Sie müssen sich einen Überblick über die eigenen Daten und Anwendungen, deren Verteilung im Unternehmen, den Compliance- und Schutzanforderungen verschaffen. Data Discovery und Klassifizierung von Daten unter Storage- und Sicherheitsaspekten können Methoden sein, die, systematisch und umfassend umgesetzt, den notwendigen Überblick verschaffen. Aus den gewonnenen Erkenntnissen lässt sich ableiten, welche Daten oder Applikationen unter welchen Voraussetzungen Public-Cloud-tauglich sind, und welche innerhalb der eigenen Umgebung bleiben sollten.
Ein weiterer wichtiger Aspekt der Sicherheit von Cloud-Diensten ist das Identity & Access Management sowohl in Bezug auf den Kunden als auch auf den Anbieter. Der Provider sollte seinen Kunden transparent darstellen können, welche Mitarbeiterrolle welche Zugriffsmöglichkeiten hat, und welche Maßnahmen gegen unberechtigten Zugriff der Provider-Mitarbeiter eingesetzt werden. Aus Kundensicht ist eine Integration der Cloud-Dienste in das unternehmenseigene Benutzerverzeichnis wünschenswert, um zentral steuern zu können, welche Nutzer welche Zugriffsrechte auf welche Applikationen haben. Das User-Lifecycle-Management wird durch die Verlagerung von Unternehmensapplikationen in öffentlich erreichbare Infrastrukturen noch wichtiger, da ein Benutzer nach Ausscheiden aus dem Unternehmen weiterhin Zugriff auf die öffentlich bereitgestellten Applikationen und Daten hat, bis ihm die Berechtigungen explizit entzogen werden.
An dieser Stelle setzen auch aktuelle Enterprise-Rights-Management (ERM)-Werkzeuge an. Sie schützen die eigentlichen Daten und zwar unabhängig vom Speicherort, dem zugrundeliegenden Dateisystem, der verarbeitenden Applikation oder dem Transportweg. Dazu werden die Informationen in eine Art Schutzhülle verpackt, die den Zugriff auf den Inhalt erst nach erfolgreicher Authentifizierung und Autorisierung gegen das unternehmenseigene Benutzerverzeichnis ermöglicht. Auch die Art des Zugriffsrechts kann detailliert definiert werden, sodass das Drucken, Speichern oder Verändern der Dateien unmöglich ist. Diese Einschränkungen können auch nachträglich definiert werden, das heißt, die initiale zentrale Berechtigung kann jederzeit geändert oder widerrufen werden. Bei jeder Anfrage werden die aktuell gültigen Berechtigungen abgefragt und umgesetzt. So kann ausgeschiedenen Mitarbeitern der Zugang zu Datenkopien verwehrt werden um Datenabfluss zu minimieren.
Letztendlich sollte das Ziel eine ubiquitäre, informationszentrierte und standardisierte Verschlüsselung aller Informationen sein. Ob es erreicht wird, hängt entscheidend von der Kooperation der Security-Hersteller ab. Nach heutigem Verständnis ist ERM integraler Bestandteil der jeweiligen Anwendung oder Anwendungsgruppe, etwa MS Office 2010 in Verbindung mit Sharepoint 2010 und einem Windows 2008 ActiveDirectory. Beim Cloud-Computing sind klassische Dokumente in Dateiform aber nur einer von vielen Informationsträgern. Um Informationen nach dem ERM-Prinzip auch in Cloud-Umgebungen verschlüsseln zu können, muss der Informationsbegriff massiv erweitert werden zum Beispiel auf Festplattenimages in Amazons EC2-Infrastruktur oder auf Datensätze in Salesforce.com-Formularen.
Compliance-Fragen für Public Clouds noch offen
Besonderes Augenmerk ist auf die nachweisliche Einhaltung spezifischer Compliance-Anforderungen in Public-Cloud-Diensten zu legen. Werden Compliance-relevante Informationen in die Infrastruktur eines externen Anbieters verlagert, übernimmt dieser bislang nur die Betriebsverantwortung für die Dienste. Der Kunde trägt die Kontrollverantwortung, die üblicherweise eine Auditpflicht mit sich bringt. Der Kunde muss den Provider entsprechend den Vorgaben der jeweiligen Compliance-Regel auditieren. Aktuell gelten für Cloud-Dienste die gleichen Compliance-Anforderungen wie für konventionelle Infrastrukturen. Das Bundesdatenschutzgesetz, das Aktiengesetz oder KonTraG (Gesetz zur Kontrolle und Transparenz im Unternehmensbereich) differenzieren nicht zwischen Cloud- und Nicht-Cloud-Betrieb. Die Herausforderung liegt darin, die geltenden Compliance-Vorgaben nachweislich umzusetzen. Solange der Provider den Nachweis nicht erbringt, ist der Kunde in der Pflicht. Allerdings ist die Wahrnehmung dieser Pflicht oft nicht praktikabel oder realisierbar.
Am Beispiel von internationalen Public-Cloud-Anbietern wie Google oder Amazon wird die Problematik besonders deutlich. Sie bedienen Kunden in der ganzen Welt und jedes Land hat eigene Compliance-Richtlinien, die von Branche zu Branche variieren können. Wie soll ein Cloud-Provider mit hundertausenden von Kunden die Fülle an Audits umsetzen, die oft die Beantwortung umfangreicher Fragebögen, Interviews und Ortsbegehungen beinhalten, ohne die Kosten für die Dienste massiv anzupassen? Letztendlich ist dies nur möglich, indem Cloud-Provider automatische Audit-Schnittstellen für Kunden in ihre Services integrieren und ihre Sicherheitsprozesse offenlegen.
Die Arbeitsgruppe CloudAudit/A6 in der sich viele namhafte Anbieter engagieren, entwickelt derzeit eine solche automatische Audit-Schnittstelle. Neben den Cloud-Anbietern sind jedoch auch die Gesetzgeber gefordert, die aktuelle Rechtslage der technologischen Entwicklung anzupassen. In einem Zeitalter des globalen, freien Informations- und Warenfluss stellen nationale Regulierungen per se einen unpassenden Ansatz dar, auch wenn deren Inhalte, wie in der aktuellen Fassung des Bundesdatenschutzgesetzes (BDSG), durchaus begrüßenswert sind. Demnach sollten Unternehmen derzeit personenbezogene Daten nur an nationale Cloud-Provider auslagern oder sicher stellen, dass sie die Einhaltung der Anforderungen des BDSG zweifelsfrei nachweisen können. Als Pionierdaten für erste Erfahrungen mit Cloud-Services eignen sich also zunächst nur nicht-Compliance-relevante Daten. Das können alle Informationen sein, die ein Unternehmen auch intern bereits seinen Mitarbeitern ohne Zugriffsbeschränkungen zur Verfügung stellt. (ph)