Skip to content

CONCEPT Cited by 1 source

Service-enforced deletion protection

Definition

Service-enforced deletion protection is the property where a storage system prevents deletion or retention-shortening of stored artefacts by any principal — including the account root user or a compromised administrator — within a configured retention period. The protection is enforced by the service itself, not by IAM policies or per-resource permissions, which means it cannot be defeated by credential compromise.

Verbatim from the canonicalising source for the load-bearing AWS example (logically air-gapped vault):

"A logically air-gapped vault is always locked in Compliance mode. The service itself enforces retention, so recovery points can't be deleted by any principal, including the account root user or a compromised administrator, within the retention period." (Source: sources/2026-05-20-aws-cyber-resilience-on-aws-a-reference-approach-for-recovery-from-ransomware-and-destructive-events)

Why this is structurally different from IAM-based protection

Traditional IAM-based deletion protection has the form:

  • "Only role X can delete this resource."
  • "Require MFA on delete."
  • "Use deletion guards in the application."

These are all vulnerable to credential compromise: if an attacker gains the right credentials (or the root user's credentials), they can delete or modify the protection.

Service-enforced protection has the form:

  • "The service refuses to honour delete operations within the retention period — even from the root user."
  • The protection lives inside the service implementation, not in the IAM policy layer.
  • Even AWS Support cannot remove the protection (this is what Compliance mode means in S3 Object Lock and AWS Backup Vault Lock).

The two AWS primitives

The canonicalising source names two AWS primitives that provide service-enforced deletion protection:

Primitive Scope Notes
AWS Backup logically air-gapped vault Backup recovery points (S3, DynamoDB, EFS, EBS, Aurora, FSx) Always in Compliance mode; recovery points live in AWS service-owned accounts
S3 Object Lock S3 objects Compliance mode + S3 Versioning combination provides equivalent guarantee at S3 layer

The post explicitly recommends S3 Object Lock as the fallback for "S3 data outside the vault's supported resource set" — providing the same service-enforcement property at the storage layer for workloads that don't fit the vault model.

The "even root cannot delete" property

The strongest form of service-enforced protection ensures that even the AWS root user of the owning account cannot delete the protected artefact within the retention period. This is the cyber-resilience- specific guarantee: in scenarios where an adversary has obtained account credentials including root, they still cannot destroy the backups.

This is the property that makes the clean-room recovery account load-bearing for ransomware recovery — without service-enforced deletion protection, an adversary with the recovery account's credentials could still delete the backups it stores.

Logical air-gap vs network air-gap

The post is explicit about the "logical" qualifier:

  • Network air-gap (traditional) — the backup system is physically disconnected from the production network; recovery requires physical access. Provides strong isolation but is operationally expensive and slow.
  • Logical air-gap (this primitive) — the backup is in AWS service-owned accounts, accessible only via vault API operations governed by service-enforced policy. Provides equivalent attacker-isolation through the service boundary.

Verbatim:

"You can choose to encrypt these recovery points with either a service-owned key or an AWS Key Management Service (AWS KMS) customer managed key. The vault object in your Recovery Account is the governance and access boundary where sharing, restore authorization, and Multi-party approval are configured. This separation is what makes the air-gap logical rather than network- based."

The protection is a floor, not a guarantee of safety

Service-enforced deletion protection ensures the recovery point will be available when needed — but doesn't say anything about whether it's safe to use. A backup taken during an attack window might be preserved by Compliance mode but still contain malware or encrypted data. This is why service-enforced protection composes with the validation pipeline — protection ensures the candidate exists; validation ensures the candidate is clean.

The canonicalising source flags this distinction:

"Deletion protection keeps the recovery point available when needed. Whether the recovery point is safe to use is determined by the validation pipeline described in the following section."

Generalisation beyond AWS

Service-enforced deletion protection appears across cloud and on-prem systems:

  • GCP Object Lock on Cloud Storage — Compliance mode equivalent.
  • Azure Blob Storage immutable storage — time-based + legal-hold policies.
  • NetApp SnapLock Compliance — on-prem WORM storage.
  • Object-storage WORM more generally — write-once-read-many semantics enforced by the storage system, not the file system or application.

The structural property is deletion is a service-level decision, not an IAM/permission decision.

Seen in

Last updated · 542 distilled / 1,571 read