Data Protection, Encryption, and Key Management
Domain 4: Data Protection, Encryption, and Key Management
This domain tests classification, encryption design, key custody, and secrets handling. Expect envelope encryption, KMS key policies, rotation, BYOK/HYOK tradeoffs, and data loss prevention.
Core rules
- Classify data first; controls follow sensitivity, residency, and retention requirements.
- Encrypt in transit with TLS and at rest with provider-managed or customer-managed keys. Customer-managed keys give control over key policy, rotation, and revocation.
- Envelope encryption uses a data key to encrypt data and a key-encryption key to wrap the data key. The ciphertext and wrapped data key are stored together.
- Key policies are authorization documents; a key policy that removes the account principal can lock you out.
- Use a secrets manager for credentials; do not put secrets in environment variables, code, or IaC state.
- Crypto-shredding destroys keys to make data unrecoverable, but only if all copies are covered.
Worked example
A SaaS team stores tenant documents in object storage. They choose one KMS key per tenant, envelope encryption, and a key policy that allows only the tenant's application role and a break-glass admin. Reasoning: per-tenant keys limit blast radius and support crypto-shredding on offboarding; envelope encryption avoids sending bulk data to KMS; the break-glass role is audited. If they used one shared key with a wildcard principal, a single policy error would expose all tenants.
Traps
- Believing at-rest encryption prevents unauthorized access by an authorized principal.
- Scheduling immediate KMS key deletion without checking dependent data.
- Storing secrets in Terraform state or container images.
- Confusing key rotation with data re-encryption; rotation creates new backing keys, old ciphertext remains decryptable.