Entspannt unterwegs in der Datenwolke: Sicherheitstests für die Cloud

Ein Beitrag von IT Security Consultant Stefan Hempel, Fachteam Cloud Security

Die Nutzung von Cloud-Diensten beginnt häufig mit einem Missverständnis: "Ich muss mich um nichts kümmern, die Systeme sind verwaltet, und Kapazität ist unbegrenzt verfügbar." Weit verbreitet ist die Vorstellung von gemanagten Diensten, bei denen alle unterliegenden Schichten (Hardware, Betriebssystem, Software, Anwendungen, virtuelle Maschinen etc.) wegabstrahiert und unsichtbar sind. Dieser Gedanke ist für Privatanwender und IT-Administratoren gleichermaßen verlockend. Der Unterschied liegt darin, wie viele Schichten es sind: Der Anwender freut sich über eine vollständig gemanagte Anwendung, z. B. Microsoft Office, der Administrator über grenzenlos skalierbare Infrastruktur.

Das Cloud-Team der SySS trifft bei der Vorbereitung von Tests oft auf diese Idee – und kann über ihre Hintergründe aufklären: In allerletzter Konsequenz gibt es keine Cloud, sondern nur "other people‘s computers".

Das Verständnis von Cloud

Was jeweils als Cloud definiert wird, hängt davon ab, wie hoch oder tief sich der Anwender im Stack, also dem Verbund der verwendeten Komponenten, befindet. Ein mögliches Beispiel für einen Stack wäre LAMP, der Verbund aus Linux, Apache, MySQL, PHP.

Ob eine Technologie als Cloud eingeordnet wird, kommt also auch auf den Standpunkt an. Für einen Benutzer von OpenStack ist OpenStack Cloud, für den Administrator eine sehr komplexe Anwendung. Für eine technische Kategorisierung ist aber eine klare Abgrenzung notwendig – allein schon, um eine fachlich differenzierte Spezialisierung zu ermöglichen. SySS zieht diese Grenze zum einen anhand von Produkten. Mit "Produkt“ sind dabei auch explizit die großen Cloud-Plattformen gemeint, also Amazon Web Services (AWS), Microsoft Azure und Google Cloud Platform (GCP) – nicht zuletzt deshalb, weil diese Anbieter den Begriff Cloud wesentlich geprägt haben. Überdies gehören auch Tests von Hybrid-Infrastrukturen sowie Containern und Containerorchestrierung, aber auch von Diensten wie OpenStack und Kubernetes zum Angebot des Fachteams Cloud bei der SySS.

Die Testperspektive

Ausgehend von diesem Verständnis von Cloud ergeben sich bestimmte Testmethodiken. Generell hat sich für Cloud-Produkte ein offenes Testvorgehen (Whitebox-Ansatz) als sinnvoller erwiesen als ein Greybox-Ansatz wie man ihn z. B. bei einer Webapplikation wählen würde. Hier liegt die Komplexität in der Webapplikation selbst, die dahinterliegenden Systeme wie z. B. Datenbanken sind gut verstanden und bieten verhältnismäßig kleine Angriffsoberflächen. Das spiegelt sich z. B. in den OWASP Top 10 wider. Fast alle hier aufgeführten Schwächen rühren aus der Komplexität bzw. Entwicklungsfehlern der Anwendung selbst her. Eine Prüfung aus Benutzersicht schärft die Testperspektive, weil die direkt exponierten Schwächen automatisch im Fokus liegen.

Bei einer Technologieplattform wie z. B. Azure ist die Testabdeckung auf einem solchen Weg deutlich weniger ergiebig. Das liegt vor allem daran, dass die Komplexität hier über die komplette Plattform verteilt ist. Unter den OWASP Cloud Top 10-Risiken sind viele Themen zu finden, die teilweise oder komplett im organisatorischen Bereich liegen, wie z. B. Compliance-Themen.

Dass der Greybox-Ansatz für einen Cloud-Test weniger ergiebig ist als für einen klassischen Penetrationstest, liegt aber auch daran, dass zahlreiche Funktionen im Technologiezeitalter vor der Cloud überhaupt nicht existiert haben und manuell sehr schwierig zu testen sind.

Verdeutlichen lässt sich dies am Beispiel der Conditional Access-Funktion des Microsoft Azure AD. Conditional Access erlaubt Zugriffseinschränkungen und -bedingungen für Nutzer abhängig von Gruppenzugehörigkeiten, Standorten und Geräten. Dazu lassen sich Ausnahmen und Bedingungen definieren. Eine mögliche Konfiguration wäre z. B., dass Administratoren sich nur mit einem zweiten Faktor anmelden können, sofern sie sich nicht im IP-Bereich der eigenen Firma befinden.

Solche Regeln sind schwer zu testen, da die verschiedenen Testperspektiven nur sehr aufwändig herzustellen sind. Denkbar ist z. B. der Fall, dass Zugriff nur aus einem bestimmten Land zugelassen wird. Eine solche Beschränkung zu umgehen ist mittels VPN relativ leicht, eine experimentelle Prüfung dagegen ist sehr aufwändig, da für jedes mögliche Land eine entsprechende VPN-Verbindung vorgehalten werden müsste. Ferner ist es fast unmöglich, Kombinationen von Voraussetzungen abzuprüfen, also etwa die Frage zu klären, ob möglicherweise iOS-Zugriff aus Portugal gestattet ist.

Die Einsicht in die definierten Regeln liefert diese Informationen viel schneller und vollständiger. Diese Art des Testens bedeutet im Vergleich zu einer manuellen Prüfung also sowohl eine Zeitersparnis als auch eine bessere Testabdeckung. Hier bringt die Homogenität der Plattform sowohl für den Tester als auch für den Kunden einige Vorteile, da sowohl Testzeit als auch Geld gespart werden können.

Die betrachteten Bestandteile

Unterschiede zwischen Cloud- und 'klassischen' Penetrationstests bestehen auch im Testgegenstand. Beim Penetrationstest einer Webapplikation werden Back-End-Bestandteile meist gar nicht, nur indirekt oder nur teilweise betrachtet. Elemente, die nicht direkt Bestandteil der Anwendung sind, bleiben unbetrachtet, egal, ob es sich um technische Aspekte oder um Prozessthemen handelt.

Anders verhält es sich mit einer AWS-Infrastruktur. Eine solche besteht im minimalen Fall aus einem Account (meist eher mehr). Ein Account wiederum integriert verschiedene Ressourcen wie Instanzen, Datenbanken, Identity Pools, Serverless-Funktionen und weitere Dienste. Jeder dieser Bestandteile ist komplett einsehbar, meist sogar in Formaten, die auch für Maschinen lesbar sind.

Ein weiteres gutes Beispiel, um die Unterschiede von klassischen Penetrationstests und Cloud-Tests zu illustrieren, sind Firewallregeln. Bei Webapplikationen ist die Firewallkonfiguration üblicherweise nicht im Internet exponiert, d. h. schon der Zugriff auf die Firewallregeln stellt für den Tester einen zusätzlichen organisatorischen Aufwand dar. Im Falle von AWS kann der SySS-Consultant diese Regeln einfach auslesen und aufgrund dessen, dass sie sogar für Maschinen lesbar sind, sogar automatisiert weiterverarbeiten. Der gesamte Zugriff fügt sich natürlich in den Testablauf ein. Da der Zugang zu den AWS-Accounts sozusagen als Single Sign-on fungiert, muss nicht für jede Funktion ein weiterer Zugang realisiert werden. Eine Ausweitung des Testumfangs ist damit einfach und spontan möglich. Und die eingesparte Zeit lässt sich dann sinnvoll in die Analyse organisatorischer Themen investieren.

Gleichzeitig ist die Gefahr, die von einer Prüfung ausgeht, sehr gering. Sowohl in AWS als auch in Azure gibt es rein lesende Berechtigungen, bei denen eine potenzielle Beschädigung der Systeme, wie sie sonst nie komplett ausgeschlossen werden kann, gar nicht möglich ist. Für den Tester reduziert das die Last, sich permanent um den potenziellen Fallout eines Fehlers zu sorgen, und es erlaubt Tests auf produktiven Systemen, ohne dass deren Verfügbarkeit gefährdet ist.

Die Architektur

Viele neue Möglichkeiten der Cloud-Technologie liegen auch im Bereich der Architektur. Relativ junge Konzepte wie Serverless und Container erlauben es, komplett neue Arten von Infrastrukturen aufzubauen und diese auch sicher zu gestalten. Die Vielfalt an Optionen eröffnet zugleich aber auch neue Sicherheitslücken, die übersehen werden können. Nach Erfahrungswerten des Cloud-Teams der SySS ist das bedeutendste neue Element hier Kubernetes.

Kubernetes ist eine Lösung zur Containerorchestrierung und bringt die Containertechnologie, also Docker und Co., in eine infrastrukturtaugliche Form. Der administrative Mehraufwand, den die Microservice-Philosophie schafft, kann damit bewältigt werden. Gleichzeitig begünstigt die höhere technische Komplexität jedoch auch potenzielle Schwachstellen.

In einem Test führt das dazu, dass nicht nur technische, sondern auch organisatorische Themen verstärkt im Fokus liegen. Das wiederum zieht die Notwendigkeit einer engeren Zusammenarbeit zwischen dem SySS-Consultant und dem Auftraggeber nach sich. Insbesondere Prozess- und Architekturthemen lassen sich am besten im direkten Gespräch klären.

Bei Kubernetes wäre es z. B. typisch, nach der Imagesicherheit zu fragen. Zu ermitteln ist Folgendes:

  • Kann jeder Anwender jedes Image provisionieren?

Wenn ja:

  • Welche Sicherheitsimplikationen hat diese Rechtevergabe?

Wenn nicht:

  • Bei wem liegt die Verantwortlichkeit?
  • Wer besitzt das technische Know-how?
  • Wie verhalten sich Ist- und Soll-Zustand zueinander?

Unser Fazit

Wer einen Cloud-Sicherheitstest bei der SySS beauftragt, darf mit einem sehr offenen Testvorgehen rechnen. In einem Cloud-Test werden zahlreiche Detailfragen zum Gesamtaufbau aller Komponenten erörtert und zwar sowohl zu technischen wie auch zu organisatorischen Aspekten. Die Funde eines Cloud-Tests adressieren dann auch vermehrt organisatorische Themen und meistens (wenngleich nicht immer!) ist das Gesamtsicherheitsniveau des Testgegenstands schon zum Testzeitpunkt relativ hoch.

Sie nutzen bereits Cloud-Dienste oder planen, dies zukünftig zu tun? Die SySS kann Ihnen als verlässlicher Partner helfen, bei Ihrer Arbeit in und mit der Cloud höchste Sicherheitsmaßstäbe zu erfüllen. Ob als Test zur letzten Abnahme vor dem Go-Live oder für eine Sicherheitsprüfung einer bereits bestehenden Struktur: Unser Fachteam für Cloud Security unterstützt Sie gerne!

Kontaktieren Sie uns jederzeit unter:

anfrage(at)syss.de

+49 (0)7071 - 40 78 56-50

Unsere Mitarbeiterinnen und Mitarbeiter freuen sich auf Sie!

Ihr direkter Kontakt zu SySS +49 (0)7071 - 40 78 56-0 oder anfrage@syss.de | IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN +49 (0)7071 - 40 78 56-99

Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer

Ihr direkter Kontakt zu SySS +49 (0)7071 - 40 78 56-0 oder anfrage@syss.de

IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN +49 (0)7071 - 40 78 56-99

Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer

Direkter Kontakt

+49 (0)7071 - 40 78 56-0 oder anfrage@syss.de

IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN

+49 (0)7071 - 40 78 56-99

Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer