WAF-SOV-110 – Cryptographic keys for sensitive data MUST be managed in HSM or sovereign key management services

Description

Keys for sensitive and classified data MUST be generated and stored in Hardware Security Modules (HSM) or sovereign managed key services. Key operations MUST enforce role separation, dual control, and audit logging. Key import, export, and backup MUST follow documented and approved procedures. Cloud provider managed keys alone MUST NOT be used for sovereign data classes.

Rationale

Risk Description

Risk

Provider-managed keys may be accessible to cloud operators or subject to foreign jurisdiction.

Risk

Missing HSM backing weakens key protection and complicates compliance with sovereignty requirements.

Requirements

  • Keys for sensitive and classified data MUST be generated and stored in Hardware Security Modules (HSM) or sovereign managed key services.

  • Key operations MUST enforce role separation, dual control, and audit logging.

  • Key import, export, and backup MUST follow documented and approved procedures.

  • Cloud provider managed keys alone MUST NOT be used for sovereign data classes.

Implementation Guidance

  1. Document the requirement in a version-controlled policy, ADR, 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.

Maturity Levels

Level Name Criteria

L1

Ad hoc – control not consistently applied

* Die Anforderung ist nicht einheitlich umgesetzt; Nachweis existiert nur punktuell oder fehlt.

L2

Standardised – policy defined and communicated

* Eine dokumentierte Policy oder ein Standard beschreibt die Anforderung.

L3

Integrated – automated validation in CI/CD

* Terraform-Checks oder IaC-Gates prΓΌfen die Anforderung automatisch in CI/CD.

L4

Auditable – metrics and exceptions tracked

* Abdeckung, Ausnahmen und QualitΓ€tsmetriken werden quartalsweise berichtet.

L5

Optimised – continuous improvement based on data

* Die EffektivitΓ€t wird kontinuierlich gemessen und automatisch optimiert.

Checks

waf-sov-110.tf.aws.kms-hsm

Engine: terraform | Provider: aws | Automated: Yes

AWS KMS keys for sensitive data must use HSM-backed CUSTOMER-managed keys

AWS KMS keys for sensitive data must use HSM-backed CUSTOMER-managed keys

Scope: resource β€” aws_kms_key

Assertions: * customer_master_key_spec attribute_exists β€” KMS key must define key spec.

Remediation: AWS KMS keys for sensitive data must use HSM-backed CUSTOMER-managed keys

Compliant
# Example compliant with waf-sov-110.tf.aws.kms-hsm
Non-Compliant
# Example non-compliant with waf-sov-110.tf.aws.kms-hsm

waf-sov-110.tf.azurerm.hsm-keyvault

Engine: terraform | Provider: azurerm | Automated: Yes

Azure Key Vault must use Premium SKU with HSM-backed keys

Azure Key Vault must use Premium SKU with HSM-backed keys

Scope: resource β€” azurerm_key_vault

Assertions: * sku_name in ['premium', 'Premium'] β€” Key Vault must use Premium SKU for HSM-backed keys.

Remediation: Azure Key Vault must use Premium SKU with HSM-backed keys

Compliant
# Example compliant with waf-sov-110.tf.azurerm.hsm-keyvault
Non-Compliant
# Example non-compliant with waf-sov-110.tf.azurerm.hsm-keyvault

waf-sov-110.tf.google.hsm-kms

Engine: terraform | Provider: google | Automated: Yes

GCP KMS keys for sensitive data must use Cloud HSM

GCP KMS keys for sensitive data must use Cloud HSM

Scope: resource β€” google_kms_crypto_key

Assertions: * key_ring attribute_exists β€” Crypto key must be in a defined key ring.

Remediation: GCP KMS keys for sensitive data must use Cloud HSM

Compliant
# Example compliant with waf-sov-110.tf.google.hsm-kms
Non-Compliant
# Example non-compliant with waf-sov-110.tf.google.hsm-kms

Evidence

  • Terraform configuration implementing the requirement.

  • Policy, ADR, or standard documenting the requirement.

  • Optional cloud console or API output confirming runtime state.