Cloud-Fehlkonfigurationen

Fehlkonfigurationen sind eines der hartnäckigsten und gefährlichsten Risiken für die Cloud-Sicherheit. Sie sind oft die erste Sicherheitslücke, die Angreifern den Zugang zu sensiblen Systemen ermöglicht. Von ungeschützten Speicherbereichen bis hin zu übermäßig freizügigen Richtlinien für die Identitäts- und Zugriffsverwaltung (IAM) – diese Lücken beeinträchtigen die Wirksamkeit selbst der fortschrittlichsten Sicherheitskontrollen.

Fehlkonfigurationen treten auf, wenn Cloud-Dienste mit unsicheren Einstellungen bereitgestellt werden, sei es durch Versehen, schnelle Bereitstellung oder mangelnde Richtliniendurchsetzung.

Laut dem Tenable Cloud Security Risk Report 2025 gehören fehlkonfigurierte Dienste zu den häufigsten Ursachen für Cloud-Sicherheitsrisiken, wobei mehr als die Hälfte der Unternehmen (54 %) mindestens ein Secret direkt in AWS ECS-Task-Definitionen speichern, wodurch ein direkter Angriffspfad entsteht.

Solche Fehlkonfigurationen umgehen andere Sicherheitsschichten, indem sie unbeabsichtigt Zugriff gewähren, die Überwachung deaktivieren oder Dienste öffentlich zugänglich lassen.

Vor allem können sie leicht eingeführt werden – und sind schwer zu erkennen –, wenn keine automatisierten Scans und keine Richtliniendurchsetzung stattfinden.

Bei allen Cloud-Anbietern treten immer wieder ähnliche Fehlkonfigurationen auf, darunter:

• Öffentlich zugängliche Speicher-Buckets (z. B. S3, Blob Storage)
• Fehlende Verschlüsselung für Daten im Ruhezustand oder bei der Übertragung
• Deaktivierte oder fehlende Protokollierung und Audit Trails
• Zu breite IAM-Rollen oder fehlende Multi-Faktor-Authentifizierung
• Serverlose Funktionen mit nicht authentifizierten Endppoints
• Falsch konfigurierte Sicherheitsgruppen und offene Ports

Jedes dieser Beispiele allein kann ein Risiko darstellen. In Kombination bilden diese Fehlkonfigurationen die Arten von ausnutzbaren Angriffspfaden, nach denen Angreifer routinemäßig suchen.

Fehlkonfigurationen beschränken sich nicht auf offene Ports oder ungeschützten Speicher. Sie existieren auch in Identität- und Zugriffskonfigurationen.

Zu weit gefasste IAM-Rollen, ungenutzte Berechtigungen und Standarddienstkonten können im Stillen erhebliche Risiken mit sich bringen.

Ein Dienstkonto mit ungenutzten, aber hohen Berechtigungen löst möglicherweise keine Warnungen aus, aber wenn es sich mit einer öffentlich zugänglichen Workload verbindet, bildet es einen kritischen Angriffsvektor.

Tools für Cloud Infrastructure Entitlement Management (CIEM) helfen, Fehlkonfigurationen in der Cloud zu erkennen, toxische Kombinationen aufzuspüren und Warnungen zu generieren, wenn Berechtigungen nicht zur Nutzung passen.

Es kommt auf den Kontext an. Teams müssen verstehen, wer auf was zugreifen kann und wie dieser Zugriff mit der Runtime-Sicherheits interagiert.

Die Kombination von Identitätsanalyse und Erkennung von Fehlkonfigurationen stärkt Ihre Fähigkeit, echte Angriffspfade zu erkennen und zu unterbinden.

Fehlkonfigurationen in der Cloud-Infrastruktur und in Identitätssystemen scheinen für sich genommen oft nur von geringer Bedeutung zu sein. Doch in Kombination schaffen sie ausnutzbare Bedingungen, die es Angreifern ermöglichen, sich lateral zu bewegen, Privilegien zu eskalieren oder auf sensible Daten zuzugreifen.

Sicherheitsteams, die Exposure-bewusste Tools verwenden, können diese Risiken erkennen und korrelieren sowie identifizieren, wie Fehlkonfigurationen, übermäßige Berechtigungen und Dienstverbindungen laterale Bewegungen ermöglichen.

Wenn Fehlerbehebungen nach Ausnutzbarkeit statt nach Volumen priorisiert werden, führt das zu besseren Ergebnissen.

Das Verständnis dieser Muster stärkt Ihre Cloud-Sicherheitslage und beschleunigt die Reaktion auf Vorfälle.

Beispiel: Öffentliche EC2-Instanz + Entwicklerrolle mit kontoübergreifendem Zugriff

Eine AWS EC2-Instance lässt eingehenden Internetverkehr zu und verwendet eine veraltete IAM-Rolle. Diese Rolle besitzt immer noch kontoübergreifende Berechtigungen.

Ein Angreifer, der Zugriff erlangt, kann sich über Umgebungen hinweg bewegen und interne Backups oder Code-Repositories erreichen.

Beispiel: Veraltete Admin-Zugangsdaten in CI/CD

Eine ehemalige DevOps-Administratorrolle behält aktive Zugriffsschlüssel bei. Diese Schlüssel befinden sich in einem unverschlüsselten Parameterspeicher, und ein altes CI/CD-Skript kann sie immer noch aufrufen.

Wenn ein Bedrohungsakteur auf das Skript zugreift, kann er die Zugangsdaten verwenden, um die Infrastruktur in großem Umfang zu verändern.

Beispiel: Offene Firewall + Standarddienstkonto

Eine GCP Compute Engine Instanz verwendet eine Firewall-Regel, die uneingeschränkten eingehenden Datenverkehr erlaubt. Außerdem wird sie unter dem Standarddienstkonto ausgeführt, mit Zugriff auf Speicher- und Analyse-Ressourcen.

Eine Sicherheitslücke in dieser Instanz verschafft dem Angreifer einen direkten Zugang zu Ihrer gesamten Datenebene.

Beispiel: Rollenübernahme ohne Zugriffsbedingungen

Ein Azure-Dienstprinzipal kann eine abonnementübergreifende Rolle übernehmen, der keine bedingten Richtlinien fehlen.

Obwohl der Principal in einer Entwicklungsumgebung entstanden ist, greift er auf Produktionszugangsdaten zu, weil die Rolle keine Bereichsgrenzen erzwingt.

Moderne Cloud-Sicherheitsplattformen erkennen Cloud-Fehlkonfigurationen durch kontinuierliche Zustandsbewertungen.

Diese Tools bewerten Ressourcenkonfigurationen anhand bekannter Best Practices, wie den CIS Foundations Benchmarks, und individueller Unternehmensrichtlinien.

Erkennungsmechanismen erstrecken sich über mehrere Ebenen:

• API-Integrationen mit AWS, Azure und GCP
• Scannen von Infrastructure as Code (IaC)
• Runtime-Analysen von bereitgestellten Ressourcen
• Exposure-Grafik, die Fehlkonfigurationen mit tatsächlichen Risiken verknüpft

Dieser geschichtete Ansatz stellt sicher, dass Sie Fehlkonfigurationen erkennen, egal ob diese im Code, durch manuelle Änderungen oder durch Anbieter-Standardeinstellungen eingeführt wurden.

Infrastructure as Code-Vorlagen wie Terraform, CloudFormation oder Kubernetes YAML bestimmen einen Großteil der heutigen Cloud-Infrastruktur.

Die frühzeitige Erkennung von Fehlkonfigurationen vor der Bereitstellung ist von entscheidender Bedeutung.

Cloud-native Scan-Tools lassen sich direkt in CI/CD-Plattformen wie GitHub, GitLab oder Bitbucket integrieren. Sie kennzeichnen fehlkonfigurierte Ressourcen in Pull-Requests und schlagen sichere Alternativen vor, die mit internen Richtlinien und externen Frameworks übereinstimmen.

Dieses Shift-Left-Modell sorgt dafür, dass unsichere Ressourcen gar nicht erst in die Produktion gelangen, was Zeit spart und das Risiko für nachgelagerte Prozesse verringert.

Erkennung ist nur ein Teil der Lösung. Wirksame Strategien zur Behebung müssen sowohl Infrastructure-as-Code (Iac) als auch Live-Cloud-Umgebungen berücksichtigen.

Bei der Infrastructure as Code-Sicherheit können automatisierte Tools zur Durchsetzung von Richtlinien sichere Standardwerte einfügen oder Zusammenführungen mit ungelösten Problemen blockieren.

In Runtime-Umgebungen können sich die Teams auf Playbooks zur Behebung, vorab genehmigte Behebungsmaßnahmen oder Integrationen mit Konfigurationsmanagementsystemen verlassen.

In einigen Fällen erzwingen auch native Tools der Cloud-Anbieter (wie AWS Config Rules oder Azure Policy) sichere Konfigurationen.

Plattformen, die Exposure Management unterstützen, analysieren, wie fehlkonfigurierte Dienste eine Verbindung zu Identitäten, Datenspeichern und internetfähigen Endpunkten herstellen. So entsteht ein klareres Bild der Exploit-Pfade.

Ein offener Speicher-Bucket mag beispielsweise unbedeutend erscheinen, solange er nicht mit einem übermäßig berechtigten Dienstkonto und einem öffentlich erreichbaren API-Gateway verbunden ist.

Wenn man nur den Bucket behebt, wird die Bedrohung dadurch nicht beseitigt. Eine auf der Exposure basierende Priorisierung stellt sicher, dass sich die Behebungsmaßnahmen auf Fehlkonfigurationen konzentrieren, die tatsächliche Angriffsketten bilden.

Compliance-Anforderungen erfordern oft einen Nachweis über sichere Konfigurationen. Benchmark-Vergleiche wie der CIS Foundations Benchmark oder Frameworks wie NIST 800-53 bieten technische Anleitungen, die den Erwartungen der Behörden entsprechen.

Das Scannen anhand dieser Standards und die Durchsetzung von Korrekturen vor der Bereitstellung kann Ihnen helfen, die Anforderungen zu erfüllen. Außerdem werden Audit-Trails erstellt, die eine fortlaufende Compliance belegen.

Sie möchten mehr über die möglichen Auswirkungen von Cloud-Fehlkonfigurationen erfahren? Lesen Sie, wie unser Forschungsteam herausgefunden hat, dass Cloud-Fehlkonfigurationen sensible Daten und Secrets preisgeben.