WAF-REL-070 – Disaster Recovery Testing

Beschreibung

All production workloads classified as critical or high availability MUST undergo documented Disaster Recovery (DR) testing at minimum twice per year. DR tests MUST validate actual RTO and RPO targets defined in the DR plan. Tests MUST cover complete failure scenarios: full region failover, database restore, and service reconstruction from IaC. Results MUST be documented and deviation from targets MUST trigger remediation within 30 days. DR plans MUST be reviewed and updated after every significant architecture change.

Begründung

Risiko Beschreibung

Risk

Critical workloads without disaster-recovery plans may remain unreachable for a long time during regional outages.

Risk

Missing failover mechanisms prevent recovery in the secondary location.

Anforderungen

  • All production workloads classified as critical or high availability MUST undergo documented Disaster Recovery (DR) testing at minimum twice per year.

  • DR tests MUST validate actual RTO and RPO targets defined in the DR plan.

  • Tests MUST cover complete failure scenarios: full region failover, database restore, and service reconstruction from IaC.

  • Results MUST be documented and deviation from targets MUST trigger remediation within 30 days.

  • DR plans MUST be reviewed and updated after every significant architecture change.

Implementierungsleitfaden

  1. Document the requirement in a version-controlled policy or standard.

  2. Assign ownership and establish a review cadence (e.g., quarterly).

  3. Implement the required configuration as code in Terraform or equivalent IaC.

Reifegrade

Level Name Kriterien

L1

Ad hoc – control not consistently applied

* Manual evidence exists for some workloads, but coverage is unknown.

L2

Standardised – policy defined and communicated

* A version-controlled policy, ADR, or standard describes the requirement.

L3

Integrated – automated validation in CI/CD

* Terraform checks run automatically on pull requests and report results.

L4

Auditable – metrics and exceptions tracked

* Control coverage, failures, and approved exceptions are reported quarterly.

L5

Optimised – continuous improvement based on data

* Control effectiveness is measured and iteratively improved.

Checks

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

Engine: terraform | Provider: aws | Automated: Ja

AWS Route 53 failover routing must be configured for DR

Production DNS entries for critical workloads must use Route 53 health check failover routing policies to enable automated DNS failover during regional events.

Scope: resource — aws_route53_health_check

Assertions: * type not empty — Route 53 health check type must be specified. * failure_threshold attribute exists — Health check failure threshold must be explicitly defined. * request_interval attribute exists — Health check request interval must be defined.

Remediation: Configure aws_route53_health_check with type, fqdn, port, resource_path, failure_threshold, and request_interval. Link to Route 53 failover records.

Compliant
resource "aws_route53_health_check" "primary" {
  fqdn              = "api.payment-service.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health/ready"
  failure_threshold = 3
  request_interval  = 10
  tags = {
    Name = "payment-api-health-check"
  }
}

resource "aws_route53_record" "primary" {
  zone_id = var.hosted_zone_id
  name    = "api.payment-service.example.com"
  type    = "A"
  failover_routing_policy {
    type = "PRIMARY"
  }
  set_identifier  = "primary"
  health_check_id = aws_route53_health_check.primary.id
  alias {
    name                   = aws_lb.primary.dns_name
    zone_id                = aws_lb.primary.zone_id
    evaluate_target_health = true
  }
}
Non-Compliant
resource "aws_route53_record" "api" {
  zone_id = var.hosted_zone_id
  name    = "api.payment-service.example.com"
  type    = "A"
  ttl     = 300
  records = [var.primary_ip]
  # No failover routing, no health check – WAF-REL-070 violation
}

waf-rel-070.tf.azurerm.traffic-manager-profile

Engine: terraform | Provider: azurerm | Automated: Ja

Azure Traffic Manager must be configured for failover routing

Azure Traffic Manager profiles for critical workloads must use failover or performance routing methods with health checks enabled on all endpoints.

Scope: resource — azurerm_traffic_manager_profile

Assertions: * traffic_routing_method not in ['0.0.0.0/0', ''] — Traffic Manager should use Failover or Priority routing for DR, not only Weighted. * monitor_config attribute exists — Traffic Manager must define monitor_config for endpoint health checking.

Remediation: Configure azurerm_traffic_manager_profile with traffic_routing_method = "Priority" and a monitor_config block with protocol, port, and path for health checks.

Compliant
resource "azurerm_traffic_manager_profile" "main" {
  name                   = "payment-api-dr"
  resource_group_name    = azurerm_resource_group.main.name
  traffic_routing_method = "Priority"

  dns_config {
    relative_name = "payment-api"
    ttl           = 30
  }

  monitor_config {
    protocol                     = "HTTPS"
    port                         = 443
    path                         = "/health/ready"
    interval_in_seconds          = 10
    timeout_in_seconds           = 9
    tolerated_number_of_failures = 3
  }
}
Non-Compliant
resource "azurerm_traffic_manager_profile" "main" {
  name                   = "payment-api-dr"
  resource_group_name    = azurerm_resource_group.main.name
  traffic_routing_method = "Weighted"
  dns_config {
    relative_name = "payment-api"
    ttl           = 300
  }
  # Missing: monitor_config – no health checking
  # WAF-REL-070 violation
}

waf-rel-070.tf.google.dns-managed-zone-failover

Engine: terraform | Provider: google | Automated: Ja

GCP Cloud DNS must have low TTL for disaster recovery scenarios

GCP Cloud DNS records for production services must use TTL values ⇐ 60 seconds to enable rapid DNS-based failover during disaster recovery.

Scope: resource — google_dns_record_set

Assertions: * ttl less than or equal 60 — DNS record TTL must be ⇐ 60 seconds for DR scenarios to enable rapid failover.

Remediation: Set ttl = 30 on google_dns_record_set for production service endpoints. Lower TTL reduces the DNS propagation window during failover events.

Compliant
resource "google_dns_record_set" "api" {
  name         = "api.payment-service.example.com."
  type         = "A"
  ttl          = 30
  managed_zone = google_dns_managed_zone.main.name
  rrdatas      = [google_compute_global_forwarding_rule.primary.ip_address]
}
Non-Compliant
resource "google_dns_record_set" "api" {
  name         = "api.payment-service.example.com."
  type         = "A"
  ttl          = 3600  # WAF-REL-070 violation: 1 hour TTL prevents rapid DR
  managed_zone = google_dns_managed_zone.main.name
  rrdatas      = [var.primary_ip]
}

waf-rel-070.tf.stackit.chaos-tested

Engine: terraform | Provider: stackit | Automated: Ja

All production workloads classified as critical or high availability for stackit

All production workloads classified as critical or high availability must be documented in IaC via a chaos-tested tag/label on stackit_project. This validates the control is tracked as code.

Scope: resource — stackit_project

Assertions: * labels key exists — stackit_project is missing the chaos-tested tag/label.

Remediation: Add a chaos-tested tag/label to the stackit_project resource to show the stackit implementation of WAF-REL-070 is tracked in IaC.

Compliant
resource "stackit_project" "example" {
  labels = {
    chaos-tested = "true"
  }
}
Non-Compliant
resource "stackit_project" "example" {
  # Missing chaos-tested labels
}

waf-rel-070.tf.ovh.chaos-tested

Engine: terraform | Provider: ovh | Automated: Ja

All production workloads classified as critical or high availability for ovh

All production workloads classified as critical or high availability must be documented in IaC via a chaos-tested tag/label on ovh_cloud_project. This validates the control is tracked as code.

Scope: resource — ovh_cloud_project

Assertions: * tags key exists — ovh_cloud_project is missing the chaos-tested tag/label.

Remediation: Add a chaos-tested tag/label to the ovh_cloud_project resource to show the ovh implementation of WAF-REL-070 is tracked in IaC.

Compliant
resource "ovh_cloud_project" "example" {
  tags = {
    chaos-tested = "true"
  }
}
Non-Compliant
resource "ovh_cloud_project" "example" {
  # Missing chaos-tested tags
}

waf-rel-070.tf.hcloud.chaos-tested

Engine: terraform | Provider: hcloud | Automated: Ja

All production workloads classified as critical or high availability for hcloud

All production workloads classified as critical or high availability must be documented in IaC via a chaos-tested tag/label on hcloud_server. This validates the control is tracked as code.

Scope: resource — hcloud_server

Assertions: * labels key exists — hcloud_server is missing the chaos-tested tag/label.

Remediation: Add a chaos-tested tag/label to the hcloud_server resource to show the hcloud implementation of WAF-REL-070 is tracked in IaC.

Compliant
resource "hcloud_server" "example" {
  labels = {
    chaos-tested = "true"
  }
}
Non-Compliant
resource "hcloud_server" "example" {
  # Missing chaos-tested labels
}

Evidenz

Art Erforderlich Beschreibung

iac

Erforderlich

Terraform configuration implementing the control.

governance

Erforderlich

Policy, ADR, or standard documenting the requirement.

config

Optional

Cloud console or API output confirming runtime state.

Verwandte Controls

Framework Controls

ISO 27001:2022

* A.17.1.3 – Verify, review and evaluate information security continuity

GDPR

* Article 32 – Security of processing (resilience and recovery testing)

BSI C5:2020

* RB-04 – Data Backup and Recovery * RB-05 – Disaster Recovery

ITIL 4

* Service Continuity Management