The Encryption-at-Rest Trade-off
A healthcare analytics vendor stores 4 TB of patient records in a cloud object store. The security team proposes envelope encryption with a customer-managed key (CMK) in a cloud KMS, with automatic rotation every 90 days. The data platform team objects: the analytics jobs read the data continuously, and they fear key-rotation-induced failures and latency. The compliance team wants 'encryption at rest' to satisfy a contractual control. A prior incident involved a misconfigured bucket that was briefly public. The KMS supports rotation, key policies, and audit logging. The vendor's SLA requires analytics jobs to complete within 6 hours.
1. Evaluate whether envelope encryption with CMK addresses the prior incident and the contractual control.
Read the worked answer
Envelope encryption with a CMK does not prevent a misconfigured public bucket - if the bucket policy allows public read and the objects are served, encryption at rest may not stop access (depending on whether the service enforces encryption on read and whether the bucket policy is the only control). Encryption at rest protects against media/backup theft and unauthorized direct storage access, not against a policy misconfiguration that grants read through the service. So it satisfies the contractual 'encryption at rest' control (data is encrypted with a managed key, auditable), but it is not the control that addresses the prior incident. The incident control is bucket-policy governance: block public access at the account level, policy-as-code, and continuous configuration monitoring. Recommend both, but be clear which one fixes which problem.
2. Address the platform team's rotation and latency concerns.
Read the worked answer
Separate the concerns:
- Latency: with envelope encryption, the CMK encrypts data keys, not every object read. Data keys are cached by the service; the KMS call is amortized. Measure actual p99 before assuming impact - the fear is usually larger than the effect.
- Rotation: modern KMS rotation creates a new key version; old versions remain available for decryption. Rotation should not break reads. The real risk is if the application caches a specific key version or hardcodes key IDs - that is an application defect to fix, not a reason to avoid rotation.
- Failure mode: if KMS is unavailable, cached data keys allow continued reads for a period; design for graceful degradation and monitor KMS availability. Recommendation: pilot on one dataset, measure latency and job duration against the 6-hour SLA, then roll out. If rotation causes failures, the fix is key-version handling, not disabling rotation.
3. What key-management practices should accompany the CMK?
Read the worked answer
- Key policy least privilege: only the analytics service role and a small break-glass admin can use/decrypt; no broad principal access.
- Separation of duties: the team that uses the key is not the team that can change its policy.
- Audit: enable KMS audit logging and alert on unusual decrypt volume or policy changes.
- Rotation and retirement: scheduled rotation, documented procedure, and a plan for compromised-key response (disable, re-encrypt).
- Backup/recovery: ensure the key is recoverable per policy; losing a CMK can mean losing data.
- Classification: confirm the data is actually sensitive enough to warrant CMK; over-engineering has its own cost.