Cloud-Sicherheit Konkret

Cloud-Sicherheit – Überblick für Admins und Security-Spezialisten

Was ist Cloud Computing?

• Cloud Computing bedeutet die Bereitstellung von IT-Ressourcen über das Netzwerk, typischerweise das Internet.
• Statt Hardware und Software selbst zu betreiben, nutzt man standardisierte Dienste eines Providers.
• Vorteile: Elastizität, Skalierbarkeit, Kostenmodell „Pay-per-Use“, schnelle Bereitstellung.
• Servicemodelle:
  • IaaS (Infrastructure as a Service): Virtuelle Server, Storage, Netzwerke – Kunde verwaltet Betriebssystem und Applikationen.
  • PaaS (Platform as a Service): Plattformen wie Datenbanken, Webserver – Kunde verwaltet nur Code und Daten.
  • SaaS (Software as a Service): Fertige Anwendungen wie Office 365 oder Salesforce – Kunde hat fast nur Anwenderrolle.
• Deployment-Modelle:
  • Public Cloud: Gemeinsame Infrastruktur, offen für alle Kunden (AWS, Azure, GCP).
  • Private Cloud: Dedizierte Ressourcen, meist im eigenen Rechenzentrum.
  • Hybrid Cloud: Kombination aus Public und Private.
  • Community Cloud: Gemeinsame Infrastruktur für Organisationen mit ähnlichen Anforderungen.

Shared Responsibility Model

• Zentrales Konzept: Provider und Kunde teilen sich die Verantwortung für Sicherheit.
• Provider: Sicherheit der Cloud (physische Sicherheit, Virtualisierungsschicht, Rechenzentrumsbetrieb).
• Kunde: Sicherheit in der Cloud (Betriebssysteme, Applikationen, Zugriffe, Daten).
• Je weiter oben das Service-Modell (SaaS), desto weniger Einfluss, aber auch weniger Verantwortung beim Kunden.
• Typischer Fehler: Kunden nehmen fälschlicherweise an, dass der Provider „alles“ absichert.

Angriffsvektoren und Risiken

• Fehlkonfigurationen
  • Erklärung: Häufigstes Risiko in der Cloud – falsche Einstellungen führen zu offenen Daten.
  • Beispiel: AWS S3 (Simple Storage Service) – wenn ein Bucket „öffentlich“ gesetzt ist, sind alle Dateien weltweit abrufbar.
  • Vergleich: Gleiches gilt bei Azure Blob Storage oder Google Cloud Storage.

• Multi-Tenancy-Risiken
  • Erklärung: Provider teilen Hardware und Software zwischen vielen Kunden.
  • Risiko: Fehler in der Mandantentrennung können Zugriffe übergreifend ermöglichen.
  • Beispiel: Side-Channel-Angriffe wie „Spectre“ oder „Meltdown“, die Isolation umgehen.

• API-Sicherheit
  • Erklärung: Jede Cloud-Ressource wird über APIs gesteuert – vom VM-Start bis zur Datenbankkonfiguration.
  • Risiko: Gestohlene Credentials = vollständige Kontrolle durch Angreifer.
  • Beispiel: Versehentlich in GitHub veröffentlichter AWS Access Key → Angreifer nutzen ihn für Krypto-Mining.

• Datenexfiltration
  • Erklärung: Unautorisierte Weitergabe sensibler Daten nach außen.
  • Szenario: Mitarbeiter mit zu vielen Rechten lädt Daten herunter, Malware exfiltriert Logfiles oder Datenbanken.
  • Risiko: Besonders kritisch für personenbezogene Daten (DSGVO) oder Geschäftsgeheimnisse.

• Kompromittierte Management-Accounts
  • Erklärung: Root- oder Global-Admin-Accounts sind der „Generalschlüssel“ der Cloud.
  • Risiko: Ohne MFA und strikte Policies können Angreifer alles übernehmen.
  • Folge: VMs starten/stoppen, Backups löschen, Logs manipulieren → vollständige Kontrolle.

• Supply-Chain-Angriffe
  • Erklärung: Cloud-Umgebungen setzen auf externe Abhängigkeiten (Libraries, Container, Marketplace-Apps).
  • Risiko: Manipulierte Images oder Libraries infizieren ganze Workloads.
  • Beispiel: Schadcode in öffentlichen Docker-Images, die ungeprüft in Produktion übernommen werden.

• DoS/DDoS
  • Erklärung: Überlastung von Cloud-Diensten durch massenhafte Anfragen.
  • Risiko: APIs, Load-Balancer oder Webserver werden blockiert, legitime Nutzer ausgesperrt.
  • Hinweis: Provider bieten Schutz (z. B. AWS Shield, Azure DDoS Protection), aber nur bei aktiver Konfiguration.

• Rechtliche Risiken
  • Erklärung: Gesetze im Sitzland des Providers wirken extraterritorial.
  • Beispiel: US CLOUD Act → US-Behörden dürfen auf Daten von US-Cloud-Anbietern zugreifen, auch in Europa.
  • Risiko: Konflikte mit Datenschutzgesetzen wie DSGVO, mögliche Bußgelder und Reputationsschäden.

• Abhängigkeit (Vendor Lock-in)
  • Erklärung: Proprietäre APIs und Services erschweren den Anbieterwechsel.
  • Risiko: Technisch und organisatorisch aufwendig, Datenmigration teuer und komplex.
  • Folge: Abhängigkeit wird problematisch bei steigenden Kosten, Sicherheitsvorfällen oder regulatorischen Änderungen.

Typische Bedrohungsszenarien

• Krypto-Mining
  • Erklärung: Angreifer stehlen API-Keys oder Zugangsdaten und starten damit virtuelle Maschinen in großem Umfang.
  • Ziel: Ausnutzen der Cloud-Ressourcen für das Schürfen von Kryptowährungen (z. B. Monero).
  • Folgen: Massive Kostenexplosion für den Kunden, Erkennung oft erst über die Abrechnung oder plötzliche Lastspitzen.
  • Beispiel: Tesla 2018 – Angreifer nutzten unsichere Kubernetes-Konfiguration im AWS-Cluster zum Mining.

• Ransomware in der Cloud
  • Erklärung: Angreifer verschlüsseln Cloud-Ressourcen, z. B. VM-Volumes, Datenbanken oder sogar Backups.
  • Risiko: Datenzugriff wird blockiert, Betrieb lahmgelegt, Wiederherstellung schwierig, wenn auch die Backups betroffen sind.
  • Besonderheit: Cloud-Snapshots sind oft automatisiert → Angreifer löschen diese zuerst.
  • Folge: Komplette Umgebung kann in Stunden stillgelegt werden.

• Fehlende Netzwerktrennung
  • Erklärung: Test- und Entwicklungsumgebungen sind häufig mit Produktivsystemen verbunden.
  • Risiko: Ein kompromittierter Testserver ohne Härtung ermöglicht Pivoting in kritische Produktionssysteme.
  • Beispiel: Entwickler-VM mit unsicherer Konfiguration dient als Sprungbrett ins Kernnetz.
  • Folge: Angreifer umgehen Firewalls oder segmentierte Netzwerke, wenn VPCs/Subnets nicht sauber getrennt sind.

• Cloud-Ausfall
  • Erklärung: Auch große Provider sind nicht ausfallsicher. Ganze Regionen oder Availability Zones können durch Fehler oder Angriffe ausfallen.
  • Beispiel: AWS us-east-1-Ausfall legte global Dienste lahm, darunter Streaming-Plattformen und SaaS-Anwendungen.
  • Risiko: Fehlendes Multi-Region- oder Multi-Cloud-Design führt zu weltweiten Ausfällen für Endkunden.
  • Folge: Verfügbarkeit leidet, SLAs werden verletzt, im Worst Case: Geschäftsausfall.

• Shadow IT
  • Erklärung: Mitarbeiter oder Abteilungen nutzen ohne Wissen der IT eigene Cloud-Dienste (z. B. Dropbox, Trello, Google Drive).
  • Risiko: Sicherheitslücken, unkontrollierte Datenhaltung, Umgehung von Unternehmensrichtlinien.
  • Folge: Datenabfluss oder Compliance-Verstöße, keine zentrale Kontrolle über Berechtigungen und Zugriffe.

• Supply-Chain-Kompromittierung
  • Erklärung: Angreifer platzieren manipulierte Images, Libraries oder Marketplace-Produkte in die Cloud-Ökosysteme.
  • Risiko: Kunden laden versehentlich bösartige Ressourcen und übernehmen diese in die eigene Umgebung.
  • Beispiel: Trojanisierte Container-Images aus Docker Hub, bösartige npm/PyPI-Pakete.
  • Folge: Breite Kompromittierung mehrerer Unternehmen über ein einziges Einfallstor.

• Fehlkonfiguration bei Berechtigungen
  • Erklärung: Übermäßig generöse IAM-Policies („*:* allow“) oder Default-Rollen ohne Einschränkungen.
  • Risiko: Ein Benutzer oder Dienstkonto erhält weitreichende Rechte und kann komplette Umgebungen kompromittieren.
  • Folge: Datenverlust, Ressourcenmissbrauch, Einfallstor für laterale Bewegungen.

• Datenlecks durch Drittdienste
  • Erklärung: SaaS-Tools oder externe Services werden mit Cloud-APIs verknüpft.
  • Risiko: Falsch gesetzte OAuth-Tokens oder API-Verbindungen erlauben unkontrollierten Zugriff.
  • Beispiel: Drittanbieter-CRM zieht komplette Kundendatenbank aus der Cloud.
  • Folge: DSGVO-Verstöße, Abfluss sensibler Geschäftsgeheimnisse.

Wichtige Sicherheitsmaßnahmen

• Identity & Access Management (IAM):
  • Prinzip der minimalen Rechte (Least Privilege).
  • Rollen statt statische Benutzerkonten.
  • MFA für alle privilegierten Accounts.
  • Rotieren und minimieren von API-Keys, besser Nutzung temporärer Tokens.
• Netzwerksicherheit & Zero Trust:
  • Private Subnetze, Security Groups, Network ACLs.
  • Zero Trust Ansatz: Jeder Zugriff wird geprüft, auch intern.
  • Einsatz von VPN oder Private Link für Managementzugriff.
• Verschlüsselung:
  • Data-at-Rest: Standard bei Cloud-Anbietern, Schlüsselmanagement entscheidend.
  • Data-in-Transit: TLS 1.2/1.3 erzwingen.
  • Bring Your Own Key (BYOK) oder Customer Managed Keys (CMK).
• Monitoring & Logging:
  • CloudTrail, CloudWatch, Azure Monitor, GCP Cloud Logging.
  • Logs an zentrales SIEM weiterleiten.
  • Alarmierung bei Anomalien.
• Compliance & Governance:
  • Orientierung an Standards: ISO 27001, SOC 2, BSI C5.
  • Policy as Code: Terraform, OPA, AWS Config.
  • Cloud Security Posture Management (CSPM).
• Incident Response:
  • Vorbereitung spezieller Cloud-Playbooks.
  • Isolieren kompromittierter Instanzen (z. B. Quarantine VPC).
  • Forensische Sicherung: Snapshots, Log-Export.

Best Practices für den sicheren Cloud-Betrieb

• Security by Design: Sicherheitsrichtlinien von Anfang an in Deployments integrieren.
• Infrastructure as Code (IaC) nutzen, um reproduzierbare, überprüfbare Setups zu haben.
• Cloud-native Sicherheitsdienste nutzen (AWS GuardDuty, Azure Defender, GCP Security Command Center).
• Regelmäßige Penetrationstests und Red-Team-Übungen auch in der Cloud-Umgebung.
• Backups verschlüsseln, getrennt ablegen, Wiederherstellung regelmäßig testen.
• Kostenüberwachung aktivieren – plötzliche Peaks können Hinweise auf Missbrauch sein.
• Sensible Daten vor Speicherung anonymisieren oder pseudonymisieren.

Praxisnahe Beispiele

• Offene S3-Buckets führten bei zahlreichen Unternehmen (z. B. Facebook, Verizon) zu massiven Datenlecks.
• Tesla-Fall 2018: Angreifer nutzten fehlerhafte Kubernetes-Konfiguration, um Krypto-Mining im AWS-Cluster zu betreiben.
• Code-Spiegelung bei GitHub: Angreifer nutzten geleakte Access-Tokens, um Quellcode großer Unternehmen zu kopieren.
• US-East-1-Ausfall 2020: Zahlreiche Dienste weltweit nicht erreichbar, da keine Redundanz über Regionen hinweg geplant war.

Herausforderungen für Admins und Security-Spezialisten

• Komplexität: Vielzahl an Services, schnelllebige Weiterentwicklung.
• Transparenz: Wenig Einblick in physische Schichten, starke Abhängigkeit von Provider-Trust.
• Multi-Cloud-Szenarien: Unterschiedliche Sicherheitsmodelle pro Anbieter.
• Skills: Security-Teams benötigen spezielles Wissen über Cloud-spezifische Dienste, APIs, Tools.

Quellen

• BSI C5: Cloud Computing Compliance Controls Catalogue
• ENISA Cloud Security Guidelines
• NIST SP 800-144: Guidelines on Security and Privacy in Public Cloud Computing
• Cloud Security Alliance (CSA) Cloud Controls Matrix
• AWS Well-Architected Framework – Security Pillar