Cloud Security: Sicherheit in AWS, Azure und GCP - Der komplette Guide

Die Migration in die Cloud schafft neue Effizienz - und neue Angriffsflächen. Cloud-Sicherheitsvorfälle sind in über 80 % der Fälle auf Fehlkonfigurationen zurückzuführen, nicht auf Zero-Days. Laut Gartner sind bis 2025 über 99 % aller Cloud-Sicherheitsvorfälle auf Kundenfehler zurückzugehen - nicht auf Fehler der Cloud-Anbieter. Wer Cloud-Sicherheit ernst nimmt, muss das Shared Responsibility Model verstehen, Konfigurationen konsequent härten und kontinuierlich überwachen.

Dieser Artikel ist das zentrale Hub-Dokument für Cloud Security. Weiterführende Tiefenthemen:

• Container-Sicherheit und Kubernetes
• Cloud Compliance (BSI C5, ISO 27001, NIS2)
• Cloud IAM Security
• Cloud Key Management
• Cloud Detection Engineering

---

Das Shared Responsibility Model

Das wichtigste Grundkonzept der Cloud-Sicherheit: Wer ist für was verantwortlich?

Cloud-Anbieter (AWS, Azure, GCP) garantieren die Sicherheit der Cloud selbst - also "Security OF the Cloud":

• Physische Sicherheit der Rechenzentren
• Hypervisor-Sicherheit (Isolation zwischen Tenants)
• Netzwerk-Infrastruktur (Backbone, DDoS-Schutz)
• Managed Service Software (RDS, S3, Lambda Runtime)
• Compliance der Infrastruktur (ISO 27001, SOC 2 der Platform)

Kunden sind verantwortlich für die Sicherheit in der Cloud - "Security IN the Cloud":

• Konfiguration von Cloud-Services
• Zugriffsverwaltung (IAM Policies, Berechtigungen, MFA)
• Datenverschlüsselung (at-rest und in-transit)
• Betriebssystem-Konfiguration und Patches (bei IaaS)
• Anwendungscode und -sicherheit
• Netzwerk-Konfiguration (Security Groups, NACLs, VPC)
• Monitoring und Logging-Aktivierung
• Backup und Disaster Recovery

Die Verantwortungsteilung variiert nach Service-Typ: Bei IaaS (z. B. EC2, Azure VM, GCE) übernimmt der Anbieter Hardware, Hypervisor und Netzwerk-Infrastruktur - alles darüber (OS, Middleware, Anwendung, Daten, IAM, Netzwerk-Konfiguration) liegt beim Kunden. Bei PaaS (z. B. RDS, Azure App Service, Cloud Run) kümmert sich der Anbieter zusätzlich um OS, Plattform und Runtime; der Kunde ist für Anwendung, Daten, IAM und Zugriffskonfiguration verantwortlich. Bei SaaS (z. B. Microsoft 365, Salesforce, Google Workspace) managt der Anbieter nahezu alles - der Kunde bleibt verantwortlich für Datenverwaltung, Benutzer-IAM, MFA-Enforcing und Compliance der Daten.

Verantwortungsmatrix nach Service-Typ

Komponente	IaaS	PaaS	SaaS
Physische Sicherheit	Anbieter	Anbieter	Anbieter
Hypervisor	Anbieter	Anbieter	Anbieter
Netzwerk-Hardware	Anbieter	Anbieter	Anbieter
Betriebssystem	Kunde	Anbieter	Anbieter
OS-Patches	Kunde	Anbieter	Anbieter
Runtime/Middleware	Kunde	Anbieter	Anbieter
Datenbankserver	Kunde	Anbieter	Anbieter
Anwendungscode	Kunde	Kunde	Anbieter
Daten (Inhalt)	Kunde	Kunde	Kunde
Datenverschlüsselung	Geteilt	Geteilt	Kunde
IAM/Berechtigungen	Geteilt	Geteilt	Kunde
Monitoring/Logging	Geteilt	Geteilt	Kunde
Backup	Kunde	Kunde	Kunde
Compliance der Daten	Kunde	Kunde	Kunde

Das größte Missverständnis: Viele Unternehmen glauben, die Daten in AWS seien automatisch durch AWS geschützt. Der Anbieter schützt die Infrastruktur - aber nicht falsch konfigurierte S3-Buckets, schwache IAM-Policies oder fehlende Verschlüsselung. Reale Vorfälle belegen das: Der Capital One-Vorfall (2019) resultierte aus einem fehlkonfigurierten AWS-Metadata-Service kombiniert mit einer zu weit gefassten IAM-Rolle - 100 Millionen Kundendatensätze wurden kompromittiert, obwohl die Provider-Infrastruktur sicher war. Bei Toyota (2023) lagen 215 Millionen Fahrzeugdaten in einem öffentlichen S3-Bucket - kein Angriff, reine Fehlkonfiguration. Bei Twitch (2021) war ein fehlkonfiguriertes Git-Repository in AWS die Ursache für die öffentliche Zugänglichkeit von Quellcode und internen Daten.

Fünf häufige Missverständnisse

Missverständnis 1 - "Backup macht der Cloud-Provider": AWS RDS macht automatische Backups - aber nur mit Kundenkonfiguration (Standard: 7 Tage Retention, dann gelöscht). EC2 EBS-Snapshots: kein automatisches Backup ohne explizite Kundenconfig.

Missverständnis 2 - "TLS bedeutet, Daten sind verschlüsselt": TLS schützt Daten in Transit. Verschlüsselung at Rest - S3 SSE-KMS, RDS Storage Encryption, EBS Encrypted by Default - muss der Kunde separat aktivieren.

Missverständnis 3 - "Logging macht der Cloud-Provider automatisch": AWS CloudTrail ist standardmäßig NICHT aktiviert. Azure Activity Log ist aktiviert, aber nur 90 Tage Retention. GCP Audit Logs: Admin Activity automatisch, Data Access muss explizit aktiviert werden.

Missverständnis 4 - "Das Zertifikat des Providers gilt für mich": AWS/Azure/GCP haben ISO 27001 - das gilt für ihre Infrastruktur. Für eigene Anwendungen auf der Cloud benötigt der Kunde ein eigenes ISMS und eigene Compliance-Nachweise.

Missverständnis 5 - "Datenpannen-Fristen gelten nicht bei Cloud-Beteiligung": Die 72-Stunden-DSGVO-Meldepflicht gilt auch dann, wenn der Cloud-Provider beteiligt ist.

---

Die häufigsten Cloud-Fehlkonfigurationen

Cloud-Fehlkonfigurationen verursachen mehr Datenpannen als ausgefeilte Exploits. Cloud-Umgebungen sind komplex, entwickeln sich schnell und werden oft von Teams konfiguriert, die keine Sicherheitsspezialisten sind.

Top-10 Cloud-Fehlkonfigurationen nach Häufigkeit und Schwere:

1. Öffentlicher Storage-Bucket (S3, Azure Blob, GCS): Direkter Datenzugriff für jeden im Internet.
2. Überprivilegierte IAM-Rollen: Service hat Admin-Rechte statt Least Privilege. EC2 mit AdministratorAccess → Angreifer = Cloud-Root.
3. Offene Security Groups / NSGs: 0.0.0.0/0 für RDP, SSH, Datenbank-Ports - direkter Internet-Zugang zu internen Diensten.
4. Deaktiviertes Logging: CloudTrail, VPC Flow Logs, Azure Activity Log nicht aktiv - kein Audit-Trail für Incident Response.
5. Fehlende Verschlüsselung: S3-Objekte unverschlüsselt, EBS ohne Encryption, Datenbanken ohne Encryption at Rest.
6. IMDSv1 statt IMDSv2: Angreifer kann via SSRF aus kompromittierter Instanz IAM-Credentials stehlen.
7. Root-Account ohne MFA: AWS Root oder Azure Global Admin ohne MFA - sofortiges Kompromittierungsrisiko.
8. Cross-Account-Rollen ohne External ID: Confused Deputy Problem - fremde Accounts können Rollen annehmen.
9. Keine Ressourcen-Tagging-Policy: Unbekannte Ressourcen, kein Owner → Shadow IT in der Cloud.
10. Unsichere Kubernetes-Konfigurationen: Dashboard ohne Auth, etcd unverschlüsselt, privilegierte Pods.

AWS-Fehlkonfigurationen: Erkennung und Behebung

# 1. Öffentlicher S3-Bucket - Erkennung:
aws s3api get-bucket-acl --bucket my-bucket
# Wenn "AllUsers" mit READ → öffentlich zugänglich!

# Fix: S3 Block Public Access auf Account-Ebene:
aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration \
  "BlockPublicAcls=true,IgnorePublicAcls=true,\
   BlockPublicPolicy=true,RestrictPublicBuckets=true"

# 2. IMDSv2 erzwingen (verhindert SSRF-Credential-Diebstahl):
aws ec2 modify-instance-metadata-options \
  --instance-id i-1234567890abcdef0 \
  --http-tokens required \
  --http-endpoint enabled

# 3. CloudTrail aktivieren (alle Regionen!):
aws cloudtrail create-trail \
  --name my-trail \
  --s3-bucket-name my-cloudtrail-bucket \
  --is-multi-region-trail \
  --include-global-service-events \
  --enable-log-file-validation
# S3 Object Lock aktivieren, Retention: min. 12 Monate

Root-Account-Absicherung: MFA sofort aktivieren, keine programmatischen Access Keys für Root, Alert bei Root-Login via CloudWatch mit der AWS Config Rule root-account-mfa-enabled und einem CloudWatch Metric Filter für ConsoleLogin by root. Security Groups mit Port 22 oder 3389 von 0.0.0.0/0 sind sofort zu korrigieren: SSH/RDP nur aus VPN-IP oder Bastion-SG, DB-Ports nur aus App-Server-SG. AWS Config Rules restricted-ssh, restricted-rdp und s3-bucket-public-read-prohibited erkennen solche Probleme automatisch.

Azure-Fehlkonfigurationen

# Azure Blob öffentlicher Zugriff - Prüfung und Fix:
az storage account show \
  --name mystorageaccount \
  --query "allowBlobPublicAccess"

az storage account update \
  --name mystorageaccount \
  --resource-group myRG \
  --allow-blob-public-access false

# Overprivileged Service Principals prüfen:
az role assignment list \
  --scope /subscriptions/<sub-id> \
  --query "[].{role:roleDefinitionName, principal:principalName}"
# Kein Owner für Service Principals! Managed Identities stattdessen verwenden.

# SSH/RDP in Network Security Groups prüfen:
az network nsg rule list \
  --resource-group myRG \
  --nsg-name myNSG \
  --query "[?destinationPortRange=='22' || destinationPortRange=='3389']"

Azure Defender for Cloud zeigt alle Fehlkonfigurationen mit Schweregrad und generiert automatisch Handlungsempfehlungen - für viele Findings ist eine One-Click-Remediation verfügbar.

---

Cloud Security Design-Prinzipien

Sichere Cloud-Architektur ist keine Portierung von On-Premise-Sicherheitskonzepten in die Cloud. Die Cloud bietet neue Primitiven (IAM-Rollen statt Firewall, Managed Services statt selbst verwaltete Server) und neue Angriffsflächen. Sichere Cloud-Architektur nutzt Cloud-native Sicherheitsmuster.

Die acht Prinzipien sicherer Cloud-Architektur:

Least Privilege überall: IAM-Rollen mit minimalen Berechtigungen, keine Administrator-Rollen für Services, Condition Keys für zusätzliche Einschränkungen und regelmäßige IAM Access Analyzer-Reviews.

Defense in Depth: Mehrere Sicherheitsschichten (WAF → LoadBalancer → Security Groups → NACL → App), kein Single Point of Trust, Assume-Breach-Denken: Was passiert, wenn Schicht X kompromittiert wird?

Zero Trust Netzwerk: Kein implizites Vertrauen im Netzwerk, jede Service-zu-Service-Kommunikation wird authentifiziert und autorisiert. Service Mesh (Istio, AWS App Mesh) erzwingt mTLS zwischen Services.

Immutable Infrastructure: Server werden nicht modifiziert, sie werden ersetzt. Infrastructure as Code stellt sicher, dass jede Änderung über Terraform oder CDK erfolgt. Kein SSH auf Produktionsinstanzen - AWS SSM Session Manager ist die sichere Alternative.

Secrets aus Code fernhalten: Keine hardcodierten Credentials, Secrets Manager oder Parameter Store für alle Secrets, IMDSv2 erzwingen (IMDSv1 anfällig für SSRF) und automatische Key Rotation.

Monitoring by Default: CloudTrail, Activity Log und Audit Log immer aktiviert, VPC Flow Logs immer aktiviert, CSPM für kontinuierliche Konfigurationsüberwachung.

Automation-First: Manuelle Änderungen führen zu Drift und sind undokumentiert. GitOps bedeutet Infrastruktur-Änderungen via Pull Request; automatische Remediierung via Config Rules verhindert Rückfall in unsichere Zustände.

Data Classification umsetzen: Public, Internal, Confidential, Restricted. Confidential-Daten und höher erfordern Verschlüsselung mit Customer Managed Keys (CMK). Restricted-Daten: Data Residency auf EU-Regionen beschränken und Data Access Logging für Nachvollziehbarkeit (wer hat wann auf was zugegriffen).

VPC-Netzwerkdesign

Das virtuelle Netzwerk (VPC / Virtual Network / VNet) muss sorgfältig strukturiert sein. Das bewährte 3-Tier-Modell (AWS-Beispiel) trennt das öffentliche Subnet mit Application Load Balancer und NAT Gateway (Security Group erlaubt nur Port 443 aus dem Internet), das private Anwendungssubnet für Web/App-Server und ECS/EKS-Container (Security Group erlaubt 443/8080 nur aus der Load Balancer SG, kein direkter Internet-Zugang) und das private Datenbanksubnet für RDS, ElastiCache und DocumentDB (Security Group erlaubt den DB-Port nur aus dem App-Subnet, kein Internet-Zugang nötig).

Der häufigste Fehler ist SSH (Port 22) und RDP (Port 3389) von 0.0.0.0/0 - einer der häufigsten Cloud-Angriffsvektoren. Network ACLs auf Subnet-Ebene ergänzen Security Groups: sie sind stateless (beide Richtungen müssen konfiguriert werden), können Deny-Rules für bekannte schlechte IPs aus Threat Intelligence enthalten und sollten Egress auf 443, 80 und DNS beschränken.

AWS PrivateLink / VPC Endpoints: S3, DynamoDB und Secrets Manager sind per VPC Endpoint erreichbar - ohne Internet-Traffic. Gateway Endpoints für S3 und DynamoDB sind kostenlos.

IAM-Sicherheit in der Cloud

Die drei Grundprinzipien für Cloud IAM: Least Privilege (jede Identität bekommt nur die Rechte, die für ihre Aufgabe minimal notwendig sind - keine Wildcard-Policies mit "Action": "*" oder "Resource": "*"), Just-in-Time Access (privilegierte Zugriffe nur bei Bedarf und zeitlich begrenzt via PAM) und No Long-Lived Credentials (IAM Users mit langlebigen Access Keys vermeiden, stattdessen IAM Roles, Workload Identity und kurzlebige Tokens via STS).

Workload Identity ist der Cloud-native Ansatz ohne statische Secrets: AWS nutzt IRSA (IAM Roles for Service Accounts) für EKS-Pods und EC2 Instance Profiles statt Access Keys. Azure setzt auf Managed Identities (System-Assigned oder User-Assigned) - kein Passwort, kein Secret, kein Leak-Risiko. GCP bietet Workload Identity Federation, damit kein Service Account JSON-Key mehr benötigt wird.

IAM Access Analyzer findet S3-Buckets, KMS-Keys und Secrets mit externem Zugang. Findings sollten täglich geprüft werden. Mit AWS Organizations ist ein organisationsweiter Analyzer empfehlenswert.

Secrets Management

AWS Secrets Manager bietet automatische Rotation für RDS-Passwörter und API Keys, KMS-Verschlüsselung mit Customer Managed Key sowie Cross-Account-Zugang via Resource Policy und einen VPC Endpoint für private Nutzung. AWS SSM Parameter Store ist günstiger (Standard-Parameter kostenlos) und eignet sich für Konfigurationsparameter und nicht-rotierende Secrets mit SecureString-Parametern (KMS-verschlüsselt).

Azure Key Vault vereint Secrets, Keys und Certificates in einem Service mit Soft Delete, Purge Protection, Key Vault Firewall (nur aus eigenem VNet) und Audit Logs für jeden Zugriff. HashiCorp Vault als cloud-agnostische Lösung ermöglicht Dynamic Secrets: Vault erstellt temporäre Datenbankzugangsdaten on Demand, die nach einem konfigurierbaren TTL automatisch ablaufen. Die Grundregel gilt cloud-übergreifend: keine Secrets in Code, Git-History, Environment Variables, Logs oder Konfigurationsdateien.

Verschlüsselung in der Cloud

Encryption at Rest:

• S3-Buckets: Server-Side Encryption (SSE-S3, SSE-KMS oder SSE-C)
• EBS-Volumes: AWS KMS Verschlüsselung (Encrypted by Default auf Account-Ebene aktivieren)
• RDS-Datenbanken: Encryption at Rest bei Erstellung festlegen (nachträgliche Aktivierung erfordert Migration)
• Backups: verschlüsselt speichern

Encryption in Transit:

• TLS/HTTPS für alle API-Calls
• VPC Endpoints für AWS-Dienste (keine Übertragung übers Internet)
• VPN oder Direct Connect für Hybrid-Cloud

Key Management: AWS KMS / Azure Key Vault / GCP Cloud KMS für zentrale Schlüsselverwaltung. Customer Managed Keys (CMK) für maximale Kontrolle über Verschlüsselung und Schlüsselrotation. Details: Cloud Key Management.

---

Cloud Security Posture Management (CSPM)

CSPM-Tools scannen kontinuierlich Cloud-Umgebungen auf Fehlkonfigurationen und Compliance-Verstöße. Typische automatisierte Prüfpunkte sind öffentlich zugängliche S3-Buckets und Storage Accounts, Security Groups mit 0.0.0.0/0 auf Port 22, unverschlüsselte Datenbanken, fehlende MFA für privilegierte Accounts, deaktiviertes Logging, Secrets in EC2 User Data oder Lambda Environment Variables, zu alte Zugriffsschlüssel (über 90 Tage) und fehlende Backup-Konfigurationen.

Open-Source / Kostenlose CSPM-Tools:

# Prowler (AWS, Azure, GCP) - führendes Open-Source CSPM:
pip install prowler
prowler aws -M csv html
prowler aws -S critical,high
prowler aws --compliance gdpr_aws

# ScoutSuite (NCC Group, Multi-Cloud):
pip install scoutsuite
scout aws

# Checkov (IaC Security - Probleme vor dem Deployment finden):
pip install checkov
checkov -d ./terraform/
checkov -d ./k8s/

Kommerzielle CSPM-Plattformen:

• Wiz: Führendes CSPM, Angriffspfad-Analyse ("Toxic Combinations": EC2 mit öffentlicher IP + Admin-Rolle + offener SG), agentlos
• Prisma Cloud (Palo Alto): Full-Stack CSPM inkl. CIEM (Cloud Infrastructure Entitlement Management), Compliance-Reporting für CIS, PCI DSS, HIPAA, ISO 27001
• Microsoft Defender for Cloud: Für Azure ideal, Secure Score als kontinuierliche Metrik, Azure Arc für On-Premises
• AWS Security Hub: Zentrales Dashboard für AWS-Accounts, CIS Benchmark, Integration mit GuardDuty, Inspector, Macie

---

Logging und Monitoring

Ohne Logging sind API-Calls, Berechtigungsänderungen und Datenzugriffe nicht nachvollziehbar - Forensik ist unmöglich.

Pflicht-Logs in AWS: CloudTrail für alle API-Calls in allen Regionen (S3-Bucket mit Object Lock), VPC Flow Logs für alle VPCs (akzeptierte und abgelehnte Verbindungen), S3 Access Logging für sensitive Buckets, RDS Audit Logs für Datenbankoperationen sowie GuardDuty (Threat Detection via Machine Learning), AWS Config (Konfigurationsänderungen aller Ressourcen) und Security Hub als zentraler Aggregator.

Pflicht-Logs in Azure: Azure Activity Log für alle Resource-Operationen, Azure AD Sign-In Logs für Authentifizierungen, NSG Flow Logs für Netzwerkverbindungen, Diagnostic Logs für Key Vault, SQL und andere Services sowie Microsoft Defender for Cloud für CSPM und Threat Detection und Microsoft Sentinel als SIEM.

Kritische CloudTrail-Alerts (sofortige Benachrichtigung): Root-Account-Nutzung, Console-Login ohne MFA, IAM-Policy-Änderungen außerhalb der IaC-Pipeline, Security Group mit 0.0.0.0/0 hinzugefügt, S3-Bucket-Public-Access deaktiviert, CloudTrail gestoppt oder gelöscht, KMS-Key gelöscht sowie API-Calls aus neuen oder unbekannten Regionen.

GuardDuty High-Confidence Findings nach Kategorie: CryptoCurrency (EC2-Instanz macht Crypto-Mining), UnauthorizedAccess (SSH-Brute-Force, Tor-Ausstieg), Backdoor (C2-Kommunikation erkannt), Impact (Dateien gelöscht, Ransomware-Muster) und Stealth (CloudTrail disabled, Password-Policy verändert).

Weiterführend: Cloud Detection Engineering

---

Cloud Penetration Testing

Regelmäßige Cloud Penetration Tests sind ein wesentlicher Bestandteil der Cloud-Sicherheit.

Typische Test-Bereiche:

• IAM-Konfiguration und Privilege Escalation Paths
• Netzwerk-Segmentierung und Firewall-Regeln
• Exposed Services (öffentlich erreichbare Endpunkte)
• Fehlkonfigurierte Storage-Ressourcen
• Secrets in Code, Logs, Environment Variables
• Container-Sicherheit (Docker, Kubernetes)
• Metadata-Service-Angriffe (IMDSv1-SSRF)

Genehmigung erforderlich: Cloud-Anbieter haben eigene Penetration Testing Policies. AWS erlaubt Tests ohne vorherige Genehmigung für bestimmte Services - für andere Services und bei anderen Anbietern ist ein offizielles Ticket erforderlich.

---

Cloud Security und deutsche Compliance

DSGVO / BDSG

• Auftragsverarbeitungsvertrag (AVV): Mit AWS, Azure, GCP abschließen
• Datenlokalität: Hauptspeicherort in EU-Regionen (Frankfurt, Amsterdam) explizit wählen
• Drittland-Transfers: EU-US Data Privacy Framework prüfen; Standard Contractual Clauses (SCC)
• Eigene TOMs: Technische und organisatorische Maßnahmen selbst dokumentieren
• Datenpannen-Meldung: 72-Stunden-Frist gilt auch bei Cloud-Provider-Beteiligung

Datenlokalisierung lässt sich über Cloud-native Policies erzwingen: AWS Control Tower für organisationsweite Region-Einschränkungen, Azure Policy für Ressourcen-Erstellung nur in EU-Regionen und GCP Org Policy mit resourceLocations-Constraint.

BSI C5 - Cloud Computing Compliance Criteria Catalogue

Das BSI hat mit C5 einen deutschen Standard für Cloud-Sicherheit entwickelt. Große Cloud-Anbieter (AWS, Azure, GCP) veröffentlichen C5-Attestierungen (Typ 1 und Typ 2), die Kunden als Nachweis der Infrastruktursicherheit nutzen können - ersetzen aber keine eigene Compliance für Anwendungen und Daten.

NIS2 und Cloud

Kritische Infrastrukturen und wichtige Einrichtungen müssen Cloud-Dienste in ihr Risikomanagement einbeziehen. Art. 21 NIS2 fordert explizit Sicherheitsmaßnahmen für die Lieferkette - einschließlich Cloud-Dienstleister. Folgende Maßnahmen sind nachzuweisen:

• Risikobewertung für Cloud-Dienste im Lieferketten-Risikomanagement
• Vertragsgestaltung mit Cloud-Anbietern (Sicherheitsanforderungen, SLAs)
• Incident Response inklusive Cloud-spezifischer Szenarien
• Monitoring und Protokollierung für Compliance-Nachweise

ISO 27001 in der Cloud

Provider-Kontrollen können im Statement of Applicability referenziert werden - eigene ISMS-Kontrollen sind dennoch erforderlich: A.9.2 für Zugriffsrechte-Verwaltung und IAM-Policies, A.10.1 für kryptografische Kontrollen und Encryption-Entscheidungen, A.12.4 für Logging (welche Logs, wie lange, wo gespeichert) und A.16.1 für Incident Management mit cloud-spezifischen IR-Prozessen.

Weiterführend: Cloud Compliance

---

Prüfplan für Cloud-Fehlkonfigurationen

Täglich (automatisiert): Cloud Security Posture über AWS Security Hub oder Defender Secure Score, GuardDuty und Microsoft Defender for Cloud Findings, CloudTrail-Alert bei Root-Login und IAM-Policy-Änderungen.

Wöchentlich: Neue IAM-User oder Rollen der letzten 7 Tage prüfen, neue öffentliche Ressourcen (S3, Storage, EC2) identifizieren, CloudTrail auf ungewöhnliche API-Calls (nachts, aus fremden Regionen) untersuchen.

Monatlich: Prowler/ScoutSuite Scan für alle neuen Findings seit letztem Monat, IAM Access Advisor für ungenutzte Berechtigungen (Unused Permissions entfernen), Cost Anomaly Detection für unbekannte Ressourcen und Shadow IT.

Quartalsweise: Vollständiger Prowler-Report gegen CIS Benchmark, Penetrationstest der Cloud-Infrastruktur, IAM Access Review für alle Service Accounts und Rollen.

Nach jedem Deployment: Checkov/tfsec für IaC-Fehlkonfigurationen, neue Security Groups auf 0.0.0.0/0 für sensible Ports prüfen, neuer Storage auf aktives Block Public Access prüfen.

---

Cloud Security Best Practices - Checkliste

IAM:

• Root-Account MFA aktiviert, keine programmatischen Access Keys
• Alle Nutzer haben eigene Credentials (kein shared Account)
• MFA für alle privilegierten Accounts
• IAM Roles statt Access Keys für Services (IRSA, Instance Profile)
• Least-Privilege-Policies (keine Wildcards)
• Regelmäßige Access Reviews (quartalsweise)
• IAM Access Analyzer aktiviert

Netzwerk:

• VPC mit Subnetz-Segmentierung (3-Tier: ALB, App, DB)
• Security Groups: kein 0.0.0.0/0 auf Port 22/3389/DB-Ports
• VPC Flow Logs aktiviert
• WAF vor öffentlichen Web-Apps
• VPC Endpoints für AWS-Dienste (kein Internet-Traffic)

Storage:

• Kein öffentlicher Bucket-Zugriff (Account-Level Block Public Access)
• Encryption at Rest für alle Datenspeicher (SSE-KMS)
• Versionierung und MFA-Delete auf kritischen Buckets
• Regelmäßige Backups mit Restore-Tests

Secrets:

• Keine Secrets in Code, Git oder Config-Dateien
• Secrets Manager / Key Vault im Einsatz
• Regelmäßige Key-Rotation (automatisiert)
• IMDSv2 erzwungen (kein IMDSv1)

Monitoring:

• CloudTrail aktiviert (alle Regionen, Multi-Region Trail)
• S3-Bucket für CloudTrail mit Object Lock (unveränderlich)
• Alarme für kritische Events (Root-Login, Policy-Änderungen)
• GuardDuty / Defender for Cloud aktiviert
• CSPM-Tool im Einsatz
• Log-Retention mindestens 90 Tage, 12 Monate für Compliance

IaC und Deployment:

• Infrastructure as Code (Terraform/CDK) - kein ClickOps
• Checkov / tfsec in CI/CD-Pipeline integriert
• Keine manuellen Änderungen an Produktionsumgebungen

---

Thematische Übersicht: Cloud Security Cluster

Thema	Artikel
Container, Docker, Kubernetes	Container-Sicherheit und Kubernetes
BSI C5, ISO 27001, NIS2, PCI DSS	Cloud Compliance
IAM, Rollen, Berechtigungen, CIEM	Cloud IAM Security
KMS, HSM, Schlüsselrotation	Cloud Key Management
SIEM, GuardDuty, Alerting	Cloud Detection Engineering

---

Fazit

Cloud-Sicherheit ist kein Selbstläufer. Das Shared Responsibility Model macht deutlich: Der Cloud-Anbieter schützt die Infrastruktur - Konfiguration, Identitäten und Daten liegen in der Verantwortung des Nutzers. Die meisten Cloud-Sicherheitsvorfälle sind durch konsequentes Konfigurationsmanagement, robuste IAM-Policies, automatisiertes CSPM und kontinuierliches Monitoring vermeidbar. Infrastructure as Code, das Least-Privilege-Prinzip und "Monitoring by Default" sind die drei wichtigsten Hebel für eine sichere Cloud-Umgebung.