WAF-REL-040 – Backup & Recovery Validation
Beschreibung
Alle Produktionsdatenbanken MÜSSEN automatisierte Backups mit Retention >= 7 Tage und Point-in-Time Recovery (PITR) konfigurieren. Backups MÜSSEN in einem separaten Account oder einer separaten Region gespeichert werden. Recovery-Verfahren MÜSSEN mindestens quartalsweise getestet und dokumentiert sein. Ungetestete Backups gelten als nicht vorhanden.
Rationale
Datenverlust durch Accidental Deletion, Ransomware oder Korruption ist ohne validierte Recovery-Verfahren katastrophal. Der häufigste Fehler ist nicht das Fehlen von Backups, sondern ein nie getestetes Recovery-Verfahren, das im Ernstfall aufgrund veralteter Anleitungen, fehlender Schlüssel oder nicht existierender Zielinfrastruktur scheitert.
Bedrohungskontext
| Risiko | Beschreibung |
|---|---|
Ransomware |
Backup im selben Account wie Produktionsdaten wird gleichzeitig verschlüsselt. |
Accidental Deletion |
Ohne ausreichende Retention sind Daten, die erst nach Tagen fehlen, nicht wiederherstellbar. |
Ungetesteter Restore |
Recovery-Prozedur scheitert im Ernstfall an manuellen Schritten, die nie dokumentiert wurden. |
RPO-Verletzung |
Backup-Interval zu groß: Daten, die zwischen zwei Backups erstellt wurden, gehen verloren. |
Anforderung
-
Automatisierte Backups: Retention >= 7 Tage für alle Produktionsdatenbanken
-
PITR: Für alle relationalen Produktionsdatenbanken aktiviert
-
Backup-Speicherung: Separates AWS Account / Azure Subscription / GCP Project
-
Deletion Protection: Aktiviert auf allen Produktionsdatenbanken
-
Restore-Test: Quartalsweise mit Ergebnisdokumentation (RTO, Datenintegrität)
-
Backup-Alerts: Benachrichtigung bei Job-Fehler oder überaltertem Backup
Implementierungsanleitung
-
Retention erhöhen:
backup_retention_period = 14– mindestens 7, besser 14 Tage -
PITR aktivieren:
point_in_time_recovery_enabled = true(GCP), Standard bei RDS/Azure -
Cross-Account Backup: AWS Backup Plan mit
copy_actionauf Backup-Account-Vault -
Deletion Protection:
deletion_protection = true– verhindert versehentliches Löschen -
Restore-Test automatisieren: Skript für quartalsweisen automatisierten Restore-Test
-
Monitoring: CloudWatch Event Rule für fehlgeschlagene Backup-Jobs
Reifegrad-Abstufung
| Level | Bezeichnung | Kriterien |
|---|---|---|
1 |
Keine Backups |
Keine automatisierten Backups konfiguriert. |
2 |
Backups da, ungetestet |
Automatische Backups aktiv; Restore nie getestet; kein Cross-Account. |
3 |
PITR + Cross-Account + getestet |
PITR aktiviert; Backup in separatem Account; Restore quartalsweise getestet. |
4 |
Automatisierter monatlicher Test |
Automatisierter Restore-Test in Pipeline; Backup-Integrity-Checks. |
5 |
WORM + CDP |
Immutable Backup Storage; Continuous Data Protection; schemagetriggerte Tests. |
Terraform Checks
waf-rel-040.tf.aws.rds-backup-retention
Prüft: RDS hat backup_retention_period >= 7 und deletion_protection = true.
| Compliant | Non-Compliant |
|---|---|
|
|
Remediation: backup_retention_period >= 7 und deletion_protection = true
auf aws_db_instance setzen.
Evidenz
| Typ | Pflicht | Beschreibung |
|---|---|---|
IaC |
✅ Pflicht |
Terraform mit Backup-Konfiguration: Retention, PITR, Cross-Account-Storage. |
Process |
✅ Pflicht |
Quartalsweiser Restore-Test-Bericht: RTO erreicht, Datenintegrität validiert, Unterschrift. |
Governance |
Optional |
RTO/RPO Dokument pro Workload, jährlich reviewed. |
Config |
Optional |
Backup-Monitoring Alerts für Job-Fehler und überalterte Backups. |
Regulatorisches Mapping
| Framework | Controls |
|---|---|
ISO/IEC 27001:2022 |
A.5.15 – Threat intelligence; A.5.16 – Threat classification; A.5.24 – Information security incident management; A.5.25 – Assessment and decision on information security events; A.5.26 – Response to information security incidents; A.5.27 – Learning from information security incidents; A.5.28 – Collection of evidence; A.8.16 – Technology use identification and monitoring; A.8.21 – Telecommunications and network security |
ITIL 4 |
SVS – Service value system; DP – Design principle; OV – Operation value chain; CW – Continual improvement |
AWS Well-Architected Framework |
Reliability Pillar – Prepare; Reliability Pillar – Deploy; Reliability Pillar – Monitor; Reliability Pillar – Improve |
SRE Book (Google) |
Chapter 4 – Service Level Objectives; Chapter 5 – Eliminating toil; Chapter 6 – Monitoring; Chapter 7 – Emergency response |
CNCF Cloud Native Security |
SLSA – Supply chain Levels for Software Artifacts; SBOM – Software Bill of Materials |
BSI C5:2022 |
SIM-01 – Security incident management; SIM-02 – Security information and event management; SIM-03 – Emergency response |
GDPR |
Art. 32 – Security of processing; Art. 33 – Breach notification; Art. 34 – Communication of breach |
NIST SP 800-161 |
SR-1 – Supply chain risk management; SR-2 – Supplier agreements; SR-3 – Supply chain controls |
DORA |
Art. 9 – Protection and prevention; Art. 13 – ICT incident reporting; Art. 17 – Testing of ICT tools and systems |
COBIT 2019 |
DSS04.01.01 – Ensure service availability; DSS04.01.02 – Ensure service capacity; DSS04.02.01 – Manage incidents |
TISAX |
Information security – Incident response |
ANSSI SecNumCloud |
Domain – Incident response; Domain – Business continuity |
BIO |
BIO – Incidentmanagement; BIO – Bedrijfscontinuïteit |
ENS High |
op.exp.7 – Gestión de incidentes; op.exp.8 – Gestión de la continuidad del negocio |
UK NCSC CAF |
D1 – Response and recovery planning; D2 – Lessons learned |
CMMC 2.0 |
IR.L2-3.6.1 – Establish incident handling capability; IR.L2-3.6.2 – Track, document and report incidents |
IRAP |
ISM – Incident management; ISM – Business continuity |
CCCS PBMM |
IR-4 – Incident handling; IR-8 – Incident response plan |
MAS TRM |
Ch.10 – Security incident management; Ch.11 – Business continuity |
ISMAP |
Reliability and incident management |
FISC |
Operational measures – Incident response |