Encryption at Rest Explained

Encryption at Rest: Protecting Stored Data

Encryption at rest refers to encrypting data while it is stored — on disk, in a database, in cloud storage, or on backup media. Even if an attacker gains physical access to the storage medium, encrypted data remains unreadable without the encryption key.

Why Encrypt at Rest?

1. Physical theft — Laptops, hard drives, and backup tapes can be stolen
2. Decommissioned hardware — Data remains on drives even after deletion
3. Unauthorized access — Database administrators or cloud operators should not read sensitive data
4. Compliance — Regulations like GDPR, HIPAA, PCI DSS, and SOC 2 require or recommend encryption at rest

Encryption Levels

Data at rest can be encrypted at different layers:

Full Disk Encryption (FDE):

Physical Disk ──▶ Encrypted partition ──▶ File system ──▶ Files
Examples: BitLocker, FileVault, LUKS

• Protects against physical theft
• Transparent to applications
• Does NOT protect against a logged-in attacker or compromised OS

File-Level Encryption:

Individual files encrypted with per-file keys
Examples: eCryptfs, gocryptfs, Boxcryptor

• Granular control over which files are encrypted
• Can use different keys for different sensitivity levels

Database-Level Encryption:

Table or column-level encryption within the database
Examples: TDE (Transparent Data Encryption) in SQL Server, PostgreSQL pgcrypto

• Protects specific sensitive fields (SSN, credit card numbers)
• Application can query non-encrypted columns normally

Application-Level Encryption:

Application encrypts data before storing it anywhere
Examples: Client-side encryption in browser, server-side field encryption

• Strongest protection — data is encrypted before it reaches storage
• Application controls key management
• Cannot query encrypted fields (unless using specialized schemes)

Envelope Encryption

Cloud providers (AWS, GCP, Azure) use envelope encryption:

1. A Data Encryption Key (DEK) encrypts the actual data
2. A Key Encryption Key (KEK) encrypts the DEK
3. The KEK is stored in a Hardware Security Module (HSM) and never leaves it

Data ──▶ AES-256-GCM(DEK) ──▶ Encrypted Data
DEK  ──▶ AES-256-KW(KEK)  ──▶ Encrypted DEK
                                 ↑
                           KEK stays in HSM

This design means rotating keys only requires re-encrypting the DEK (small), not re-encrypting all the data (potentially terabytes).

Key Management Considerations

• Key rotation — Regularly rotate encryption keys (e.g., annually)
• Key hierarchy — Use a hierarchy of keys (master key → key-encrypting key → data key)
• Access control — Strictly limit who and what can access encryption keys
• Backup — Encryption keys must be backed up securely; losing the key means losing the data permanently
• Audit logging — Log every key access for compliance and incident response