A WORM Backup Layer Runbook with S3 Object Lock

When backups come up in conversation, hearing “we took a snapshot” feels reassuring fast. But under ransomware or accidental internal deletion, the question that actually matters is: who can delete the backup? If a production identity (or a compromised pipeline) can also wipe the backup, what you have isn’t insurance — it’s just another copy.

In S3-compatible stores, Object Lock answers exactly this gap and delivers WORM (Write Once Read Many) semantics. This runbook walks through a practical flow for setting up and validating Object Lock the operational way.

Prerequisites and the design call

• Object Lock has to be turned on at bucket creation time (enabling it later isn’t supported by every provider).
• The bucket usually needs versioning enabled too.
• Pick a retention model:
  • Governance mode: privileged roles can bypass it (more flexible)
  • Compliance mode: bypass is impossible (stricter, riskier)

1) Creating the bucket (Object Lock + versioning)

AWS example (commands vary by provider):

aws s3api create-bucket --bucket corp-backup-worm --region eu-central-1
aws s3api put-bucket-versioning --bucket corp-backup-worm --versioning-configuration Status=Enabled
aws s3api put-object-lock-configuration --bucket corp-backup-worm --object-lock-configuration "ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=GOVERNANCE,Days=30}}"

Goal at this point: produce an “undeletable copy” with at least the default retention applied.

2) IAM / access model (the most critical piece)

WORM only earns its keep through the access model around it. A pragmatic setup:

• Production workload identities should only do PUT (turn off read too if it isn’t required).
• Strip delete permission from regular roles.
• The “break-glass” role lives in a separate account or identity and stays under audit.

The minimum bar: even if an attacker compromises a production identity, objects under retention must not be deletable.

3) Writing a backup and verifying retention

Upload an object and inspect its retention:

echo "probe" > probe.txt
aws s3 cp probe.txt s3://corp-backup-worm/probes/probe.txt
aws s3api head-object --bucket corp-backup-worm --key probes/probe.txt

Deletion test (expected: blocked):

aws s3 rm s3://corp-backup-worm/probes/probe.txt

If the deletion goes through, Object Lock either isn’t active or your IAM is bypassing it.

4) Retention duration: balancing operational reality with regulation

Two axes determine the retention day count:

• Recovery window: how far back must the “worst day” be recoverable?
• Cost and data volume: longer retention drives cost up.

In practice I tend to favor:

• Operational WORM: 14–30 days
• Archive / compliance: longer, but on a separate tier (different bucket / account)

5) Alarms and audit

The WORM layer should not stay “silent”:

• Audit alarm for any Object Lock config change
• Alarm on deletion attempts (AccessDenied)
• Alarm on retention-bypass attempts
• Change-control over bucket policy / IAM policy edits

6) Incident runbook: when ransomware is suspected

1. Lock down production identities and CI/CD tokens
2. Check the WORM bucket for delete attempts
3. Choose a recovery target: “last clean snapshot” → “last clean object version”
4. Validate restore in an isolated separate environment
5. Re-validate the IAM model before going back to production (do not return with the same weakness)

Closing

Object Lock alone is not the full answer to your backup strategy; what it does is dramatically raise the bar for the “the backups got wiped too” scenario. The real value of WORM emerges only alongside a sound IAM model, audit alarms, and an incident flow that has actually been rehearsed.