HackBlue

Tools · Cloud security · 09 / 24

Protect S3 data from deletion and ransomware: versioning, Object Lock, and KMS

Turn on versioning, use Object Lock for immutable backups, pick SSE-S3 or SSE-KMS, and add MFA delete or a deny policy for deletions.

10 min read · practice only with authorization

The threat is deletion, not only exposure

Attackers with stolen credentials increasingly delete or encrypt cloud data and demand payment, or simply delete backups before attacking elsewhere. Encryption at rest does not help against someone with valid credentials. What helps is keeping old versions and making some data impossible to delete for a period.

S3 encrypts new objects by default with SSE-S3 since January 2023. SSE-KMS adds key policies and CloudTrail records of key use, which lets you limit who can decrypt.

The controls

Versioning keeps every version of an object; a delete adds a delete marker and older versions remain. Lifecycle rules expire noncurrent versions after a set time to control cost. Object Lock, which requires versioning, stores objects in a write-once-read-many mode for a retention period: governance mode can be overridden by specially permitted users, while compliance mode cannot be shortened by anyone, including root.

MFA delete requires the root user’s MFA to permanently delete versions or change versioning, and is useful for a small number of critical buckets.

Lab: a ransomware-resistant backup bucket

Create a new bucket with Object Lock enabled, set a default retention of 30 days in governance mode, upload a file, and try to delete that version. The delete is refused. Upload a new version and see both versions listed. Add a lifecycle rule that expires noncurrent versions after 90 days.

Use governance mode in the lab so you can clean up. For real backups, consider compliance mode with a retention that matches your recovery needs.

Snippet
aws s3api create-bucket --bucket hb-lab-backups --object-lock-enabled-for-bucket
aws s3api put-object-lock-configuration --bucket hb-lab-backups \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"GOVERNANCE","Days":30}}}'
aws s3api put-object --bucket hb-lab-backups --key db.dump --body db.dump
aws s3api list-object-versions --bucket hb-lab-backups --prefix db.dump
aws s3api delete-object --bucket hb-lab-backups --key db.dump --version-id <id>   # AccessDenied

SSE-KMS key policies

With SSE-KMS and a customer managed key, the key policy decides who can decrypt. A backup role can encrypt and write, while only a restore role can decrypt. Every decrypt is a CloudTrail event, which makes unusual bulk reads visible.

Enable S3 Bucket Keys to reduce KMS request costs on busy buckets.

Diagram

S3 protections and what they stop

Layer them for important data.

  • Versioning

    Accidental overwrite and simple deletes.

  • Object Lock (governance)

    Deletion except by specially permitted users.

  • Object Lock (compliance)

    Deletion by anyone, including root, for the retention period.

  • SSE-KMS key policy

    Reading by principals without decrypt rights.

Check yourself

1. What happens when you delete an object in a versioned bucket without a version ID?

2. Which Object Lock mode cannot be shortened even by the root user?

3. What does SSE-KMS add over SSE-S3?