Segmentation projects rarely fail on the firewall. They fail on the list of connections nobody can switch off. A backup environment is supposed to be isolated, yet it has to reach the hypervisor it protects, the storage it writes to, the update source it patches from, and a clock it can trust. The useful work is not cutting links, it is deciding the direction and the broker for each one that has to stay.
The stall happens at the same point in every project. Someone draws a segment around the backup infrastructure, the rules go in, and within a week an exception list has grown back most of what was removed. The exceptions are not carelessness. Each one exists because a real function stopped working, and nobody had decided which functions were allowed to cross.
A more honest starting point is that the backup segment will never be fully isolated while it is doing its job. What can be achieved is narrower and still valuable. No path that lets a compromised production host initiate a session into the segment, no shared credential that works on both sides, and no management plane reachable from an ordinary desktop.
Six categories cover almost every backup deployment. The first is the backup server to the production estate, which in a virtualized environment means the hypervisor management interface, the hosts themselves, and guest level access when application aware processing is in use. This is the widest of the six, running from the protected segment into everything worth protecting.
The second is the backup server to the storage endpoint, normally a single HTTPS port to an S3 compatible service. The third is management access, a human reaching the backup console and the storage administration interface. The fourth is monitoring and logging, which has to leave the segment to be worth anything. The fifth is time synchronization. The sixth covers updates and certificate revocation checks.
Time deserves more attention than it gets. Retention dates, token lifetimes and TLS validation all depend on the clock, so a segment with no trustworthy time source can fail to authenticate to its own storage. Taking that time from a production domain controller reintroduces the dependency the segment was built to remove, which argues for a local source or an upstream feed of its own.
Most of these connections can stay if they only ever open in one direction. A stateful rule that lets the backup server initiate to the hypervisor while refusing any session starting on the production side keeps the function and removes the path an attacker walks in reverse. That single change is usually the largest improvement available.
The storage connection is the cleanest case. The backup server initiates to the storage endpoint and the storage never initiates back, so one outbound HTTPS rule from one host address to one endpoint address covers the entire data path. Monitoring behaves the same way when the collector is configured for push rather than poll, since a pull based collector needs an inbound rule and an account on every monitored host.
Two of the six resist this treatment. Management access is inherently inbound, since a person outside the segment has to arrive at a console inside it. Guest level processing needs several ports and a credential valid on production systems, which is the strongest reason to ask whether application aware processing is required for every workload or only for the databases that justify it.
| Connection | Realistic treatment | What it leaves behind |
|---|---|---|
| Backup server to hypervisor and guests | Outbound only, no production initiated sessions | A production credential held inside the segment |
| Backup server to storage endpoint | One host to one endpoint, outbound HTTPS | An access key stored on the backup server |
| Administrator to backup console | Brokered through a jump host, local accounts only | One inbound path that has to be watched |
| Monitoring and logging | Push outbound to a collector outside the segment | Evidence that survives if the segment falls |
| Time synchronization | Local or upstream source, not a production controller | A dependency on a device outside the backup software |
| Updates and revocation checks | Internal mirror or proxy with a fixed destination list | A staging system with its own patching discipline |
A broker is any intermediary that terminates a session and starts a new one, so the two ends never talk directly. A jump host does this for management access, an internal mirror does it for updates, and a forward proxy with a fixed destination list does it for revocation and vendor endpoints. The value is not encryption, it is that the segment now has a single named peer instead of a range.
Brokering only helps when the broker is not part of the estate being defended against. A jump host that is domain joined, patched by production tooling and reachable from any desktop is a convenience, not a control. The version that changes the outcome is a dedicated host with local accounts and identities that exist nowhere else, which is the reasoning behind separating backup administrator accounts from everyday ones.
The same test applies to the backup infrastructure. If the backup server authenticates its administrators against the production directory, segmentation has moved packets around without changing who can log in, and taking the backup infrastructure off the domain does more for the outcome than another firewall rule will.
A finished backup segment has a small written inventory. A handful of outbound rules with named destinations, one inbound management path through a broker, one outbound telemetry flow, and a time source that does not belong to production. Everything else is denied, and the deny is logged rather than silent, since a blocked connection is early evidence that something changed.
It is worth being clear about what this achieves. Segmentation makes lateral movement expensive and noisy. It does not make the backup data immutable, and it does not survive theft of the credentials permitted to cross the boundary. The network boundary and the retention control on the storage are independent defenses, which is the practical difference between an air gap and immutability rather than a choice between them.
The residual risk is easy to name, which is the sign of a good design. One credential set that works on production, one inbound management path, one storage key. Those three are what the remaining monitoring should concentrate on, and a short list makes it realistic to decide which alerts matter instead of subscribing to everything.
ARTESCA is object storage software used as a backup target, presenting an S3 compatible API over HTTPS. From a segmentation standpoint the entire data path between the backup server and the storage is one protocol on one port to one endpoint address, expressible as a single outbound rule.
Because ARTESCA runs on infrastructure the customer operates, the endpoint sits inside a network boundary the customer defines rather than behind a public service address. Its administrative interface can be reached through the same brokered path as other backup management rather than exposed alongside the data endpoint.
The immutability side is separate from all of this. Object Lock applies retention at the storage layer regardless of which network path a request arrived on, so the two controls fail independently rather than together.
Build the connection inventory before touching the firewall, one row per flow, with source, destination, port, and the function that breaks if it is removed. The fourth field is what prevents the exception list from growing back, since a request without a named function is one nobody can evaluate.
Review the inventory when the backup software is upgraded, when a hypervisor version changes, and when a new workload type is added, since those events introduce ports quietly. A rule added for a migration and never removed is the most common finding in an environment segmented correctly two years earlier.
Keep the deny logging on permanently and give someone the job of reading it monthly. Those blocked connections describe what the environment is trying to do that the design did not anticipate, which is a better guide to the next change than any diagram drawn at the start.