Encryption at Rest

Securing the Vault

Imagine you run a highly secure jewelry store. During the day, you have security guards checking IDs and watching the doors. But what happens at night when the store is closed, the lights are off, and no one is around? You don't just leave the diamonds sitting on the glass counters. You lock them inside a heavy, reinforced steel safe.

If a burglar manages to break through the front door and disable the alarms, they still can't steal the diamonds because the safe is impenetrable.

In system design, network security (like firewalls and TLS) is the security guard at the door. Encryption at Rest is the steel safe. It ensures that if someone physically breaks into your data center and steals the hard drives, or if a hacker compromises your cloud infrastructure, the raw data remains completely unreadable without the cryptographic keys.

What is "Data at Rest"?

Data basically exists in three states:

1. Data in Transit: Data moving across a network (e.g., sending an API request). We protect this with TLS/SSL.
2. Data in Use: Data currently loaded into active RAM or CPU caches for processing.
3. Data at Rest: Data that is inactive and stored physically on a disk, database, or object storage (like an AWS S3 bucket).

When we talk about Encryption at Rest, we are specifically talking about securing the third category: files, databases, and backups sitting on hard drives.

The Threat Model: Why do we need it?

You might wonder, "If my database requires a username and password, why do I need to encrypt the disk?"

Databases are software. If an attacker bypasses the software (for example, by directly accessing the underlying server's file system, or by stealing a backup tape from a storage facility, or by discovering an exposed S3 bucket), they can just read the raw files containing the database tables. They don't need a database password because they are bypassing the database entirely.

If the disk is encrypted, the attacker will just see gigabytes of random, scrambled gibberish.

How Encryption at Rest Works

The concept is incredibly straightforward: before data is written to the physical spinning disk or SSD, it is run through an encryption algorithm (usually AES-256). When the operating system needs to read the data, it decrypts it on the fly.

This process is entirely transparent to the application. If you have a Node.js app talking to a PostgreSQL database, the Node.js app has absolutely no idea the data is encrypted on disk. It writes and reads data normally. The database or operating system handles the encryption seamlessly in the background.

The Key Management Problem

The hardest part of Encryption at Rest isn't the encryption itself. It's managing the keys.

If you encrypt your entire database with a single master key and store that master key on the same server as the database, you have left the combination to the safe written on a sticky note attached to the safe.

If an attacker steals the server image, they get the data and the key.

Enter KMS (Key Management Service)

To solve this, large organizations use dedicated systems called a Key Management Service (like AWS KMS, Google Cloud KMS, or HashiCorp Vault).

A KMS is a highly secure, specialized service whose only job is to store and protect cryptographic keys.

Here's how a secure architecture works:

1. Your database needs to write data.
2. It talks to the external KMS and says, "Please give me a temporary Data Key."
3. The KMS hands over a Data Key, which the database uses to encrypt the file on disk.
4. The database then asks the KMS to encrypt the Data Key itself using a master key that never leaves the KMS hardware.
5. The database stores the encrypted data and the encrypted Data Key on the disk.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Envelope encryption with KMS: the application requests a data key from KMS, receives a plaintext copy to encrypt data and an encrypted copy to store alongside the data. The master key that protects all data keys never leaves the KMS. A stolen disk contains only ciphertext and an encrypted key that cannot be opened without the KMS.

1 / 10.5×1×2×3×Playground

KMS envelope encryption: the application gets a data key from KMS, encrypts data locally, and stores only ciphertext and the encrypted key on disk

Now, if a hacker steals the database hard drive, they have the encrypted data, and an encrypted key that they can't open. To decrypt it, they would need access to the KMS system, which has massive layers of Identity and Access Management (IAM) protecting it.

Summary

• Encryption at Rest protects inactive data stored on disks, databases, and object storage.
• It mitigates the risk of physical hardware theft, exposed backups, and compromised file systems by making the raw files unreadable.
• The encryption is typically transparent to the application software.
• The biggest challenge is Key Management. Storing the encryption key next to the data defeats the purpose.
• Cloud providers offer KMS (Key Management Services) to securely generate, store, and rotate encryption keys separately from the data itself.