Cloud-Sicherheit Konkret: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(3 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'''
+
=== 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: 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 ==
+
=== Ransomware in Cloud-Umgebungen ===
−
* '''Offene S3-Buckets''' führten bei zahlreichen Unternehmen (z. B. Facebook, Verizon) zu massiven Datenlecks.
+
;Ausgangslage
−
* '''Tesla-Fall''' 2018: Angreifer nutzten fehlerhafte Kubernetes-Konfiguration, um Krypto-Mining im AWS-Cluster zu betreiben.
+
*Backups nicht isoliert.
−
* '''Code-Spiegelung''' bei GitHub: Angreifer nutzten geleakte Access-Tokens, um Quellcode großer Unternehmen zu kopieren.
+
*Snapshots löschbar.
−
* '''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 ==
+
;Angriff
−
* Komplexität: Vielzahl an Services, schnelllebige Weiterentwicklung.
+
*Admin-Zugang kompromittiert.
−
* Transparenz: Wenig Einblick in physische Schichten, starke Abhängigkeit von Provider-Trust.
+
*Snapshots gelöscht.
−
* Multi-Cloud-Szenarien: Unterschiedliche Sicherheitsmodelle pro Anbieter.
+
*Datenbanken verschlüsselt.
−
* Skills: Security-Teams benötigen spezielles Wissen über Cloud-spezifische Dienste, APIs, Tools.
 
  
−
== Quellen ==
+
;Auswirkung
−
* BSI C5: Cloud Computing Compliance Controls Catalogue 
+
*Totalausfall.
−
* ENISA Cloud Security Guidelines 
+
*Keine Wiederherstellung möglich.
−
* NIST SP 800-144: Guidelines on Security and Privacy in Public Cloud Computing 
+
 
−
* Cloud Security Alliance (CSA) Cloud Controls Matrix 
+
;Gegenmaßnahmen
−
* AWS Well-Architected Framework – Security Pillar
+
*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“