Encryption

Definition

Three states, three mechanisms:

• In transit — TLS between every pair of components, including internal ones. Cheap, well understood, and the default.
• At rest — disk, database and object storage encryption. Usually a checkbox with the provider, and it protects against a narrow threat: physical media theft and improperly decommissioned hardware.
• In use — confidential computing and homomorphic techniques. Real but niche; relevant when the operator of the infrastructure is in your threat model.

What at-rest encryption actually protects against

This is where architectural claims most often overreach. Provider-managed disk encryption protects against someone walking out with a drive. It does not protect against a compromised application, a stolen credential, a SQL injection, or an over-permissive access policy — because in all those cases the data is decrypted transparently for whoever asks.

If the threat is a compromised application, you need application-level encryption: the data is encrypted before it reaches the database, with keys the database cannot access. That is a genuine control, and it is meaningfully more expensive — you lose the ability to index, search or sort the encrypted fields.

Stating which threat is being addressed is the whole discipline here.

Key management is the architecture

The cipher is not the interesting decision; every reasonable choice is fine. The decisions that matter:

• Where do keys live? A managed key service, an HSM, or in your own code — and the third is not an option for anything serious.
• Who can use a key? Access policy on the key is the real access control on the data.
• Envelope encryption. Encrypt data with a data key; encrypt the data key with a master key. This makes rotation tractable — rotating the master key does not require re-encrypting the data.
• Rotation. Automatic, with a defined period, and — critically — the system must handle data encrypted with several key versions simultaneously.
• Per-tenant or per-subject keys, where isolation or crypto-shredding is required.
• Recovery. Losing a key is unrecoverable data loss. Key backup and its own access control are as important as the encryption.

Crypto-shredding

Encrypt each data subject's personal data with a per-subject key; destroy the key to satisfy erasure. This is the standard reconciliation between immutable stores and deletion rights, and it must be designed in from the start — data already written in plaintext cannot be shredded.

Failure scenarios

• At-rest encryption cited as protection against application compromise, which it is not.
• Keys in source control or environment variables, which is the most common real finding.
• No rotation, or rotation that requires re-encrypting everything and is therefore never done.
• Encrypted fields that must be searched, discovered after the design is committed.
• Self-signed or unvalidated certificates internally, making TLS decorative.

Interview question

"Your database is encrypted at rest. An attacker obtains valid application credentials. What does the encryption protect?"