Security & governance
Encryption at rest
Encryption at rest is the encryption of data while it is stored on disk, flash or tape, as opposed to while it moves across a network or is being processed in memory. Its purpose is that anyone who obtains the storage media, or a raw copy of what is on it, without the keys sees only unreadable ciphertext.
Where is encryption at rest applied?
It can be applied at several layers, and they protect against different things.
| Layer | Example | Protects against |
|---|---|---|
| Drive | Self-encrypting drives | Theft or disposal of individual drives |
| Volume or file system | Operating system disk encryption | Theft of a server or its disks |
| Storage service | Server-side encryption of objects | The above, plus separation of keys per tenant or bucket |
| Application or client | Data encrypted before it is sent | All of the above, plus the storage operator |
Which threats does it address?
Encryption at rest is effective against physical loss: a drive returned under warranty, a decommissioned server, a stolen backup tape. With keys held in a separate key management service, it also limits what an attacker gains from reading storage media directly beneath the access control layer. And it enables crypto-erasure, in which destroying a key makes the data under it unrecoverable without overwriting every block.
What does it not protect against?
Encryption at rest is transparent to authorized access. A request that arrives with valid credentials is decrypted and served. It therefore does nothing against stolen access keys, an over-permissive bucket policy, a malicious insider with legitimate rights or ransomware running under a user's account. Those are matters of access control, covered under bucket policy and IAM policy, and of immutability. Treating encryption as an answer to those risks is a common mistake.
What should be decided when enabling it?
Four questions matter. Where are the keys held, and are their administrators separate from the storage administrators? How granular are the keys: one per system, per tenant, per bucket or per object through envelope encryption? How are keys rotated and backed up? And what is the recovery path if the key service is unavailable? Regulations such as the GDPR name encryption as an example of an appropriate security measure, which makes these choices part of compliance evidence. Encryption keys and data sovereignty looks at who should hold them.
Frequently asked questions
Does encryption at rest protect against ransomware?
No. Ransomware acting with valid access reads and overwrites data through the normal path. Immutability and access control address that.
Does encryption at rest reduce performance?
Modern processors accelerate the ciphers used, so the overhead is usually small.
Is encryption at rest required by law?
Some regulations and standards require it for specific data. Others, including the GDPR, require security appropriate to the risk and cite encryption as an example.
Related terms
- Encryption in transit: protection for data on the network.
- Key management service (KMS): where the keys are held.
- Envelope encryption: how keys are layered.
- Bucket policy: access control that encryption does not replace.
- Bring your own key (BYOK): customer control over the keys.