Most backup architectures include something described as isolated: an air gapped copy, a segmented repository, a vault. The description is usually accurate about intent and frequently optimistic about implementation. Isolation is a property of the actual network paths, credentials and management interfaces in place, and those accumulate exceptions over time for reasons that seemed reasonable at the moment each one was made.
The test is specific and answerable: from a compromised production system with administrative credentials, what can be reached, authenticated to, altered or deleted. Running that test turns isolation from an architecture diagram into a measured control.
The threat model is an attacker who has already obtained administrative access to the production environment. That is the assumed starting position, not a worst case, because it describes most serious ransomware incidents. The purpose of isolation is that this position does not extend to the backup copies.
Three outcomes need to be prevented. The attacker should not be able to delete or encrypt the copies. They should not be able to alter retention so the copies expire early. And they should not be able to disable the protection so that future copies are unprotected while everything still appears normal.
Notice that the last two do not involve touching the data at all. An attacker who can change a retention policy or stop a job has removed the recovery capability without triggering anything that watches for deletion.
Isolation is typically implemented at the network layer and then undermined somewhere else. The table below covers the paths most often found open during a real test.
| Path | How it stays open | What to check |
|---|---|---|
| Management interface | Storage or appliance console on the production network | Whether an admin workstation can reach it at all |
| Shared directory service | Repository authenticates against production identity | Whether a domain admin has any rights on it |
| Backup server itself | It must reach the repository, and it is in production | What its credentials can do beyond writing |
| Hypervisor or platform layer | Isolated system runs on shared infrastructure | Whether a platform admin can delete the storage underneath |
| Monitoring and support access | Agents, remote support tunnels and jump hosts | What those channels can change, not just read |
| Retention and policy settings | Configurable from a console reachable in production | Whether lock settings can be shortened by anyone |
| Recovery of the isolated system | Its own credentials stored in production | Whether access survives the loss of production |
The backup server row is the structural difficulty. Something has to write the backups, so a path exists by construction. The question is what that path is permitted to do. A credential that can write new objects but cannot delete or shorten retention is a very different exposure from one that administers the repository, which is the reasoning behind keeping backup access on separate paths.
The exercise should start from a realistic position: a workstation or server inside production, with domain administrator credentials, behaving as an attacker would. From there, attempt each action in turn and record the result rather than the expectation.
Attempt to reach the repository's management interface. Attempt to authenticate with production credentials. Attempt to list, then delete, then overwrite an object. Attempt to shorten a retention setting or disable a lock. Attempt to stop or modify a backup job. Attempt to reach the isolated environment's hypervisor or underlying platform.
Each attempt has three possible results: blocked, permitted, or permitted but detected. The third is worth recording separately, because a control that generates an alert nobody is watching is functionally the first.
Findings cluster into a few categories. Network paths that were opened for a legitimate purpose and never closed are the most common and the easiest to fix. Shared credentials are next, and they are usually resolved by giving the repository its own authentication rather than integrating it with the corporate directory.
The more awkward findings concern the platform layer. An isolated repository running as a virtual machine on the same hypervisor cluster as production is isolated at the network layer and not at all at the storage layer, because a platform administrator can delete the underlying disks. Genuine separation of the platform is more expensive and it is the difference between a control and an appearance of one.
It is also worth testing what an attacker could do slowly. Isolation that holds against deletion but permits a gradual change to retention policy fails against a patient intrusion, and that pattern is exactly what silent retention changes describe.
Object storage with S3 Object Lock in compliance mode enforces retention within the storage system itself, so a copy cannot be deleted or its retention shortened before the period expires, regardless of the credentials presented. That places the control below the level an attacker operates at, which is what makes it hold when identity infrastructure has been compromised.
On Scality RING and ARTESCA the repository authenticates with its own S3 credentials rather than through the corporate directory, so a domain administrator does not inherit rights over the copies. The credentials the backup software uses should be scoped to write and read rather than to administer, and the account that could change lock configuration should be separate, held outside production, and used rarely enough that its use is itself a signal. Those are configuration choices rather than defaults, which is why the test is what confirms them.
Isolation degrades quietly. A firewall rule added for a migration, a monitoring agent deployed estate wide, a directory integration enabled for convenience, and the separation that was verified last year no longer exists. None of these changes look like a weakening of backup protection at the time they are made.
Running the test annually, and after any significant change to networking, identity or the backup platform, keeps the finding list short. The output is a simple statement that can be given to an auditor or an executive: here is what a compromised production environment could reach, and here is what it could not.