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

IaaS (z.B. EC2, Azure VM, GCE):
  Anbieter:  Hardware, Hypervisor, Netzwerk-Infrastruktur
  Kunde:     OS, Middleware, Anwendung, Daten, IAM, Netzwerk-Konfiguration

PaaS (z.B. RDS, Azure App Service, Cloud Run):
  Anbieter:  Hardware, OS, Plattform, Runtime
  Kunde:     Anwendung, Daten, IAM, Zugriffskonfiguration

SaaS (z.B. Microsoft 365, Salesforce, Google Workspace):
  Anbieter:  Alles außer Nutzerdaten und Zugänge
  Kunde:     Datenverwaltung, Benutzer-IAM, MFA-Enforcing, Compliance

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:

Capital One (2019):
  Fehlkonfigurierter AWS-Metadata-Service + zu weite IAM-Rolle
  Ergebnis: 100 Millionen Kundendatensätze kompromittiert
  Provider-Infrastruktur war sicher - Kundenkonfiguration nicht!

Toyota (2023):
  215 Millionen Fahrzeugdaten in öffentlichem S3-Bucket
  Kein Angriff, reine Fehlkonfiguration

Twitch (2021):
  Fehlkonfiguriertes Git-Repository in AWS
  Quellcode und interne Daten öffentlich zugänglich

Verantwortungsmatrix nach Service-Typ

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

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

# In Terraform:
# resource "aws_instance" "example" {
#   metadata_options {
#     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

# 4. Root-Account absichern:
#    MFA sofort aktivieren
#    Keine programmatischen Access Keys für Root
#    Alert bei Root-Login via CloudWatch:
#      AWS Config Rule: root-account-mfa-enabled
#      CloudWatch Metric Filter: ConsoleLogin by root

# 5. Security Groups: Port 22 / 3389 von 0.0.0.0/0:
#    SSH / RDP von überall → Fix: nur aus VPN-IP oder Bastion-SG
#    DB-Port von überall → Fix: nur aus App-Server-SG
#    AWS Config Rules für automatische Erkennung:
#      restricted-ssh
#      restricted-rdp
#      s3-bucket-public-read-prohibited

Azure-Fehlkonfigurationen

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

# Fix:
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 statt Service-Principal-Keys 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 - Secure Score:
# Zeigt alle Fehlkonfigurationen mit Schweregrad
# Empfehlungen automatisch generiert
# One-Click-Remediation für viele Findings

---

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.

8 Prinzipien sicherer Cloud-Architektur:

1. Least Privilege überall
   IAM-Rollen mit minimalen Berechtigungen
   Keine Administrator-Rollen für Services
   Condition Keys für zusätzliche Einschränkungen
   Regelmäßige IAM Access Analyzer-Reviews

2. Defense in Depth
   Mehrere Sicherheitsschichten: WAF → LoadBalancer → Security Groups → NACL → App
   Kein Single Point of Trust
   Assume Breach: Was passiert, wenn Layer X kompromittiert wird?

3. Zero Trust Netzwerk
   Kein implizites Vertrauen im Netzwerk
   Jede Service-zu-Service-Kommunikation: authentifiziert + autorisiert
   Service Mesh (Istio, AWS App Mesh): mTLS zwischen Services

4. Immutable Infrastructure
   Server werden nicht modifiziert, sie werden ersetzt
   Infrastructure as Code: jede Änderung über Terraform/CDK
   Kein SSH auf Produktionsinstanzen (AWS SSM Session Manager stattdessen)

5. Secrets aus Code fernhalten
   Keine Hardcoded Credentials
   Secrets Manager / Parameter Store für alle Secrets
   IMDSv2 erzwingen (IMDSv1 anfällig für SSRF!)
   Automatische Key Rotation

6. Monitoring by Default
   CloudTrail / Activity Log / Audit Log: immer aktiviert
   VPC Flow Logs: immer aktiviert
   CSPM: kontinuierliche Konfigurationsüberwachung

7. Automation-First
   Manuelle Änderungen = Drift + undokumentiert
   GitOps: Infrastruktur-Änderungen via Pull Request
   Automatische Remediierung: Config Rules mit Auto-Remediation

8. Data Classification umsetzen
   Public, Internal, Confidential, Restricted
   Confidential+ Daten: Verschlüsselung mit Customer Managed Keys (CMK)
   Restricted Daten: Data Residency erzwingen (nur EU-Regionen)
   Data Access Logging: wer hat wann auf was zugegriffen

VPC-Netzwerkdesign

Das virtuelle Netzwerk (VPC / Virtual Network / VNet) muss sorgfältig strukturiert sein:

Sicheres VPC-Design (3-Tier-Architektur, AWS-Beispiel):

Internet
  │
[Internet Gateway]
  │
Öffentliches Subnet (10.0.0.0/24)
  └── Application Load Balancer, NAT Gateway
        Security Group: NUR Port 443 eingehend aus Internet

Privates Subnet - Anwendungsebene (10.0.1.0/24)
  └── Web/App-Server, ECS/EKS-Container
        Security Group: 443/8080 nur von Load Balancer SG
        Kein direkter Internet-Zugang (nur via NAT Gateway)

Privates Subnet - Datenbankebene (10.0.2.0/24)
  └── RDS, ElastiCache, DocumentDB
        Security Group: DB-Port (5432/3306) NUR aus App-Subnet
        Kein Internet-Zugang (NAT Gateway unnötig!)

Häufiger Fehler: SSH (Port 22) und RDP (Port 3389) von 0.0.0.0/0 -
einer der häufigsten Cloud-Angriffsvektoren!

Network ACLs (Subnet-Level, zusätzlich zu Security Groups):
  Stateless (beide Richtungen konfigurieren!)
  Deny-Rule für bekannte Bad-IPs (aus Threat Intelligence)
  Egress: DENY außer 443, 80, DNS

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

IAM-Sicherheit in der Cloud

Cloud IAM Best Practices:

Grundprinzipien:
  Least Privilege:
    Jede Identität (User, Service, Anwendung) bekommt nur die Rechte,
    die für ihre Aufgabe minimal notwendig sind
    Keine Wildcard-Policies ("Action": "*" oder "Resource": "*")

  Just-in-Time Access:
    Privilegierte Zugriffe nur bei Bedarf und zeitlich begrenzt
    Privileged Access Management (PAM)

  No Long-Lived Credentials:
    IAM Users mit langlebigen Access Keys vermeiden
    Stattdessen: IAM Roles, Workload Identity, kurzlebige Tokens via STS

Workload Identity (Cloud-nativ - kein statisches Secret!):
  AWS:   IRSA (IAM Roles for Service Accounts) für EKS-Pods
         EC2 Instance Profiles statt Access Keys
         IMDSv2 erzwingen (SSRF-Schutz)
  Azure: Managed Identities (System-Assigned oder User-Assigned)
         Kein Passwort, kein Secret → kein Leak-Risiko
  GCP:   Workload Identity Federation
         Kein Service Account Key (JSON-Key) mehr nötig!

IAM Access Analyzer:
  Findet: S3-Buckets, KMS-Keys, Secrets mit externem Zugang
  Findings täglich prüfen!
  AWS Organizations: organisationsweiter Analyzer

AWS IAM Best Practices im Überblick:
  Root-Account: MFA aktivieren, keine programmatischen Access Keys
  IAM Roles für EC2/Lambda statt Access Keys
  Permission Boundaries für delegierte Administration
  IAM Access Analyzer aktivieren
  Access Keys max. 90 Tage alt (automatisch rotieren)
  CloudTrail aktivieren (alle Regionen)
  AWS Config für Compliance-Monitoring
  Service Control Policies (SCPs) in AWS Organizations

Secrets Management

Secrets sicher verwalten - Cloud-nativ:

AWS Secrets Manager:
  Automatische Rotation (RDS-Passwörter, API Keys)
  KMS-Verschlüsselung (Customer Managed Key empfohlen!)
  Cross-Account-Zugang via Resource Policy
  VPC Endpoint für private Nutzung

AWS SSM Parameter Store:
  Günstiger als Secrets Manager (Standard-Parameter kostenlos)
  SecureString Parameters: KMS-verschlüsselt
  Use Case: Konfigurationsparameter, nicht-rotierende Secrets

Azure Key Vault:
  Secrets, Keys und Certificates in einem Service
  Soft Delete + Purge Protection
  Key Vault Firewall: nur aus eigenem VNet zugreifbar
  Audit Logs: wer hat wann auf welches Secret zugegriffen

HashiCorp Vault (Cloud-agnostisch):
  Dynamic Secrets: Vault erstellt temporäre DB-Credentials on Demand
  Kein statisches Datenbankpasswort mehr nötig!
  Credential läuft nach konfigurierbarem TTL ab
  Audit: jeder Zugriff geloggt mit Caller-Identity

Regel: 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. Sie überprüfen hunderte von Konfigurationsregeln automatisiert:

Typische CSPM-Checks:
  Öffentlich zugängliche S3-Buckets / 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 Env Vars
  Zu alte Zugriffsschlüssel (>90 Tage)
  Fehlende Backup-Konfigurationen

Open-Source / Kostenlose CSPM-Tools:

# Prowler (AWS, Azure, GCP) - führendes Open-Source CSPM:
pip install prowler

# AWS scannen:
prowler aws -M csv html

# Nur CRITICAL und HIGH:
prowler aws -S critical,high

# Compliance-Framework:
prowler aws --compliance gdpr_aws
# HTML-Report mit allen Findings, Schweregrad, Fix-Empfehlung

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

# Checkov (IaC Security - Probleme BEVOR sie deployed werden!):
pip install checkov
checkov -d ./terraform/      # Terraform prüfen
checkov -d ./k8s/            # Kubernetes YAML prüfen
# Pipeline schlägt fehl bei CRITICAL

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 (immer aktiviert):

AWS:
  CloudTrail: alle API-Calls, alle Regionen, S3-Bucket mit Object Lock
  VPC Flow Logs: alle VPCs (akzeptierte + abgelehnte Verbindungen)
  S3 Access Logging: für sensitive Buckets
  RDS Audit Logs: Datenbankoperationen
  GuardDuty: Threat Detection via Machine Learning (aktivieren!)
  AWS Config: Konfigurationsänderungen aller Ressourcen
  Security Hub: Zentralisierte Security Findings

Azure:
  Azure Activity Log: alle Resource-Operationen
  Azure AD Sign-In Logs: Authentifizierungen
  NSG Flow Logs: Netzwerkverbindungen
  Diagnostic Logs: Service-spezifische Logs (KeyVault, SQL, etc.)
  Microsoft Defender for Cloud: CSPM + Threat Detection
  Microsoft Sentinel: SIEM für alle Azure-Logs

Kritische CloudTrail-Alerts (sofortige Benachrichtigung!):
  Root-Account-Nutzung (immer alert!)
  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
  API-Calls aus neuen oder unbekannten Regionen

GuardDuty High-Confidence Findings:
  CryptoCurrency:       EC2-Instanz macht Crypto-Mining
  UnauthorizedAccess:   SSH-Brute-Force, Tor-Ausstieg
  Backdoor:             C2-Kommunikation erkannt
  Impact:               Dateien gelöscht, Ransomware-Muster
  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 erzwingen:
  AWS Control Tower:    Organisationsweite Region-Einschränkungen
  Azure Policy:         Ressourcen-Erstellung nur in EU-Regionen erlauben
  GCP Org Policy:       Locations-Einschränkung (resourceLocations)

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:

Eigene Kontrollen immer nötig:
  A.9.2:  Zugriffsrechte-Verwaltung → IAM-Policies dokumentieren
  A.10.1: Kryptografische Kontrollen → Encryption-Entscheidungen dokumentieren
  A.12.4: Logging → welche Logs, wie lange, wo gespeichert
  A.16.1: Incident Management → Cloud-spezifische IR-Prozesse

Weiterführend: Cloud Compliance

---

Prüfplan für Cloud-Fehlkonfigurationen

Cloud-Security-Prüfrhythmus:

Täglich (automatisiert):
  Cloud Security Posture (AWS Security Hub / Defender Secure Score)
  GuardDuty / 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?
  Neue öffentliche Ressourcen (S3, Storage, EC2)?
  CloudTrail: ungewöhnliche API-Calls (z.B. nachts, aus fremden Regionen)

Monatlich:
  Prowler/ScoutSuite Scan - alle neuen Findings seit letztem Monat
  IAM Access Advisor: welche Berechtigungen werden nie genutzt?
    Unused Permissions entfernen!
  Cost Anomaly Detection: unbekannte Ressourcen → Shadow IT?

Quartalsweise:
  Vollständiger Prowler-Report gegen CIS Benchmark
  Penetrationstest Cloud-Infrastruktur
  IAM Access Review: alle Service Accounts und Rollen

Nach jedem Deployment:
  Checkov/tfsec: IaC auf Fehlkonfigurationen geprüft?
  Neue Security Groups: 0.0.0.0/0 für sensible Ports?
  Neuer Storage: Block Public Access aktiv?

---

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 min. 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

Cloud Security ist ein breites Feld. Die folgenden Wiki-Artikel vertiefen einzelne Aspekte:

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.