WAF-REL-080 – Dependency & Upstream Resilience Management

Beschreibung

All production workloads MUST maintain an up-to-date inventory of external and internal service dependencies. Each dependency MUST be assessed for reliability risk: SLA provided, failure history, substitutability. Critical dependencies MUST have defined fallback behaviors. Third-party API dependencies MUST implement graceful degradation when the upstream is unavailable. Dependency inventory MUST be reviewed quarterly and updated after each significant architecture change.

Begründung

Risiko Beschreibung

Risk

Incomplete dependency inventories complicate impact analysis and emergency planning.

Risk

External dependencies without documentation are underestimated or overlooked during incidents.

Anforderungen

  • All production workloads MUST maintain an up-to-date inventory of external and internal service dependencies.

  • Each dependency MUST be assessed for reliability risk: SLA provided, failure history, substitutability.

  • Critical dependencies MUST have defined fallback behaviors.

  • Third-party API dependencies MUST implement graceful degradation when the upstream is unavailable.

  • Dependency inventory MUST be reviewed quarterly and updated after each 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-080.tf.aws.vpc-endpoint-dependency-isolation

Engine: terraform | Provider: aws | Automated: Ja

AWS services should use VPC endpoints to isolate AWS API dependencies

Critical AWS API dependencies (S3, DynamoDB, SQS, etc.) should be accessed through VPC endpoints to reduce dependency on internet routing and improve reliability and security.

Scope: resource — aws_vpc_endpoint

Assertions: * vpc_id not empty — VPC endpoint must be associated with a VPC. * service_name not empty — VPC endpoint must specify the AWS service name.

Remediation: Create aws_vpc_endpoint resources for S3, DynamoDB, and other heavily used AWS services. Interface endpoints are recommended for SQS, SNS, and SSM.

Compliant
resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.aws_region}.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = [aws_route_table.private.id]
  tags = merge(var.mandatory_tags, { Name = "s3-vpc-endpoint" })
}

resource "aws_vpc_endpoint" "dynamodb" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.aws_region}.dynamodb"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = [aws_route_table.private.id]
  tags = merge(var.mandatory_tags, { Name = "dynamodb-vpc-endpoint" })
}
Non-Compliant
# No VPC endpoints configured – all AWS API calls traverse internet NAT gateway
# Dependency on NAT gateway availability and internet routing
# WAF-REL-080 violation for high-traffic AWS API dependencies

waf-rel-080.tf.azurerm.private-endpoint-dependency

Engine: terraform | Provider: azurerm | Automated: Ja

Azure private endpoints should be used for critical managed service dependencies

Azure managed services (Storage, Key Vault, Service Bus) accessed by production workloads should use private endpoints to reduce dependency on public routing.

Scope: resource — azurerm_private_endpoint

Assertions: * name not empty — Private endpoint must have a name. * private_service_connection attribute exists — Private endpoint must define private_service_connection.

Remediation: Create azurerm_private_endpoint resources for each critical Azure managed service. Configure private_service_connection with the target resource ID and subresource names.

Compliant
resource "azurerm_private_endpoint" "storage" {
  name                = "storage-private-endpoint"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  subnet_id           = azurerm_subnet.private.id

  private_service_connection {
    name                           = "storage-connection"
    private_connection_resource_id = azurerm_storage_account.main.id
    is_manual_connection           = false
    subresource_names              = ["blob"]
  }
}
Non-Compliant
# azurerm_storage_account accessed directly from public endpoint
# No private endpoint configured – WAF-REL-080 violation
resource "azurerm_storage_account" "main" {
  name                     = "paymentdataprod"
  resource_group_name      = azurerm_resource_group.main.name
  location                 = azurerm_resource_group.main.location
  account_tier             = "Standard"
  account_replication_type = "GRS"
  # public_network_access_enabled = true (default)
}

waf-rel-080.tf.google.vpc-sc-dependency-isolation

Engine: terraform | Provider: google | Automated: Ja

GCP services should use Private Service Connect for dependency isolation

GCP workloads should access Google APIs through Private Service Connect or private Google access to improve reliability by avoiding public internet routing.

Scope: resource — google_compute_subnetwork

Assertions: * private_ip_google_access is true — Subnetwork must enable private_ip_google_access for reliable Google API access.

Remediation: Set private_ip_google_access = true on google_compute_subnetwork resources to allow VMs without public IPs to access Google APIs reliably.

Compliant
resource "google_compute_subnetwork" "private" {
  name                     = "payment-private-subnet"
  ip_cidr_range            = "10.0.0.0/24"
  region                   = var.region
  network                  = google_compute_network.main.id
  private_ip_google_access = true
}
Non-Compliant
resource "google_compute_subnetwork" "private" {
  name                     = "payment-private-subnet"
  ip_cidr_range            = "10.0.0.0/24"
  region                   = var.region
  network                  = google_compute_network.main.id
  private_ip_google_access = false  # WAF-REL-080 violation
}

waf-rel-080.tf.stackit.dependency-mapped

Engine: terraform | Provider: stackit | Automated: Ja

All production workloads for stackit

All production workloads must be documented in IaC via a dependency-mapped 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 dependency-mapped tag/label.

Remediation: Add a dependency-mapped tag/label to the stackit_project resource to show the stackit implementation of WAF-REL-080 is tracked in IaC.

Compliant
resource "stackit_project" "example" {
  labels = {
    dependency-mapped = "true"
  }
}
Non-Compliant
resource "stackit_project" "example" {
  # Missing dependency-mapped labels
}

waf-rel-080.tf.ovh.dependency-mapped

Engine: terraform | Provider: ovh | Automated: Ja

All production workloads for ovh

All production workloads must be documented in IaC via a dependency-mapped 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 dependency-mapped tag/label.

Remediation: Add a dependency-mapped tag/label to the ovh_cloud_project resource to show the ovh implementation of WAF-REL-080 is tracked in IaC.

Compliant
resource "ovh_cloud_project" "example" {
  tags = {
    dependency-mapped = "true"
  }
}
Non-Compliant
resource "ovh_cloud_project" "example" {
  # Missing dependency-mapped tags
}

waf-rel-080.tf.hcloud.dependency-mapped

Engine: terraform | Provider: hcloud | Automated: Ja

All production workloads for hcloud

All production workloads must be documented in IaC via a dependency-mapped 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 dependency-mapped tag/label.

Remediation: Add a dependency-mapped tag/label to the hcloud_server resource to show the hcloud implementation of WAF-REL-080 is tracked in IaC.

Compliant
resource "hcloud_server" "example" {
  labels = {
    dependency-mapped = "true"
  }
}
Non-Compliant
resource "hcloud_server" "example" {
  # Missing dependency-mapped 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.15.1 – Information security in supplier relationships * A.17.1 – Information security continuity

ITIL 4

* Supplier Management * Service Configuration Management