Cloud-Sicherheit Konkret

Cloud-Sicherheit – Angriff, Kontrolle, Verantwortung

Architekturprinzip Cloud

• Ressourcen werden über APIs gesteuert.
• Identität ist der zentrale Sicherheitsanker.
• Netzwerk ist softwaredefiniert.
• Konfiguration ersetzt physische Kontrolle.
• Automatisierung ersetzt manuelle Administration.

Shared Responsibility – Realität

• Provider sichert Infrastruktur.
• Kunde sichert Identität, Konfiguration, Daten.
• Fehlkonfiguration ist häufigste Ursache für Vorfälle.
• Cloud ist nicht automatisch sicher – nur automatisiert.

Zentrale Angriffsfläche: Identität

Kompromittierter IAM-Account

Ausgangslage

• Global-Admin ohne MFA.
• Statische Access Keys im Einsatz.

Angriff

• Credential Phishing oder Leak in GitHub.
• Login über API.
• Neue Admin-User werden angelegt.
• Logs werden manipuliert oder deaktiviert.

Auswirkung

• Vollständige Übernahme der Cloud-Umgebung.
• Backups löschbar.
• Instanzen startbar/stoppbar.
• Daten exfiltrierbar.

Gegenmaßnahmen

• MFA verpflichtend.
• Kein Root-Login für Tagesbetrieb.
• Least Privilege.
• CloudTrail/Logging unveränderbar speichern.

Fehlkonfiguration – Offene Storage-Ressourcen

Ausgangslage

• S3-Bucket oder Blob-Storage öffentlich gesetzt.

Angriff

• Automatisierte Scanner finden offene Buckets.
• Download sensibler Daten.

Auswirkung

• DSGVO-Verstoß.
• Reputationsschaden.
• Bußgelder.

Gegenmaßnahmen

• Default Private Policies.
• CSPM-Tools.
• Automatische Compliance-Checks.
• Regelmäßige Audits.

API-Missbrauch

Ausgangslage

• Cloud wird vollständig über APIs gesteuert.
• Keine Rate-Limits oder Monitoring aktiv.

Angriff

• Gestohlener API-Key.
• Massives Starten von Instanzen.
• Krypto-Mining.

Auswirkung

• Kostenexplosion.
• Ressourcenverbrauch.
• Service-Instabilität.

Gegenmaßnahmen

• Temporäre Tokens statt statischer Keys.
• Billing Alerts.
• API-Monitoring.
• Rollenbasierte Einschränkung.

Laterale Bewegung in der Cloud

Ausgangslage

• Mehrere VPCs ohne saubere Trennung.
• Übermäßige IAM-Rechte.

Angriff

• Kompromittierte Test-VM.
• Auslesen von Metadaten-Service.
• Übernahme weiterer Rollen.

Auswirkung

• Pivot von Dev nach Prod.
• Zugriff auf Datenbanken.

Gegenmaßnahmen

• Trennung von Dev/Test/Prod.
• Restriktiver Zugriff auf Instance Metadata.
• Service Control Policies.

Ransomware in Cloud-Umgebungen

Ausgangslage

• Backups nicht isoliert.
• Snapshots löschbar.

Angriff

• Admin-Zugang kompromittiert.
• Snapshots gelöscht.
• Datenbanken verschlüsselt.

Auswirkung

• Totalausfall.
• Keine Wiederherstellung möglich.

Gegenmaßnahmen

• Immutable Backups.
• Versionierung aktivieren.
• Backup-Zugriff getrennt absichern.

Systemische Risiken

Vendor Lock-In

• Proprietäre Services erschweren Migration.
• Sicherheitsstrategie wird an Provider gebunden.

Multi-Cloud-Komplexität

• Unterschiedliche IAM-Modelle.
• Unterschiedliche Logging-Systeme.
• Policy-Inkonsistenzen möglich.

Rechtliche Risiken

• Datenstandort relevant.
• Extraterritoriale Zugriffsrechte möglich.
• Compliance-Anforderungen prüfen.

Verteidigungsstrategie

Identität

• Zero Trust.
• Rollen statt Benutzer.
• MFA für alle privilegierten Accounts.
• Regelmäßige Rechteprüfung.

Netzwerk

• Private Subnetze.
• Security Groups minimal.
• Keine offenen Management-Ports.

Verschlüsselung

• Data at Rest standardmäßig aktiv.
• Customer Managed Keys prüfen.
• TLS 1.2/1.3 erzwingen.

Monitoring

• Zentrale Log-Aggregation.
• Anomalieerkennung.
• Alarmierung bei IAM-Änderungen.

Resilienz

• Multi-Region-Architektur.
• Regelmäßige Restore-Tests.
• Chaos-Tests durchführen.

Kernaussage

• Cloud ist API-gesteuerte Infrastruktur.
• Identität ist der zentrale Angriffspunkt.
• Fehlkonfiguration schlägt technische Schutzmaßnahmen.
• Automatisierung kann Sicherheit erhöhen – oder Fehler skalieren.