Cloud-Angriffsfläche

Die Cloud-Angriffsfläche umfasst alle Punkte, an denen ein Angreifer versuchen könnte, in eine Cloud-Umgebung einzudringen oder Daten aus ihr abzuziehen. Anders als bei lokalen Netzwerken wird die Angriffsfläche in der Cloud hauptsächlich durch Konfiguration und Identität und nicht durch einen physischen Perimeter bestimmt.

• Öffentlich erreichbare APIs und Verwaltungskonsolen
• Identity and Access Management (IAM)
• Storage-Buckets, Datenbanken und serverlose Funktionen
• Netzwerkexposition (Security Groups, Load Balancer)

Eine einzige Fehlkonfiguration kann ein gesamtes Konto offenlegen.

Die meisten Cloud-Pentests zielen auf einen der drei großen Anbieter. Jeder hat sein eigenes Identitätsmodell und seine eigene Terminologie, aber die Angriffsmuster ähneln sich.

• AWS — IAM-Benutzer und -Rollen, S3, EC2, Lambda
• Azure — Entra ID (Azure AD), Blob Storage, VMs, Functions
• GCP — IAM-Servicekonten, Cloud Storage, Compute Engine

Wenn Sie einen Anbieter gründlich lernen, fallen Ihnen die anderen leichter, da die grundlegenden Konzepte (Identität, Rechenleistung, Speicher, Netzwerk) sich auf alle übertragen lassen.

Cloud-Anbieter sichern die Infrastruktur; der Kunde sichert das, was er in ihr ablegt. Das ist das Modell der geteilten Verantwortung, und fast jeder Cloud-Angriff findet auf Kundenseite statt.

• Anbieter: physische Rechenzentren, Hypervisor, Patchen verwalteter Dienste
• Kunde: IAM-Richtlinien, Daten, Betriebssystem-Patches (IaaS), Netzwerkkonfiguration

Als Pentester konzentrieren Sie sich auf die Verantwortlichkeiten des Kunden, denn dort liegen die ausnutzbaren Fehler.

Die erste Aufgabe bei einer Cloud-Prüfung besteht darin herauszufinden, wer Sie sind und was Sie mit den vorhandenen Zugangsdaten tun können. Die AWS CLI gibt die Identität des Aufrufers sofort aus.

Wenn ein Schlüssel zu weitreichende Berechtigungen besitzt, kann diese einzelne Identität sich im gesamten Konto weiterbewegen.

Cloud-Ressourcen können aus dem öffentlichen Internet oder nur innerhalb eines virtuellen Netzwerks erreichbar sein. Eine falsch konfigurierte Erreichbarkeit ist einer der häufigsten Befunde.

• Security Groups / NSGs, offen für 0.0.0.0/0
• Storage-Buckets mit aktiviertem öffentlichem Lesezugriff
• Datenbanken mit aktivierten öffentlichen Endpunkten
• Offene Verwaltungsports (22, 3389, 5432)

Die Erfassung aller öffentlich erreichbaren Ressourcen bildet die Grundlage der Cloud-Aufklärung.

Auch ohne Zugangsdaten erfassen Angreifer die Cloud-Präsenz eines Ziels. Vorhersehbare Namenskonventionen und DNS geben überraschend viele Informationen preis.

Tools probieren Bucket- und Speichernamen anhand des Unternehmensnamens und gängiger Muster automatisiert durch.

In jedem Cloud-Konto gibt es zwei unterschiedliche Angriffsebenen:

• Verwaltungs- oder Steuerungsebene — die APIs zum Erstellen, Ändern und Löschen von Ressourcen (z. B. iam:CreateUser, ec2:RunInstances)
• Datenebene — Zugriff auf die Daten innerhalb der Ressourcen (Lesen eines S3-Objekts, Abfragen einer Datenbank)

Die Kompromittierung der Verwaltungsebene bedeutet normalerweise das Ende, da der Angreifer sich selbst jeden gewünschten Zugriff auf die Datenebene gewähren kann.

Cloud-Aktionen werden zentral protokolliert. Als Pentester müssen Sie wissen, dass diese Protokolle existieren, weil Verteidiger sie überwachen und bereits die Feststellung, dass sie deaktiviert sind, selbst ein Befund ist.

• AWS CloudTrail — zeichnet alle API-Aufrufe auf
• Azure Activity Log / Monitor
• GCP Cloud Audit Logs

Ein Konto, bei dem die Protokollierung deaktiviert oder nicht überwacht wird, ist bereits vor einer Ausnutzung ein Befund mit hohem Risiko.

Die meisten Cloud-Kompromittierungen beginnen an einem von wenigen Ansatzpunkten:

• Durchgesickerte Zugriffsschlüssel in Git-Repositories, CI-Protokollen oder mobilen Apps
• Zu weitreichende IAM-Rollen, die kompromittierten Servern zugewiesen sind
• SSRF, die den Instanz-Metadatendienst erreicht
• Öffentliche Storage-Buckets, die Geheimnisse oder Backups offenlegen

Wenn Sie diese Muster erkennen, können Sie priorisieren, wo Sie zuerst suchen.

Ein strukturierter Ansatz sorgt für eine gründliche Cloud-Bewertung. Sobald Sie über Zugangsdaten verfügen, erfassen automatisierte Tools das gesamte Konto.

Tools wie ScoutSuite und Prowler prüfen die Konfiguration dienstübergreifend und kennzeichnen Risiken automatisch.

Cloud-Tests müssen innerhalb der Autorisierung des Auftrags bleiben. Auch die Anbieter haben Regeln für die Durchführung von Tests.

• Bestätigen Sie die genauen Konten, Abonnements oder Projekte im Testumfang
• Vermeiden Sie Aktionen, die andere Mandanten oder gemeinsam genutzte Infrastruktur beeinträchtigen
• Führen Sie Tests im Stil einer Denial-of-Service-Attacke niemals ohne ausdrückliche schriftliche Genehmigung durch

Unbefugte Cloud-Tests können gegen die Bedingungen des Anbieters und gegen lokales Recht verstoßen.

Welche Seite ist im Modell der geteilten Verantwortung für IAM-Richtlinien und die Datenkonfiguration zuständig?

Sie haben gelernt, wodurch die Cloud-Angriffsoberfläche definiert wird und wie sie sich von herkömmlichen Netzwerken unterscheidet.

• Die Oberfläche wird durch Identität und Konfiguration geprägt, nicht durch einen physischen Perimeter
• AWS, Azure und GCP teilen dieselben grundlegenden Konzepte: Identität, Computing, Storage und Netzwerk
• Das Modell der geteilten Verantwortung ordnet Konfiguration und Daten dem Kunden zu
• Unterscheiden Sie zwischen der Management Plane und der Data Plane
• Bestätigen Sie vor jedem Test den Umfang und die Autorisierung

Als Nächstes sehen wir uns IAM-Fehlkonfigurationen an, den Kern von Cloud-Angriffen.