How do you build air-gapped cloud backups for ransomware resilience?

What “air-gapped” should mean in cloud backup design

An air-gapped backup is not just a backup stored in a different account or region. For ransomware resilience, the important property is that production compromise does not give the attacker routine write or delete access to the backup copy. In cloud environments, that usually means immutable storage, separate administrative control, and a restore path that is reachable only through tightly limited access.

The practical test is whether a compromised production identity, workload, or admin session can still alter the backup plane. If it can, the backup is only logically separate on paper. A usable design combines immutability, network and permission isolation, and a deliberate break-glass path for restore operations.

A good reference point is the Backup Security and Immutable Backup Guide, which covers the core backup controls that make an air-gapped model durable in practice.

How to separate production from the backup plane

Start by ensuring the backup target is not managed through the same credentials, roles, or automation used by production. Separate admin accounts, separate API keys or service principals, and separate approval paths reduce the chance that stolen production access can reach backup deletion or overwrite functions. Where the cloud platform supports it, use object lock, WORM-style retention, or equivalent immutability settings so even a privileged operator cannot casually remove protected backup objects.

Network separation matters too, but it is not sufficient on its own. A logically isolated vault can still be reachable through control-plane permissions, shared automation, or delegated trust. The safest model is to assume the attacker will discover any route that remains available from production and remove those routes from the normal operating path.

For cloud compromise scenarios, the Cloud Incident Response Guide is useful because backup isolation depends on the same discipline used to contain keys, sessions, and recovery access during a live incident.

How to keep backups usable after an attack

Resilience depends on more than storing copies. You need proof that you can restore a clean workload, at speed, with the right dependencies and access controls. That means testing restore procedures regularly, verifying that retained versions are actually recoverable, and confirming that backup credentials are not embedded in production automation. Restore testing should include the failure conditions ransomware creates in real incidents, such as tampered indexes, deleted snapshots, poisoned credentials, or corrupted metadata.

You should also monitor the backup plane itself. Deletion attempts, retention policy changes, unusual admin logins, and mass object operations are strong indicators that an attacker is trying to destroy recovery options before deploying encryption. If backup visibility is weak, teams often discover the loss of recoverability only after the production environment is already encrypted.

The Ransomware Prevention Guide and the Ransomware Response and Recovery Guide both reinforce the same operational point: resilient backups only matter if they survive the compromise and are actually restorable under pressure.

Risk and Threat Considerations

Ransomware operators frequently target backups first because destroying recovery options increases the chance of payment and slows containment. In cloud environments, the main risk is assuming that account separation alone creates an air gap when shared identity, shared automation, or broad delete permissions still expose the backup plane. Immutable storage reduces that risk, but only if the administrative path to disable, shorten, or bypass retention is itself tightly controlled.

Failure mechanism: An attacker who compromises a production admin, CI/CD secret, or cloud automation role can pivot into the backup plane, delete or overwrite recovery points, or tamper with retention settings before encryption starts.

Impact: The organisation loses its clean recovery option, extends outage duration, and may be forced into partial rebuilds from older copies or incomplete data, which can materially increase operational and business damage.

Practitioner Guidance

What to prioritise: Make backup deletion and retention changes harder than production changes. If the same person or automation can both encrypt production and destroy recovery, the design is not resilient enough.

What to verify: Confirm that a restore can be completed from an isolated copy using credentials that are not present in the compromised environment. Also verify that the backup admin path is monitored and that failed delete or retention-change attempts generate alertable logs.

Decision rule: If a backup control can be reached from the same trust zone as production, treat it as part of the attack surface and redesign it before relying on it for ransomware recovery.

Practitioner takeaway: The goal is not “backup somewhere else”, it is “backup somewhere the ransomware path cannot routinely reach, and where recovery can still be proven under compromise conditions.”

Related resources from NHI Mgmt Group

• Why do multi-cloud backup strategies need air-gapped recovery copies for ransomware resilience?
• Why do offsite and air-gapped backups reduce the impact of ransomware and disasters?
• How should security teams use air-gapped backups to reduce ransomware blast radius?
• How should organisations use air-gapped cloud storage in a ransomware recovery strategy?