Encryption at rest

Data is encrypted before it is written and decrypted when it is read, by something between the requester and the storage. Where that something sits decides what the control actually protects.

At the disk or volume layer, the whole device is encrypted and anything that mounts it sees plaintext. This defends against a drive being removed, a laptop being stolen or hardware being decommissioned badly, and against nothing else. At the storage service layer, which is what cloud providers apply by default, objects and volumes are encrypted with keys the platform manages, and any caller the platform authorises receives plaintext. At the database layer, the files are encrypted and every authorised query returns readable rows. At the application layer, specific fields are encrypted before they reach the database, so the database administrator sees ciphertext and only the application can read the values.

Almost all real deployments use envelope encryption. A data encryption key encrypts the data, and a key encryption key held in a key management service encrypts that key. Rotating the outer key is then cheap, because only the small key needs re-encrypting, and access to the key management service becomes the real control.

That last point is the whole game. Once the data is encrypted competently, the security of the data is the security of the keys and of who may ask the key service to use them.

The most common misunderstanding, and it appears in audit responses constantly, is that encryption at rest protects against a breach. It does not protect against the breach you are most likely to have. An attacker who compromises the application, or steals a credential with read access, asks through the authorised path and gets plaintext. On engagements we have never once been stopped by encryption at rest, because we do not arrive at the disk, we arrive at an identity.

The second is key custody with no separation. The key is held in the same account, under the same administrators, protected by the same credentials as the data. Compromise the account and you have both. Where the key policy permits the same role that reads the storage to use the key, the two controls are one control.

The third is coverage. The primary database is encrypted and the replicas, the exports, the analytics copy, the temporary files, the message queue and the backup taken by a different team are not. Data does not stay where it was designed to be, and the copies are where we find it.

The fourth is confusing the platform default with a decision. Cloud storage encrypted with provider-managed keys satisfies the sentence “data is encrypted at rest” and gives you no separation of duty and no ability to revoke access by destroying a key. That may be entirely appropriate. It should be a documented choice rather than a checkbox that got ticked by default and then quoted to an auditor as if it were one.

The three states get compared constantly, usually to establish which one a control covers. They defend against different adversaries.

The row that matters for planning is the last one. Neither at rest nor in transit does anything about a compromised application or a stolen credential, which is how nearly every real breach happens. They are necessary, cheap and solve specific, narrow threats. Presenting them as a general data protection answer is where audit responses go wrong.

Claiming encryption at rest as a breach control. It answers a storage-layer threat. Say so precisely, especially in a regulatory response where the wording will be read carefully.

Keeping the key where the data is. Separate accounts, separate administrators, key policies that name the roles permitted to use each key.

Encrypting the database and not its copies. Backups, replicas, exports and analytics copies are the ones that leave.

Never rotating, or rotating without testing. A key rotation that has not been exercised is a recovery risk, and an unrotatable key is a permanent one.

Encrypting a field you also need to search. Deterministic encryption to preserve searching leaks equality, which for low-cardinality fields is close to leaking the value. Where the requirement is searchable and protected, tokenisation is usually the better answer.

Decide the layer from the threat rather than from the default. If the concern is hardware and decommissioning, volume encryption is sufficient and free. If the concern is a database administrator or a cloud provider employee, only field-level or application-level encryption changes anything. Those are different projects and only one of them is cheap.

Separate key custody from data custody. Use a key management service, hold keys in an account with different administrators, write key policies that name the roles allowed to use each key, and log every use. Where the requirement is genuinely high, a hardware security module gives you a key that cannot be exported, which is a materially different assurance from a managed key.

Cover the copies. Inventory every place the data lands, including backups, replicas, exports, queues and analytics stores, and apply the same standard. That inventory is data classification doing real work rather than producing labels.

Then, since the control does not address the likely attack, spend the rest of the effort where the attack is: on who can call the authorised path. Scope the identities that can read the data, require strong authentication for them, and log the reads. That is what makes a difference to the incident you are actually going to have.

Regulators and certification schemes ask about encryption at rest specifically, and the honest answer names the layer, the key custody model, the rotation practice and the coverage of copies. A response that says only “data is encrypted at rest” invites a follow-up question that is harder to answer, and answering it precisely the first time is faster.

In our reports the finding is rarely absence of encryption. It is key custody in the same boundary as the data, or a copy that was missed, or an authorised path with weak controls that renders the whole question moot. We say plainly when encryption is present and irrelevant to the path we used, because a client who believes the control stopped us will not fix the thing that would have.

Severity follows what the authorised path exposes rather than the encryption state. Where we read the data through an identity, we report the identity and the path, and we note the encryption as present and not applicable to the finding.

Reviewing key custody, key policy and the coverage of copies is part of assessing a cloud environment, where the key service is usually the highest-value target in the account.

Does encryption at rest protect us from a data breach? It protects against breaches that occur at the storage layer: stolen disks, copied backups, badly decommissioned hardware. It does not protect against a compromised application, a stolen credential or an over-permissioned identity, which is how most breaches happen.

Should we use provider-managed or customer-managed keys? Customer-managed keys give you separation of duty, an auditable key policy and the ability to revoke access by destroying a key. They cost operational effort and carry a real risk of losing data if key management is poor. Choose deliberately and record the reason.

Is the default cloud encryption enough? For hardware and decommissioning threats, yes. It gives no separation between whoever administers the data and whoever controls the keys, so if your threat model includes an insider or a compromised account, it changes nothing about that.

What about encryption in use? Confidential computing and enclave technologies protect data while it is being processed, which is the gap the other two leave. They are real and currently narrow in applicability, and they should be scoped to specific high-value workloads rather than adopted broadly.