Cloud-Sicherheit Konkret: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(5 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''': 
 
−
  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''': 
+
=== Kompromittierter IAM-Account ===
−
  Cloud-Provider betreiben für viele Kunden gleichzeitig Hardware und Software. 
+
;Ausgangslage
−
  Normalerweise ist eine strikte Trennung (Mandantentrennung) vorgesehen, z. B. über Hypervisoren oder Container-Isolation.
+
*Global-Admin ohne MFA.
−
  Fehler in diesen Mechanismen (z. B. Side-Channel-Angriffe wie „Spectre/Meltdown“) könnten Angreifern Zugriff auf fremde Daten ermöglichen.
+
*Statische Access Keys im Einsatz.
  
−
* '''API-Sicherheit''': 
+
;Angriff
−
  Alle Cloud-Dienste (VM-Erstellung, Datenbankzugriff, Netzwerksteuerung) laufen über Management-APIs.
+
*Credential Phishing oder Leak in GitHub.
−
  Wer gültige Zugangsdaten (Access Keys, Tokens) hat, kann über die API Ressourcen starten, Daten kopieren oder löschen.
+
*Login über API.
−
  Beispiel: Ein gestohlener AWS Access Key in einer GitHub-Repo kann von Angreifern sofort zum Missbrauch genutzt werden (z. B. für Krypto-Mining).
+
*Neue Admin-User werden angelegt.
 +
*Logs werden manipuliert oder deaktiviert.
  
−
* '''Datenexfiltration''': 
+
;Auswirkung
−
  Vertrauliche Daten können absichtlich oder unabsichtlich nach außen gelangen.
+
*Vollständige Übernahme der Cloud-Umgebung.
−
  Szenarien: Mitarbeiter mit weitreichenden Rechten kopiert Daten, Schadsoftware leitet Logs oder Datenbanken weiter, oder falsch gesetzte Zugriffsrechte machen Daten für Externe abrufbar.
+
*Backups löschbar.
−
  Besonders kritisch: personenbezogene Daten (DSGVO), Finanzdaten oder interne Geschäftsgeheimnisse.
+
*Instanzen startbar/stoppbar.
 +
*Daten exfiltrierbar.
  
−
* '''Kompromittierte Management-Accounts''': 
+
;Gegenmaßnahmen
−
  Root-Account bei AWS oder Global Admin bei Azure = volle Kontrolle über die Umgebung.
+
*MFA verpflichtend.
−
  Ohne MFA und restriktive Policies ist ein kompromittierter Admin-Account katastrophal: Angreifer können VMs starten, Backups löschen, Logs manipulieren und Spuren verwischen.
+
*Kein Root-Login für Tagesbetrieb.
−
  In der Praxis einer der häufigsten Gründe für Totalverlust einer Cloud-Umgebung.
+
*Least Privilege.
 +
*CloudTrail/Logging unveränderbar speichern.
  
−
* '''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''': 
+
=== Fehlkonfiguration – Offene Storage-Ressourcen ===
−
  Cloud-Services sind öffentlich erreichbar. Angreifer können diese durch massive Anfragen überlasten. 
+
;Ausgangslage
−
  Beispiele: API-Gateway, Load-Balancer oder Webserver werden mit Traffic geflutet, sodass legitime Anfragen nicht mehr beantwortet werden. 
+
*S3-Bucket oder Blob-Storage öffentlich gesetzt.
−
  Zwar bieten Provider Schutzmaßnahmen (z. B. AWS Shield, Azure DDoS Protection), aber ohne Konfiguration greifen diese nicht automatisch.
 
  
−
* '''Rechtliche Risiken''': 
+
;Angriff
−
  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). 
+
*Automatisierte Scanner finden offene Buckets.
−
  Zudem gelten Datenschutzanforderungen wie DSGVO, die nicht immer leicht mit global verteilten Cloud-Diensten vereinbar sind. 
+
*Download sensibler Daten.
−
  Folge: Compliance-Verstöße, hohe Bußgelder und Imageverlust.
 
  
−
* '''Abhängigkeit (Vendor Lock-in)''': 
+
;Auswirkung
−
  Ein Wechsel zwischen Cloud-Anbietern ist technisch und organisatorisch schwierig, da APIs, Services und Datenmodelle oft proprietär sind.
+
*DSGVO-Verstoß.
−
  Hat man einmal viele Systeme bei einem Anbieter integriert, ist man faktisch „gefangen“.
+
*Reputationsschaden.
−
  Problematisch, wenn Kosten steigen, Sicherheitsprobleme bekannt werden oder regulatorische Anforderungen nicht mehr erfüllt sind.
+
*Bußgelder.
  
−
== Typische Bedrohungsszenarien ==
+
;Gegenmaßnahmen
−
* '''Krypto-Mining''': Angreifer nutzen geklaute Access-Keys, um teure Compute-Ressourcen zu missbrauchen.
+
*Default Private Policies.
−
* '''Ransomware in der Cloud''': Verschlüsselung von VM-Volumes, Datenbanken oder Backups.
+
*CSPM-Tools.
−
* '''Fehlende Netzwerktrennung''': Ein kompromittiertes Testsystem wird zum Einfallstor für Produktionssysteme.
+
*Automatische Compliance-Checks.
−
* '''Cloud-Ausfall''': Region oder Availability Zone fällt aus (z. B. AWS us-east-1) – Dienste global betroffen.
+
*Regelmäßige Audits.
  
−
== 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 ==
+
=== API-Missbrauch ===
−
* Security by Design: Sicherheitsrichtlinien von Anfang an in Deployments integrieren.
+
;Ausgangslage
−
* Infrastructure as Code (IaC) nutzen, um reproduzierbare, überprüfbare Setups zu haben.
+
*Cloud wird vollständig über APIs gesteuert.
−
* Cloud-native Sicherheitsdienste nutzen (AWS GuardDuty, Azure Defender, GCP Security Command Center).
+
*Keine Rate-Limits oder Monitoring aktiv.
−
* 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 ==
+
;Angriff
−
* '''Offene S3-Buckets''' führten bei zahlreichen Unternehmen (z. B. Facebook, Verizon) zu massiven Datenlecks.
+
*Gestohlener API-Key.
−
* '''Tesla-Fall''' 2018: Angreifer nutzten fehlerhafte Kubernetes-Konfiguration, um Krypto-Mining im AWS-Cluster zu betreiben.
+
*Massives Starten von Instanzen.
−
* '''Code-Spiegelung''' bei GitHub: Angreifer nutzten geleakte Access-Tokens, um Quellcode großer Unternehmen zu kopieren.
+
*Krypto-Mining.
−
* '''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 ==
+
;Auswirkung
−
* Komplexität: Vielzahl an Services, schnelllebige Weiterentwicklung.
+
*Kostenexplosion.
−
* Transparenz: Wenig Einblick in physische Schichten, starke Abhängigkeit von Provider-Trust.
+
*Ressourcenverbrauch.
−
* Multi-Cloud-Szenarien: Unterschiedliche Sicherheitsmodelle pro Anbieter.
+
*Service-Instabilität.
−
* Skills: Security-Teams benötigen spezielles Wissen über Cloud-spezifische Dienste, APIs, Tools.
 
  
−
== Quellen ==
+
;Gegenmaßnahmen
−
* BSI C5: Cloud Computing Compliance Controls Catalogue 
+
*Temporäre Tokens statt statischer Keys.
−
* ENISA Cloud Security Guidelines 
+
*Billing Alerts.
−
* NIST SP 800-144: Guidelines on Security and Privacy in Public Cloud Computing 
+
*API-Monitoring.
−
* Cloud Security Alliance (CSA) Cloud Controls Matrix 
+
*Rollenbasierte Einschränkung.
−
* AWS Well-Architected Framework – Security Pillar
+
 
 +
 
 +
=== 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“