Encryption at Rest and Key Management Basics

"Data is encrypted at rest" appears in every security questionnaire and means very different things depending on where the encryption sits. Understanding which threat each layer addresses avoids both false comfort and unnecessary complexity.

The layers, and what each protects against

• Full-disk or volume encryption — protects against someone taking the physical disk or an unwiped cloud volume. Transparent to the application, and therefore transparent to an attacker who has application access.
• Database transparent encryption — protects the database files and backups. Again invisible to anyone querying through the database.
• Field- or column-level encryption — the application encrypts specific values before storing them. This is the layer that limits what a compromised database dump reveals.
• Application-managed envelope encryption — data keys encrypted by a master key in a key service, which is how field-level encryption is done properly at scale.

Key management is the real work

• Keys must not live beside the data they protect, or in the repository, or in a configuration file on the same server.
• Use a managed key service or hardware security module so keys can be used without being exported.
• Restrict who and what can use each key, and log every use — that log is often more useful than the encryption itself during an investigation.
• Plan rotation before launch: envelope encryption lets you rotate the master key without re-encrypting every record, which is the difference between a routine task and a project.
• Have an escrow and recovery process. Losing a key destroys data as effectively as any attacker.

What to encrypt at field level

• Identifiers that enable fraud or identity theft: national insurance or social security numbers, passport and licence numbers, bank details.
• Health information and anything a regulator treats as special category data.
• Authentication secrets and tokens — and passwords are hashed, never encrypted.
• Not everything. Encrypted columns can't be searched, sorted, or joined normally, so encrypt deliberately rather than universally.

Practical consequences to plan for

Encrypted fields break reporting, search, and support tooling unless you plan for it — typically by keeping a searchable blind index or a masked display value alongside. Decide that at design time. And remember encryption addresses confidentiality only: it does nothing about an attacker who has valid credentials, which is how most breaches actually happen.