Per-site encryption keys: why every warehouse gets its own
Giving each warehouse its own encryption boundary limits what one leaked key can expose, keeps rotation a local job, and stops a single weak site from putting every other site at risk.
A warehouse that sends its data to a central store is trusting a lot of things it cannot see: the public internet, the cloud account at the other end, and every other site feeding the same place. Encryption is how you make that trust smaller. The harder question is not whether to encrypt, but how many keys to use and how far each one reaches.
In the multi-site sync we build, changes are queued at each site, compressed, and encrypted with a key unique to that site before they leave the building. Below we set out what a per-site key buys, how replacing keys behaves when they are separate, and why one shared key is a weak design.
What travels, and where it waits
A small service runs inside the customer's own network at each warehouse, depot or plant. It watches the tables the customer chooses and carries rows that are added, changed or deleted. Data flows one way only, outward from the site to a central store, and nothing comes back in.
When a row changes, that change waits its turn at the site, compressed and encrypted, and is then sent on. If the link drops, the queue waits, and sending resumes from where it stopped, table by table. Delivery is at-least-once, meaning a change may occasionally arrive twice, and it is reconciled on arrival.
That queue matters for encryption. On a poor link, changes can sit on site for as long as the link is down, so waiting data needs protecting as much as data on the move.
What a per-site key protects against
An encryption key is the secret that turns readable data into scrambled data and back again. Anyone holding it can read everything it protects. So the useful question is simple: if it leaked tomorrow, what would it expose?
Because each site has its own key, the answer is bounded. Consider the ordinary ways a key can escape:
- A server at one warehouse is stolen, thrown out carelessly, or broken into.
- A contractor with access to one site copies more than they should.
- A configuration backup from one location ends up somewhere it should not.
In each case, a per-site key exposes that one site's data. The other warehouses, in other time zones, run on other hardware under other staff, and their data stays unreadable. The damage stops at the site fence, which is where the risk started.
The right size for a key is the smallest boundary you would want a leak to stop at.
This lines up with how the central store is organized. Every row is stamped with the site it came from, and each site keeps its own space. Encrypting per site applies the same separation before the data ever leaves the building.
Why one shared key is the wrong design
A single key for every warehouse is tempting. It is one thing to create and look after. But it turns every site into a door to every other site.
The weakest location sets the security of the whole network. A shared key has to be present at every site, so it is only as safe as the least guarded server in the least watched warehouse. Thirty sites means thirty places it can leak from, and any one leak exposes all thirty.
It also blurs accountability. If data turns up where it should not be, a per-site key points to the site involved and to the one key that needs replacing. With a shared key, you know only that something, somewhere, went wrong.
Finally, sites are added at different times and sometimes close or change hands. A key tied to one site can be retired with that site, while a shared key outlives every site that ever held it.
What happens when a key is rotated
Rotation means replacing a key with a new one on purpose, either on a schedule or because you suspect the old one is exposed. The design question is what a rotation disturbs, and separate keys pay off again here. What follows is general reasoning, not a description of any product's procedure.
With per-site keys, rotating one warehouse is a local event. In outline, a sound rotation for one site follows this shape:
- Issue a new key for that one site.
- Encrypt new changes at that site with the new key.
- Let anything already queued under the old key drain and be read centrally.
- Retire the old key once nothing depends on it.
Every other site carries on untouched. With a shared key, the same rotation has to happen everywhere at once, across sites that may be offline, busy, or on a poor link at the moment you choose. A site that misses the change stops being readable, and the central store is left holding data under two keys with no clean line between them.
Queued data during a rotation
The queue deserves one more thought. Because changes can wait on site while a link is down, any sound rotation plan has to account for data encrypted under the old key that has not been sent yet. Keeping the old key usable for reading until that backlog clears is the general principle; cutting it off early would strand changes that were otherwise safe.
Where redfly fits
In the multi-site sync redfly provides, changes are compressed and encrypted with a key that belongs to that site alone, so that only the customer can decrypt them, before they travel outward to one central store. That per-site boundary matches the separate space each site keeps once its rows arrive.