How to protect backups from ransomware and account compromise

The threat model

CISA's #StopRansomware Guide warns that many ransomware variants try to find and then delete or encrypt any backups they can reach, so that restoring is impossible without paying. Plan for each position an attacker can be in:

The goal: no single stolen credential, and no single compromised machine, can delete every copy.

Give servers keys that can write but not delete

A backup job needs to upload. It rarely needs to delete: let lifecycle rules in the storage remove old backups instead, as in the retention policy guide. On AWS, attach this policy to the server's IAM user or role. AWS evaluates an explicit deny over any allow, so the Deny statement holds even if a broader policy is attached later by mistake.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListOwnPrefix",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::acme-server-backups",
      "Condition": { "StringLike": { "s3:prefix": ["web-01/*"] } }
    },
    {
      "Sid": "UploadAndReadOwnPrefix",
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject", "s3:AbortMultipartUpload"],
      "Resource": "arn:aws:s3:::acme-server-backups/web-01/*"
    },
    {
      "Sid": "NeverDeleteOrLoosen",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:BypassGovernanceRetention",
        "s3:PutObjectRetention",
        "s3:PutObjectLegalHold",
        "s3:PutBucketVersioning",
        "s3:PutLifecycleConfiguration",
        "s3:PutBucketObjectLockConfiguration",
        "s3:PutBucketPolicy",
        "s3:DeleteBucketPolicy",
        "s3:DeleteBucket"
      ],
      "Resource": [
        "arn:aws:s3:::acme-server-backups",
        "arn:aws:s3:::acme-server-backups/*"
      ]
    }
  ]
}

• s3:ListBucket and the object actions are limited to the web-01/ prefix, so one server cannot see another's backups.
• s3:PutObject uploads, including multipart uploads. s3:GetObject reads backups back for checks and restores. s3:AbortMultipartUpload cleans up a failed upload. None of them removes a finished backup.
• The Deny list blocks deleting objects and versions, bypassing or setting Object Lock retention and legal holds, and changing versioning, lifecycle rules, Object Lock or the bucket policy. Uploads still get the bucket's default retention: s3:PutObjectRetention is only needed to set retention on an object explicitly, so denying it also stops a stolen key from extending locks to run up your bill.

Other storage works the same way, with different controls:

• Wasabi: a policy with no delete actions, plus a lifecycle rule for retention, as in the Wasabi guide.
• Backblaze B2: the b2_create_key API lets you pick key capabilities one by one, such as listFiles, readFiles and writeFiles without deleteFiles. writeFiles can still hide files, which a lifecycle rule later deletes, so keep that delay long enough to notice. See the B2 guide.
• Cloudflare R2: an Object Read & Write token can delete, and R2 has no versioning or write-only option. Bucket lock rules, below, are the protection. See the R2 guide.
• Your own backup server: pull instead of push. If the backup machine connects to production and copies from it, as in the rsync guide, the production server holds no credentials that reach its backups.

Lock copies so nobody can delete them early

Write-only keys stop the server. Locks stop people as well, up to someone who has taken over the storage account, depending on the mode:

Object Lock needs versioning, and once on, it cannot be turned off on S3, B2 or Wasabi. On S3, a delete without a version ID on a locked object only adds a delete marker; the locked version stays. Setup commands and the lifecycle interplay are in the 3-2-1 guide and the S3 bucket guide.

Lock for at least as long as it could take you to notice an attack, and for less than your lifecycle expiry. CISA's guide cautions that misconfigured immutable storage can impose significant cost, since every locked version is billed until its lock ends. Start in governance mode, watch a full cycle of costs, then decide on compliance mode.

Some clouds can lock snapshots too. On AWS, EBS snapshot lock stops a locked snapshot from being deleted, and Recycle Bin keeps deleted snapshots recoverable for a period you set; see the EBS snapshots guide.

Keep one copy at another provider, under another login

Locks inside one account still depend on that account. CISA's guide suggests considering a multi-cloud approach for cloud backups, in case all accounts with the same vendor are affected. That is the off-site copy of the 3-2-1 rule, with three conditions:

• A different company from the one running your servers.
• A different login: another email address, another password, its own MFA. Not single sign-on through the identity that runs production.
• No credentials for it on production servers, except a write-only key.

Append-only repositories for restic and Borg

Deduplicating backup tools can be served in append-only mode, where clients can add backups but not remove or overwrite them:

• restic: rest-server's --append-only flag allows new backups but not deleting or changing existing ones. restic's docs warn that fake snapshots added by an attacker can make a later forget --keep-weekly remove the real ones, so on append-only repositories use --keep-within, and run forget and prune from a separate, trusted machine.
• Borg: put borg serve --append-only in the command= entry for the server's key in the backup host's authorized_keys. A compromised client can still run borg delete or borg prune, but nothing is removed from disk, and a transaction log lets you roll back to the last good state. borg compact does nothing in append-only mode; run it only with a trusted admin key after checking the archive list.

Setup for both is in the restic and Borg guides.

MFA, separate admins and fewer standing keys

• Turn on MFA for every cloud, storage, DNS and email account. CISA recommends phishing-resistant MFA, especially for email and accounts that reach critical systems.
• Never use the root or owner account day to day, or put its keys on a server. Use a separate admin user for bucket settings and a write-only user per server.
• Keep recovery codes and the backup encryption key offline or in a password manager that does not depend on the systems you protect. Object Lock does not help if the key is lost.
• Delete API tokens you no longer use, and scope the rest as narrowly as the provider allows.

Watch for deletions and silence

• Missing backups. Alert when the newest backup is older than its interval, not only when a job reports a failure. A job that never ran reports nothing.
• Shrinking backups. A backup much smaller than yesterday's can mean the source was emptied or encrypted.
• Deletions. On S3, an event notification for s3:ObjectRemoved:* fires when an object is deleted or a delete marker is created, and AWS notes it does not fire for lifecycle deletions. If only lifecycle rules delete, every such event means a person or a key deleted something; send it to an SNS topic that reaches your phone.
• Account activity. Read your providers' sign-in and new-key alerts. An unexpected login is the earliest warning you will get.
• Restores. CISA advises keeping offline, encrypted backups and testing their availability and integrity regularly. A backup of files that were already encrypted uploads and verifies normally; only a restore drill shows the problem.

An offline copy is one no network path can reach: a disk you connect monthly, copy the newest backup to, check and disconnect. It is slow to restore from, so it adds to the online copies rather than replacing them.

Checklist

Frequently asked questions

Can ransomware delete cloud backups?

Yes, if the backups can be reached with credentials on the infected machine or in an account the attacker controls. Write-only keys, Object Lock and a copy at another provider under another login close those paths.

Is Object Lock enough to protect backups?

It stops locked versions from being deleted or overwritten. It does not help with a lost encryption key, a backup that was bad before it was locked, or the cost of a lock set too long. Combine it with restore tests and an independent copy.

Are provider snapshots safe from ransomware?

From malware on the server, usually, unless a provider API token is stored on it. From someone with your cloud login, no: they can delete snapshots unless your provider offers a lock and you use it.

What is an immutable backup?

A backup that cannot be changed or deleted for a set period, enforced by the storage rather than by your own scripts. S3 Object Lock in compliance mode is the strictest common form.