The Secret Store

Encrypting 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.

The protecting key must arrive from outside the store's own records: recombined from a threshold of shares held separately, unwrapped by a device or a separate key service the store authenticates to, or held by a managed provider that applies it for you.

Most stores append a version rather than overwriting the old one, so the earlier value stays in the name's history and any caller with read rights on that name can ask for it by version. Replacing is not retiring.

Re-key and replace everything. One file-wide key means the departure exposes every entry, so each value is replaced, the file re-encrypted under a new key and every consumer redeployed. A store withdraws that one identity's grant instead.

Three failures share one complaint. Slow means requests still complete, past the caller's timeout. Read-only means reads answer instantly while writes and issuance are rejected instantly. Unable to decrypt means every request fails alike, from the moment the process started.

A restore rewinds the store and nothing else. Values, grants and registrations written after the restore point are gone, as is the read trail for that window — and credentials the store issued into other systems stay live there, unrecorded.

Reading a stored value is served from the copy the follower already holds; generating a credential is a write — the store must record the new credential and its expiry before returning it, and a follower has no write path.

A 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.

Make the credential instead of holding it. Given authority on the downstream system, a store can create a distinct account per consumer at request time, so each has its own identity, its own rights and a withdrawal that touches nobody else.

The store is a start-up dependency, not a per-request one. Already-running processes hold what they fetched and never call it, so a degraded store is invisible until something new starts — and scaling out and rolling restarts are the two activities that manufacture new start-ups.

The credential was rotated after the restore point, and the restore rewound only the store's copy while the downstream system kept the new value. Repair forward: set a fresh value downstream, write it into the store, never reinstate the old one.

You cannot tell from the artefacts. It turns on custody: whether the material that opens each copy ever sat with it, whether it still exists and is reachable, and which values inside have been replaced since.

At-rest encryption covers exactly the store's dataset files and the backups written from them. Plaintext also lives in the serving process's memory, in what the system pages out, in a crash dump, and in the response leaving the store.

Automating the step buys an unattended restart and gives up the property the quorum existed for: that no single holder, and nothing present on the host alone, can open the store. Protection then rests on whatever guards the automated path.

The input that opens a store must be obtainable while the store is closed. Move the unwrap credential to something the node holds independently — an identity its platform signs for the machine, or material its hardware holds — and rehearse a genuinely cold start.

Deletion is reversible in many stores: the entry stops answering reads while the value is still held and can be brought back during a recovery window. Destruction is the separate, irreversible step, and even that covers only the live store.

Read the entry's previous version and write that value back — the undo is a new version, not an erase. It works only where history is kept and still enabled, and the pasted staging value stays in the history until it is retired.

With an encrypted file, nothing about reads — decryption is offline and unobserved, so the honest scope is every entry it held. A store serves the value itself, so each read is an event that narrows the scope to names actually fetched.

Two levers exist: make the store more available, or make the estate need it less. Decide which operations must survive a partition — plain reads — and which may fail, then publish that as the contract every consumer designs against.

A written recovery procedure is an untested assumption; a rehearsal turns it into evidence. Commit to a cadence, a named owner and an isolated environment, and define a pass as a restored store serving a known value within the promised time.

Keeping the opening material as long as the ciphertext keeps every old backup recoverable, and a disclosure waiting on that material. Retiring it sooner makes the archive noise, cheaply and irreversibly, and trades recoverability for custody.

Handing the protecting key to a provider decides who must be present for the estate to start. It buys unattended recovery with no custody to run, and costs the ability to withhold consent or to show that only you can open the contents.

Long enough to undo a mistaken write and no longer: days rather than quarters, with destruction on a schedule rather than on memory, and a tighter setting for names whose single value reaches a large part of the estate.

Which operations you will actually perform, not which feature list is longer. Running one yourself means owning start-up, replicas, backups and a rehearsed restore for a service the whole estate depends on; taking a hosted one trades that for a dependency on somebody else's availability and boundary.