Encryption at Rest: Securing Your Data When It's Not Moving

WHY IT EXISTS Data must be protected even when it's just sitting on a disk. Physical storage devices can be stolen, lost, or improperly decommissioned. Encryption at rest was created to make the raw data on storage media unreadable and useless to an attacker without the correct decryption keys, mitigating the risk of a major data breach from physical access.

THE MENTAL MODEL Think of your data as a sensitive document. When it's 'at rest,' it's stored on a disk, like a document left on a desk. Encryption at rest is the process of locking that document in a secure safe (encrypting it) before you walk away. Even if someone steals the entire desk (the hard drive), the document remains secure inside the safe. The document is only vulnerable when it's out of the safe, meaning decrypted in memory for processing or being sent over the network.

HOW IT WORKS When your application writes data, the storage system intercepts it and encrypts it before committing it to disk, typically using a strong algorithm like AES-256. This is usually done with a multi-layered key system. The data is encrypted with a Data Encryption Key (DEK). That DEK is then itself encrypted with a Key Encryption Key (KEK) from a secure Key Management Service (KMS). To read the data, the system gets the encrypted DEK, uses the KEK to decrypt it, and then uses the now-plaintext DEK to decrypt the actual data. This 'envelope encryption' allows for easier key rotation and granular access control.

WHEN TO USE IT This should be a default security control for nearly all data stored on persistent media, especially sensitive customer, financial, or proprietary data. Major cloud providers like Google Cloud enable it by default for their core storage services (object storage, block storage, databases). It is a foundational requirement for meeting compliance standards like GDPR, HIPAA, and PCI-DSS.

WHEN NOT TO USE IT It is almost never correct to disable encryption at rest, as the performance overhead on modern systems is negligible. The more important concept is understanding its limitations. Do not rely on it to protect data from a compromised application with valid credentials, as the system will happily decrypt data for an authenticated request. It also provides no protection for data in-transit (use TLS for that) or data being processed in-memory (use confidential computing for that).

ONE CANONICAL EXAMPLE When you upload a file to Google Cloud Storage, it is automatically encrypted at rest without any action on your part. Google's infrastructure breaks the data into chunks and encrypts each chunk with a unique Data Encryption Key (DEK). These DEKs are then encrypted with a Key Encryption Key (KEK) stored and managed by Google's internal KMS. When you download the file, the service transparently reverses the process, using the KEK to unlock the DEKs, which in turn decrypt your data chunks before reassembling them and sending the file to you.