Encryption at Rest: Whose Threat Model Is It Anyway?

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.