Die Shared-Responsibility-Grenze ist klar: Der Cloud-Provider sichert die Infrastruktur — aber die Konfiguration ist Ihre Verantwortung. Und genau dort passieren die Fehler.
Top-Fehlkonfigurationen — die häufigsten Cloud-Security-Fehler
Die Shared Responsibility Model ist das Fundament der Cloud-Security: Der Cloud-Provider (AWS, Azure, GCP) sichert die Infrastruktur (physische Rechenzentren, Netzwerk, Hypervisor), der Kunde sichert alles darüber (Daten, Identitäten, Konfiguration, Anwendungen). Die meisten Cloud-Breaches passieren auf der Kundenseite — nicht weil die Cloud unsicher ist, sondern weil die Konfiguration falsch ist. Die Top-5-Fehlkonfigurationen 2026: 1) Öffentliche Storage Buckets (S3, Azure Blob, GCS), 2) Überprivilegierte IAM-Rollen, 3) Fehlende Verschlüsselung (at rest und in transit), 4) Offene Security Groups / NSGs (0.0.0.0/0 auf SSH/RDP), 5) Fehlende Logging/Monitoring-Konfiguration (CloudTrail deaktiviert).
- S3-Bucket-Fehlkonfigurationen (AWS): Trotz aller Warnungen von AWS sind öffentliche S3-Buckets immer noch eine der häufigsten Ursachen für Datenlecks. Berühmte Fälle: Capital One (2019) — 100 Mio. Kundendaten über SSRF + falsch konfigurierte IAM-Rolle. Twitch (2021) — gesamter Quellcode und Streamer-Einnahmen in öffentlichem Bucket. AWS hat seit 2023 S3 Block Public Access als Default aktiviert — aber ältere Buckets und explizite Policy-Änderungen können den Schutz umgehen. Prüfung: aws s3api get-public-access-block für jeden Bucket. Zusätzlich: Bucket Policies prüfen („Principal“: „*“ = öffentlich).
- Azure Storage Account Exposure: Ähnlich wie S3: Azure Storage Accounts können über Shared Access Signatures (SAS-Tokens) geteilt werden. Risiko: SAS-Tokens mit zu langer Gültigkeit (Jahre statt Stunden), zu breiten Berechtigungen (Read+Write+Delete statt nur Read), oder SAS-Tokens, die in Quellcode/Logs/E-Mails exponiert sind. Azure Blob Public Access: Container-Level (alle Blobs öffentlich) oder Blob-Level (einzelne Blobs öffentlich). Best Practice: Storage Account → Public Access = Disabled auf Account-Level setzen. Azure Policy: „Storage accounts should disable public network access“ als Audit/Deny-Policy.
- Security Groups / NSGs — das offene Scheunentor: AWS Security Groups und Azure NSGs sind virtuelle Firewalls — und die häufigste Fehlkonfiguration:
0.0.0.0/0auf Port 22 (SSH) oder Port 3389 (RDP) — die gesamte Welt kann sich verbinden. Automatisierte Scanner (Shodan, Censys, Masscan) finden diese offenen Ports innerhalb von Minuten nach der Erstellung. AWS Config Rule:restricted-sshundrestricted-common-portserkennen diese Fehlkonfiguration automatisch. Best Practice: Kein direkter SSH/RDP aus dem Internet — stattdessen VPN, AWS Systems Manager Session Manager, oder Azure Bastion. - Fehlende Verschlüsselung: Encryption at Rest: AWS S3/EBS/RDS bieten serverseitige Verschlüsselung (SSE-S3, SSE-KMS) — aber sie muss explizit aktiviert werden (bzw. ist seit 2023 Default für S3, aber nicht für alle Dienste). Azure: Storage Service Encryption ist Default, aber Customer-Managed Keys (CMK) werden für Compliance oft verlangt. Encryption in Transit: Erzwingen Sie HTTPS auf allen Storage-Endpunkten (
aws:SecureTransportCondition in Bucket Policies,supportsHttpsTrafficOnlyin Azure Storage). Database Encryption: RDS/Aurora, Azure SQL — Transparent Data Encryption (TDE) aktivieren, Backup-Verschlüsselung nicht vergessen.
IAM-Privilege-Escalation — der gefährlichste Cloud-Angriffsvektor
Identity and Access Management (IAM) ist in der Cloud das Äquivalent zu Active Directory — und genauso anfällig für Fehlkonfigurationen und Privilege Escalation. In AWS gibt es über 20 dokumentierte IAM-Privilege-Escalation-Pfade (Forschung von Rhino Security Labs): Ein Benutzer mit scheinbar harmlosen Berechtigungen kann sich durch geschickte Kombination von IAM-Aktionen selbst zum Administrator machen. Beispiel: iam:CreatePolicyVersion — ein Benutzer kann eine neue Version seiner eigenen Policy erstellen und sich darin AdministratorAccess geben. iam:AttachUserPolicy — ein Benutzer kann sich selbst jede beliebige Policy zuweisen. iam:PassRole + lambda:CreateFunction — ein Benutzer erstellt eine Lambda-Funktion mit einer hochprivilegierten Rolle und führt sie aus.
- AWS IAM Privilege Escalation (Top 5): 1) iam:CreatePolicyVersion — neue Policy-Version mit
*:*erstellen. 2) iam:AttachUserPolicy / iam:AttachRolePolicy —AdministratorAccessPolicy zuweisen. 3) iam:PutUserPolicy / iam:PutRolePolicy — Inline Policy mit vollen Rechten erstellen. 4) iam:PassRole + ec2:RunInstances — EC2-Instanz mit Admin-Rolle starten und über Instance Metadata die Credentials nutzen. 5) iam:PassRole + lambda:CreateFunction + lambda:InvokeFunction — Lambda mit Admin-Rolle erstellen und ausführen. Tool: PACU (Rhino Security Labs) — AWS Exploitation Framework, automatisiert Privilege Escalation. - Azure RBAC Escalation: In Azure: Owner-Rolle auf einer Resource Group ermöglicht das Zuweisen von Rollen — ein Benutzer mit Owner auf einer RG kann sich selbst Contributor auf dem gesamten Subscription geben (wenn die Vererbung nicht eingeschränkt ist). User Access Administrator auf Subscription-Level kann sich selbst jede Rolle zuweisen. Automation Account Run-As — viele Automation Accounts laufen mit hochprivilegierten Service Principals. Kompromittierung des Automation Accounts = Admin-Zugriff auf den gesamten Tenant. Tool: AzureHound (BloodHound für Azure) — visualisiert Privilege-Escalation-Pfade in Azure/Entra ID.
- Instance Metadata Service (IMDS) Abuse: Alle großen Cloud-Provider bieten einen Metadata-Service (169.254.169.254), über den Instanzen ihre eigenen Konfigurationen und IAM-Credentials abfragen können. SSRF-Schwachstellen in Webanwendungen können diesen Dienst missbrauchen, um IAM-Credentials zu stehlen. IMDSv1 (AWS, Legacy) — einfacher GET-Request genügt — extrem SSRF-anfällig. IMDSv2 (AWS, empfohlen) — erfordert zuerst ein PUT-Request für einen Session-Token, dann GET mit Token — deutlich SSRF-resistenter. Best Practice: IMDSv2-Only erzwingen (
HttpTokens: required), Hop-Limit auf 1 setzen (verhindert SSRF über Container/Proxies). - Least-Privilege-Implementierung: Das Prinzip ist einfach, die Umsetzung komplex: AWS IAM Access Analyzer — analysiert CloudTrail-Logs und generiert Least-Privilege-Policies basierend auf tatsächlicher Nutzung („Sie haben in 90 Tagen nur s3:GetObject und s3:PutObject auf diesen Bucket verwendet — hier ist die eingeschränkte Policy“). AWS Permissions Boundaries — setzen eine maximale Berechtigungsobergrenze, die auch Administratoren nicht überschreiten können. Azure PIM (Privileged Identity Management) — Just-in-Time-Zugriff für privilegierte Azure-Rollen. Service Control Policies (SCP) in AWS Organizations — Guardrails für den gesamten Account (z. B. „Niemand darf CloudTrail deaktivieren“).
CSPM-Strategie & Tools — kontinuierliche Cloud-Sicherheit
CSPM-Tools überprüfen Ihre Cloud-Konfiguration kontinuierlich gegen Best-Practice-Frameworks und alarmieren bei Abweichungen. Die Architektur: Der CSPM-Agent verbindet sich über Read-Only-API-Zugriff (IAM-Rolle in AWS, App Registration in Azure) mit Ihren Cloud-Accounts und enumeriert alle Ressourcen und deren Konfiguration. Anschließend werden Hunderte von Checks ausgeführt: Ist S3-Verschlüsselung aktiviert? Sind Security Groups restriktiv? Ist CloudTrail aktiviert? Ist MFA auf Root-Account aktiviert? Ergebnisse werden als Compliance-Score dargestellt (z. B. „78 % CIS-Benchmark-konform“) mit priorisierten Remediation-Empfehlungen.
- CSPM-Tool-Landschaft 2026: Microsoft Defender for Cloud (ehem. Azure Security Center) — CSPM für Azure, AWS und GCP, integriert in Azure Portal, Secure Score, Regulatory Compliance Dashboard. AWS Security Hub — konsolidiert Findings von GuardDuty, Inspector, IAM Access Analyzer, Config Rules. Prisma Cloud (Palo Alto) — Multi-Cloud CSPM + CWPP + CIEM, marktführend im Gartner Magic Quadrant. Wiz — agentless Cloud-Security-Plattform, Graph-basierte Risikoanalyse („toxic combinations“ — welche Fehlkonfigurationen in Kombination kritisch sind). Open Source: Prowler (AWS/Azure/GCP, CLI-basiert, über 300 Checks), ScoutSuite (NCC Group, Multi-Cloud).
- CIS Benchmarks als Baseline: Die CIS (Center for Internet Security) Benchmarks sind der De-facto-Standard für Cloud-Konfigurationssicherheit: CIS AWS Foundations Benchmark (über 50 Checks in Kategorien: IAM, Logging, Monitoring, Networking, Storage), CIS Azure Foundations Benchmark, CIS GCP Foundations Benchmark. Jeder Check hat ein Profil: Level 1 (grundlegend, geringes Risiko bei Implementierung) und Level 2 (fortgeschritten, kann Funktionalität einschränken). Empfehlung: Level 1 vollständig implementieren, Level 2 risikobasiert. CSPM-Tools können automatisch gegen CIS Benchmarks prüfen.
- Infrastructure as Code (IaC) Security: Fehlkonfigurationen vor dem Deployment erkennen: Checkov (Bridgecrew/Prisma Cloud, Open Source) — scannt Terraform, CloudFormation, Kubernetes-Manifeste auf über 1.000 Security-Checks. tfsec / Trivy (Aqua Security) — Terraform-spezifischer Scanner mit Custom-Rule-Support. KICS (Checkmarx) — Multi-IaC-Scanner. Integration: Pre-commit Hooks (Scan vor Git Commit), CI/CD-Pipeline (Scan in GitHub Actions/GitLab CI — Deployment blockieren bei kritischen Findings), IDE-Plugins (VS Code Extension für Echtzeit-Feedback). Policy-as-Code: OPA/Rego (Open Policy Agent) oder Sentinel (HashiCorp) für Custom-Policies.
- CIEM (Cloud Infrastructure Entitlement Management): CIEM adressiert das spezifische Problem der überprivilegierten Cloud-Identitäten: In einer typischen AWS-Umgebung nutzen Benutzer und Service-Rollen weniger als 5 % ihrer zugewiesenen Berechtigungen. CIEM-Tools analysieren die tatsächliche Nutzung (CloudTrail-Logs) und empfehlen Least-Privilege-Policies. Microsoft Entra Permissions Management (ehem. CloudKnox) — Multi-Cloud CIEM, integriert in Entra Admin Center. Prisma Cloud CIEM — kombiniert mit CSPM. AWS IAM Access Analyzer — AWS-native Lösung für Policy-Analyse und -Generierung. Empfehlung: Permissions Creep Index (PCI) als KPI — Verhältnis zwischen zugewiesenen und genutzten Berechtigungen.
Sie benötigen Unterstützung?
65 % aller Cloud-Incidents gehen auf Fehlkonfigurationen zurück. Wir implementieren CSPM für Ihre AWS/Azure-Umgebung, führen CIS-Benchmark-Audits durch, härten IAM-Policies und integrieren IaC-Security in Ihre CI/CD-Pipeline — damit Fehlkonfigurationen gefunden werden, bevor Angreifer sie finden.
Cloud & Azure ansehen →
