Threat-model encrypted data

Encryption is not useful in the abstract. Ask two questions before anything else: who has the key, and who are you trying to keep out?

The answers decide the layer where encryption belongs. Each layer blocks a different attacker.

What each layer actually protects

Disk encryption protects a powered-off stolen disk. It does nothing against an attacker controlling the running server, because the operating system decrypts transparently for every process.

Database-level or application-level encryption can protect a database dump or a stolen backup. But the application holds the key, so the application can still decrypt records. Anyone who compromises the application inherits that ability.

TLS protects data moving between machines. It says nothing about what happens at either end.

Here is the failure pattern I see most often. A database field is encrypted, but the decryption key sits in the same application environment:

# .env on the same host that stores the data
DATABASE_URL=postgres://[email protected]/prod
FIELD_ENCRYPTION_KEY=6f1d...c2a9

A stolen database backup is protected; remote code execution in the application is not. The attacker reads the key from the environment and decrypts everything, same as the app does.

Map plaintext and keys before choosing

Before picking a layer, trace one piece of data through the system and mark every place plaintext or key material exists:

customer address:
  browser input     -> plaintext (TLS in transit)
  app server memory -> plaintext
  request logs      -> plaintext?  <- often forgotten
  database column   -> ciphertext
  database backup   -> ciphertext
  encryption key    -> app environment variable

The logs line is where audits find surprises. Encrypting the column while logging the request body protects nothing.

Moving the key to a managed key service reduces direct key exposure, and it gives you an audit log of decrypt calls. But an authorized application may still request decryption whenever it wants. Encryption changes the attack path rather than removing it. That is not a weakness, it is the honest description of what you bought.

Practice

Draw the plaintext and key locations for one customer address from browser input through logs, database, backups, and application memory. Mark which attacker each encryption layer blocks and save the diagram. Then assume the application process is compromised and identify every remaining plaintext and decryption path. If the diagram shows the key next to the data, you have found your first fix.