WAF-SOV-100 – Exit Plan & Portability Tested
Beschreibung
Ein dokumentierter Exit-Plan MUSS existieren, der Datenexport-Verfahren, IaC-Portabilitätsstrategie, Dependency-Replacement-Mapping, Zeitplan und Kostenschätzungen abdeckt. Exit-/Restore-Drills MÜSSEN mindestens jährlich durchgeführt werden, um zu validieren, dass der Exit-Plan ausführbar ist.
IaC MUSS offene Standards und provider-agnostische Patterns verwenden, wo machbar, um proprietäres Lock-In zu reduzieren. S3-Bucket-Lifecycle-Policies MÜSSEN konfiguriert sein, um Data-Retention- und Deletion-Anforderungen zu unterstützen.
Rationale
Eine Sovereignty-Posture ohne Exit-Fähigkeit ist eine Sovereignty-Illusion. Wenn ein Migration-Weg von einem Cloud-Provider in einem vernünftigen Zeitrahmen unmöglich ist – aufgrund proprietärer Datenformate, undokumentierter Abhängigkeiten oder ungetesteter Verfahren – ist die Organisation de facto gefangen, unabhängig von vertraglichen Souveränitätsgarantien.
Exit-Readiness ist der ultimative Test der Souveränität: Wenn man gehen kann, hat man Macht in der Beziehung. Wenn man nicht gehen kann, hat man diese Macht nicht.
Bedrohungskontext
| Risiko | Beschreibung |
|---|---|
Daten in proprietärem Format |
Daten können nicht ohne Provider-Unterstützung exportiert werden. |
Nie getesteter Exit-Plan |
Exit-Plan existiert auf Papier, ist aber operativ nicht ausführbar. |
Unbekannte Abhängigkeiten |
Abhängigkeiten erst bei tatsächlichem Migrationsversuch entdeckt. |
Proprietäre Managed Services ohne Alternative |
Ohne offene Alternativen einzige Datenprozessierungsschicht. |
Fehlende S3-Lifecycle-Policies |
Unbegrenzte Retention sensitiver Daten; DSGVO Art. 17 nicht erfüllbar. |
Tightly Coupled IaC |
IaC-Module stark an einzelnen Provider gebunden; keine Abstraktionsschicht. |
Regulatorisches Mapping
| Framework | Controls |
|---|---|
DSGVO |
Art. 44 – Allg. Grundsätze für Übermittlungen; Art. 46 – Geeignete Garantien; Art. 28 – Verarbeitungsvereinbarung |
BSI C5:2020 |
OPS-04 – Datenverwaltung; OPS-05 – Datenleakage-Prävention; SIM-01 – Sicherheitsvorfallmanagement |
EUCS (ENISA) |
DSP-01 – Datenklassifikation; DSP-02 – Dateninventar und Datenfluss; DSP-03 – Datenverfügbarkeit; DSP-04 – Datenlöschung; IAM-01 – Identität und Zugriff |
ISO 27001:2022 |
A.5.12 – Klassifizierung von Informationen; A.5.13 – Kennzeichnung von Informationen; A.5.33 – Schutz von Aufzeichnungen |
ISO 27017 |
CLD.5.1 – Information security in cloud services; CLD.5.2 – Access control in cloud services |
ISO 27018 |
A.2 – Purpose legitimacy and PII protection; A.10 – Confidentiality and security of PII |
BSI C3A:2026 |
Domain – Datenhoheit; Domain – Cloud-Spezifische Anforderungen |
GAIA-X |
Sovereign Cloud – Anforderungen an Datenlokation und Transparenz |
NIST SP 800-53 |
SC-1 – Cloud computing security; SC-7 – Boundary protection; SC-8 – Transmission confidentiality |
NIST CSF 2.0 |
GV.PO – Policy; GV.RM – Risk management; GV.SC – Cybersecurity supply chain risk management |
FedRAMP |
SC-1, SC-7, SC-8 (High baseline) |
TISAX |
Information security – Data protection; Prototype protection – Sensitive data handling |
ANSSI SecNumCloud |
Domain – Data protection; Domain – Cloud security |
BIO |
BIO – Gegevensbescherming; BIO – Cloudbeveiliging |
ENS High |
ds.info.1 – Datos personales; ds.info.2 – Calificación de la información |
UK NCSC CAF |
B3 – Understanding data; B4 – System security |
CMMC 2.0 |
SC.L2-3.13.16 – Protect CUI confidentiality at rest |
IRAP |
ISM – Data protection; ISM – Cloud security |
CCCS PBMM |
SC-7 – Boundary protection; SC-8 – Transmission confidentiality |
MAS TRM |
Ch.5 – Technology risk governance; Ch.8 – Cloud computing controls |
ISMAP |
Data sovereignty and cloud security |
FISC |
Technical measures – Data protection |