Outbound only, encrypted per site: how warehouse data leaves the building safely
The sync service opens outbound connections only, compresses and encrypts each site's changes with that site's own key, and keeps each site in its own central space. What a security reviewer will ask.
Any proposal to send warehouse data to the cloud arrives at an IT security reviewer's desk eventually, and the reviewer's job is to assume the worst. This is a description of how the redfly sync service moves data out of a site, written for that reviewer, with the questions they are likely to ask and the honest answers.
Nothing connects inward
The service runs on a machine inside the site's network, behind the site's existing firewall, next to the warehouse database. It opens connections outward, to the central store, and to nothing else. It accepts no inbound connections; nothing reaches in.
The consequence for the firewall is simple. No inbound rule is needed; the service only has to be allowed out to the central store. If the site's outbound policy is restrictive, that is the single exception to add.
The service reads from the warehouse database using login details you provide, and it touches only what those details permit. It needs to read the tables you choose; on SQL Server it reads change tracking (the engine's built-in list of which rows changed) for those tables. It never writes to the warehouse database, and the login you provide need not allow it.
What leaves the building
Only rows from the tables you have chosen, and only when they are added, changed or deleted after the initial copy. The service does not read tables outside its list.
Before anything leaves, each batch of changes is compressed and then encrypted with that site's own encryption, so that only you can decrypt it. Compression comes first, because encrypted data does not compress; encryption second, so the bytes on the wire are unreadable to anyone in between.
Encrypting per site matters for a specific reason. If one site's encryption is ever exposed, it opens that site's data and nothing else. A single shared key across thirty warehouses would make every site's data hostage to the least careful one.
Where it lands
The central store is low-cost document storage, and it can run in your own cloud account, under your identity and access rules rather than ours. Each site keeps its own space in the store, and every row is stamped with the site it came from. Access to reports can therefore be granted per site: a regional manager sees their region's spaces, a customer portal sees only the rows for that customer, head office sees all of it.
When the store is in your account, your existing logging, retention and key management apply to it, and your rows sit alongside nothing that is not yours.
The questions a reviewer asks
The same questions tend to come up in this review. Here are the ones that matter and the straight answers.
- Can the central side reach into the site? No. There are no inbound connections and the service is not built to accept one. The central store cannot write to the warehouse database.
- What if the service's machine is compromised? What is on that machine is the read-only login to the chosen tables, that site's queued changes and that site's encryption. Other sites are encrypted separately, and a read-only login cannot alter the warehouse database.
- What if the central store is compromised? The store sits in your cloud account under your own access controls, so what can be read there is governed by the same policy that protects the rest of your account.
- Does it use triggers or a transaction-log reader on SQL Server? No. It reads change tracking on a short interval, a built-in feature of the engine; there are no triggers and no log reader.
- What happens on the wire during an outage? Nothing. Changes wait on site, compressed and encrypted in the queue, and resume when the link returns.
- Is delivery guaranteed? At-least-once, reconciled on arrival. Nothing is lost; some changes may be sent twice and are recognized centrally.
What we do not claim
We do not claim the service is invisible to the warehouse server; it is a process that uses some processor time and disk, and it holds back when the machine is busy. We do not claim the central copy is a security boundary for the warehouse; the warehouse's own controls remain the controls that matter. And we do not claim the data is anonymous once it arrives; it is your operational data, in your account, and how it is governed there is your policy applied to your store.
What we do claim is narrow. Data leaves the site through one outbound channel, encrypted for that site, only for the tables you chose, and lands in a space of its own in a store you control.
One outbound connection, one key per site, one space per site, nothing reaching back in.
redfly installs and runs this service at each site as part of a design partnership, with your IT contact and your security reviewer in the loop from the first site.