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: Angreifer nutzen geklaute Access-Keys, um teure Compute-Ressourcen zu missbrauchen.
• Ransomware in der Cloud: Verschlüsselung von VM-Volumes, Datenbanken oder Backups.
• Fehlende Netzwerktrennung: Ein kompromittiertes Testsystem wird zum Einfallstor für Produktionssysteme.
• Cloud-Ausfall: Region oder Availability Zone fällt aus (z. B. AWS us-east-1) – Dienste global betroffen.

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