Beyond its own files, where else does a running secret store's plaintext exist, and what does at-rest encryption cover?

## Covered means one specific thing 'The store is encrypted at rest' is a statement about the store's **dataset files** and the backups written from them. It is not a statement about the host, the process, or anything the store emits. Getting an honest answer here means enumerating where plaintext actually is while the service runs, and then marking each place covered or not. ## The split that organises the whole answer | Where a copy comes from | What it yields | Covered by the file encryption? | |---|---|---| | The dataset files on disk | Ciphertext | Yes | | A backup written from those files | Ciphertext | Yes, on the same condition - the opening material is held apart | | A block-level copy of the volume | The same ciphertext files | Yes, for the files themselves | | The serving process's memory | Plaintext for what it has decrypted | No | | Memory the system paged out of that process | Plaintext | No | | A crash dump of the serving process | Plaintext, written to disk in the clear | No | | Temporary files or diagnostics the store writes | Plaintext, if the store writes any | No | | The response on its way to the caller | Plaintext, wrapped by the connection | No - a different control entirely | The organising rule: **a block-level copy is ciphertext, a memory-level copy is not.** That one sentence resolves most of the confusion in this area, including why a snapshot of a running node is reassuring while a dump of the same node's memory is a full disclosure. ## Why the plaintext has to be there There is no design in which a store answers a request without decrypting, so plaintext in the serving process is a property of the thing, not a shortcoming of one implementation. What differs between designs is how much and how long: whether the whole dataset is decrypted once and held, or each value is decrypted per request and released; whether the process pins its memory so the system cannot page it out; whether crash dumps are disabled outright on those hosts. Those are real, meaningful differences, and they are differences of degree inside a boundary nobody escapes. The techniques a process uses to hold a value carefully once it has it - the choice of buffer, wiping after use, keeping it out of diagnostic output - are a subject of their own and belong to whoever writes that code. What matters at this altitude is the inventory: knowing that these copies exist at all, and not claiming a control over them that the file encryption does not provide. ## What actually bounds the uncovered copies Since the encryption does not reach them, something else must: - **Host access.** Whoever can read the serving process or its dumps has the contents. This is why access to store hosts is normally narrower than access to the store's data through its own interface, which sounds backwards until you notice that the interface can check rules and the host cannot. - **Operational settings on those hosts.** Disabling crash dumps, keeping the process's memory from being paged out, and keeping general-purpose tooling off the machine each remove one of the rows above. - **Protection of the connection.** The response is plaintext the moment it leaves; only the transport protects it in flight, and that is an entirely separate control from the at-rest encryption. Counting them as one is a common double-count. - **The scope of what any one value can reach.** Once you accept that some copies are not covered, keeping each value narrow is what limits what an uncovered copy is worth. ## How to answer this in an interview The weak answer is a list of good practices. The strong answer is an inventory with a verdict per row, in the candidate's own words: here is where plaintext is, here is which copies the encryption reaches, here is what bounds the rest. Then one honest consequence: an attacker who reaches the store's host has not been slowed by the file encryption at all, which is why 'encrypted at rest' belongs in a threat model as a line around the storage and never as a line around the service.