Fallbeispiel: Öffentliche Verwaltung – Sovereign Cloud Migration
Ausgangssituation
Eine mittelgroße Bundesbehörde betreibt eine Fachapplikation mit Bürgerdaten (DSGVO Art. 6 und Art. 9) und plant die Migration auf AWS (eu-central-1 Frankfurt).
Anforderungen:
-
BSI C5 Typ II Testat des Anbieters liegt vor – reicht das für Compliance?
-
Alle Daten müssen in Deutschland verbleiben
-
Externer Audit durch BSI-IT-Grundschutz-Auditor geplant
-
Keine US-Zugriffsmöglichkeit (Cloud Act)
Herausforderungen
-
BSI C5 Testat reicht nicht: Das Testat deckt den Anbieter ab, nicht die Behörde. Die Behörde muss eigene technische Kontrollen nachweisen.
-
Default-Konfigurationen nicht sovereign: AWS-Defaults (AES256 statt CMK, kein Region Pinning, offene Security Groups) sind nicht BSI-C5-konform.
-
Cloud Act Risiko: Für HYOK-Anforderungen (keine Zugriffsmöglichkeit für Anbieter) mussten externe HSM-Lösungen evaluiert werden.
-
Break-Glass ohne Prozess: Root-Credentials existierten, aber kein Prozess.
Implementierung nach WAF++ Sovereign
Schritt 1: Data Residency Policy (WAF-SOV-010)
Die Behörde definierte eine maschinenlesbare Data-Residency-Policy mit:
-
Erlaubte Region: ausschließlich
eu-central-1 -
Datenklassen:
buerger-pii(DSGVO Art. 9),verwaltung-intern,oeffentlich -
Für
buerger-pii: HYOK-Requirement (kein AWS-Zugriff auf Schlüsselmaterial)
Schritt 2: Region Pinning (WAF-SOV-020)
-
Terraform Variable Validation: nur
eu-central-1erlaubt -
AWS SCP auf Organisations-Ebene: Deny für alle Regionen außer
eu-central-1 -
CI-Gate: OPA-Policy prüft jeden Terraform Plan auf Region-Compliance
Schritt 3: Key Sovereignty (WAF-SOV-050)
Für buerger-pii Daten:
-
HYOK-Implementierung via AWS CloudHSM (in Frankfurt)
-
CloudHSM ist ein dedicated HSM in der AWS-Region, aber hardware-isoliert
-
Schlüsselmaterial verlässt nie das HSM; AWS hat keinen Zugriff auf das Schlüsselmaterial
-
Annual Key Ceremony dokumentiert; Delegation auf drei autorisierte Personen
Für Verwaltungsdaten:
-
CMK mit tight Key Policy
-
Automatische Rotation: jährlich
Schritt 4: Privileged Access & Break-Glass (WAF-SOV-060, WAF-SOV-070)
-
AWS IAM Identity Center für JIT-Zugriff
-
Root-Account: deaktiviert für normale Nutzung; Break-Glass nur mit Dual Control + Ticket
-
CloudTrail mit Log File Validation und CloudWatch-Alarmen für Root-Aktivität
-
Post-Incident Review: mandatory innerhalb 5 Werktagen
Evidenz für den Audit
Der BSI-Auditor erhielt:
| Control | Evidenz |
|---|---|
WAF-SOV-010 |
Data-Residency-Policy-Dokument (versioniert, Git-History), Terraform provider.tf |
WAF-SOV-020 |
SCP-Konfiguration, OPA Policy Rules, CI-Log mit blockiertem Non-EU-Deployment (Test) |
WAF-SOV-050 |
KMS Key Policy Export, CloudHSM Audit Log, Key Ceremony Protokoll |
WAF-SOV-060 |
IAM Policy Documents (kein Wildcard), Quarterly Access Review Q1-Q4 |
WAF-SOV-070 |
Break-Glass Runbook, CloudTrail-Config, Root-Account-Alarm Konfiguration, Test-Activation-Log |
WAF-SOV-040 |
CloudTrail-S3-Bucket-Config (Region: eu-central-1), Log Group Retention Screenshots |
Ergebnis
-
BSI Grundschutz-Audit erfolgreich bestanden
-
DSGVO-Datenschutzfolgenabschätzung (DSFA) für Cloud-Migration abgeschlossen
-
Behörde kann jetzt eigenständig Sovereign-Compliance nachweisen (ohne Anbieter-Testat)
-
Jährliches Audit-Cycle mit WAF++ Checker in CI/CD integriert
Lessons Learned
-
BSI C5 Testat des Anbieters ist notwendig, aber nicht hinreichend. Die eigenen Controls müssen unabhängig nachgewiesen werden.
-
HYOK ist umsetzbar, aber operativ aufwändig. CloudHSM erfordert eigene Expertise und erhöht Betriebskomplexität.
-
Region Pinning via SCP ist die sicherste Methode. IaC-Validation allein kann durch manuelle API-Calls umgangen werden.
-
Audit-Evidenz muss kontinuierlich gesammelt werden, nicht erst wenn der Auditor kommt.