Tödliche Cloud-Fehlkonfigurationen mit Penetration Testing aufspüren

Sie haben Monate damit verbracht, Ihre Infrastruktur in die Cloud zu migrieren. Sie haben die Auto-Scaling-Gruppen am Laufen, die Kubernetes-Cluster orchestriert und die Serverless Functions, die genau dann ausgelöst werden, wenn sie sollen. Auf dem Papier ist Ihre Architektur ein Meisterwerk moderner Technik. Aber hier ist die Wahrheit: Die Cloud ist nicht von Natur aus unsicher; es ist nur unglaublich einfach, sie zu vermasseln.

Ein falsch gesetztes Häkchen in einer S3-Bucket-Richtlinie oder eine etwas zu permissive IAM-Rolle kann Ihre Festung in eine Drehtür verwandeln. Und das Beängstigende daran? Sie werden nicht wissen, dass sie offen ist, bis jemand – oder etwas – direkt hindurchgeht. Wir haben alle die Schlagzeilen über "massive Datenlecks" gesehen, die in Wirklichkeit nur eine offene Datenbank ohne Passwort waren. Es ist selten ein ausgeklügelter Zero Day Exploit, der ein Unternehmen zu Fall bringt; es ist meist eine banale Fehlkonfiguration.

Hier kommt Penetration Testing ins Spiel. Während automatisierte Scanner hervorragend geeignet sind, um bekannte CVEs zu finden, übersehen sie oft die Logikfehler und "erlaubten, aber gefährlichen" Konfigurationen, die ein menschlicher Angreifer liebt. Um Ihre Cloud wirklich zu sichern, müssen Sie wie die Person denken, die versucht, einzubrechen. Sie müssen aktiv nach diesen tödlichen Fehlkonfigurationen suchen, bevor es ein böswilliger Akteur tut.

In diesem Leitfaden werden wir tief in die häufigsten Cloud-Fallstricke eintauchen, warum automatisierte Tools nicht ausreichen und wie ein dedizierter Pentesting-Ansatz – unterstützt durch Plattformen wie Penetrify – verhindern kann, dass ein kleines Versäumnis zu einem existenzbedrohenden Ereignis für das Unternehmen wird.

Die versteckte Gefahr der "Standard"-Cloud-Einstellung

Wenn Sie einen neuen Dienst in AWS, Azure oder GCP starten, werden Sie mit einer Reihe von Standardeinstellungen begrüßt. Diese Standardeinstellungen sind für eines konzipiert: Benutzerfreundlichkeit. Cloud-Anbieter möchten, dass Sie Ihre App so schnell wie möglich zum Laufen bringen. Leider stehen sich "einfach einzurichten" und "standardmäßig sicher" oft entgegen.

Viele Unternehmen tappen in die Falle, an diesen Standardeinstellungen festzuhalten oder einer "Schnellstart"-Anleitung aus einem Blogbeitrag zu folgen, die Funktionalität über Sicherheit stellt. Diese Anleitungen empfehlen oft, AdministratorAccess für Ihre Ersteinrichtung zu verwenden oder Port 22 für 0.0.0.0/0 zu öffnen, nur damit Sie von zu Hause aus per SSH auf Ihre Instanz zugreifen können. Das Problem ist, dass "temporäre" Einstellungen die Angewohnheit haben, dauerhaft zu werden.

Die Psychologie der Fehlkonfiguration

Die meisten Fehlkonfigurationen passieren aufgrund einer Wissenslücke. Die Cloud führt ein "Shared Responsibility Model" ein. Der Anbieter sichert die Hardware und den Hypervisor, aber Sie sichern die Daten, das Identity Management und die Netzwerkkonfiguration.

Es klingt einfach, aber wenn Sie Hunderte von Microservices und Tausende von IAM-Berechtigungen haben, wächst die Komplexität exponentiell. Ein Entwickler öffnet möglicherweise einen Port, um eine Funktion zu testen, vergisst, ihn zu schließen, und da die App einwandfrei funktioniert, bemerkt es niemand. Diese "stille" Schwachstelle ist genau das, wonach ein Pentester sucht.

Warum Standardeinstellungen eine Karte für Angreifer sind

Angreifer raten nicht einfach; sie verwenden Skripte, die das gesamte Internet nach bestimmten, gängigen Standardkonfigurationen durchsuchen. Wenn Sie einen Standardport für eine Datenbank oder eine Standardnamenskonvention für Ihre Buckets verwenden, legen Sie im Wesentlichen eine "Willkommen"-Matte für Hacker aus. Penetration Testing hilft Ihnen, diese Muster zu identifizieren und die Vorhersagbarkeit Ihrer Umgebung zu durchbrechen.

Häufige Cloud-Fehlkonfigurationen, die zu einer Katastrophe führen

Wenn Sie nach Schwachstellen suchen wollen, müssen Sie wissen, wo sie sich normalerweise verstecken. Cloud-Fehlkonfigurationen lassen sich im Allgemeinen in einige wenige Hochrisikokategorien einteilen.

1. Überprivilegiertes Identity and Access Management (IAM)

IAM ist der neue Perimeter. In den alten Tagen hatten Sie eine Firewall; jetzt haben Sie Rollen und Richtlinien. Der häufigste Fehler hier ist "Permission Creep".

Einem Entwickler wird eine umfassende Berechtigung erteilt, um einen Fehler in der Produktion zu beheben. Der Fehler wird behoben, aber die Berechtigung bleibt bestehen. Im Laufe der Zeit könnte ein einzelnes kompromittiertes Benutzerkonto oder ein durchgesickerter API-Schlüssel die Möglichkeit haben, Ihre gesamte Produktionsdatenbank zu löschen oder neue administrative Benutzer zu erstellen.

Wonach ein Pentester sucht:

Wildcard-Berechtigungen (z. B. s3:* oder iam:*).
Benutzer mit permanenten administrativen Rechten anstelle von temporären, übernommenen Rollen.
Fehlende Multi-Faktor-Authentifizierung (MFA) für privilegierte Konten.
Fest codierte Anmeldeinformationen in Skripten oder Umgebungsvariablen.

2. Exponierte Storage Buckets und Datenbanken

Wir haben es schon tausendmal gesehen: Ein Unternehmen veröffentlicht Millionen von Kundendatensätzen, weil ein S3-Bucket oder ein Azure Blob auf "Öffentlich" gesetzt wurde. Manchmal ist es ein Fehler; manchmal ist es ein fehlgeleiteter Versuch, ein öffentliches Bild oder eine CSS-Datei zu hosten, ohne zu merken, dass der Rest des Buckets jetzt ebenfalls exponiert ist.

Die "versteckte" Gefahr: Es geht nicht nur um "Alle Benutzer". Manchmal bedeutet "Authentifizierte Benutzer" tatsächlich jeder mit einem beliebigen AWS-Konto, nicht nur Benutzer in Ihrer Organisation. Dies ist eine Nuance, die viele IT-Teams aus dem Tritt bringt.

3. Permissive Security Groups und Firewalls

Das Öffnen von Ports für die ganze Welt (0.0.0.0/0) ist das Cloud-Äquivalent dazu, die Haustür weit offen zu lassen. Während Sie möglicherweise Port 80 oder 443 für Web-Traffic geöffnet haben müssen, ist das Öffnen von Port 22 (SSH), 3389 (RDP) oder 5432 (Postgres) für das öffentliche Internet eine Einladung zu einem Brute-Force-Angriff.

Häufige Fehler sind:

Erlauben des gesamten Traffics innerhalb einer VPC, was bedeutet, dass, wenn ein kleiner Webserver kompromittiert wird, der Angreifer sich lateral zum Datenbankserver bewegen kann, ohne auf Widerstand zu stoßen.
Vergessen, temporäre "Allow-All"-Regeln zu entfernen, die während einer Fehlerbehebungssitzung verwendet wurden.

4. Unverschlüsselte Daten im Ruhezustand und bei der Übertragung

Viele Cloud-Dienste bieten "Verschlüsselung standardmäßig" an, aber das bedeutet nicht, dass sie korrekt konfiguriert ist. Wenn Sie vom Anbieter verwaltete Schlüssel ohne Rotationsrichtlinie verwenden oder, schlimmer noch, sensible Daten im Klartext in einer Datenbank speichern, sind Sie nur eine Datenschutzverletzung von einem Compliance-Albtraum entfernt.

Automatisierung vs. manuelles Pentesting: Warum Sie beides brauchen

Vielleicht denken Sie jetzt: "Ich habe ein Cloud Security Posture Management (CSPM) Tool. Findet das nicht all diese Dinge?"

Ja und nein.

CSPMs sind fantastisch. Sie können Ihre Umgebung stündlich scannen und Ihnen sagen: "Hey, dieser Bucket ist öffentlich." Das ist wichtig für die Hygiene. Aber ein Scanner ist eine Checkliste. Er weiß, wie man "X" findet, aber er weiß nicht, wie man "X" ausnutzt, um zu "Y" zu gelangen.

Die "Kette von Schwachstellen"

Dies ist der Kern von professionellem Penetration Testing. Ein Scanner findet möglicherweise drei Probleme mit der Schweregradstufe "Low":

Eine zu permissive IAM-Rolle für eine Low-Level-App.
Ein lesbarer Metadatendienst auf einer EC2-Instanz.
Eine Entwicklungsdatenbank mit einem schwachen Passwort.

Einzeln betrachtet könnte Ihr Sicherheitsteam diese als "niedrige Priorität" ignorieren. Aber ein menschlicher Pentester sieht einen Pfad:

Sie nutzen eine Schwachstelle in der App aus, um eine Shell zu erhalten.
Sie verwenden die zu permissive IAM-Rolle, um den Metadatendienst abzufragen.
Sie stehlen ein temporäres Token.
Sie verwenden dieses Token, um auf die Entwicklungsdatenbank zuzugreifen.
Sie finden Produktionsanmeldeinformationen in der Entwicklungsdatenbank.
Boom: Vollständige Kompromittierung der Produktion.

Ein Scanner sieht drei kleine Löcher. Ein Pentester sieht einen Tunnel zu Ihren Kronjuwelen.

Wo Penetrify ins Spiel kommt

Genau deshalb schließt Penetrify die Lücke. Durch die Kombination von automatisiertem Scannen mit manuellen Testfunktionen ermöglicht es Unternehmen, über die grundlegende Checkliste hinauszugehen. Sie können diese realen Angriffsketten in einer kontrollierten Umgebung simulieren. Anstatt nur eine Liste von 500 "mittleren" Warnungen zu erhalten, erhalten Sie ein klares Bild davon, wie sich ein Angreifer tatsächlich durch Ihre spezifische Architektur bewegen könnte.

Schritt für Schritt: So führen Sie eine Cloud-Fehlkonfigurationssuche durch

Wenn Sie Ihre eigene Sicherheitsbewertung starten oder eine solche beaufsichtigen, benötigen Sie einen strukturierten Ansatz. Sie können nicht einfach "herumstochern". Sie brauchen eine Methodik.

Phase 1: Aufklärung und Asset Discovery

Sie können nicht sichern, was Sie nicht kennen. Der erste Schritt ist die Kartierung der Angriffsfläche.

Öffentliche DNS-Einträge: Welche Subdomains verweisen auf Ihre Cloud?
IP-Bereiche: Welche öffentlichen IPs sind Ihren Instanzen zugewiesen?
Bucket Sniffing: Überprüfung auf gängige Namensmuster (z. B. company-dev-backup), um festzustellen, ob Buckets versehentlich öffentlich sind.

Phase 2: Identifizierung von Einstiegspunkten

Sobald die Karte gezeichnet ist, suchen Sie nach den schwächsten Türen.

Webanwendungen: Gibt es veraltete Plugins oder SQL Injection-Punkte?
SSH/RDP-Ports: Gibt es offene Management-Ports?
API Endpoints: Sind Ihre APIs ordnungsgemäß authentifiziert, oder können Sie auf Daten zugreifen, indem Sie einfach eine ID in der URL ändern?

Phase 3: Privilege Escalation und Lateral Movement

Angenommen, Sie haben einen Weg hinein gefunden (auch als Benutzer mit geringen Berechtigungen), wie weit können Sie gehen?

Token Theft: Wenn Sie sich auf einer Cloud-Instanz befinden, können Sie den Instance Metadata Service (IMDS) aufrufen, um Anmeldeinformationen zu erhalten? (Profi-Tipp: Überprüfen Sie, ob IMDSv2 erzwungen wird; wenn nicht, sind SSRF-Angriffe viel einfacher).
IAM Analysis: Verwenden Sie Tools, um zu überprüfen, welche Berechtigungen Ihre aktuelle Rolle hat. Können Sie einen neuen Benutzer erstellen? Können Sie sich selbst eine Richtlinie zuweisen?
Internes Scannen: Scannen Sie von der kompromittierten Instanz aus die interne VPC. Sind die Datenbanken für den gesamten internen Datenverkehr geöffnet?

Phase 4: Data Exfiltration Simulation

Das Endziel eines Angreifers sind in der Regel die Daten.

Können Sie sensible Dateien aus einem S3-Bucket lesen?
Können Sie eine Datenbanktabelle auslesen?
Können Sie auf Secrets zugreifen, die in AWS Secrets Manager oder Azure Key Vault gespeichert sind?

Die Compliance-Falle: Warum "Compliant" nicht "Sicher" bedeutet

Ich habe mit vielen IT-Managern gesprochen, die sagen: "Wir haben gerade unser SOC 2 Audit bestanden, also sind wir gut."

Hier ist die kalte, harte Wahrheit: Compliance ist eine Basislinie. Es ist eine Momentaufnahme in der Zeit. Ein Auditor prüft, ob Sie eine Richtlinie für die Passwortrotation haben; er verbringt nicht unbedingt drei Tage damit, zu versuchen, Ihre MFA mit einem Session-Hijacking-Angriff zu umgehen.

Die Lücke zwischen Audit und Realität

Compliance-Frameworks (GDPR, HIPAA, PCI DSS) sind so breit gefasst, dass sie für jeden gelten. Sie sagen Ihnen, was Sie erreichen sollen, nicht, wie Sie sich gegen einen engagierten Angreifer schützen können.

PCI DSS könnte beispielsweise "regelmäßiges Vulnerability Scanning" erfordern. Sie führen einen Scanner aus, er zeigt keine Criticals an, und Sie setzen ein Häkchen. Aber ein Pentester könnte feststellen, dass die Software zwar gepatcht ist, die Art und Weise, wie die Software konfiguriert ist, es einem Angreifer ermöglicht, die Authentifizierung vollständig zu umgehen. Der Scanner sieht eine "gepatchte" Version und sagt "Sicher". Der Pentester sieht eine "defekte" Konfiguration und sagt "Kompromittiert".

Hin zu einer kontinuierlichen Bewertung

Der einzige Weg, die Compliance-Falle zu vermeiden, ist der Übergang von "Point-in-Time"-Audits zu kontinuierlichem Security Testing. Da sich die Cloud jedes Mal ändert, wenn ein Entwickler Code pusht oder ein Terraform-Skript ausgeführt wird, ändert sich Ihre Security Posture stündlich. Aus diesem Grund betont Penetrify die kontinuierliche Überwachung und das On-Demand-Testing. Sie sollten nicht auf Ihr jährliches Audit warten, um herauszufinden, dass Ihre Daten seit sechs Monaten öffentlich sind.

Real-World-Szenario: Der "Dev-to-Prod"-Dominoeffekt

Lassen Sie uns ein hypothetisches (aber sehr häufiges) Szenario durchgehen, um zu zeigen, wie ein paar kleine Fehlkonfigurationen eine Katastrophe verursachen.

Das Setup:

Dev-Umgebung: Eine gespiegelte Version der Produktion, die für Tests verwendet wird. Um die Dinge zu "erleichtern", haben die Entwickler hier etwas lockerere Berechtigungen.
Prod-Umgebung: Stark gesichert. Kein öffentliches SSH, striktes IAM.

Der Angriffspfad:

Der Ausgangspunkt: Ein Angreifer findet eine Schwachstelle in einer Dev-Webanwendung (vielleicht eine alte Version eines CMS). Er erhält eine Shell mit geringen Berechtigungen auf der Dev-EC2-Instanz.
Der Metadaten-Grab: Der Angreifer fragt den Instance-Metadatendienst ab. Er findet eine IAM-Rolle, die an die Instanz angehängt ist und Dev-App-Role heißt.
Die Über-Berechtigung: Die Dev-App-Role sollte eigentlich nur auf einen Dev-S3-Bucket zugreifen, aber ein fauler Admin hat ihr s3:*-Berechtigungen gegeben, weil "es ja nur für Dev war."
Die Goldmine: Der Angreifer nutzt diese Berechtigungen, um alle S3-Buckets im Konto aufzulisten. Er findet einen Bucket namens prod-deployment-scripts.
Das Geheimnis-Leck: In diesem Bucket findet er eine .env-Datei oder ein Shell-Skript, das einen fest codierten API-Schlüssel für die Produktionsdatenbank enthält.
Der finale Schlag: Der Angreifer verwendet den Produktions-API-Schlüssel, um sich direkt von seinem eigenen Rechner aus in die Produktionsdatenbank einzuloggen und umgeht dabei die Produktions-Firewall vollständig, da die Datenbank Verbindungen von jedem authentifizierten API-Schlüssel zulässt.

Die Lektion: Die Produktionsumgebung war "sicher". Die Dev-Umgebung war "getrennt". Aber aufgrund einer überprivilegierten Rolle in einer nicht-kritischen Umgebung wurde das gesamte Unternehmen kompromittiert. Ein Penetration Test hätte dies erkannt, indem er speziell die Grenzen zwischen Dev und Prod getestet hätte.

Eine Checkliste für die Jagd nach Cloud-Fehlkonfigurationen

Wenn Sie heute eine Selbsteinschätzung vornehmen, beginnen Sie mit dieser Liste. Setzen Sie nicht einfach nur ein Häkchen – überprüfen Sie das tatsächliche Verhalten.

Speicher & Datenbanken

Öffentlicher S3/Blob-Zugriff: Gibt es Buckets mit AllUsers- oder AuthenticatedUsers-Berechtigungen?
Bucket-Richtlinien: Verwenden Richtlinien das Prinzip der "Least Privilege" oder verwenden sie * für Aktionen/Ressourcen?
Datenbank-Exponierung: Sind Datenbanken (RDS, CosmosDB, Cloud SQL) über eine öffentliche IP-Adresse erreichbar?
Verschlüsselung: Ist die AES-256-Verschlüsselung für alle Festplatten und Buckets aktiviert? Werden Schlüssel rotiert?

Identität & Zugriff (IAM)

Root-Konto: Wird das Root-Konto für tägliche Aufgaben verwendet? (Sollte es nicht). Ist MFA aktiviert?
Überprivilegierte Rollen: Gibt es Rollen mit AdministratorAccess oder FullAccess, die nicht unbedingt erforderlich sind?
Langlebige Schlüssel: Gibt es IAM Access Keys, die seit 90+ Tagen nicht mehr rotiert wurden?
MFA-Erzwingung: Ist MFA für alle Benutzer erforderlich, die die Infrastruktur ändern können?

Netzwerk & Compute

Sicherheitsgruppen-Regeln "Any": Gibt es Regeln, die 0.0.0.0/0 auf anderen Ports als 80/443 zulassen?
Ungenutzte Instanzen: Laufen alte "Test"-Instanzen mit veralteter Software?
IMDS-Version: Sind Ihre Instanzen gezwungen, IMDSv2 zu verwenden, um SSRF-Angriffe zu verhindern?
VPC-Peering: Gibt es Peering-Verbindungen, die uneingeschränkten Datenverkehr zwischen verschiedenen Umgebungen ermöglichen?

Protokollierung & Überwachung

CloudTrail/Aktivitätsprotokolle: Ist die Protokollierung in allen Regionen aktiviert? (Angreifer starten oft Ressourcen in ungenutzten Regionen, um sich zu verstecken).
Benachrichtigungen: Erhalten Sie sofort eine Benachrichtigung, wenn ein Bucket öffentlich gemacht oder ein Admin-Benutzer erstellt wird?
Protokollintegrität: Werden Protokolle an ein separates, schreibgeschütztes Konto gesendet, damit ein Angreifer seine Spuren nicht verwischen kann?

Das Chaos der Behebung verwalten

Sobald ein Penetration Test abgeschlossen ist, erhalten Sie in der Regel einen Bericht. Für einige Unternehmen ist dieser Bericht ein Albtraum – ein 60-seitiges PDF mit 100 "High" und "Critical" Findings. Die unmittelbare Reaktion des Engineering-Teams ist oft: "Wir können das alles nicht beheben; das wird die App kaputt machen!"

Hier scheitern die meisten Organisationen. Sie behandeln Sicherheit als eine "To-Do"-Liste und nicht als einen Risikomanagementprozess.

Priorisierung der "Kill Chain"

Beheben Sie die Dinge nicht in alphabetischer Reihenfolge. Beheben Sie sie basierend auf dem Angriffspfad. Wenn Sie 10 öffentliche S3-Buckets und eine überprivilegierte IAM-Rolle haben und diese IAM-Rolle die einzige Möglichkeit für einen Angreifer ist, tatsächlich in die Buckets zu gelangen, beheben Sie zuerst die IAM-Rolle.

Konzentrieren Sie sich auf "Choke Points". Ein Choke Point ist eine Schwachstelle, die, wenn sie behoben wird, mehrere Angriffspfade auf einmal unterbindet. Beispielsweise ist die Durchsetzung von MFA über die gesamte Linie ein massiver Choke Point, der gestohlene Passwörter unbrauchbar macht.

Implementierung von Leitplanken, nicht nur Korrekturen

Die Behebung einer Fehlkonfiguration ist großartig, aber es ist besser, zu verhindern, dass sie wieder auftritt. Dies ist der Übergang von "Behebung" zu "Governance".

Service Control Policies (SCPs): In AWS können Sie SCPs verwenden, um bestimmte Aktionen buchstäblich zu verbieten. Sie können beispielsweise eine Richtlinie erstellen, die besagt: "Niemand in dieser Organisation, nicht einmal ein Administrator, darf einen S3-Bucket öffentlich machen."
Infrastructure as Code (IaC) Scanning: Verwenden Sie Tools, um Ihre Terraform- oder CloudFormation-Vorlagen zu scannen, bevor sie bereitgestellt werden. Wenn eine Vorlage eine 0.0.0.0/0-Regel enthält, sollte der Build in der CI/CD-Pipeline fehlschlagen.
Automatisierte Behebung: Richten Sie Funktionen (wie AWS Lambda) ein, die ausgelöst werden, wenn eine Konfigurationsänderung auftritt. Wenn ein Bucket öffentlich gemacht wird, setzt die Lambda-Funktion ihn sofort wieder auf privat und benachrichtigt das Sicherheitsteam.

Die Rolle von Penetrify in Ihrem Security Lifecycle

Die Sicherung einer Cloud-Umgebung ist kein einmaliges Projekt, sondern ein ständiger Kreislauf aus Bereitstellung, Tests und Verfeinerung. Hier wird eine Plattform wie Penetrify zu einem Vorteil und nicht nur zu einem weiteren Tool.

Beseitigung von Infrastrukturbarrieren

Traditionelles Penetration Testing erfordert oft einen hohen Aufwand – Onboarding von Beratern, Einrichten von VPNs, Bereitstellung von White-Listed IPs. Die Cloud-native Architektur von Penetrify beseitigt diese Hürden. Da es für die Cloud entwickelt wurde, kann es Testressourcen bei Bedarf bereitstellen, sodass Sie Bewertungen durchführen können, ohne dass spezielle Hardware oder wochenlange Einrichtung erforderlich sind.

Skalierung mit Ihrem Wachstum

Wenn Sie mehr Cloud-Konten, mehr Regionen und mehr Services hinzufügen, vergrößert sich die Angriffsfläche für Fehlkonfigurationen. Sie können nicht realistischerweise für jeweils zehn hinzugefügte Entwickler einen neuen Sicherheitsingenieur einstellen. Penetrify ermöglicht Ihnen die Skalierung Ihrer Testkapazitäten. Sie können Angriffe über mehrere Umgebungen gleichzeitig simulieren und so sicherstellen, dass Ihre "Dev"-Sicherheit genauso hoch ist wie Ihre "Prod"-Sicherheit.

Integration in den Workflow

Ein Sicherheitsbericht ist nutzlos, wenn er als PDF auf dem Desktop eines Managers liegt. Penetrify konzentriert sich auf die Integration der Ergebnisse in die Workflows, die Ihr Team bereits verwendet. Indem Schwachstellendaten direkt in SIEM-Systeme oder Ticketing-Tools eingespeist werden, wird Sicherheit zu einem Teil des Entwicklungs-Sprints und nicht zu einer lästigen Unterbrechung am Ende des Quartals.

Deep Dive: Erweiterte Fehlkonfigurationen, auf die Sie achten sollten

Für diejenigen, die die Grundlagen abgedeckt haben, ist es an der Zeit, nach den "stillen" Schwachstellen zu suchen. Dies sind diejenigen, die keine grundlegenden Scanner auslösen, aber in den Händen eines Profis verheerend sind.

1. Fehler bei der Identitätsföderation

Viele Unternehmen verwenden Okta, Azure AD oder Google, um sich über SAML oder OIDC bei ihren Cloud-Konsolen anzumelden. Wenn die Vertrauensbeziehung falsch konfiguriert ist, ist es möglicherweise möglich, "Identity Spoofing" durchzuführen. Wenn der Cloud-Anbieter beispielsweise die vom Identitätsanbieter gesendeten Attribute nicht strikt validiert, kann ein Angreifer möglicherweise behaupten, er sei ein Administrator, indem er einfach eine Behauptung in seinem Sitzungstoken ändert.

2. Serverloses "Over-Privilege"

Lambda-Funktionen und Google Cloud Functions werden oft als "risikoarm" angesehen. Diese Funktionen haben jedoch oft IAM-Rollen, die ihnen zugeordnet sind. Wenn eine Lambda-Funktion, die Bilder verarbeitet, Berechtigungen zum Lesen aller S3-Buckets hat, erhält der Angreifer durch eine einfache Code-Injection in dieser Funktion Zugriff auf alles. Dies ist eine "Function-level"-Privilegienerweiterung.

3. Cross-Account Trust Issues

In großen Organisationen haben Sie oft mehrere Konten (Logging-Konto, Shared Services-Konto, Produktionskonto). Wenn Sie Cross-Account-Vertrauensbeziehungen eingerichtet haben, haben Sie eine Brücke geschaffen. Wenn das "Shared Services"-Konto kompromittiert ist, kann der Angreifer diese Vertrauensbeziehungen nutzen, um in das Produktionskonto zu gelangen und möglicherweise die strengeren Produktions-Firewalls zu umgehen.

4. Verwaiste Ressourcen und "Shadow IT"

Die einfache Möglichkeit, eine Cloud-Instanz zu erstellen, führt zu "Shadow IT". Ein Entwickler erstellt ein eigenständiges Projekt in einem persönlichen Konto, um eine Theorie zu testen, migriert einige Produktionsdaten dorthin, um "Bequemlichkeit" zu gewährleisten, und vergisst es dann. Diese Instanz wird nicht vom zentralen Sicherheitsteam verwaltet, wird nicht gescannt und wird nicht gepatcht. Sie wird zum perfekten Einstiegspunkt.

Häufig gestellte Fragen zum Cloud Penetration Testing

F: Ist Penetration Testing der Cloud nicht illegal? Könnte mein Konto gesperrt werden? A: Dies ist eine weit verbreitete Angst. Die kurze Antwort lautet: Es hängt vom Anbieter ab. Die meisten großen Anbieter (AWS, Azure, GCP) erlauben jetzt die meisten Arten von Sicherheitstests ohne vorherige Benachrichtigung, vorausgesetzt, Sie führen keine Denial of Service (DoS)-Angriffe durch oder greifen die zugrunde liegende Infrastruktur des Anbieters selbst an. Überprüfen Sie jedoch immer die neueste "Customer Policy for Penetration Testing" für Ihren jeweiligen Anbieter, um sicherzustellen, dass Sie die Bestimmungen einhalten.

F: Wie oft sollten wir einen Cloud Penetration Test durchführen? A: Wenn Sie eine agile Organisation sind, die täglich Code veröffentlicht, ist ein jährlicher Test nutzlos. Bis der Bericht zurückkommt, hat sich die Umgebung vollständig verändert. Wir empfehlen einen hybriden Ansatz: kontinuierliches automatisiertes Scannen (über CSPMs oder Penetrify) und manuelle Deep-Dive Penetration Tests jedes Quartal oder nach jeder größeren architektonischen Änderung (wie die Migration in eine neue Region oder der Wechsel zu Kubernetes).

F: Kann ich nicht einfach ein Bug-Bounty-Programm anstelle von Penetration Testing verwenden? A: Bug Bounties eignen sich hervorragend, um "Edge Case"-Bugs in Ihrer öffentlichen Anwendung zu finden, aber sie sind kein Ersatz für einen strukturierten Penetration Test. Bug-Bounty-Jäger gehen dorthin, wo das Geld ist; sie finden vielleicht einen auffälligen XSS-Bug, ignorieren aber eine langweilige IAM-Fehlkonfiguration, die entweder nicht gut bezahlt wird oder nicht "cool" erscheint. Ein professioneller Penetration Test ist umfassend und systematisch; ein Bug Bounty ist opportunistisch.

F: Was ist der Unterschied zwischen einer Schwachstellenbewertung und einem Penetration Test? A: Eine Schwachstellenbewertung ist wie ein Hausinspektor, der Ihr Haus umrundet und feststellt, dass das Schloss an der Hintertür alt und das Fenster gesprungen ist. Ein Penetration Test ist wie jemand, der tatsächlich versucht, das Schloss zu knacken, durch das Fenster zu klettern und zu sehen, ob er in den Safe im Schlafzimmer gelangen kann. Der eine findet die Löcher; der andere beweist, wie gefährlich diese Löcher tatsächlich sind.

F: Muss ich dem Pentester vollen Administratorzugriff auf mein Cloud-Konto gewähren? A: Nein. Das sollten Sie sogar vermeiden. Ein guter Pentest kann auf zwei Arten durchgeführt werden: "Black Box" (kein Wissen, simuliert einen Außenstehenden) oder "Grey Box" (eingeschränkter Zugriff, simuliert einen kompromittierten Benutzer). Die Bereitstellung von vollem Administratorzugriff nimmt die "Jagd" weg und testet nicht wirklich Ihre IAM-Grenzen. Die wertvollsten Tests sind diejenigen, die mit minimalem Zugriff beginnen und versuchen, zu eskalieren.

Wichtigste Erkenntnisse: Ihr Weg zu einer gehärteten Cloud

Die Cloud hat die Spielregeln der Sicherheit verändert. Wir haben nicht mehr eine einzige "Mauer" zu verteidigen. Stattdessen haben wir tausend winzige Türen, die alle durch Identität und Konfiguration gesteuert werden. Die "tödliche Fehlkonfiguration" ist normalerweise keine komplexe Malware; es ist ein Kontrollkästchen, das in der falschen Position belassen wurde.

Wenn Sie von einer Haltung des "Hoffens, dass wir sicher sind" zu "Wissen, dass wir sicher sind" übergehen wollen, müssen Sie Ihre Denkweise ändern. Behandeln Sie Sicherheit nicht mehr als einen letzten Check vor dem Start, sondern als einen kontinuierlichen Prozess der Entdeckung und Behebung.

Hier ist Ihr sofortiger Aktionsplan:

Überprüfen Sie Ihr IAM: Suchen Sie nach Rollen mit *-Berechtigungen und beginnen Sie, diese zurückzunehmen.
Beseitigen Sie die Standardeinstellungen: Überprüfen Sie Ihre Sicherheitsgruppen. Wenn Sie 0.0.0.0/0 auf einem Port sehen, der nicht für öffentlichen Webverkehr bestimmt ist, schließen Sie ihn noch heute.
Testen Sie die Kette: Schauen Sie sich nicht nur die "High"-Warnungen Ihres Scanners an. Sehen Sie sich an, wie eine "Low"-Warnung zu einer "Medium"- und schließlich zu einer "Critical"-Kompromittierung führen könnte.
Automatisieren Sie die langweiligen Dinge: Verwenden Sie SCPs und IaC-Scanning, um sicherzustellen, dass sich dieselben Fehler nicht zweimal wiederholen.
Holen Sie sich professionelle Augen: Verwenden Sie eine Plattform wie Penetrify, um eine realistische Simulation eines Angriffs durchzuführen. Finden Sie die Tunnel, bevor es die Bösen tun.

Die Cloud ist ein mächtiges Werkzeug, aber sie ist auch unversöhnlich. Seien Sie proaktiv, seien Sie skeptisch gegenüber Ihren eigenen Konfigurationen und hören Sie nie auf, nach den Löchern zu suchen. Ihre Daten – und Ihre Kunden – hängen davon ab.

Zurück zum Blog