Your nightly backup of the secret store is ciphertext — what else must recovery have in hand, and why is it deliberately not in the backup?
answer
- the archive alone is not the store
- two inputs, two custodies
- restoring copies bytes, not readability
- self-opening backup if stored together
- prove the second custody before the outage
basics
~20 sA store's backup holds its own ciphertext, so recovery also needs the key that protects the store, kept in separate custody. Keeping both in one place makes the backup self-opening: a single stolen copy is then a full compromise.
solid answer
~40 sA secret store writes ciphertext, so its archive is ciphertext too — restoring it copies bytes back without making them readable. The second input is the material that unwraps the store's contents, and it is held apart on purpose, because an archive travels: it is copied offsite, retained, and handled by more systems and people than the running store. Separation is what makes each of those copies uninteresting on its own. The price is that recovery has a step nobody watches — producing that material from its custody, which has its own availability. The shortcut of storing both behind the same access removes the price and the protection together: one theft yields the records and the means to read them.
code
pseudocode · 12 linesrestore(archive, unwrapMaterial):
files = copyBack(archive) # ciphertext on disk
if unwrapMaterial is absent:
store.state = "restored, not serving"
return store # records present, unreadable
store.open(files, unwrapMaterial)
store.state = "serving"
return store
# run this BEFORE the outage, not during it
if custodyOf(archive) == custodyOf(unwrapMaterial):
finding = "one theft opens the backup; one loss ends recovery"go deeper
Recall the shape: a secret store's backup is encrypted, so a copy of it is not the same as access to it. Something held elsewhere is needed to open it.
Explain the mechanics: the archive is ciphertext, the key that protects the store is a second input held in separate custody, and encryption of the archive only means anything while the two stay apart.
Show that you have operated it: name the custody step as part of recovery time, say who can produce the material out of hours, and describe how you would spot the partial failure where one credential reaches both custodies.
Frame the trade: separation moves leak risk onto reachability risk. Decide how many custodies the estate can actually staff, and set the standard for what counts as two independent failure domains.
## What a backup of a secret store actually holds A secret store does not keep credentials as readable files. Its records are encrypted under a key of its own, and everything it writes to disk — the live data files and the archive a backup job produces — is ciphertext. A backup is therefore a copy of encrypted records plus enough structure to rebuild the store's state. Restoring it copies bytes back into place. It does not make them readable. What makes them readable is **the key that protects the store**, and in a well-run estate that material is deliberately elsewhere: in another service's custody, inside a device that will not export it, or split into shares that several holders must recombine. Designs differ in where it lives and in how the store obtains it when it starts. The recovery consequence is identical everywhere: *the archive is one of two inputs, and you must be able to produce the other.* ## Why the two are kept apart - An archive is made to travel. It is copied to a second location, held for a retention period, and handled by more systems and more people than the running store ever is. - Every copy is another place a theft can start. Separation is what makes each of those copies worthless on its own. - Encrypting the archive means something only while the key is not beside it. Once both sit behind the same access, the ciphertext is decorative. - Separation also bounds an insider: whoever holds the archive cannot read it, and whoever holds the key has nothing to apply it to. ## What the separation costs when you actually need it Recovery is four steps, and only the first is the one people rehearse: 1. Obtain the archive — usually the fast part, and the part monitoring already watches. 2. Obtain the material that unwraps it, from whatever custody holds it. This step has its own availability: a person who must be reachable, an approval, a device that must be present, or another service that must itself be up. 3. Open the restored store and confirm it serves a known value to a real caller. 4. Reconcile what the restore did not bring back. Step 2 is where recovery time is usually lost, and it is the step a green backup dashboard says nothing about. | | Archive and key in one custody | Archive and key in two custodies | |---|---|---| | A stolen archive | opens; full compromise | ciphertext, with nothing to open it | | The key custody is unreachable | irrelevant — you already have it | recovery stalls until it is produced | | Recovery time | shortest | longer, dominated by producing the key | | What must be rehearsed | the restore | the restore **and** the custody path | The table does not say separation is free. It says separation moves a risk you cannot control — a copy of the archive leaking — onto a risk you can, which is being able to reach your own custody, and that the trade only pays if the second one is exercised before you need it. ## The shortcut, and what it undoes The shortcut is to put the unwrap material into the archive, beside it, or behind the same access as it — usually because a recovery once stalled waiting for a person. The result is a self-opening backup. One theft, one mistaken permission, or one over-broad grant on the archive location now yields both the records and the means to read them, and the store's encryption at rest protects nothing that matters. The partial version is more common and just as bad: the archive and the key live in different files or different services, but the same credential, the same rule or the same operator reaches both. Separation is about failure domains and people, not about paths. Two custodies that fall to one compromise are one custody. ## What this does not claim Encrypting the archive defends it against someone who obtains a copy and reads it offline. It does not defend a value against a caller the store's own rules allow, against an operator who can read the running process, or against anyone the store will answer. A backup strategy is not an access-control strategy, and the two are judged separately. ## Where designs genuinely differ - Some stores produce an archive only an equivalent instance can open, holding the protecting key entirely outside it; others hand you an export whose protection you choose yourself. - Where the unwrap is delegated to a managed key service, what recovery must produce is not key material at all but the right to call that service — which can be revoked, can expire, or can belong to an account that no longer exists. - Where the key lives in a device that will not export it, the archive is openable only where such a device is present, which is a real constraint on where and how quickly you can recover. Whichever design you are on, the interview answer is the same shape: name the second input, name who can produce it, and say when that was last proven.
- The archive is copied to a third location — what has that improved, and what has it not?It improves durability: losing one copy no longer ends recovery. It improves nothing about openability, because every copy still needs the same material to unwrap it. It also adds a third place a theft can start, so the copies are only safe while that material stays out of all of them.
- What should a recovery record state about the protecting key without recording the key itself?Where custody sits, who may produce it, how many of them are needed, how their identity is checked, how long producing it took the last time, and the date it was last exercised. The material never appears in the runbook; the path to it does, because that path is what recovery actually waits on.
The safe is delivered to the new office and the combination travels by a different route: intercepting one lorry gets you nothing, and forgetting to arrange the second delivery leaves you with furniture instead of money.
saying these in an interview costs you the question
- Says the backup is safe because the store encrypts at rest, then stores the key beside it
- Assumes a restore needs only the archive file
- Thinks the key that protects the store can be recovered from the backup itself
- Calls an offsite copy sufficient without saying who can supply the protecting key
- Treats split custody as removing the need to test the recovery path