10 sicherheitsrelevante Gründe gegen Cloud Computing

10 sicherheitsrelevante Gründe gegen Cloud Computing

Marc Ruef
von Marc Ruef
Lesezeit: 7 Minuten

Im Zuge der anhaltenden Virtualisierung der letzten 10 Jahre bekam ein artverwandtes – aber nicht zwingend neues – Thema immer mehr Aufmerksamkeit: Cloud Computing. Forrester Research fasst das Prinzip dieses Konzepts (es handelt sich nicht um eine Software oder ein Produkt als solches) wie folgt zusammen (Inquiry Spotlight: Cloud Computing, Q2 2009):

Cloud Computing steht für einen Pool aus abstrahierter, hochskalierbarer und verwalteter IT-Infrastruktur, die Kundenanwendungen vorhält und falls erforderlich nach Gebrauch abgerechnet werden kann.

Modularität ist ein wichtiger Aspekt von Cloud Computing. Denn nur dadurch kann die transparente Abstrahierung und dynamische Skalierbarkeit – die mittlerweile auch von Botnet-Betreibern und Crackern entdeckt wurde – erlangt werden. Im Rahmen von Cloud Computing werden jedoch grundlegende Risiken aufgetan, die im Zuge wirtschaftlicher Aspekte gerne abgewiegelt oder gänzlich ignoriert werden:

  1. Fehlende Transparenz: Durch die Abstrahierung wird es für einen Kunden nicht mehr möglich zu erkennen, wo sich seine Daten genau befinden und wie mit diesen umgegangen wird. Branchenspezifische Anforderungen an Sicherheitsüberprüfungen werden nur sehr schwer umsetzbar. Damit wird die Grundlage für alle weiter genannten Probleme geschaffen. Dieser Aspekt wird massgeblich dem bis dato umfangreichsten Kreditkartenrückruf angelastet.
  2. Vermengung von Kunden/Diensten/Daten: Durch das Teilen von Ressourcen findet eine Vermengung von Kunden, Diensten und Daten statt, wodurch ungleich klassifizierte Assets in gleicher Weise behandelt werden. Verliert ein Asset seine Integrität, kann sich dies unmittelbar auf die anderen Assets auswirken. Beteuerungen eines Anbieters, einen sicheren und geschützten Umgang der Daten durchzusetzen, können oftmals auf Grund der fehlenden Transparenz nicht verifiziert werden.
  3. Verlust der Kontrolle über Daten/Prozesse: Die fehlende Transparenz und das Teilen der Ressourcen führen dazu, dass ein Verlust über die Nutzdaten und Aktivitäten stattfindet. Ein Anbieter könnte diese unerlaubt selbst weiterverwenden oder an einen Mitbewerber oder eine Behörde weiterreichen. Dies ist das zentrale Argument, welches Whitfield Diffie in einem Interview mit Technology Review anführt.
  4. Abhängigkeit vom Anbieter: Man ist in direkter Weise vom Angebot und der Qualität des Dienstleisters abhängig. Ausfälle des Dienstes können sich als sofortige Einbusse der Produktivität auswirken (siehe den Datenverlust des Sidekick-Dienstes im Oktober 2009; heise online, fefe).
  5. Schwierigkeit von Backups: Das Erstellen von Backups könnte massgeblich erschwert sein. Nur mit erheblichem Aufwand lassen sich diese selbstständig umsetzen. Will man diesen nicht in Kauf nehmen, ist man bezüglich derer erneut vom Anbieter abhängig. Die kompetente Umsetzung dieses Prozesses sowie unter Einhaltung branchen-/unternehmensspezifischer Vorhaben lässt sich oftmals nur schwer durchsetzen.
  6. Schwierigkeit bei Migration: Durch komplexe Abhängigkeiten und Inkompatibilitäten kann ein Wechsel zu einem anderen Anbieter nur mit sehr viel Aufwand möglich sein. Die Abhängigkeit zum Partner führt eine ständige Trägheit mit sich. Bei Differenzen in der Zusammenarbeit ist man lange Zeit der Willkür des Partners unterworfen.
  7. Juristische Konflikte bezüglich Datenschutz: Es ist denkbar, dass sich eine Cloud über verschiedene Länder erstreckt. Diese können ihrerseits unterschiedliche Rechtsgrundlagen aufweisen. Durch ein dynamisches Verteilen eines Dienstes ins Ausland können juristische Probleme auftreten (z.B. bei Exportverbot oder bezüglich Datenschutz). Amazon versucht diesem Problem auf technischer Ebene mit den Availability Zones und Finjan mit Vital Cloud Herr zu werden.
  8. Juristische Eigenverantwortung: Ein Unternehmen kann sich durch das Auslagern von Daten und Prozessen nicht gänzlich von der Eigenverantwortung lossprechen. Selbst eine strukturierte Evaluation und Prüfung des Partners sowie eine solide vertragliche Vereinbarung lassen ein derartiges Abtreten von Verantwortung nicht zu.
  9. Einbusse bei Knowhow: Das Auslagern von Prozessen und Technologien wird meist umgesetzt, um bezüglich internen Ressourcen eine Kostenersparnis zu erreichen. Der Abbau von ausgebildetem Personal hat längerfristig die Einbusse von Knowhow und Kompetenzen zur Folge. Im schlimmsten Fall ist bei Verhandlungen und Problemen nicht einmal mehr jemand intern anwesend, der dem Sachverhalt ansatzweise ein Verständnis entgegenbringen kann. Ein etwaiges Insourcing gestaltet sich dann als Neuaufbau einer gesamten Abteilung (inkl. Personal, Prozesse, Strukturen).
  10. Zentraler Angriffspunkt: Obschon Cloud Computing als Distributed Computing verstanden wird, wird damit ein zentraler Angriffspunkt geschaffen. Je mehr Mechanismen in eine spezifische Cloud ausgelagert werden, desto fokussierter kann sich ein Angreifer eben diesem Konstrukt annehmen. Eine Kompromittierung der Cloud hat theoretisch die Kompromittierung sämtlicher ausgelagerter Mechanismen zur Folge.

Cloud Computing kombiniert die unliebsamen Risiken von Virtualisierung und Outsourcing. Von der pauschalen Nutzung von Cloud Computing ist deshalb in Umgebungen mit hohen Ansprüchen an die Sicherheit abzusehen. Zu gross sind die Risiken, die sich bisweilen nur sehr schwer ausmachen und eliminieren lassen. Hilfestellung bei einer entsprechenden Risikokalkulation gewährt die umfangreiche aber auch nicht unumstrittene ENISA-Studie. Und mögliche Ansätze für ein sicheres Cloud Computing werden von RSA zusammengefasst.

Update 28. Dezember 2009

Marcus Ranum von Tenable Network Security hat in seinem Blog-Post Ranum’s Rants: Cloud Forum Roundtable einige äusserst zutreffende und damit lesenswerte Bemerkungen zur Entwicklung von Cloud Computing gemacht.

Update 18. Juni 2010

Anlässlich unseres Vortrags am ISMS Praxis Forum zum Thema Cloud Security werden auf der Basis dieses Beitrags die Präsentationsfolien hier bereitgestellt.

Über den Autor

Marc Ruef

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

Herausforderung Datenschutz-Grundverordnung DSGVO?

Unsere Spezialisten kontaktieren Sie gern!

×
Konkrete Kritik an CVSSv4

Konkrete Kritik an CVSSv4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentisierung

Voice Authentisierung

Marc Ruef

Bug-Bounty

Bug-Bounty

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv