Skip to main content
emnode
Sign up
Compliance Medium severity

AWS Security Hub · DocumentDB

DocumentDB.1: DocumentDB clusters should encrypt at rest

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub DocumentDB.1 check?

DocumentDB.1 checks whether a cluster's `StorageEncrypted` flag is `true`, covering the storage volumes, automated backups, snapshots, and replicas with AES-256 and KMS-held keys. It reports FAILED when the flag is false, and the backing Config rule `docdb-cluster-encrypted` marks the cluster NON_COMPLIANT.

Why does DocumentDB.1 matter?

An unencrypted persistent store is a data-protection gap that NIST 800-53, PCI DSS, and most internal baselines treat as non-negotiable. What makes this control sharper is that encryption is immutable for the life of a DocumentDB cluster (there's no `modify-db-cluster` flag to turn it on), so the longer the cluster runs and the more data it holds, the more costly and risky the eventual migration becomes.

How do I fix DocumentDB.1?

  1. Confirm the gap and choose the KMS key for the new cluster.
  2. Snapshot the cluster, then copy the snapshot specifying a KMS key (the copy is where encryption is introduced).
  3. Restore a new encrypted cluster from the encrypted snapshot copy and cut application traffic over.
  4. Add a guardrail so new clusters are created with `StorageEncrypted` set from the start.

Remediation script · bash

# 1. Find unencrypted databases across engines (sample: RDS, Redshift, OpenSearch).
aws rds describe-db-instances \
  --query 'DBInstances[?StorageEncrypted==`false`].DBInstanceIdentifier' --output text
aws redshift describe-clusters \
  --query 'Clusters[?Encrypted==`false`].ClusterIdentifier' --output text

# 2. Immutable engine (RDS): snapshot, copy WITH a KMS key, restore the new instance.
SRC=prod-orders-db; KEY=alias/db-encryption
aws rds create-db-snapshot --db-instance-identifier $SRC --db-snapshot-identifier ${SRC}-snap
aws rds wait db-snapshot-completed --db-snapshot-identifier ${SRC}-snap
aws rds copy-db-snapshot \
  --source-db-snapshot-identifier ${SRC}-snap \
  --target-db-snapshot-identifier ${SRC}-snap-enc \
  --kms-key-id $KEY
aws rds wait db-snapshot-completed --db-snapshot-identifier ${SRC}-snap-enc
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier ${SRC}-enc --db-snapshot-identifier ${SRC}-snap-enc

# 3. In-place engine (Redshift): background migration (cluster is read-only during it).
aws redshift modify-cluster --cluster-identifier analytics-prod \
  --encrypted --kms-key-id $KEY

# 4. Prevent recurrence: deploy the rds-storage-encrypted Config rule to flag any
#    new unencrypted RDS instance (back it with an SCP to deny creation outright).
aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "rds-storage-encrypted",
  "Source": {"Owner": "AWS", "SourceIdentifier": "RDS_STORAGE_ENCRYPTED"}
}'

Full walkthrough (console steps, edge cases and verification) in the lesson Encrypt AWS databases at rest.

Is DocumentDB.1 a false positive?

There is no in-place toggle: teams sometimes expect a `modify-db-cluster` flag to clear the finding, but encryption can only be applied by creating a new encrypted cluster and migrating the data.

Full lesson Encrypt AWS databases at rest Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for DocumentDB controls ↗ Check your own account for DocumentDB.1 →
Part of the learning path Encrypt everything

More DocumentDB controls