Cloud-Sicherheit Konkret: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
Zeile 1: Zeile 1:
−
= Cloud-Sicherheit – Überblick für Admins und Security-Spezialisten =
+
= Cloud-Sicherheit – Angriff, Kontrolle, Verantwortung =
  
−
== Was ist Cloud Computing? ==
+
== Architekturprinzip Cloud ==
−
* Cloud Computing bedeutet die Bereitstellung von IT-Ressourcen über das Netzwerk, typischerweise das Internet.
+
*Ressourcen werden über APIs gesteuert.
−
* Statt Hardware und Software selbst zu betreiben, nutzt man standardisierte Dienste eines Providers.
+
*Identität ist der zentrale Sicherheitsanker.
−
* Vorteile: Elastizität, Skalierbarkeit, Kostenmodell „Pay-per-Use“, schnelle Bereitstellung.
+
*Netzwerk ist softwaredefiniert.
−
* Servicemodelle:
+
*Konfiguration ersetzt physische Kontrolle.
−
** '''IaaS (Infrastructure as a Service)''': Virtuelle Server, Storage, Netzwerke – Kunde verwaltet Betriebssystem und Applikationen.
+
*Automatisierung ersetzt manuelle Administration.
−
** '''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 ==
+
== Shared Responsibility – Realität ==
−
* Zentrales Konzept: Provider und Kunde teilen sich die Verantwortung für Sicherheit.
+
*Provider sichert Infrastruktur.
−
* Provider: Sicherheit '''der''' Cloud (physische Sicherheit, Virtualisierungsschicht, Rechenzentrumsbetrieb).
+
*Kunde sichert Identität, Konfiguration, Daten.
−
* Kunde: Sicherheit '''in''' der Cloud (Betriebssysteme, Applikationen, Zugriffe, Daten).
+
*Fehlkonfiguration ist häufigste Ursache für Vorfälle.
−
* Je weiter oben das Service-Modell (SaaS), desto weniger Einfluss, aber auch weniger Verantwortung beim Kunden.
+
*Cloud ist nicht automatisch sicher – nur automatisiert.
−
* Typischer Fehler: Kunden nehmen fälschlicherweise an, dass der Provider „alles“ absichert.
 
  
−
== Angriffsvektoren und Risiken ==
+
== Zentrale Angriffsfläche: Identität ==
  
−
* '''Fehlkonfigurationen'''
+
=== Kompromittierter IAM-Account ===
−
** Erklärung: Häufigstes Risiko in der Cloud – falsche Einstellungen führen zu offenen Daten. 
+
;Ausgangslage
−
** Beispiel: AWS S3 (Simple Storage Service) – wenn ein Bucket „öffentlich“ gesetzt ist, sind alle Dateien weltweit abrufbar.
+
*Global-Admin ohne MFA.
−
** Vergleich: Gleiches gilt bei Azure Blob Storage oder Google Cloud Storage.
+
*Statische Access Keys im Einsatz.
  
−
* '''Multi-Tenancy-Risiken'''
+
;Angriff
−
** Erklärung: Provider teilen Hardware und Software zwischen vielen Kunden.
+
*Credential Phishing oder Leak in GitHub.
−
** Risiko: Fehler in der Mandantentrennung können Zugriffe übergreifend ermöglichen.
+
*Login über API.
−
** Beispiel: Side-Channel-Angriffe wie „Spectre“ oder „Meltdown“, die Isolation umgehen.
+
*Neue Admin-User werden angelegt.
 +
*Logs werden manipuliert oder deaktiviert.
  
−
* '''API-Sicherheit'''
+
;Auswirkung
−
** Erklärung: Jede Cloud-Ressource wird über APIs gesteuert – vom VM-Start bis zur Datenbankkonfiguration.
+
*Vollständige Übernahme der Cloud-Umgebung.
−
** Risiko: Gestohlene Credentials = vollständige Kontrolle durch Angreifer.
+
*Backups löschbar.
−
** Beispiel: Versehentlich in GitHub veröffentlichter AWS Access Key → Angreifer nutzen ihn für Krypto-Mining.
+
*Instanzen startbar/stoppbar.
 +
*Daten exfiltrierbar.
  
−
* '''Datenexfiltration'''
+
;Gegenmaßnahmen
−
** Erklärung: Unautorisierte Weitergabe sensibler Daten nach außen.
+
*MFA verpflichtend.
−
** Szenario: Mitarbeiter mit zu vielen Rechten lädt Daten herunter, Malware exfiltriert Logfiles oder Datenbanken.
+
*Kein Root-Login für Tagesbetrieb.
−
** Risiko: Besonders kritisch für personenbezogene Daten (DSGVO) oder Geschäftsgeheimnisse.
+
*Least Privilege.
 +
*CloudTrail/Logging unveränderbar speichern.
  
−
* '''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'''
+
=== Fehlkonfiguration – Offene Storage-Ressourcen ===
−
** Erklärung: Cloud-Umgebungen setzen auf externe Abhängigkeiten (Libraries, Container, Marketplace-Apps). 
+
;Ausgangslage
−
** Risiko: Manipulierte Images oder Libraries infizieren ganze Workloads. 
+
*S3-Bucket oder Blob-Storage öffentlich gesetzt.
−
** Beispiel: Schadcode in öffentlichen Docker-Images, die ungeprüft in Produktion übernommen werden.
 
  
−
* '''DoS/DDoS'''
+
;Angriff
−
** Erklärung: Überlastung von Cloud-Diensten durch massenhafte Anfragen.
+
*Automatisierte Scanner finden offene Buckets.
−
** Risiko: APIs, Load-Balancer oder Webserver werden blockiert, legitime Nutzer ausgesperrt. 
+
*Download sensibler Daten.
−
** Hinweis: Provider bieten Schutz (z. B. AWS Shield, Azure DDoS Protection), aber nur bei aktiver Konfiguration.
 
  
−
* '''Rechtliche Risiken'''
+
;Auswirkung
−
** Erklärung: Gesetze im Sitzland des Providers wirken extraterritorial.
+
*DSGVO-Verstoß.
−
** Beispiel: US CLOUD Act → US-Behörden dürfen auf Daten von US-Cloud-Anbietern zugreifen, auch in Europa.
+
*Reputationsschaden.
−
** Risiko: Konflikte mit Datenschutzgesetzen wie DSGVO, mögliche Bußgelder und Reputationsschäden.
+
*Bußgelder.
  
−
* '''Abhängigkeit (Vendor Lock-in)'''
+
;Gegenmaßnahmen
−
** Erklärung: Proprietäre APIs und Services erschweren den Anbieterwechsel.
+
*Default Private Policies.
−
** Risiko: Technisch und organisatorisch aufwendig, Datenmigration teuer und komplex.
+
*CSPM-Tools.
−
** Folge: Abhängigkeit wird problematisch bei steigenden Kosten, Sicherheitsvorfällen oder regulatorischen Änderungen.
+
*Automatische Compliance-Checks.
 +
*Regelmäßige Audits.
  
−
== Typische Bedrohungsszenarien ==
 
  
−
* '''Krypto-Mining'''
+
=== API-Missbrauch ===
−
** Erklärung: Angreifer stehlen API-Keys oder Zugangsdaten und starten damit virtuelle Maschinen in großem Umfang. 
+
;Ausgangslage
−
** Ziel: Ausnutzen der Cloud-Ressourcen für das Schürfen von Kryptowährungen (z. B. Monero). 
+
*Cloud wird vollständig über APIs gesteuert.
−
** Folgen: Massive Kostenexplosion für den Kunden, Erkennung oft erst über die Abrechnung oder plötzliche Lastspitzen.
+
*Keine Rate-Limits oder Monitoring aktiv.
−
** Beispiel: Tesla 2018 – Angreifer nutzten unsichere Kubernetes-Konfiguration im AWS-Cluster zum Mining.
 
  
−
* '''Ransomware in der Cloud'''
+
;Angriff
−
** Erklärung: Angreifer verschlüsseln Cloud-Ressourcen, z. B. VM-Volumes, Datenbanken oder sogar Backups.
+
*Gestohlener API-Key.
−
** Risiko: Datenzugriff wird blockiert, Betrieb lahmgelegt, Wiederherstellung schwierig, wenn auch die Backups betroffen sind.
+
*Massives Starten von Instanzen.
−
** Besonderheit: Cloud-Snapshots sind oft automatisiert → Angreifer löschen diese zuerst. 
+
*Krypto-Mining.
−
** Folge: Komplette Umgebung kann in Stunden stillgelegt werden.
 
  
−
* '''Fehlende Netzwerktrennung'''
+
;Auswirkung
−
** Erklärung: Test- und Entwicklungsumgebungen sind häufig mit Produktivsystemen verbunden.
+
*Kostenexplosion.
−
** Risiko: Ein kompromittierter Testserver ohne Härtung ermöglicht Pivoting in kritische Produktionssysteme.
+
*Ressourcenverbrauch.
−
** Beispiel: Entwickler-VM mit unsicherer Konfiguration dient als Sprungbrett ins Kernnetz. 
+
*Service-Instabilität.
−
** Folge: Angreifer umgehen Firewalls oder segmentierte Netzwerke, wenn VPCs/Subnets nicht sauber getrennt sind.
 
  
−
* '''Cloud-Ausfall'''
+
;Gegenmaßnahmen
−
** Erklärung: Auch große Provider sind nicht ausfallsicher. Ganze Regionen oder Availability Zones können durch Fehler oder Angriffe ausfallen.
+
*Temporäre Tokens statt statischer Keys.
−
** Beispiel: AWS us-east-1-Ausfall legte global Dienste lahm, darunter Streaming-Plattformen und SaaS-Anwendungen.
+
*Billing Alerts.
−
** Risiko: Fehlendes Multi-Region- oder Multi-Cloud-Design führt zu weltweiten Ausfällen für Endkunden.
+
*API-Monitoring.
−
** Folge: Verfügbarkeit leidet, SLAs werden verletzt, im Worst Case: Geschäftsausfall.
+
*Rollenbasierte Einschränkung.
  
−
* '''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'''
+
=== Laterale Bewegung in der Cloud ===
−
** Erklärung: Angreifer platzieren manipulierte Images, Libraries oder Marketplace-Produkte in die Cloud-Ökosysteme. 
+
;Ausgangslage
−
** Risiko: Kunden laden versehentlich bösartige Ressourcen und übernehmen diese in die eigene Umgebung.
+
*Mehrere VPCs ohne saubere Trennung.
−
** Beispiel: Trojanisierte Container-Images aus Docker Hub, bösartige npm/PyPI-Pakete. 
+
*Übermäßige IAM-Rechte.
−
** Folge: Breite Kompromittierung mehrerer Unternehmen über ein einziges Einfallstor.
 
  
−
* '''Fehlkonfiguration bei Berechtigungen'''
+
;Angriff
−
** Erklärung: Übermäßig generöse IAM-Policies („*:* allow“) oder Default-Rollen ohne Einschränkungen.
+
*Kompromittierte Test-VM.
−
** Risiko: Ein Benutzer oder Dienstkonto erhält weitreichende Rechte und kann komplette Umgebungen kompromittieren.
+
*Auslesen von Metadaten-Service.
−
** Folge: Datenverlust, Ressourcenmissbrauch, Einfallstor für laterale Bewegungen.
+
*Übernahme weiterer Rollen.
  
−
* '''Datenlecks durch Drittdienste'''
+
;Auswirkung
−
** Erklärung: SaaS-Tools oder externe Services werden mit Cloud-APIs verknüpft.
+
*Pivot von Dev nach Prod.
−
** Risiko: Falsch gesetzte OAuth-Tokens oder API-Verbindungen erlauben unkontrollierten Zugriff. 
+
*Zugriff auf Datenbanken.
−
** Beispiel: Drittanbieter-CRM zieht komplette Kundendatenbank aus der Cloud. 
 
−
** Folge: DSGVO-Verstöße, Abfluss sensibler Geschäftsgeheimnisse.
 
  
−
== Wichtige Sicherheitsmaßnahmen ==
+
;Gegenmaßnahmen
−
* '''Identity & Access Management (IAM)''':
+
*Trennung von Dev/Test/Prod.
−
** Prinzip der minimalen Rechte (Least Privilege).
+
*Restriktiver Zugriff auf Instance Metadata.
−
** Rollen statt statische Benutzerkonten.
+
*Service Control Policies.
−
** '''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'''
+
=== Ransomware in Cloud-Umgebungen ===
−
** Sicherheitsrichtlinien und Compliance-Anforderungen von Beginn an in die Architektur einplanen. 
+
;Ausgangslage
−
** Beispiel: Zugriffskontrollen, Verschlüsselung, Logging gleich in IaC-Templates integrieren.
+
*Backups nicht isoliert.
−
** Vorteil: Weniger Aufwand, als Sicherheitslücken nachträglich zu schließen.
+
*Snapshots löschbar.
  
−
* '''Infrastructure as Code (IaC)'''
+
;Angriff
−
** Terraform, Ansible oder CloudFormation nutzen, um Infrastruktur reproduzierbar und überprüfbar bereitzustellen.
+
*Admin-Zugang kompromittiert.
−
** Security Policies als Code (z. B. OPA, AWS Config Rules) → automatisierte Kontrolle. 
+
*Snapshots gelöscht.
−
** Vorteil: Änderungen sind versioniert, nachvollziehbar und auditierbar.
+
*Datenbanken verschlüsselt.
  
−
* '''Cloud-native Sicherheitsdienste'''
+
;Auswirkung
−
** AWS GuardDuty, Azure Defender, GCP Security Command Center aktivieren und regelmäßig auswerten.
+
*Totalausfall.
−
** Ergänzend: CSPM-Tools (Cloud Security Posture Management) für kontinuierliche Konfigurationsprüfung. 
+
*Keine Wiederherstellung möglich.
−
** Vorteil: Provider-spezifische Bedrohungserkennung nutzen, um Angriffe schneller zu erkennen.
 
  
−
* '''Regelmäßige Penetrationstests und Red-Team-Übungen'''
+
;Gegenmaßnahmen
−
** Cloud-spezifische Szenarien testen (Credential Theft, IAM-Fehler, API-Missbrauch).
+
*Immutable Backups.
−
** In Abstimmung mit dem Provider (z. B. AWS Penetration Testing Policy).
+
*Versionierung aktivieren.
−
** Ziel: Erkennen von Schwachstellen und Lücken in Detection & Response.
+
*Backup-Zugriff getrennt absichern.
  
−
* '''Backup-Strategie'''
 
−
** Backups verschlüsseln und physisch/logisch vom Produktionssystem trennen. 
 
−
** Testen der Wiederherstellung in regelmäßigen Intervallen. 
 
−
** Wichtig: Backups gegen Manipulation oder Löschung absichern (z. B. Immutable Storage, Versioning). 
 
  
−
* '''Kosten- und Ressourcenüberwachung'''
+
== Systemische Risiken ==
−
** Aktivierung von Billing-Alerts und Limits. 
 
−
** Plötzliche Kosten- oder Lastspitzen können Hinweis auf Kompromittierung (z. B. Krypto-Mining) sein. 
 
−
** Vorteil: Früherkennung von Missbrauch. 
 
  
−
* '''Datenminimierung und Pseudonymisierung'''
+
=== Vendor Lock-In ===
−
** Nur notwendige Daten in der Cloud speichern.
+
*Proprietäre Services erschweren Migration.
−
** Sensible Daten verschlüsseln oder pseudonymisieren. 
+
*Sicherheitsstrategie wird an Provider gebunden.
−
** Vorteil: Reduzierung des Schadenspotentials bei Datenabfluss.
 
  
−
* '''Least Privilege und Zero Trust'''
+
=== Multi-Cloud-Komplexität ===
−
** IAM-Richtlinien streng nach Minimalprinzip.
+
*Unterschiedliche IAM-Modelle.
−
** Zero-Trust-Architektur: Jeder Zugriff wird geprüft, auch interne.
+
*Unterschiedliche Logging-Systeme.
−
** Beispiel: Service-to-Service-Kommunikation nur über authentifizierte Endpunkte.
+
*Policy-Inkonsistenzen möglich.
  
−
* '''Multi-Region / Multi-Cloud-Strategie'''
+
=== Rechtliche Risiken ===
−
** Dienste über mehrere Regionen oder Anbieter verteilen, um Single Points of Failure zu vermeiden.
+
*Datenstandort relevant.
−
** Failover-Mechanismen testen (Chaos Engineering).
+
*Extraterritoriale Zugriffsrechte möglich.
−
** Vorteil: Höhere Resilienz gegenüber Cloud-Ausfällen.
+
*Compliance-Anforderungen prüfen.
  
−
* '''Netzwerksegmentierung'''
 
−
** Trennung von Entwicklungs-, Test- und Produktionsumgebungen. 
 
−
** Private Subnetze für interne Systeme, Public nur für notwendige Dienste. 
 
−
** Vorteil: Eingeschränkte Bewegungsmöglichkeiten für Angreifer. 
 
  
−
* '''Monitoring, Logging & SIEM-Integration'''
+
== Verteidigungsstrategie ==
−
** Alle Logs zentralisieren (CloudTrail, VPC Flow Logs, Azure Activity Logs). 
 
−
** Anbindung an ein zentrales SIEM (Splunk, ELK, Sentinel). 
 
−
** Vorteil: Anomalien und Angriffe frühzeitig erkennen. 
 
  
−
* '''Patch- und Schwachstellenmanagement'''
+
;Identität
−
** Regelmäßige Aktualisierung von VMs, Containern, Plattform-Komponenten.
+
*Zero Trust.
−
** Nutzung von Security-Scannern (z. B. AWS Inspector, Qualys, Nessus). 
+
*Rollen statt Benutzer.
−
** Vorteil: Minimierung der Angriffsfläche.
+
*MFA für alle privilegierten Accounts.
 +
*Regelmäßige Rechteprüfung.
  
−
* '''Schulung und Awareness'''
+
;Netzwerk
−
** Admins und Entwickler in Cloud-Security-Konzepten regelmäßig schulen.
+
*Private Subnetze.
−
** Typische Fehler (z. B. offene S3-Buckets) aktiv in Awareness-Programme aufnehmen. 
+
*Security Groups minimal.
−
** Vorteil: Fehlerprävention durch Wissenstransfer.
+
*Keine offenen Management-Ports.
  
−
== Praxisbeispiele für Cloud-Sicherheitsvorfälle ==
+
;Verschlüsselung
 +
*Data at Rest standardmäßig aktiv.
 +
*Customer Managed Keys prüfen.
 +
*TLS 1.2/1.3 erzwingen.
  
−
* '''Offene S3-Buckets'''
+
;Monitoring
−
** Erklärung: S3 (Simple Storage Service) ist Amazons Objektspeicher. Standardmäßig privat, kann aber auf „öffentlich“ gesetzt werden. 
+
*Zentrale Log-Aggregation.
−
** Vorfälle: Zahlreiche Unternehmen (z. B. Facebook, Verizon, Accenture) haben vertrauliche Daten wie Quellcode, Kundendaten oder Passwörter ungeschützt im Internet hinterlassen. 
+
*Anomalieerkennung.
−
** Risiko: Jeder mit Link oder Tools wie „bucket finder“ kann Daten abrufen. 
+
*Alarmierung bei IAM-Änderungen.
−
** Lehre: Standardmäßig private Konfigurationen beibehalten, regelmäßige Audits und CSPM-Tools einsetzen.
 
  
−
* '''Tesla-Fall 2018'''
+
;Resilienz
−
** Erklärung: Angreifer fanden eine fehlerhafte Kubernetes-Konfiguration im AWS-Cluster von Tesla.
+
*Multi-Region-Architektur.
−
** Vorgehen: Über ein öffentlich erreichbares Dashboard gelangten sie an Zugangsdaten und starteten daraufhin Container zum Krypto-Mining.
+
*Regelmäßige Restore-Tests.
−
** Risiko: Hohe Betriebskosten, Performanceverlust, potenzielle Datenexfiltration. 
+
*Chaos-Tests durchführen.
−
** Lehre: Kubernetes-Dashboards absichern (z. B. RBAC, kein öffentlicher Zugriff), Secrets nie unverschlüsselt speichern.
 
  
−
* '''Code-Spiegelung bei GitHub'''
 
−
** Erklärung: Entwickler speicherten Cloud-API-Keys versehentlich in öffentlichen Repositories. 
 
−
** Angreifer konnten mit diesen Tokens auf interne Ressourcen zugreifen, darunter Quellcode großer Unternehmen. 
 
−
** Beispiel: 2020 wurden tausende GitHub-Repos nach hartcodierten AWS-Keys durchsucht – teils automatisiert mit Bots. 
 
−
** Lehre: Secrets Management (z. B. Vault, AWS Secrets Manager) einsetzen, Scans auf geleakte Keys automatisieren (GitHub Secret Scanning). 
 
  
−
* '''US-East-1-Ausfall 2020'''
+
== Kernaussage ==
−
** Erklärung: AWS-Region us-east-1 (Virginia) fiel durch interne Netzwerkprobleme aus. 
+
*Cloud ist API-gesteuerte Infrastruktur.
−
** Folge: Weltweit waren große Dienste wie Adobe, Roku, Flickr oder iRobot für Stunden nicht erreichbar. 
+
*Identität ist der zentrale Angriffspunkt.
−
** Risiko: Dienste mit Single-Region-Architektur waren komplett offline. 
+
*Fehlkonfiguration schlägt technische Schutzmaßnahmen.
−
** Lehre: Multi-Region-Design einplanen, kritische Workloads geografisch redundant betreiben, Chaos-Tests durchführen.
+
*Automatisierung kann Sicherheit erhöhen – oder Fehler skalieren.
−
 
 
−
== Herausforderungen für Admins und Security-Spezialisten ==
 
−
 
 
−
* '''Komplexität'''
 
−
** Erklärung: Cloud-Anbieter bieten hunderte Services an (Compute, Storage, KI, Datenbanken, Netzwerk, Security).
 
−
** Herausforderung: Neue Services und Funktionen werden im Monatsrhythmus eingeführt oder geändert.
 
−
** Risiko: Security-Teams verlieren leicht den Überblick, Best Practices ändern sich ständig. 
 
−
** Lehre: Standardisierte Architekturen und kontinuierliche Weiterbildung sind notwendig. 
 
−
 
 
−
* '''Transparenz'''
 
−
** Erklärung: Kunden haben kaum Einblick in die physischen Schichten (Hardware, Hypervisor, interne Netzwerke). 
 
−
** Abhängigkeit: Man muss den Provider-Reports und Zertifizierungen vertrauen (z. B. SOC2, ISO 27001, BSI C5). 
 
−
** Risiko: Fehlende Sichtbarkeit erschwert Forensik, Incident Response und Root-Cause-Analysen. 
 
−
** Lehre: Logging & Monitoring konsequent selbst aufbauen und nicht nur Provider-Angaben verlassen. 
 
−
 
 
−
* '''Multi-Cloud-Szenarien'''
 
−
** Erklärung: Viele Unternehmen nutzen mehr als einen Anbieter (z. B. AWS + Azure + GCP). 
 
−
** Herausforderung: Jedes Ökosystem hat eigene Security-Modelle, IAM-Systeme und APIs. 
 
−
** Risiko: Inkonsistente Policies, erhöhte Komplexität, „Blind Spots“ zwischen Clouds. 
 
−
** Lehre: Einheitliche Governance, Cloud Security Posture Management (CSPM) und möglichst abstrahierende Tools einsetzen. 
 
−
 
 
−
* '''Skills und Know-how'''
 
−
** Erklärung: Security-Teams müssen neben klassischen IT-Skills auch Cloud-spezifische Themen beherrschen (z. B. IAM, API-Security, Container, Serverless). 
 
−
** Risiko: Fachkräftemangel verschärft die Situation – viele Teams sind überlastet oder nicht ausreichend geschult. 
 
−
** Herausforderung: Incident Response in der Cloud erfordert andere Methoden als On-Premises (Snapshots, API-Logs statt physischer Forensik). 
 
−
** Lehre: Investition in Schulungen, Cloud-Security-Zertifizierungen (z. B. CCSK, CCSP, AWS Security Specialty).
 
−
 
 
−
== 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
 

Aktuelle Version vom 20. Februar 2026, 16:01 Uhr

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.
Abgerufen von „http://wiki.ixheim.de/index.php?title=Cloud-Sicherheit_Konkret&oldid=67173“