S3 Object Lock: the copy that cannot be deleted – WORM, rete

WebDisk Blog · category: Security · reading time: ~12 minutes

In short:- S3 Object Lock turns object storage into WORM (write once, read many): a file that has been written can be read, but for a defined period no S3 request – including one from an administrator or the account owner – will change it or delete it.- Today this is the basic defence of backups against ransomware, which routinely deletes backups before it encrypts production.- In WebDisk Files this mechanism is called Anty-Ransomware: you turn it on with a switch on a storage space and you have WORM-class storage for backups. >Not working with a terminal? Skip the code examples – the description of the mechanism and the WebDisk section give you the full picture.

A modern ransomware attack rarely starts with encryption. An attacker who has gained access to the infrastructure first spends days or weeks inside it – and during that time methodically looks for backups. They delete them, encrypt them or quietly corrupt them. Only when the victim has nothing to go back to does the attacker launch the actual encryption and issue the ransom demand. The logic is brutally simple: a company that has a working backup will not pay.

The conclusion from thousands of such incidents is this: a backup that can be deleted with the same permissions that were used to write it is not protection – it is the illusion of protection. What you need is a copy that will not be erased by an attacker with stolen keys, nor by an errant script, nor – hardest of all to accept – by ourselves on a bad day. In the S3 world, that is exactly what Object Lock does. In this article we explain how it works, show usage examples and describe how we built the Anty-Ransomware feature on top of it in WebDisk Files.

WORM: an idea older than the cloud

WORM (write once, read many) is a concept that has been known for decades. The most familiar example is a CD-R: once burned, the content can be read as many times as you like, but it cannot be overwritten or erased – the physics of the medium simply does not allow it. Banks and archives have used WORM media and arrays for years wherever the law requires a record to remain untouched: transaction ledgers, medical records, correspondence subject to regulatory oversight.

S3 Object Lock brings that guarantee to object storage – with no special hardware. The lock is enforced by the storage layer itself: a request to delete or overwrite a protected object version is rejected, no matter who sent it and with what permissions. That is the crucial difference from ordinary permissions (IAM policies): a policy can be changed by anyone with sufficient access – a WORM lock in Compliance mode will not be lifted by any S3 request.

The foundation: versioning

Object Lock does not work in a vacuum – it requires bucket versioning (a bucket – a container for files in S3 storage, the equivalent of a disk or a share; in WebDisk services we call it a storage space). Versioning means the storage never overwrites anything in place: every write under an existing name creates a new version of the object, and the previous ones remain. "Deleting" a file in a versioned bucket does not erase data either – it only adds a delete marker, and the older versions underneath it can be retrieved at any time.

Only on this foundation does the lock make sense, because Object Lock protects specific object versions. A practical consequence worth understanding: writing new content under the same name is not blocked – it simply creates another version. The protected version sits untouched alongside it. Visually:

file "report.pdf" in a bucket with Object Lock:

  [delete marker] ← the file "disappeared" from the listing…
  v2 ransomware write ← …the "overwriting" junk landed NEXT TO it, not instead of it
  v1 🔒 Compliance until Nov 1 ← the original: untouchable, ready to restore

So ransomware can "overwrite" your files with encrypted junk and "delete" them from the listing, but the original, locked versions will survive – and you will be able to go back to them.

Two modes and two locking mechanisms

A version can be locked in two ways and in two modes – and these distinctions are the most important technical part of this article.

Retention – a time-limited lock: a version has a retain-until-date before which it cannot be deleted or changed. The date can be set explicitly when the object is written, or configured as a bucket default retention (e.g. "every new object: 90 days") – protection then covers everything automatically, with no involvement required from the tool doing the writing.

Retention modes:

Governance – a lock with a back door: ordinary users cannot do anything, but designated users with a special permission (s3:BypassGovernanceRetention) can shorten or remove the lock. Good for tidying up processes and for a trial period: it protects against a mistake, it does not protect against an attacker who takes over a privileged account.
Compliance – a lock with no back door at the S3 layer: until the version's retention date expires, no S3 request will delete it – regardless of whether it is sent by the account owner, the organization's administrator or an attacker with a compromised privileged account. The period can only be extended, never shortened. This is the right mode for ransomware protection and for legal requirements. (Beyond the S3 layer, every provider is left with at most a strictly controlled, audited operator procedure – we describe ours honestly in the FAQ.)
Legal hold – an open-ended lock, independent of retention: a "hold everything until further notice" switch on a single version. It has no end date; it is lifted by a deliberate decision of someone with the appropriate permission. Used when litigation or an investigation is under way and the data must not be touched until the case is closed.
Duration – Governance: until the retention date · Compliance: until the retention date · Legal hold: until revoked
Can it be shortened/lifted? – Governance: yes, with a special permission · Compliance: no – not by any S3 request · Legal hold: yes, with the legal hold permission
Can it be extended? – Governance: yes · Compliance: yes (extension only) · Legal hold: not applicable
Typical use – Governance: internal processes, testing · Compliance: ransomware, legal requirements · Legal hold: litigation, investigations

Do it yourself: WORM in the terminal

Before you start. The examples use the aws CLI configured as in the previous articles in this series (aws configure + --endpoint-url of your provider – we omit it below for readability). Be careful with real data: Compliance locks cannot be undone – which is why all the exercises below use a retention of 1 day and a test bucket; production values are shown in the comments.

Object Lock is enabled when the bucket is created (on retrofitting an existing one – see the FAQ):

# 1. bucket with Object Lock enabled (versioning is enabled automatically)
aws s3api create-bucket --bucket backup-worm \
  --object-lock-enabled-for-bucket

# 2. default Compliance retention – CAUTION: the effects of this step are irreversible,
# every new object will be untouchable for the configured period
aws s3api put-object-lock-configuration --bucket backup-worm \
  --object-lock-configuration \
  '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":1}}}'
# for the exercises: 1 day · in production for backups: {"Mode":"COMPLIANCE","Days":90}

# 3. an ordinary upload – the protection applies itself, the backup tool
# does not need to know anything about Object Lock
aws s3 cp backup-2026-08-02.tar.gz s3://backup-worm/

From that moment on, every version written is untouchable for the configured period. Let's check:

# version metadata: lock mode and the date until which it applies
aws s3api head-object --bucket backup-worm --key backup-2026-08-02.tar.gz
# "ObjectLockMode": "COMPLIANCE",
# "ObjectLockRetainUntilDate": "...",

# an attempt to permanently delete the protected version
aws s3api delete-object --bucket backup-worm \
--key backup-2026-08-02.tar.gz --version-id "<version-id>"
# → AccessDenied – and that is exactly the point

And what about a plain aws s3 rm, without pointing at a version? It will "succeed" – and that is not a hole in the protection:

aws s3 rm s3://backup-worm/backup-2026-08-02.tar.gz
# success – but this is only a delete marker from the versioning section!

aws s3api list-object-versions --bucket backup-worm
# the protected version still exists beneath the marker – the data is untouched

The file has disappeared from the listing, but not from the storage; restoring it means removing the marker or downloading the version by its identifier.

Protection for a single version can also be set explicitly at write time (a date set this way takes precedence over the bucket's default retention) or later – bearing in mind that in Compliance mode it is a one-way street:

# explicit lock at write time (for the exercises: a date one day ahead;
# in production e.g. a year: 2027-08-02)
aws s3api put-object --bucket backup-worm --key annual-report.pdf \
  --body annual-report.pdf \
  --object-lock-mode COMPLIANCE \
  --object-lock-retain-until-date "2026-08-03T00:00:00Z"

# extending the protection of an existing version (shortening → denied)
aws s3api put-object-retention --bucket backup-worm --key annual-report.pdf \
  --version-id "<version-id>" \
  --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2026-08-04T00:00:00Z"}'

# legal hold: hold until revoked (regardless of retention dates)
aws s3api put-object-legal-hold --bucket backup-worm --key annual-report.pdf \
  --legal-hold '{"Status":"ON"}'

Retention is not only locking – it is also cleaning up

A retention policy has two sides. The first says: "it must not be deleted before the deadline". The second – equally important – says: "after the deadline, delete it automatically". The second one is carried out by the storage's lifecycle rules. Paired with Object Lock, this gives you self-cleaning WORM storage: copies are untouchable for the protection period, and once it expires they disappear on their own – no scripts, no cron, no manual review. A lifecycle rule will respect an active lock: a protected version will not be removed before its retention date.

To close the example from the previous section – version cleanup matched to a 90-day production retention:

aws s3api put-bucket-lifecycle-configuration --bucket backup-worm \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "cleanup-after-protection",
      "Status": "Enabled",
      "Filter": {},
      "Expiration": { "Days": 90 },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 90 }
    }]
  }'

Well-chosen retention is always a compromise: too short will not defend against an attacker who waits patiently (the break-in often happens long before the encryption); too long multiplies storage costs and may collide with data erasure obligations (more on that in the FAQ). For backups, a reasonable minimum of immutable protection is around 90 days – plus longer, less frequent archival copies.

An honest reckoning: what Object Lock will not solve

Compliance means Compliance. A mistake cuts both ways: if you lock 10 TB of junk for 7 years, you will store (and pay for) it for 7 years. There is no "delete just this once" button – exceptions to immutability are limited to the strictly regulated situations described in the terms of service. Retention is set deliberately, and testing is done with short periods.
Versions cost money. Storage with versioning and retention keeps everything that was written during the protection period – including the versions "overwritten" by ransomware. That is the price of the guarantee; when budgeting a WORM backup, calculate: capacity × number of copies within the retention window.
The lock protects integrity, not confidentiality. An attacker with access can still read the data and exfiltrate it. Encryption (we wrote about SSE in this series), access control and short-lived credentials (we wrote about STS) protect against that.
WORM does not replace backup principles. An immutable copy in one place is still a single copy. The 3-2-1 rule (three copies, two media, one off-site) still applies – Object Lock hardens one of its links.
New writes are not blocked. Object Lock freezes existing versions; it will not stop anyone from piling new objects into the bucket. Limits, quotas and write monitoring are a separate layer.

Anty-Ransomware in WebDisk Files

In WebDisk Files the whole mechanism described above is wrapped in a single feature with an unambiguous name: Anty-Ransomware. It works at the level of an additional storage space (bucket) and is turned on with a switch – with a protection period from 90 days to 7 years (the 90-day minimum is deliberate: break-ins precede encryption by weeks, and shorter protection can be an illusion):

Under the hood it is simply S3 Object Lock in Compliance mode: every version of every file in the storage space is unmodifiable and undeletable until the protection period expires. The guarantee is enforced by the storage layer, not by the application – it holds even if the application itself or the organization administrator's account is compromised. That is exactly the model that ransomware defence calls for.
The decision is one-way – and we say so plainly: a storage space with Anty-Ransomware enabled cannot be "unlocked", nor can the protection period of its contents be shortened. Nor can the storage space be deleted while it still protects any versions. This is not a limitation we try to work around – it is the essence of the product.
Alongside it there is auto-rotation: a retention rule that permanently deletes old objects once the configured period has passed – implemented with lifecycle policies on the storage side, with no cron on the application side. On a storage space with Anty-Ransomware the rotation period equals the protection period (files disappear exactly when the protection ends); on an ordinary storage space you choose the period yourself. Combined, this gives the self-cleaning WORM storage mentioned above.
The feature has undergone a data protection impact assessment (DPIA, GDPR art. 35) – because the immutability of data has to be reconciled with the right to erase it; the protection period is therefore chosen deliberately to match the nature of the data. We make the document available to B2B customers on request – as input to their own impact assessments.

The use case we built this for is simple: a safe WORM-class backup target. Point your backups at an Anty-Ransomware storage space – over S3 (any backup tool that writes to S3 – protection is applied by the bucket's default retention, so the tool does not need to know about Object Lock at all), through the web application or the desktop application. Every copy you write becomes untouchable automatically. We also keep backups of the key elements of our own platform in WORM storage with S3 Object Lock.

A note for users of tools with native Object Lock support (e.g. Veeam): such software manages retention per object itself and, in line with the vendor's requirements, needs a bucket with Object Lock enabled but without default retention and without lifecycle rules – the integration documentation warns that default locks on the bucket may lead to unpredictable data loss. The Anty-Ransomware storage space (with enforced Compliance retention and auto-rotation) is designed for tools that know nothing about Object Lock; for Veeam and similar tools a separately configured bucket compliant with the vendor's guidelines is needed – write to us and we will help.

The complementary layers in Files you already know from the previous articles in the series: file versioning, encryption at rest (SSE-S3 per storage space, SSE-C per organization) and access control. Object Lock closes this set from the integrity side: even if everything else fails, the copy from before the attack exists and you can restore from it.

Frequently asked questions

Can I ask WebDisk to delete a file from an Anty-Ransomware storage space before its protection expires? Not by any S3 operation, not through the panel, not "on the spot" – no. The lock is enforced by the storage layer and it will not be lifted by your organization's administrator, by an attacker with stolen keys, or by our support. Exceptions are limited to strictly regulated, audited situations provided for in the terms of service – such as fulfilling legal obligations – and they cannot be triggered quietly, remotely or with compromised S3 keys. For the ransomware scenario this means there is no back door.

I made a mistake and locked data for too long. What now? At the S3 layer – nothing; the data will remain until the retention expires. So: test new policies with short periods and a separate bucket, set default retention carefully, and reserve very long periods for data you are sure about. Governance mode exists precisely so that you can get your processes right before you switch to Compliance.

Can ransomware encrypt files in a storage space with Object Lock? At most it can add encrypted versions next to the protected ones – the originals will remain untouched and recoverable. It cannot overwrite them in place or delete them. Recovery comes down to restoring the version from before the attack.

Can Object Lock be enabled on an existing bucket? That depends on the platform and the version: AWS allows an existing bucket to be retrofitted, in Ceph RGW only the most recent releases make it possible – in this respect what matters is the version your provider runs. In Files we solve it plainly: you enable Anty-Ransomware when creating the storage space (it can also be an existing, empty storage space); for a storage space that already holds data you create a new protected one and copy the data into it.

What will happen to an Anty-Ransomware storage space when I close my account? Protection does not disappear along with the account: the storage space cannot be deleted while it still protects any versions, so removing it is planned and carried out only after the protection period expires. The billing rules for that period are in the terms of service – factor the protection period into your decision about its length.

How does WORM square with GDPR and the right to erasure? Through a deliberate choice of scope and period. WORM storage holds backups and archives, not the everyday flow of personal data; the protection period is chosen so that it balances the ransomware risk against erasure obligations. In Files the feature has undergone a DPIA (GDPR art. 35) precisely so that this balance is documented – and edge cases, such as fulfilling legal obligations, are handled in the manner provided for in the terms of service.

Governance or Compliance – where to start? If you are only just setting up your backup process: Governance while the procedures bed in (it protects against a mistake and lets you clean up), then Compliance for production copies. If the goal is defence against ransomware or a legal requirement – ultimately always Compliance; the Governance back door is exactly what a compromised privileged account can use.

Summary

Object Lock reverses the usual logic of permissions: instead of policing who may delete data, it makes sure that for a defined period no one can – not by any S3 request. Three things are worth remembering:

the foundation is versioning – the lock protects versions, so files "overwritten" by an attacker have untouched originals,
Compliance is a guarantee with no back door at the S3 layer, irrevocable even for our own support – which is why retention is chosen deliberately, and cleaning up is handled by lifecycle rules,
WORM protects integrity and recoverability; confidentiality and access are the job of encryption (SSE) and short-lived credentials (STS) from the earlier parts of the series.

In WebDisk Files you will find this as Anty-Ransomware: WORM storage for backups, launched with a single switch, with protection from 90 days to 7 years and – optionally – automatic cleanup once it expires. Try WebDisk Files or write to us if you want to talk through a ransomware-resilient backup architecture for your organization.

This article is part of a series on data security in WebDisk services – earlier pieces covered encryption at rest (SSE-S3, SSE-KMS, SSE-C) and access via STS/SSO. You can run the examples on any S3 platform that supports Object Lock; the --endpoint-url parameter in the aws CLI points to your provider's endpoint.

S3 Object Lock: the copy that cannot be deleted – WORM, retention and Anty-Ransomware