WAF++ WAF++

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

  1. BSI C5 Testat reicht nicht: Das Testat deckt den Anbieter ab, nicht die Behörde. Die Behörde muss eigene technische Kontrollen nachweisen.

  2. Default-Konfigurationen nicht sovereign: AWS-Defaults (AES256 statt CMK, kein Region Pinning, offene Security Groups) sind nicht BSI-C5-konform.

  3. Cloud Act Risiko: Für HYOK-Anforderungen (keine Zugriffsmöglichkeit für Anbieter) mussten externe HSM-Lösungen evaluiert werden.

  4. 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-1 erlaubt

  • 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

Schritt 5: Logging Residency (WAF-SOV-040)

  • CloudTrail S3 Bucket ausschließlich in eu-central-1

  • CloudWatch Log Groups: Retention 365 Tage für Audit-Logs

  • Kein externer Log-Export ohne explizite Genehmigung

  • VPC Flow Logs aktiviert; in S3 (eu-central-1) mit KMS verschlüsselt

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

  1. BSI C5 Testat des Anbieters ist notwendig, aber nicht hinreichend. Die eigenen Controls müssen unabhängig nachgewiesen werden.

  2. HYOK ist umsetzbar, aber operativ aufwändig. CloudHSM erfordert eigene Expertise und erhöht Betriebskomplexität.

  3. Region Pinning via SCP ist die sicherste Methode. IaC-Validation allein kann durch manuelle API-Calls umgangen werden.

  4. Audit-Evidenz muss kontinuierlich gesammelt werden, nicht erst wenn der Auditor kommt.