Encryption and Key Management, Without the Hand-Waving
"Is the data encrypted?" is the wrong question, because the answer is almost always yes and it almost never tells you anything. AES has not been the weak link in a breach for years. The interesting questions are where does the key live, who can call it, and what happens when it has to change. Encryption moves the problem from protecting data to protecting keys — and key management is where programs quietly fail.
The core pattern worth understanding is envelope encryption, and once it clicks, most of a KMS makes sense. You do not encrypt your data directly with a master key. You generate a fresh data encryption key (DEK) for the data, encrypt the data with it, then encrypt that DEK with a key encryption key (KEK) that never leaves the KMS or HSM. You store the encrypted DEK right next to the ciphertext. The master key does one job — wrap and unwrap small keys — and stays in a hardened boundary.
The key hierarchy is the security
Envelope encryption buys you three things. Rotating the KEK is cheap — you re-wrap DEKs, not petabytes of data. Blast radius shrinks — a leaked DEK exposes one object, not the estate. And the audit story gets real — every unwrap is a KMS API call you can log, alert on, and rate-limit. The master key becomes a chokepoint you can watch rather than a secret smeared across config files.
Decrypt. Your encryption is exactly as strong as the access policy on the key, and not one bit stronger.Rotation people actually do
Rotation is where good intentions go to die. Teams enable automatic KEK rotation, feel safe, and miss the point: rotating the wrapping key does not re-encrypt old data, and it does nothing about a leaked DEK. Real rotation policy distinguishes the layers. KEK rotation should be automatic and frequent — it is cheap. DEK rotation matters when a key may be compromised or when re-encrypting old data is worth the cost. And rotation is worthless without the ability to revoke: if you cannot make a key un-callable within minutes of a suspected compromise, you do not have key management, you have key storage.
- Never let the master key leave the boundary. KEKs live in a KMS or HSM and are used by reference. If a human or an app can export the raw KEK, envelope encryption has bought you nothing.
- Scope decrypt permission ruthlessly. Separate keys per environment, tenant, and data class, so one compromised role cannot unwrap the whole business. Grant
Decryptto services, not to standing human roles. - Log and alert on key use. A service that normally unwraps ten DEKs an hour suddenly unwrapping ten thousand is your earliest exfiltration signal — but only if you watch the KMS.
- Plan revocation before you need it. Know exactly which action makes a key un-callable and rehearse it, so a compromise is contained in minutes, not discovered in the post-mortem.
- List who and what can call
Decrypton your most sensitive key. If the answer includes broad human roles or a wildcard, your data’s real access model is that IAM policy, not the cipher. - Ask your team to demonstrate revoking one key and confirming the data it protects is now unreadable. If nobody can do it quickly and confidently, rotation is a checkbox, not a control.
Mapping key hierarchies, hunting over-broad decrypt grants, and validating that rotation and revocation actually work end-to-end is what our assessment examines — because ‘we encrypt everything’ is where the investigation starts, not ends.
Encryption done well disappears into infrastructure; encryption done badly is a false sense of security wearing a compliance badge. The bytes are safe the moment you accept that the real asset is the key and the real control is who may call it. You cannot govern keys for systems you have not inventoried — and shadow services with their own quiet KMS grants are exactly the ones nobody is watching.