WAF++ WAF++
Back to WAF++ Homepage

WAF-REL-070 – Disaster Recovery Testing

Beschreibung

Alle als kritisch oder High-Availability klassifizierten Produktions-Workloads MÜSSEN mindestens zweimal jährlich dokumentierte Disaster Recovery Tests durchführen. DR-Tests MÜSSEN das tatsächlich erreichte RTO und RPO messen und mit den Zielen vergleichen. Abweichungen MÜSSEN innerhalb von 30 Tagen adressiert werden. DR-Pläne MÜSSEN nach signifikanten Architekturänderungen aktualisiert werden.

Rationale

Ein untesteter DR-Plan ist eine unvalidierte Hypothese. DR-Pläne, die nie getestet wurden, scheitern in realen Katastrophen systematisch: veraltete Runbooks, fehlende Automatisierung, Infrastruktur-Drift und undokumentierte manuelle Schritte. Nur regelmäßiges Testen validiert, dass RTO-Ziele tatsächlich erreichbar sind.

Bedrohungskontext

Risiko Beschreibung

Ungetesteter DR-Plan

DR-Plan 18 Monate alt; Architektur hat sich geändert; Recovery dauert 4x länger als RTO.

Fehlende DB-Restore-Schritte

Restore-Prozedur scheitert an nicht-dokumentiertem manuellem Schritt.

Verschlüsselungsschlüssel nicht verfügbar

KMS-Schlüssel im ausgefallenen Account gespeichert; Backup nicht entschlüsselbar.

IaC-Abhängigkeiten fehlen

Terraform nimmt Ressourcen an, die im Ziel-Account nicht existieren.

Anforderung

  • DR-Plan mit RTO/RPO-Zielen pro Workload, versioniert

  • Halbjährliche DR-Tests mit gemessenem RTO/RPO und dokumentierten Ergebnissen

  • Abweichungen von RTO/RPO-Zielen: Remediation-Plan innerhalb 30 Tage

  • DR-Plan aktualisiert nach jeder signifikanten Architekturänderung

  • Automatisierte DR-Failover-Prozeduren via IaC wo möglich

  • Route 53 oder Traffic Manager Failover Routing für kritische DNS-Einträge

Implementierungsanleitung

  1. DR-Scope definieren: Welche Szenarien (AZ, Region, Account-Kompromittierung)?

  2. RTO/RPO messen: Aktuellen Baseline-RTO durch Test ermitteln; Ziel daraus ableiten

  3. DNS-Failover vorbereiten: Route 53 Health Check + Failover Record oder Traffic Manager

  4. IaC für DR: Failover-Procedure via Terraform automatisieren

  5. Test dokumentieren: Vorlage: Startzeit, Endzeit, tatsächliches RTO, Probleme, Unterschrift

  6. Testkalender: Halbjährliche Tests im Kalender; nach jeder Major-Architecture-Änderung

Reifegrad-Abstufung

Level Bezeichnung Kriterien

1

Kein DR-Plan

Keine dokumentierte Recovery-Strategie.

2

Plan dokumentiert, jährlich getestet

DR-Plan vorhanden; jährlicher Test; Ergebnisse nicht systematisch dokumentiert.

3

Halbjährlich + dokumentiert

DR-Tests mind. 2x/Jahr; Ergebnisse dokumentiert mit RTO/RPO; Deviations tracked.

4

Quartalsweise automatisiert

DR-Prozeduren via IaC automatisiert; quartalsweise Tests < 2h; GameDay jährlich.

5

Kontinuierliche Validierung

RTO < 15 Minuten nachgewiesen; automatisierte monatliche Komponententests.

Terraform Checks

waf-rel-070.tf.aws.route53-health-check-failover

Prüft: Route 53 Health Check mit explizitem failure_threshold und request_interval.

Compliant Non-Compliant
resource "aws_route53_health_check"
    "primary" {
  fqdn              = "api.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health/ready"
  failure_threshold = 3
  request_interval  = 10
  tags = {
    Name = "payment-api-hc"
  }
}
resource "aws_route53_record" "api" {
  zone_id = var.hosted_zone_id
  name    = "api.example.com"
  type    = "A"
  ttl     = 300
  records = [var.primary_ip]
  # Kein Failover Routing,
  # kein Health Check
  # WAF-REL-070 Violation
}

Remediation: Route 53 Failover Routing Policy mit Health Check konfigurieren. DNS-TTL auf 30s reduzieren für schnelles Failover.

Evidenz

Typ Pflicht Beschreibung

Process

✅ Pflicht

DR-Testberichte letzter 12 Monate: RTO/RPO erreicht, Probleme, Unterschrift.

Governance

✅ Pflicht

DR-Plan mit RTO/RPO-Zielen, Testplan und Datum der letzten Aktualisierung.

IaC

Optional

Automatisierungsskripte oder Terraform für DR-Failover-Prozeduren.

Process

Optional

DR-Testkalender für die nächsten 12 Monate.