Encryption at rest: what it protects against and what it does not

What it is

"Encryption at rest" names several distinct layers. The PostgreSQL documentation lists these among the options for a database server: encryption of the data partition at block or file-system level (on Linux typically dm-crypt with LUKS, managed by cryptsetup), encryption of specific columns with pgcrypto, where the client supplies the key and the server decrypts, and client-side encryption, where the server never sees plaintext. Cloud platforms add provider-managed volume encryption with keys in a key-management service. The documentation states the limit of partition encryption plainly: it prevents unencrypted data from being read from the drives if the drives or the computer are stolen, but it does not protect against attacks while the file system is mounted, because the operating system then provides an unencrypted view of the data; and to mount it the key must be given to the host, which sometimes means the key is stored on that host.

Why it matters

Questionnaires ask "is data encrypted at rest?" and a yes is often read as protection against breaches. An attack that goes through the application or its credentials hits a running system, where volume encryption is transparent. Knowing which layer stops which threat prevents both false comfort and needless complexity.

How to apply

• Threat: stolen or decommissioned disks, lost backup media, snapshots copied to the wrong account. Control: full-volume encryption, encrypted backups, and a key stored somewhere other than the encrypted disk.
• Threat: a database administrator or host intruder reading particular sensitive fields. Control: column encryption with keys held by the application, accepting that the plaintext and key are briefly present on the server (the pgcrypto model), or client-side encryption, which gives up server-side search and indexing on those fields.
• Keys: the OWASP Cryptographic Storage cheat sheet recommends storing keys separately from the data, wrapping the data-encrypting key (DEK) with a key-encrypting key (KEK) kept elsewhere, and retaining retired keys as long as old backups may need them.
• Write down, per data class, which layer protects it against what; include backups, exports and logs, which are often the unencrypted copy.

Pitfalls

Encrypting a column and then indexing, searching or logging its plaintext. Losing the KEK, which is indistinguishable from losing the data. Treating provider-managed encryption, where the provider holds the key, as protection against the provider or against anyone holding your account credentials. Assuming an encrypted volume makes dumps encrypted: pg_dump output, exported CSV files and log files are plaintext unless encrypted separately.

Keys in statement logs

A key passed to pgcrypto inside a SQL statement is written wherever statement text is written: the server log under log_statement = 'all' or log_min_duration_statement, pg_stat_activity.query, client history files and any logging proxy. Bind parameters are logged too by default since PostgreSQL 13 unless log_parameter_max_length is 0. Server-side column decryption therefore requires that statement and parameter logging be disabled for the role that supplies keys and that access to logs be treated as access to keys; if that cannot be guaranteed, use client-side encryption, where the key never reaches the server.