Key takeaway: Encryption only helps when the attacker lacks the key. If the compromised identity can decrypt transparently, encryption at rest changes nothing about the outcome.
What the Checkbox Actually Buys
Enabling encryption at rest means the provider encrypts blocks before writing them and decrypts on read, using keys it manages. Any authorised request is served plaintext automatically.
The threat this addresses is someone obtaining the physical media — a stolen drive, an improperly decommissioned disk. In a major cloud provider’s data centre, that threat is remote and already mitigated by physical controls.
The threat you actually face is a compromised credential: a leaked access key, an over-permissioned role, a subverted application. In every one of those cases the request is authorised, so the data is decrypted and returned. The encryption performed exactly as designed and prevented nothing.
This is why breach reports so often include the phrase that data was encrypted at rest. It is true and it was irrelevant.
Where Key Control Changes the Outcome
Encryption becomes meaningful when the identity holding the data cannot decrypt it unilaterally.
| Arrangement | Stops credential compromise |
|---|---|
| Provider-managed keys, transparent | No |
| Customer-managed key, same account and role | No |
| Customer-managed key, separate policy and account | Partially |
| Application-layer encryption, key outside the datastore | Yes |
| Per-tenant keys | Yes, limits scope to one tenant |
The distinction is whether decryption requires a permission the attacker did not obtain. A customer-managed key whose policy grants use to the same role that reads the data adds audit logging and no protection.
Separating the key policy means an attacker needs both storage access and key permission. That is genuinely harder, and the key usage log provides a detection signal — an unusual volume of decrypt operations is visible even when the storage access looks normal.
Application-layer encryption of specific fields is the strongest option. The database holds ciphertext, so a database compromise or a leaked backup yields nothing readable without a separate key from a different system. The cost is real: encrypted fields cannot be searched or indexed conventionally.
Choosing What to Protect
Encrypting everything at the application layer is impractical. Identify the fields where disclosure is genuinely severe — identifiers, financial details, health information, authentication material — and encrypt those specifically.
Per-tenant keys deserve consideration for multi-tenant systems. They limit the blast radius of a key compromise to one customer and make deletion straightforward, since destroying a tenant’s key renders their data unrecoverable without touching anyone else’s.
The Operational Requirements
Key rotation must be a defined procedure that has been executed rather than a policy statement. Rotating a key that encrypted years of data requires re-encryption, and discovering that during an incident is too late.
Key deletion needs care in both directions. Deleting a key destroys the data it protected, permanently. Scheduled deletion with a waiting period exists because this mistake is unrecoverable.
Alert on key usage anomalies. A sharp increase in decrypt calls is one of the clearest exfiltration signals available, and it works even where the underlying access appears authorised.
The Bottom Line
Treat provider default encryption as a compliance requirement rather than a security control. Separate key permissions from data permissions so decryption requires something extra, encrypt the highest-sensitivity fields at the application layer, and monitor decrypt volume as an exfiltration signal.
