Envelope encryption only helps if the key hierarchy is real
Envelope encryption means encrypting data with a data key, then encrypting that data key with a key-encryption key held in a KMS or HSM. The pattern is standard, and it is often described as if adoption alone solves key management. It does not. The guarantee comes from the hierarchy and the access policy around it.
Why the reader needs this
Teams adopt a KMS to stop storing keys next to the data, then store a decrypted data key in application memory, in a cache, or in a log. The hierarchy exists on paper and is bypassed in the running system.
Technical context
A KMS holds a master key that never leaves the boundary. The application asks it to generate or unwrap a data key, uses that key to encrypt a record, and stores the wrapped data key beside the ciphertext. Decryption reverses the process. Two properties matter: the KMS enforces who may call Decrypt, and the master key is not exportable.
Data keys have a lifetime that is far shorter than the master key. Reusing one data key for years removes most of the benefit, because a single disclosed key then opens every record. The wrapped key stored beside the ciphertext also has to be integrity-protected, or an attacker can swap it for a key they control.
Where the defect hides
Three patterns weaken the model. A service principal with blanket decrypt permission means any compromise of that service reaches every record. A data key cached in a shared cache or logged for debugging persists after the request. A single region or single KMS account becomes a single point of failure and a single point of compromise.
Defensive implications
Scope decrypt permissions per tenant or per data class, so one compromised principal opens a bounded set of records. Rotate data keys on a defined interval and re-wrap rather than re-encrypt where the format allows. Never log plaintext keys, and treat a key in memory as a volatile secret with a short lifetime. Bind the wrapped key to its ciphertext with an authenticated context, so a swapped key fails to decrypt. Test by calling decrypt with a principal that should not have access and confirming the KMS refuses.
References
- AWS, Envelope encryption
- NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
- Google Cloud, Envelope encryption
Top comments (1)
Agreed on the per-tenant scoping point. One thing I'd add: rotation. A short-lived data key doesn't help much if the key-encryption key above it never rotates — you just end up with one unchanging root, which is the same "one key for everything" problem one layer up. Worth building a re-encryption path from day one, so rotating the master key doesn't require touching all the data.