Cloud Computing wirft ein neues Licht auf bekannte Themen. Ein zentraler Aspekt ist die IT-Sicherheit. Das gilt gerade für allgemein zugängliche Public Clouds, deren Anbieter oft sehr einfache Verfahren für den Vertragsabschluss und die Leistungserbringung einschließlich der Migration von Daten in die Cloud vorsehen. Dadurch sinken die Sicherheitsbedürfnisse und -anforderungen der Kunden allerdings nicht. Schon der Schutz personenbezogener Daten in der Cloud verlangt angemessene technische und organisatorische Maßnahmen auch für die IT-Sicherheit (Paragraf 9 Bundesdatenschutzgesetz).
Compliance-Anforderungen des Kunden und gesetzliche Regelungen für spezifische Daten setzen zusätzliche Kriterien für die IT-Sicherheit. Die Umsetzung erfordert nicht nur die Analyse und Bewertung der Sicherheitsmaßnahmen des Providers durch den Kunden. Notwendige Maßnahmen sind vor Beginn der Nutzung der Cloud-Lösung zu vereinbaren und zu realisieren.
Dieser Artikel beschäftigt sich mit der Auslagerung von kritischen Funktionen (Applikationen, Plattformen, Infrastruktur) in eine Public Cloud oder Hybrid Cloud (mit Public Cloud-Anteil). Die Auslagerung in allgemein zugängliche Public-Cloud-Ressourcen weist eine typische Besonderheit auf: Die Provider und die "Standorte" einer Public Cloud sind anonym über die Welt verteilt. Gerade diese Besonderheit führt aber zu neuen Risiken.
Bei der Auslagerung sensitiver Daten ist eine fest definierte Vorgehensweise notwendig. Insoweit wird das "klassische" Paradigma der Public Cloud verlassen, was zu höheren Kosten für die Auslagerung von Funktionen führen kann.
Die zehn größten Security-Risiken in der Cloud
Allgemein sind folgende Risiken beim Einsatz von Leistungen aus einer Public oder Hybrid Cloud zu beachten:
-
Verletzung der Vertraulichkeit und Integrität der Daten: Eine Lokalisierung der Daten ist in einer Public oder Hybrid Cloud für den Dateneigentümer nicht mehr so leicht möglich. Daher ist der Schutz der Daten auf der Infrastruktur-, Plattform und Applikationsebene häufig nicht mehr mit üblichen Mitteln zu gewährleisten. Gerade für sensitive Daten kann eine ausreichende Zugriffskontrolle nur schwer realisiert werden. Auch die Infrastruktur der Cloud selbst kann angegriffen oder missbraucht werden.
-
Löschung von Daten: Daten müssen in vielen Fällen (etwa aufgrund gesetzlicher Bestimmungen) gelöscht werden. Auch hier besteht das Risiko einer nur unzureichenden oder unvollständigen Löschung auf allen Plattformen und Datenbanken der Cloud, da die Lokalisierung der Daten nur schwer möglich ist. Auch nach Beendigung des Auftrags müssen die verarbeiteten Daten und alle Zwischenergebnisse in der Public Cloud gelöscht werden.
-
Ungenügende Mandantentrennung: Bei nicht ausreichend abgesicherter Mandantentrennung besteht die Gefahr, dass Dritte unautorisiert Daten einsehen oder manipulieren können. Dieses Risiko ist in einer Public Cloud erhöht, da durch Virtualisierung und Grid Computing keine physikalische Trennung der Daten unterschiedlicher Mandanten erfolgt.
-
Verletzung der Compliance: Da Daten in einer Public Cloud prinzipiell in allen Ländern der Welt in deren spezifischen Rechtsordnungen verarbeitet werden können, ist die Erfüllung aller gesetzlicher Anforderungen eine wesentliche Aufgabe bei der Nutzung von Public-Cloud-Leistungen.
-
Verletzung von Datenschutzgesetzen: Es ist nicht von vornherein klar, in welchen Ländern, Rechenzentren, auf welchen Servern und mit welcher Software die Daten gespeichert und verarbeitet werden. Auch sind die Datenflüsse unbekannt. Es besteht dadurch die Gefahr der Verletzung von Datenschutzvorschriften.
-
Insolvenz des Providers: Die Insolvenz eines Providers bedeutet meist nicht die Insolvenz aller Rechenzentren, die der Provider verwendet hat. Rechenzentren werden zudem bei Insolvenz mit großer Wahrscheinlichkeit an andere Provider verkauft werden. In allen diesen Fällen besteht das Risiko, dass Daten nicht vor unberechtigtem Zugriff geschützt sind.
-
Problematik der Subunternehmer: Ein weiteres Problem stellt die Auftragsweitergabe an Subunternehmer dar. Der Provider wird häufig Subunternehmer für bestimmte Leistungen verpflichten. In einer Public Cloud bleibt auch diese Komplexität dem Benutzer häufig verborgen (und soll ja nach der Philosophie des Cloud Computing verborgen bleiben). Daten können sich dann auf Computing-Ressourcen eines unbekannten Subunternehmers irgendwo in der Welt befinden.
-
Beschlagnahmung von Hardware: Eine Beschlagnahme von Hardware kann in allen Ländern erfolgen, in denen der Provider Computing-Ressourcen nutzt. Meist werden sich Daten des Auftraggebers auf beschlagnahmten Servern befinden. Logdaten auf Servern und Routern können Rückschlüsse auf die Geschäftstätigkeit des Kunden auch dann ermöglichen, wenn keine sonstigen Geschäftsdaten vorliegen.
-
Handel mit Ressourcen wird denkbar: Denkbar ist auch, dass Provider einen Handel mit ihren Ressourcen untereinander aufbauen und damit eine "Ressourcenbörse" realisieren. Auf dieser Börse werden Ressourcen zu einem bestimmten Preis angeboten. In Leistungsspitzen würde etwa der Preis pro CPU-Stunde auf der Börse höher gehandelt. Welche Konsequenzen dies für die Sicherheit der Daten haben kann, ist noch vollkommen unklar.
-
Erpressungsversuche: Die Gefahr von Erpressungsversuchen steigt, da der Personenkreis mit Administrationsaufgaben für Ressourcen der Public Cloud unüberschaubar groß ist. Das eingesetzte Personal verfügt im Allgemeinen über unterschiedliches Ausbildungsniveau und Sicherheitsbewusstsein. Auch sind die Motivationslagen der Mitarbeiter in vielen Ländern nicht kalkulierbar.
Auslagern in die Public Cloud: So sollten Sie vorgehen
Jedes Unternehmen, das den Einsatz von Leistungen einer Public Cloud plant, sollte zunächst über eine Strategie für Outsourcing-Vorhaben nachdenken. Die Outsourcing-Strategie stellt dar, wie ein Outsourcing-Vorhaben in die gesamte Strategie (insbesondere auch in die Risikostrategie) des Unternehmens zu integrieren ist. Dazu gehören Aspekte wie generelle Zielvorgaben, Etablierung eines Outsourcing-Managements mit Organisationsstrukturen und definierten Verantwortlichkeiten, die Festlegung akzeptabler Risiken und die Entwicklung von Fallback-Strategien.
Insbesondere muss geklärt werden, welche Funktionen nicht in eine Public Cloud ausgelagert werden dürfen, etwa wegen gesetzlicher Anforderungen, zu hoher Risiken oder aus anderen Gründen. Weiter ist das Outsourcing-Management in das Managementsystem des Unternehmens zu integrieren. Als weitere Mindestanforderung darf keine Auslagerung einer Funktion in eine Public Cloud ohne Sicherheitskonzepte, SLAs und Verträge mit definierten, messbaren Leistungen realisiert werden. Wesentlich ist die Implementierung eines Outsourcing-Prozesses, der gemäß Abbildung 1 näher erläutert wird.
1. Planungsphase
Zunächst sind verschiedene Alternativen für das Cloud Computing auf grober Ebene zu entwickeln und einer ersten "Sicherheitsanalyse" zu unterziehen. Unterscheidungsmerkmale der Alternativen sind unter anderem die Lokalitäten der Rechenzentren, Möglichkeiten zur Beschränkung der Public Cloud auf bestimmte Regionen, Kontrollmöglichkeiten für den Datenfluss und die angebotenen Serviceebenen (Software-as-a-Service, Platform-as-a-Service oder Infrastructure-as-a-Service). Die Alternativen für die Auslagerung in die Public Cloud werden einer Sicherheits- und Risikoanalyse unterzogen. Zudem wird ermittelt, welche gesetzlichen (insbesondere des Datenschutzes) und organisatorischen Anforderungen für die verschiedenen Alternativen gelten. Aus all diesen Informationen werden die zu erfüllenden "Sicherheitsanforderungen" abgeleitet.
Danach wird entschieden, welche Alternativen in die engere Auswahl kommen oder überhaupt in Betracht gezogen werden können. Für diese Alternativen wird ein Leistungskatalog erstellt, der detailliert die Auslagerung und alle geforderten Leistungen inklusive aller Sicherheitsanforderungen beschreibt. Die Angebote der Provider können anhand dieses Leistungskataloges bewertet werden. Insbesondere können Defizite von Providern identifiziert werden, die zuvor noch nicht in die Sicherheitsanalyse einfließen konnten. Zusätzlich kann eine Due-Diligence-Prüfung des Providers durchgeführt werden. Danach fällt die Entscheidung für eine Alternative und für einen Provider.
2. Vertragsphase
Im Schritt "Vertragsgestaltung" wird ein Vertrag ausgearbeitet. Ziel ist es, in Verträgen und/oder Service Level Agreements (SLA) eine vollständige und kontrollierbare Leistungsbeschreibung zur Gewährleistung der Qualität und Informationssicherheit in der Public Cloud zu vereinbaren. Besondere Aufmerksamkeit bei der Vertragsgestaltung erfordern unter anderen folgende Punkte:
-
Einräumung von Auditrechten: Im Allgemeinen wird der Provider seinen Kunden keine Audit-Rechte für seine Rechenzentren einräumen wollen und können. Dies wäre für den Provider einerseits viel zu aufwendig, andererseits würde das Sicherheitsniveau sinken, wenn viele Fremd-Auditoren der Kunden die Rechenzentren inspizieren würden. Deshalb ist es sinnvoll, sich Audit-Rechte für Dokumente, Beschreibungen und Protokolle einräumen zu lassen, um etwa den korrekten Ablauf von Prozessen nachvollziehen zu können. Zudem können Zertifizierungen gefordert werden, die einen Mindeststandard für Informationssicherheit gewährleisten (zum Beispiel die Zertifizierung nach ISO 27001).
-
Kennzahlen: Gerade die Definition messbarer Kennzahlen für Vertraulichkeit und Integrität als Schutzziele ist keine einfache Aufgabe. Für Verfügbarkeit und Performance werden bereits sinnvolle Kennzahlen durch die Provider angegeben.
-
Schnittstellendefinition: Besonders wichtig für den korrekten Betrieb der ausgelagerten Funktion sind Schnittstellen für Security Monitoring und Incident Handling. Hier müssen Prozesse mit klaren Verantwortlichkeiten, Eskalationsstufen und Kommunikationswegen zwischen Kunde und Provider definiert werden.
-
Regelungen für die Beendigung der Cloud-Leistungen: Auch Vereinbarungen für die Beendigung der Leistungen der Public Cloud sind zu treffen. Insbesondere muss geregelt werden, welche Daten wie zu übergeben sind und welche Daten nicht mehr wiederherstellbar gelöscht werden.
3. Migration
Nach Vertragsabschluss beginnt die Migration, also die schrittweise und geplante Auslagerung der Funktion. Zur Planung gehört die Erstellung von Sicherheitskonzepten, die sowohl die Migration als auch den Betrieb und die Beendigung der Auslagerung beinhalten. Als Basis für ihre Erstellung dienen die Ergebnisse der Risikoanalyse und des Auswahlverfahrens der Planungsphase. Die Umsetzung und das Testen der Auslagerung in die Cloud erfolgen nach den erstellten Sicherheitskonzepten.
4. Betriebsphase
Während der Betriebsphase werden die ausgelagerten Funktionen gemäß Vertrag und Sicherheitskonzepten durch den Provider betrieben. Wichtig ist jetzt ein funktionierendes Security Monitoring, um Abweichungen vom erforderlichen Sicherheitsniveau schnell erkennen zu können. Das Security Monitoring dient auch dazu, die Erfüllung der vertraglich vereinbarten Leistungen nachweisen, kontinuierlich verbessern und überprüfen zu können.
5. Beendigung der Auslagerung
Mit diesem Arbeitsschritt wird eine geregelte Beendigung der Cloud-Leistungen durchgeführt. Auch dies muss nach den vertraglich vereinbarten Regelungen erfolgen. Der Provider muss insbesondere Daten auf seinen Systemen nachweisbar so löschen, dass sie auch mit ausgefeilten Methoden und Technologien nicht wiederherstellbar sind. Hierzu zählen nicht nur Daten des Geschäftsprozesses, sondern auch betriebliche Daten wie Protokolldaten von Systemen und Applikationen.
Diese Sicherheitsmaßnahmen sollten Sie treffen
Über folgende generelle Sicherheitsmaßnahmen müssen Unternehmen bei Leistungen aus einer Public oder Hybrid Cloud nachdenken:
1. Prozesse
Der Provider muss über definierte und dokumentierte Prozesse (zum Beispiel Benutzer- und Rechtemanagement, Change Management, Incident Handling oder Problem Management) verfügen, deren Schnittstellen zu den entsprechenden Prozessen des Kunden nach den Sicherheitskonzepten der Migrationsphase getestet wurden. Alle technischen Schnittstellen zum Provider müssen die Architektur- und Sicherheitsanforderungen des Kunden erfüllen. Beispiele für diesen Bereich: Es dürfen nur durch den Kunden autorisierte Änderungen durchgeführt werden; Eskalations- und Kritikalitätsstufen sowie Reaktionszeiten des Kunden für Störungen müssen beim Incident Handling eingehalten werden. Weiter weist der Provider über die regelmäßige Auswertung von Kennzahlen nach, dass die Prozesse mit einem vereinbarten Reifegrad eingehalten werden.
2. Business Continuity
Der Provider muss durch Zertifizierung und Protokolldaten nachweisen, dass er ein angemessenes Notfallmanagement aufgebaut hat und betreibt. Gemeinsam mit dem Kunden entwickelt der Provider geeignete Notfall- und Recovery-Pläne, die etwa Teil der Sicherheitskonzepte aus der Migrationsphase sind. Nach diesen Plänen erfolgen regelmäßige Übungen, die auch Tests für das Zusammenspiel zwischen Kunde und Provider einbeziehen.
3. Technik
Alle Kommunikationsverbindungen, über die sensitive Daten übertragen werden, sind mit State-of-the-Art-Technologien zu verschlüsseln - auch in den Cloud-Rechenzentren. Bei hohen Anforderungen an die Vertraulichkeit sind Daten auch in verschlüsselter Form zu speichern.
Die Authentifizierung von Benutzern und Administratoren muss angemessen abgesichert werden. Bei hohen Zugriffsrechten sollte mindestens eine Zwei-Faktor-Authentifizierung (zum Beispiel durch Wissen und Besitz, Passwort und Token) erfolgen. Fernwartungszugriffe erfolgen nur nach ausreichender Authentifizierung über verschlüsselte Kommunikationsverbindungen. Weiter ist ein Monitoring zu implementieren, das es erlaubt, Störungen und Sicherheitsvorfällen frühzeitig zu erkennen.
Fazit: IT-Sicherheit und Cloud sind kein Widerspruch
Auch wenn die Anforderungen und das Vorgehen für die IT-Sicherheit zunächst als Widerspruch zum Paradigma des "klassischen" Public und Hybrid Cloud Computings erscheinen mögen: Es liegt bereits im eigenen Interesse der Provider, Sicherheitsmaßnahmen zu implementieren, die das Niveau vieler Anwender deutlich übertreffen. Kunden können diese Maßnahmen für ihr eigenes Sicherheitskonzept nutzen, wenn sie entsprechende Maßgaben zuvor im Cloud-Computing-Vertrag vereinbaren. (hal)
Dieser Artikel basiert auf einem Beitrag unserer Schwesterpublikation Computerwoche .