Cloud-Sicherheit Konkret: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „= Cloud-Sicherheit – Überblick für Admins und Security-Spezialisten = == Was ist Cloud Computing? == * Cloud Computing bedeutet die Bereitstellung von IT-…“)
 
 
(6 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
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''': Offene S3-Buckets, zu weitreichende IAM-Rollen, unsichere API-Endpunkte.
 
−
* '''Multi-Tenancy-Risiken''': Mandantentrennung kann bei Implementierungsfehlern ausgenutzt werden.
 
−
* '''API-Sicherheit''': Alle Cloud-Dienste werden über APIs gesteuert. Gestohlene Credentials = volle Kontrolle.
 
−
* '''Datenexfiltration''': Durch Insider, durch Malware oder durch falsch konfigurierte Zugriffsrechte.
 
−
* '''Kompromittierte Management-Accounts''': Root- oder Global-Admin-Accounts ohne MFA sind besonders kritisch.
 
−
* '''Supply-Chain-Angriffe''': Manipulierte Container-Images, Libraries oder Marketplace-Angebote.
 
−
* '''DoS/DDoS''': Angriffe auf öffentlich erreichbare Dienste, API-Gateways oder Load-Balancer.
 
−
* '''Rechtliche Risiken''': Zugriff durch Drittstaaten (z. B. CLOUD Act), DSGVO-Verstöße.
 
−
* '''Abhängigkeit (Vendor Lock-in)''': Schwerer Wechsel, wenn Sicherheitsprobleme oder Kosten explodieren.
 
  
−
== Typische Bedrohungsszenarien ==
+
=== Kompromittierter IAM-Account ===
−
* '''Krypto-Mining''': Angreifer nutzen geklaute Access-Keys, um teure Compute-Ressourcen zu missbrauchen.
+
;Ausgangslage
−
* '''Ransomware in der Cloud''': Verschlüsselung von VM-Volumes, Datenbanken oder Backups.
+
*Global-Admin ohne MFA.
−
* '''Fehlende Netzwerktrennung''': Ein kompromittiertes Testsystem wird zum Einfallstor für Produktionssysteme.
+
*Statische Access Keys im Einsatz.
−
* '''Cloud-Ausfall''': Region oder Availability Zone fällt aus (z. B. AWS us-east-1) – Dienste global betroffen.
 
  
−
== Wichtige Sicherheitsmaßnahmen ==
+
;Angriff
−
* '''Identity & Access Management (IAM)''':
+
*Credential Phishing oder Leak in GitHub.
−
** Prinzip der minimalen Rechte (Least Privilege).
+
*Login über API.
−
** Rollen statt statische Benutzerkonten.
+
*Neue Admin-User werden angelegt.
−
** '''MFA''' für alle privilegierten Accounts.
+
*Logs werden manipuliert oder deaktiviert.
−
** 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 ==
+
;Auswirkung
−
* Security by Design: Sicherheitsrichtlinien von Anfang an in Deployments integrieren.
+
*Vollständige Übernahme der Cloud-Umgebung.
−
* Infrastructure as Code (IaC) nutzen, um reproduzierbare, überprüfbare Setups zu haben.
+
*Backups löschbar.
−
* Cloud-native Sicherheitsdienste nutzen (AWS GuardDuty, Azure Defender, GCP Security Command Center).
+
*Instanzen startbar/stoppbar.
−
* Regelmäßige Penetrationstests und Red-Team-Übungen auch in der Cloud-Umgebung.
+
*Daten exfiltrierbar.
−
* 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 ==
+
;Gegenmaßnahmen
−
* '''Offene S3-Buckets''' führten bei zahlreichen Unternehmen (z. B. Facebook, Verizon) zu massiven Datenlecks.
+
*MFA verpflichtend.
−
* '''Tesla-Fall''' 2018: Angreifer nutzten fehlerhafte Kubernetes-Konfiguration, um Krypto-Mining im AWS-Cluster zu betreiben.
+
*Kein Root-Login für Tagesbetrieb.
−
* '''Code-Spiegelung''' bei GitHub: Angreifer nutzten geleakte Access-Tokens, um Quellcode großer Unternehmen zu kopieren.
+
*Least Privilege.
−
* '''US-East-1-Ausfall''' 2020: Zahlreiche Dienste weltweit nicht erreichbar, da keine Redundanz über Regionen hinweg geplant war.
+
*CloudTrail/Logging unveränderbar speichern.
  
−
== 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 ==
+
=== Fehlkonfiguration – Offene Storage-Ressourcen ===
−
* BSI C5: Cloud Computing Compliance Controls Catalogue 
+
;Ausgangslage
−
* ENISA Cloud Security Guidelines 
+
*S3-Bucket oder Blob-Storage öffentlich gesetzt.
−
* NIST SP 800-144: Guidelines on Security and Privacy in Public Cloud Computing 
+
 
−
* Cloud Security Alliance (CSA) Cloud Controls Matrix 
+
;Angriff
−
* AWS Well-Architected Framework – Security Pillar
+
*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.

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“