Munscheidstr. 14 in 45886 Gelsenkirchen

Jetzt anrufen 0209 - 8830 6760

Cloud Pentest: Eine Einführung in die Sicherheit von Cloud Computing

Dr. Matteo Große-Kampmann

Cloud Computing ist aktuell in aller Munde. Insbesondere die fortlaufend zunehmende Verbreitung von Home Office sorgt dafür, dass Cloud Dienste einen enormen Zulauf haben. Diese Umgebungen werden häufig hochgefahren und können genutzt werden. Doch wie steht es mit der Sicherheit? Kann ein Cloud Pentest helfen? Und was ist „die Cloud“ überhaupt?


Laden Sie jetzt unsere kostenfreien ISO 27001:2022 Vorlagen herunter

Über 40 Vorlagen die Sie für den Aufbau Ihres Informationssicherheitsmanagementsystems nutzen können.

Kostenfrei. Jetzt anfordern


Aktuelle Cloud Nutzung

Alleine Microsoft 365 musste im März seine Dienste einschränken aufgrund der zunehmenden Last auf den Servern. Bis zu 44 Millionen tägliche User verzeichnet die Microsoft Umgebung. Microsoft definiert Cloud als „die Bereitstellung von Rechnerleistungen über das Internet, basierend auf der Nutzung„.

Auch die erfolge Amazon Cloud (AWS) verzeichnet eine deutliche Zunahme an Nutzern und Last. Nicht zuletzt durch das vermehrte Streaming, verursacht durch Netflix und Amazon Prime. Amazon definiert die Cloud als „On-Demand Bereitstellung von IT Ressourcen mit einem nutzungsbasierten Abrechnungsverfahren“. Anhand dieser unterschiedlichen Definitionen ist erkennbar, dass es nicht die „eine Cloud“ gibt, sondern die Definition von Cloud ist auch abhängig vom Cloud Betreiber (meistens Microsoft, Google oder Amazon).

Amazon führte den Markt im Q4 2019 noch deutlich an mit 33%. Der nächste Verfolger ist dann mit 18% Microsoft Azure gefolgt von Google mit 8%. Weltweit wurde im Jahr 2019 mit Cloud Infrastruktur Dienstleistungen 96 Milliarden Dollar umgesetzt. Seit 2017 hat sich der Markt verdoppelt.

Der Cloud Markt steigt und damit auch der Bedarf an einem Cloud Pentest.
Der Markt der Clodugeschäfte wächst und wächst. Quelle: statista.com

Der größte konzeptionelle Unterschied besteht zwischen „Public“ und „Private“ Cloud Umgebungen, sowie „Infrastructure-„, „Platform-“ oder „Software as a Service“ als Service Modelle. Diese wollen wir im folgenden näher beschreiben.

Unabhängig von Konzepten ist innerhalb der veränderten Arbeitsumgebungen eine Sache jedoch klar: Unternehmen weltweit benötigen aktuell flexiblen Zugang zu Rechenkapazitäten und Infrastrukturen um Remote Work, kollaboratives Arbeiten und Online Handel zu ermöglichen. Cloud Infrastrukturen können dabei helfen, bergen aber auch Sicherheitsprobleme. Diese zu Entdecken ist Aufgabe eines Cloud Pentest.

Private und Public Cloud für den Cloud Pentest

Es gibt unterschiedliche Definitionen für „Private“ und „Public Cloud“ (z.B. vom Fraunhofer Institut). Die Private Cloud ist hierbei eine Cloud Infrastruktur, die ausschließlich für eigene Mitarbeiter zugänglich ist und entweder selbst betrieben wird oder exklusiv für eine spezifische Organisation bereitgestellt wird.

Typische Beispiele sind skalierbare IT Infrastrukturen oder wartungsfreie Anwendungen, die über einen Webbrowser in Anspruch genommen werden können. Die Public Cloud ist ein öffentliches Angebot eines frei zugänglichen Anbieters. Google Docs oder Microsoft 365 sind ein Beispiel für Public Cloud Angebote.

Um den Leser weiter zu verwirren und das Themenfeld noch komplexer zu machen gibt es zwei weitere vermischte Definitionen: „Hybride Cloud“ und „Virtual Private Cloud“ (VPC).

  • Eine VPC ist eine isolierte Umgebung einer öffentlichen Cloud die nur für eine bestimmte Organisation bereitsteht.
  • Eine hybride Cloud ist eine Zusammenstellung aus mindestens einer privaten und einer öffentlichen Cloudumgebung. Dies wird oft verwendet wenn Daten oder Applikationen geteilt werden sollen aber auf einer geschlossenen Grundarchitektur aufbauen.

Um einen Cloud Pentest durchzuführen muss klar sein, welche Art von Cloud verwendet wird und welches Service Modell.

Infrastruktur, Plattform oder Software?

Neben diesen unterschiedlichen, teilweise unklaren Definitionen für die Cloudtypen gibt es noch unterschiedliche Service Modelle. Die Service Modelle unterscheiden sich in Ihrer Zuständigkeit und Verantwortlichkeit für die einzelnen Komponenten. Im folgenden Bild sind die einzelnen Service Modelle dargestellt, sowie die Kontrolle über die einzelnen Komponenten.

Cloud Models

Eine Analogie für die zunehmende Einfachheit aber den Verlust der Kontrolle ist das Pizzabacken. Diese Analogie stammt aus einem LinkedIn Beitrag eines IBM Mitarbeiters. Wir haben vier unterschiedliche Möglichkeiten uns nach einem langen Arbeitstag mit einer Pizza zu belohnen. Diese vier Möglichkeiten entsprechen den vier Service Modellen:

  • In der On-Premise Pizza verwalten wir alles und haben die volle Kontrolle. Wir müssen Zutaten beschaffen, einen Esstisch stellen, den Ofen und sogar unsere eigenen Tomaten anbauen.
  • Bei unserer Infrastructure Pizza sind wir bereits bei der Tiefkühlpizza. Wir müssen nur die Pizza kaufen, den Ofen anheizen und uns an den Tisch setzen.
  • Unsere Platform Pizza wird uns nach Hause geliefert. Wir haben keine Kontrolle über den kompletten unterliegenden Prozess, können nur noch entscheiden ob wir die Pizza am Esstisch oder auf dem Sofa essen.
  • Die Software Pizza ist dann die Pizza bei unserem Lieblingsrestaurant. Alles wird gestellt und wir müssen nur noch die Pizza genießen. Auch hier verlieren wir immer mehr Kontrolle über den Prozess allerdings wird der Prozess auch immer einfacher und ist mit weniger Folgeprozessen verbunden.

Bei unserer On-Premise Pizza haben wir laufende Kosten durch den Eigenanbau der Tomaten und den Betrieb des Ofens. Bei der Platform Pizza müssen wir nur noch Müll entsorgen und eventuell Reste verwerten während uns im Restaurant auch dieser Prozess abgenommen wird und wir uns auf die Kernaufgabe konzentrieren können – nämlich das Pizza essen.

Genauso ist es bei der Bereitstellung von IT-Ressourcen. Mit der Abgabe von Kontrolle wird es immer mehr „Convenient“ und flexibler, allerdings verlieren wir auch immer mehr die Kontrolle über interne Prozesse und Datenhoheit.

Mit dem Verlust der Kontrolle kommt zudem eine Unklarheit über die Zuständigkeit für die Sicherheit der Nutzerdaten und Applikation im Allgemeinen. Bei einer On Premise gehosteten Anwendungen liegen sämtliche Verantwortlichkeiten bei der entsprechenden Organisation, bei Cloud Anwendungen ist dies jedoch nicht so deutlich.

Die Infrastruktur ist meist in der Verantwortlichkeit des Cloudproviders aber Applikationen die für die Cloud geschrieben werden oder Daten die in der Cloud verarbeitet werden liegen oft im Verantwortungsbereich des Nutzers der Cloud (Organisation).

Auch Konfigurationen müssen durch den Cloudnutzer korrekt eingesetzt werden, beispielsweise die Verschlüsselung der Daten auf einem Endpunkt. So sind 85% der 2019 verursachten Datendiebstähle auf eine Fehlkonfiguration von Systemen zurückzuführen gewesen.


Erkennen Sie zuverlässig Phishing E-Mails?

Jetzt das AWARE7 Phishing Quiz absolvieren
und das eigene Wissen überprüfen!


Bedrohungen in der Cloud

Die zugrundeliegende Infrastrukturen der großen Cloud Provider sind in der Regel sicher. Dafür verwenden die Provider viele Ressourcen jährlich auf. Die Durchführung interner und externer Pentests steht dabei oft auf der Agenda der Verantwortlichen. Aber auch der Betrieb eines Bug Bounty Programms wird in Kauf genommen. Google hat seit 2010 21 Millionen Dollar nur an Bug Bounty Hunter ausgezahlt.

Aufgrund der geteilten Verantwortlichkeiten in den meisten Cloudumgebungen müssen Sie dennoch Bedrohungen evaluieren und Sicherheitsstrategien auf den Prüfstand stellen. Für die Cloud gibt es neben unterschiedlichen Modellen auch diverse Bedrohungsszenarien für die Nutzung von Cloud Infrastrukturen und Services:

  • Datenverlust oder ein Datenleck
  • Manipulation von verschiedenen Nutzern in Cloudumgebungen
  • Manipulation durch kompromittierte Instanzen innerhalb der Cloud
  • Keine Internetverbindung und damit kein Zugang zu den Daten und Applikationen in der Cloud
  • Denial Of Service Angriffe die einen Zugriff auf die Daten verhindern
  • Fehler in der Administration von Cloudumgebungen die zu signifikanten Problemen führen

Insbesondere bei der Administration von Cloudumgebunden ist auf eine korrekte Konfiguration zu achten. Aufgrund der hohen Komplexität und den unterschiedlichen Architekturen kann bereits ein kleiner Konfigurationsfehler eine substantielle Beeinflussung der Cloudinfrastruktur auslösen.

Wenn Sie mit dem Gedanken spielen Ihre Cloudumgebung einer Sicherheitsüberprüfung zu unterziehen sollten Sie folgende Risiken betrachten. Diese Diskussion kann ebenfalls mit dem Pentester bzw. dem Unternehmen durchgeführt werden:

  • Kann der Cloud Anbieter auf meine Daten zugreifen?
  • Gibt es in anderen Jurisdiktionen die Möglichkeit auf meine Anwendungen oder Kundendaten zuzugreifen?
  • Gibt es einen Plan bei Nichtverfügbarkeit der Infrastruktur?
  • Können wir feststellen ob Daten manipuliert wurden?

Beispiel: AWS Zwischenfall von 2017 und die Abhängigkeit von Diensten

Es sind Vorfälle wie diese, die eindrucksvoll vorführen: Es reicht ein falscher Befehl um zahlreiche Dienste vom Netz zu nehmen! Der AWS Zwischenfall reiht sich damit in die Vorfälle ein, welche auf menschliches Versagen zurückzuführen sind. Amazon eine Mitteilung veröffentlicht und Stellung zu den Ereignissen bezieht. Liest man den ersten Absatz, wird das Problem direkt beschrieben:

Unfortunately, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended. (aws)

Durch den falschen Befehl wurden einige große Dienste zeitweise vom Netz genommen. Darunter waren u.a.: Dropbox, Netflix, Reddit, Foursquare, IFTTT. Gerade letzteres kann kritisch werden, da durch „if this then that“ bereits diverse Heimautomatisierungsdienste gesteuert werden. Kein IFTTT, keine Haussteuerung, kein Licht.

Cloud-Anbieter wie z.B. Amazon werben mit einer Verfügbarkeit von 99,9% – doch wenn die 0,1% greifen können diese zahlreiche und umfangreiche Probleme nach sich zehen. AWS bedient 31% der Marktanteile im Cloud Bereich und ist damit Marktführer. Vorfälle wie diese zeigen: Viele Anbieter wie Trello, Slack und die oben aufgelisteten sind in dem Augenblick so abhängig von Amazon, wie die moderne Gesellschaft von fossilen Brennstoffen.

Cloud Pentest als Sicherung

Es gibt auch bei einem Pentest einer Cloud Infrastruktur unterschiedliche Ansätze, die verfolgt werden können. Wir teilen unsere Sicherheitsuntersuchungen in drei Aspekte auf in Analogie zu den drei Arten von Tests die Penetrationstester durchführen:

  • Black Box/ Testing gegen die Cloud

Hier werden Applikationen getestet, die als Cloud Anwendung gehostet werden. Dies können zum Beispiel Systeme sein, die von der unternehmenseigenen Infrastruktur kürzlich in die Cloud umgezogen sind oder einfach Webapplikationen. Es werden klassische Webapplikationsvektoren getestet ebenso wie fehlkonfigurierte Nutzerberechtigungen oder falsch konfigurierte Speicherinstanzen (z.B. S3 Buckets oder Metadaten von EC2 Instanzen)

  • Grey Box / Testing in der Cloud

Hier werden Systeme getestet die nicht öffentlich zugänglich sind, beispielsweise getrennt durch eine Firewall. Beim Test in der Cloud werden dem Angreifer häufig gültige Zugänge zum Backend bereitgestellt. Dies geschieht um zu prüfen, was passiert wenn versehentlich einmal Zugangsdaten abhanden kommen und ein Angreifer Zugang zum Backend bekommt.

  • White Box / Testing der Konsole

Beim Test der Konsole wird die Konfiguration der Cloudumgebung überprüft. Es wird evaluiert welche Nutzer welche Rechte haben, ob Zugangskontrollen korrekt gesetzt sind und alle Konfigurationen korrekt implementiert sind. So können Privilege Escalation Vektoren und Informationslecks effizient und nachhaltig geschlossen werden.

Diese Formen des Penetrationstests können wir unabhängig des gewählten Service Modells durchführen. Je nach Service Modell sind die Grenzen eines Penetrationstests stark definiert. Ein Infrastructure as a Service (IaaS) System hat andere Anforderungen als ein Software as a Service (Saas) System.

Bei einer IaaS kann der Penetrationstest deutlich aggressiver durchgeführt werden. Dies liegt vor allem daran, dass bei einer Beeinträchtigung durch einen Penetrationstest bei einem SaaS System deutlich mehr Nutzer betroffen sind als bei einem IaaS System.

Es ist zudem möglich mit einem Black Box Test zu starten. Wenn ein kompromittierbares System auffindbar ist eine sogenannte „Pivoting“ Attacke durchzuführen. Bei einer Pivoting Attacke werden kompromittierte Systeme verwendet, um andere Systeme zu beeinträchtigen. Ist beispielsweise von dem System ein internes System erreichbar, welches kritisch für die Erbringung der Leistung ist macht ein Pivoting Sinn.

DDoS Angriffe sind von allen Cloud Anbietern verboten und können durch Pentester nicht durchgeführt werden. Es gibt zudem weitere Beschränkungen an die Penetrationstester sich halten müssen, abhängig davon bei welchen Anbieter die Daten bzw. die Cloudapplikation liegt.

AWS erlaubt einen Penetrationstest beispielsweise bei acht Services aktuell und verbietet

  • DNS Zone Walking
  • DoS Attacken
  • Port Flooding

Microsoft erlaubt das Testing von sieben Microsoft Cloud Produkten ohne vorherige Freigabe. Auch bei Microsoft sind DoS Attacken verboten. Dafür sind Portscans bei virtuellen Azure Instanzen erlaubt. Jeder Pentest in der Cloud erfordert also einen erhöhten Planungs- und Durchführungsaufwand, da neben der Abstimmung mit dem Kunden auch auf die Anforderungen der unterschiedlichen Cloud Anbieter eingegangen werden muss. Gerne beraten wir Sie in einem kostenfreien Erstgespräch über den Penetrationstest Ihrer Cloud Umgebung.

Beispiel: Zwischenfall Amazon Web Services


Hat Ihnen der Beitrag gefallen? Gerne benachrichtigen wir Sie, wenn wir einen neuen Beitrag veröffentlicht haben. Tragen Sie jetzt Ihre E-Mail-Adresse ein. Für Sie entstehen keine Kosten.


Foto des Autors

Dr. Matteo Große-Kampmann

Mein Name ist Matteo Große-Kampmann. Gemeinsam mit Chris Wojzechowski habe ich die AWARE7 GmbH in Gelsenkirchen gegründet. Ich habe meine Promotion zum Thema "Towards Understanding Attack Surfaces of Analog and Digital Threats" abgeschlossen und bin ausgebildeter ISO 27001 Lead Auditor.