A secret store encrypts its files and backups on disk - which attacks does that remove, and which does it leave untouched?
answer
- one attacker, not all attackers
- key not kept beside the files
- offline media, not a live store
- an allowed caller still gets plaintext
- the serving process holds it decrypted
basics
~20 sEncrypting a store's files removes the value of any offline copy: a stolen disk, a decommissioned volume, a copied backup. It changes nothing for anyone the store answers - an allowed caller, or an operator reading the serving process.
solid answer
~50 sAt-rest encryption answers exactly one question: what the bytes are worth to someone who holds the media but cannot make the store serve. A disk pulled from a lost node, a volume that left the fleet unwiped, a backup file copied out of an archive - each is ciphertext whose protecting key is held apart from it, so it is inert. That is the whole of the protection. It does nothing against a caller the store's rules allow, because the store decrypts for that caller by design; nothing against a stolen caller credential, because the store answers it as it would the real one; and nothing against an operator who can read the serving process, because plaintext lives in that process for as long as it serves. Bounding who may read which value is the job of authentication and authorization, not of the file encryption.
go deeper
Recall the boundary in one line: encrypted files defeat someone holding the disk or the backup, and do nothing against someone the store answers.
Explain the mechanics: the protecting key is held apart from the files, so an offline copy is inert, while the serving process must hold plaintext in memory to answer any request at all.
Show the diagnosis. When a value leaks, name which copy was taken and whether at-rest encryption was ever in that path, instead of citing it as a mitigation after the fact.
Own the boundary in design review, so one control is never counted twice - once against lost media and once against callers - and so the gap between them is filled by something real.
## The property, stated precisely A secret store keeps its contents - credentials, keys, and the metadata describing them - in files on a disk somewhere. **Encryption at rest** means those files are ciphertext, and the key that turns them back into plaintext is not kept beside them. That is the whole mechanism, and the property it buys is conditional: *someone who holds the bytes but not the protecting key holds noise*. Almost everything people believe about at-rest encryption that turns out to be wrong comes from dropping the second half of that sentence. ## What it genuinely removes It removes the value of every **offline copy** of the store's data: - a disk pulled from a machine that was lost, stolen or sold; - a volume that left the fleet during a decommissioning without being wiped; - a backup file copied out of an archive, or an archive handed to a third party for safekeeping; - a block-level copy taken by whoever operates the storage underneath the store; - a replica's files sitting on a host somebody else administers. In each case the holder has bytes and no way to interpret them, and the store itself never participated. This is not a small win. Storage media outlive fleets, and most of the ways a store's data physically leaves a building have exactly this shape. ## What it leaves exactly as it was | The threat | Changed by encrypting the store's files? | What actually bounds it | |---|---|---| | A stolen disk, volume or backup file | Yes - the copy is inert | Custody of the protecting key | | A caller the store's rules allow | No - the store decrypts for it by design | Rules over what each caller may read | | A stolen caller credential | No - the store answers it like the real caller | Authentication, bounded sessions, revocation | | An operator who can read the serving process | No - plaintext is in memory while it serves | Host access control, separation of duties | | The value after it is delivered | No - it left the store as plaintext | The consumer's own handling | | A mistake in the store's own rules | No - the mistake serves plaintext | Review and testing of those rules | The sentence to carry out of this: **encryption at rest changes what a copy of the bytes is worth; it changes nothing about what the store will do for someone it answers.** ## Why the running store holds plaintext anyway A store exists to answer. Once the material that protects its files is available to it, the service can decrypt what it is asked for, and plaintext therefore exists inside that process for as long as it is serving. That is not a defect - it is the trade you made when you chose a store over an encrypted file copied to every consumer. The decryption boundary moved out of many places and into one service that can also prove who is calling, decide what they may have, record it and withdraw it later. The consequence for threat modelling is blunt. Anyone with enough access to the host to read that process, or enough credential to make the store answer as a legitimate caller, is unaffected by the file encryption. An honest diagram draws at-rest encryption as a boundary around the *storage*, not around the *service*. ## The four ways this gets stated wrongly 1. **Double-counting the control.** The same encryption is claimed against media loss and against insider access. It removes only the first. 2. **Offering it as an answer to the wrong question.** 'It is encrypted at rest' does not answer 'who can read this value', which is settled by the rules over callers. 3. **Assuming an encrypted backup is safe wherever it goes.** A backup is inert only while the material that opens it is held apart and is out of the holder's reach. Ciphertext filed next to its key is plaintext in a thin wrapper. 4. **Believing a change of protecting key helps a copy already taken.** Rotation bounds what a *future* copy is worth. It does nothing to bytes someone already holds, and unless the earlier material was actually destroyed, that copy still opens. ## Where designs differ, and where they do not Stores differ in nearly every detail underneath: how finely the protection is applied - a whole file or each stored object - whether backups are written in the same form as the live files or protected separately, and where the protecting material is kept while the service runs. **What does not differ is the boundary.** Every design worth the name keeps the protecting key out of the encrypted files, and every one of them decrypts for the caller it is willing to answer. When you are asked what at-rest encryption buys, describe that boundary, and say plainly that the details below it vary rather than presenting one design as the general rule.
- If the store's files are encrypted, why does it still need rules about who may read which value?Because the store decrypts on its own initiative for anyone it will answer. The serving path is deliberately transparent to a caller that authenticates successfully, so without rules that caller reads everything the store holds. Encryption is applied to the files; the rules are applied to the callers, and only the second bounds reach.
- Does encrypting the store's files change anything about the value once it reaches the consumer?No. The store hands plaintext to the caller it allows, and everything afterwards - the response, the consumer's memory, its logs, its rendered configuration - sits entirely outside the store's encryption. Those are different controls with different owners, which is why at-rest encryption is never the answer to 'how do we stop the value leaking from the service'.
A safe protects the documents inside it against anyone who carts the safe away. It protects nothing against the person the safe opens for, and nothing at all while the drawer is out on the desk.
saying these in an interview costs you the question
- Says encryption at rest stops an insider who can call the store
- Claims the value is still protected once a caller is authorised
- Treats an encrypted store as not needing rules over callers
- Thinks the store holds no plaintext anywhere while running
- Assumes an encrypted backup is safe regardless of where the opening key sits