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:

 Oft das größte Risiko in Cloud-Umgebungen. Beispiel: AWS S3 (Simple Storage Service) ist ein Objektspeicher.  
 Wird ein S3-Bucket „öffentlich“ konfiguriert, kann jeder im Internet darauf zugreifen – inklusive vertraulicher Daten wie Backups, Quellcode oder personenbezogener Informationen.  
 Vergleichbar bei Azure Blob Storage oder Google Cloud Storage.  

• Multi-Tenancy-Risiken:

 Cloud-Provider betreiben für viele Kunden gleichzeitig Hardware und Software.  
 Normalerweise ist eine strikte Trennung (Mandantentrennung) vorgesehen, z. B. über Hypervisoren oder Container-Isolation.  
 Fehler in diesen Mechanismen (z. B. Side-Channel-Angriffe wie „Spectre/Meltdown“) könnten Angreifern Zugriff auf fremde Daten ermöglichen.  

• API-Sicherheit:

 Alle Cloud-Dienste (VM-Erstellung, Datenbankzugriff, Netzwerksteuerung) laufen über Management-APIs.  
 Wer gültige Zugangsdaten (Access Keys, Tokens) hat, kann über die API Ressourcen starten, Daten kopieren oder löschen.  
 Beispiel: Ein gestohlener AWS Access Key in einer GitHub-Repo kann von Angreifern sofort zum Missbrauch genutzt werden (z. B. für Krypto-Mining).  

• Datenexfiltration:

 Vertrauliche Daten können absichtlich oder unabsichtlich nach außen gelangen.  
 Szenarien: Mitarbeiter mit weitreichenden Rechten kopiert Daten, Schadsoftware leitet Logs oder Datenbanken weiter, oder falsch gesetzte Zugriffsrechte machen Daten für Externe abrufbar.  
 Besonders kritisch: personenbezogene Daten (DSGVO), Finanzdaten oder interne Geschäftsgeheimnisse.  

• Kompromittierte Management-Accounts:

 Root-Account bei AWS oder Global Admin bei Azure = volle Kontrolle über die Umgebung.  
 Ohne MFA und restriktive Policies ist ein kompromittierter Admin-Account katastrophal: Angreifer können VMs starten, Backups löschen, Logs manipulieren und Spuren verwischen.  
 In der Praxis einer der häufigsten Gründe für Totalverlust einer Cloud-Umgebung.  

• Supply-Chain-Angriffe:

 Cloud-Umgebungen nutzen viele externe Abhängigkeiten (Container-Images, Libraries, SaaS-Dienste).  
 Angreifer können manipulierte Docker-Images in ein öffentliches Repository hochladen → wenn diese in Produktion landen, ist das gesamte System kompromittiert.  
 Auch Marketplace-Apps (z. B. VM-Images oder Plug-ins) können Hintertüren enthalten.  

• DoS/DDoS:

 Cloud-Services sind öffentlich erreichbar. Angreifer können diese durch massive Anfragen überlasten.  
 Beispiele: API-Gateway, Load-Balancer oder Webserver werden mit Traffic geflutet, sodass legitime Anfragen nicht mehr beantwortet werden.  
 Zwar bieten Provider Schutzmaßnahmen (z. B. AWS Shield, Azure DDoS Protection), aber ohne Konfiguration greifen diese nicht automatisch.  

• Rechtliche Risiken:

 Daten können durch Gesetze im Sitzland des Providers zugänglich werden (z. B. US Cloud Act = US-Behörden können auf Daten von US-Cloud-Anbietern zugreifen, auch wenn diese in Europa gespeichert sind).  
 Zudem gelten Datenschutzanforderungen wie DSGVO, die nicht immer leicht mit global verteilten Cloud-Diensten vereinbar sind.  
 Folge: Compliance-Verstöße, hohe Bußgelder und Imageverlust.  

• Abhängigkeit (Vendor Lock-in):

 Ein Wechsel zwischen Cloud-Anbietern ist technisch und organisatorisch schwierig, da APIs, Services und Datenmodelle oft proprietär sind.  
 Hat man einmal viele Systeme bei einem Anbieter integriert, ist man faktisch „gefangen“.  
 Problematisch, wenn Kosten steigen, Sicherheitsprobleme bekannt werden oder regulatorische Anforderungen nicht mehr erfüllt sind.

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