Encryption at Rest: Whose Threat Model Is It Anyway?
Encryption “at rest” turns out to mean very different things depending on the threat you care about. Commenters distinguish full‑disk encryption—which mainly protects against lost, stolen, or decommissioned hardware and is often used for compliance—from application or field‑level encryption tied to proper authentication and key management, which is needed to limit data exposure from online attacks or insider access. Many argue that organizations over-index on ticking encryption checkboxes while under-investing in access control, authorization models, and realistic threat modeling.
What “encryption at rest” actually protects
- Many commenters stress it mainly protects against loss of physical control of storage: theft of servers/laptops, misplaced drives, shipping incidents, improper disposal, broken disks being resold, etc.
- It also simplifies device lifecycle: crypto‑erase by destroying keys instead of physical shredding or complex wiping, especially on SSDs.
- For always‑on servers, it doesn’t stop attackers who already have OS/DB‑level access; once the system is booted, the data is effectively decrypted.
Disk / volume encryption vs application- or field-level
- Full‑disk or volume encryption is easy to deploy, mostly transparent, and good for physical threats and backups.
- Application/field/row‑level encryption can protect specific sensitive data even when the DB or VM is compromised, but is harder to design and implement safely.
- Some products (e.g., database TDE, Salesforce-style field encryption) sit in between, raising questions about whether they’re implemented correctly.
Online attacks, authorization, and “security theater”
- A recurring theme: encryption ≠ authentication/authorization.
- If an app will decrypt any record it’s given, confused‑deputy style attacks can let one user read another’s data despite “encryption at rest.”
- Several argue it’s “security theater” when used as a checkbox against online attacks (SQL injection, API abuse) instead of fixing access control.
- Others push back: it’s not theater if it genuinely mitigates the defined threat (e.g., stolen disks) or is required by customers/regulators.
Threat models: cloud, insiders, and subpoenas
- Some treat the cloud provider (and its staff) as a real adversary; others accept trusting the provider and treating misuse as a legal issue.
- Bring‑your‑own‑key and external HSMs are discussed as ways to ensure subpoenas must go to the data owner, not just the cloud.
- Multi‑tenant isolation and VM co‑residency risks are mentioned but considered low probability on major clouds.
Performance, functionality, and searchable encryption
- Client‑side/field encryption often breaks indexing, filtering, and sorting; workarounds (deterministic encryption, blind indexes, Bloom filters) leak patterns or require deep data‑shape knowledge.
- Commenters note that for many workloads, app‑level encryption must be selective and carefully designed to be practical.
Compliance and key management realities
- HIPAA, PCI 4.0, SOC2, and large‑enterprise questionnaires are major drivers; often controls are adopted “for the checklist” but still yield real improvements.
- Key management, rotation, boot‑time decryption, and RTO/RPO trade‑offs are repeatedly cited as the hard part.