A team says 'the database is encrypted at rest, so we're secure.' As architect, what's the gap?
Short answer
Encryption at rest defends exactly one threat — physical or disk theft — and does nothing against a compromised application, stolen credentials, or sniffed traffic, because the database decrypts transparently for any authorized query. A sound design also requires TLS in transit, strong authentication and authorization, and proper key management with separation of duties. Doubling the at-rest encryption adds cost without changing the threat model, and encrypting only the backups leaves the live data and its access paths exposed.
When a team equates "encrypted at rest" with "secure," they have confused a single control with a complete security posture. The architect's job is to map the control to the threats it actually mitigates and expose what it leaves open.
What encryption at rest actually does
At-rest encryption — disk-level, filesystem, or transparent data encryption (TDE) — protects data on stolen or decommissioned media. If someone walks off with a drive or a backup tape, the bytes are unreadable. That is real value, but it is a narrow value.
The critical insight: the database decrypts data transparently for any authorized connection. A SQL query from the application sees plaintext. So at-rest encryption does nothing against the threats that dominate real breaches.
The gaps that remain
- App-layer compromise. SQL injection, a vulnerable API, or a compromised service account queries the database and receives plaintext. The encryption never engages.
- Stolen credentials. Phished or leaked database credentials let an attacker authenticate and read everything in the clear.
- Data in transit. Without TLS, traffic between the app and database can be sniffed or tampered with on the wire.
- Key management. If keys are poorly stored or co-located with the data, the encryption is theater.
Why the wrong answers are wrong
"Nothing — at-rest encryption is sufficient" is the trap a weaker candidate falls for: it accepts a single control as the whole answer. "Add a second at-rest encryption layer" doubles cost and complexity while defending the exact same single threat — it is motion without progress. "Encrypt only the backups" is even narrower, leaving the live production data and every access path unprotected.
What an interviewer is probing
They want to see threat-model thinking: which threat does each control address, and where are the residual risks? A strong architect answers with defense in depth — TLS in transit, least-privilege access control, parameterized queries to stop injection, and keys managed in a KMS/HSM separated from the data — rather than treating one checkbox as the finish line.
Likely follow-ups
- If the application is compromised, does at-rest encryption help at all? Why or why not?
- Where would you store and rotate the keys for this database, and who should have access?
- How would you protect the same data in transit between the app and the database?