4 Immutable Backup Rules That Survive Cloud Ransomware

An immutable backup is the one copy a ransomware crew holding your credentials still cannot delete. CISA’s joint #StopRansomware guidance tells cloud teams to enable delete protection or object lock on the storage ransomware crews hit first — object, database, file and block storage — while cautioning that immutability does not satisfy every regulation and that a misconfigured lock can impose significant cost. That tension is the real design problem: the lock has to stop attackers without trapping your own recovery. Four rules resolve it in practice: isolate the backup identity plane, lock restore copies in the strictest mode your operations can tolerate, version data before you lock it, and rehearse restores while the lock is still in force.

Why Backups Are the First Target

Ransomware operators do not treat backups as collateral damage; they treat them as the objective. The CISA guide documents that actors hunt for credentials stored in the targeted environment and then use them against backup solutions, and that they exploit unpatched backup products directly with publicly available tooling. It also warns that automated cloud backups can be actively harmful: when local files are encrypted, sync pipelines copy the encrypted versions over the unaffected copies in the cloud. The first rule, then, is identity isolation. Put backup tooling in its own cloud account or subscription, with no standing credentials shared with production workloads, and retire the long-lived keys that make credential theft trivial — the same reasoning behind workload identity federation for retiring static cloud keys. Detection matters as much as isolation: failed delete attempts against locked objects are loud, high-signal events, and the choices that surface them quickly are the ones behind a solid cloud logging strategy for fast investigations.

How Object Lock Enforces Immutability

Amazon S3 Object Lock implements immutability as a write-once-read-many model layered on mandatory versioning, and once Object Lock is enabled on a bucket you cannot disable it or suspend versioning — a deliberate one-way door. In compliance mode a protected object version cannot be overwritten or deleted by any user, including the root user, its retention period cannot be shortened, and the only way to remove an object before its retention date expires is to delete the associated AWS account. That is exactly the property you want on restore copies: compromise of every credential in the estate still cannot shrink the retention window. Governance mode is the softer variant, where most users cannot touch locked objects but administrators keep an escape hatch. Overriding or removing governance-mode retention requires the s3:BypassGovernanceRetention permission and an explicit x-amz-bypass-governance-retention:true request header on every request that bypasses the lock, which turns a bypass into an auditable, denyable action instead of a silent one. The pragmatic pattern: run backup automation in governance mode for a sprint or two, then promote restore-critical buckets to compliance mode once lifecycle and expiry behavior are proven.

Comparing AWS and Azure Retention

Azure reaches the same destination through different primitives, documented in the immutable storage overview for Azure Blob Storage. Azure Blob Storage time-based retention policies support intervals from a minimum of one day to a maximum of 146,000 days, equal to 400 years, and once a policy is locked it cannot be deleted and its retention interval cannot be shortened. The testing story differs: Azure lets you start with an unlocked policy that still blocks deletes and overwrites but can be modified or removed, and Microsoft recommends locking within a reasonable time, typically less than 24 hours. S3 has no unlocked middle state; governance mode is its proving ground.

Seven-Step Lockdown Procedure

1. Inventory the datasets you would genuinely need to restore revenue-generating systems, ranked by recovery-time tolerance.
2. Create a dedicated backup account or subscription with its own identity plane and zero shared credentials with production.
3. Enable versioning plus Object Lock, or immutability support, on brand-new buckets and containers before the first write, so no object lands unprotected.
4. Start in governance or unlocked mode and let backup automation run end to end, including expiry and lifecycle transitions.
5. Promote restore-critical data to compliance mode or a locked policy, with retention sized to your worst-case investigation and rebuild window.
6. Deny bypass permissions at the organization layer: strip s3:BypassGovernanceRetention from every role that does not need it and alert on any use of the bypass header.
7. Run a quarterly restore drill from locked copies, measure the elapsed time, and file the result beside your recovery-time objectives.

Trade-Offs Worth Planning For

Immutability is not free. Retention you cannot shorten is storage you cannot reclaim, so an over-long compliance window on a churning dataset is pure cost — the reason CISA pairs its object-lock recommendation with a warning about misconfiguration expense. Locks also do not protect the keys: S3 Object Lock does not stop data from becoming unreadable if the encryption key is deleted, so key custody needs its own controls, recovery copies included. Regulation cuts both ways, too. Some frameworks accept WORM storage as satisfying retention duties, while others impose delete-on-request rights that a long compliance lock conflicts with, which means legal review belongs in the design phase rather than after the lock clicks shut. Plan the retention window as a business decision with a calendar, not as a default you accept at bucket creation.

Sources

• CISA — #StopRansomware Guide
• AWS — Locking objects with S3 Object Lock
• AWS — Object Lock considerations
• Microsoft — Immutable storage for Azure Blob Storage overview