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
-
Document the requirement in a version-controlled policy or standard.
-
Assign ownership and establish a review cadence (e.g., quarterly).
-
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.
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
}
}
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.
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
}
}
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.
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]
}
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.
resource "stackit_project" "example" {
labels = {
chaos-tested = "true"
}
}
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.
resource "ovh_cloud_project" "example" {
tags = {
chaos-tested = "true"
}
}
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.
resource "hcloud_server" "example" {
labels = {
chaos-tested = "true"
}
}
resource "hcloud_server" "example" {
# Missing chaos-tested labels
}
Evidenz
| Art | Erforderlich | Beschreibung |
|---|---|---|
|
Erforderlich |
Terraform configuration implementing the control. |
|
Erforderlich |
Policy, ADR, or standard documenting the requirement. |
|
Optional |
Cloud console or API output confirming runtime state. |
Verwandte Controls
-
WAF-SUS-010 == Regulatorisches Mapping
| 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 |