Hi everyone,

My current focus in my day job is on data protection right now and the word that keeps coming up because of ransomware and other attacks that have occurred is “Immutability”. I am going to go deep into Immutable storage and talk about how it is done in the AWS landscape including the caveats and risks associated with turning it on.

What is Immutable Storage

“Immutable” as defined in Oxford Dictionary means “unchanging over time or unable to be changed” and in the IT landscape that means an immutable object cannot be edited, removed, overwritten, etc.

Immutable infrastructure is generally the gold standard for cloud computing as it allows machines or services to be stateless and replaceable instead of fixed and maintained (but that’s for another blog).

In Storage there is another concept you might hear a lot about. It’s called WORM (and no that’s not the worm that people can use as bait for fish or find in the garden). WORM refers to “Write Once, Read Many” and that concept is generally interchangeable with immutable. Data written can be read over and over again but not changed or modified.

Immutable Storage is a key component of the 3-2-1-1-0 Veeam Backup rule (See here: What is the 3-2-1 backup rule? (veeam.com)) and is a critical component for protecting data today as sophisticated attackers are trying to not just hit the production data but also the backups as well.

Regardless of Backup vendor (AWS Backup or a 3rd party) you should aim to ensure all copies of backup are immutable for a time to protect against ransomware.

So What does AWS Offer for Immutable Storage?

AWS Offers Immutable storage through 3 services (AWS S3, AWS Glacier and AWS Backup Vaults)

These services can be plugged into backup products and then set as storage targets for backups (AWS Backup Vault is for the AWS backup Product only but S3 and Glacier can be leveraged for 3rd party backups as well)

Types of Lock?

There are 2 modes of locks that can be applied in these cases. Each have their pros and cons. I like to compare them to maturity levels in the Australian Cyber Security Center’s Essential Eight model (which for me as an Australian is becoming talked about much more frequently with customers).

Governance Mode is generally the default option and this allows data to be locked and retained for the retention period without modification. But it also allows the lock to be removed based on IAM permissions. This is equivalent to Maturity Level 2 on the Essential model as storage/backup administrators may have permission to remove data backups and immutability settings.

Compliance Mode is a more restrictive option and this removes the ability of even an administrator or root user of an AWS account to remove an object lock or a vault lock. This would be equivalent to maturity level 3 of the Essential Eight model.

During the retention period either option provides storage that can’t be changed (unless in Governance mode a lock is removed).

What should be noted is cost is a factor. If you use compliance mode you will have the cost burden for the entirety of the immutability period, which can be a risk. An example is if you are a provider who provides a product that stores data for customers in your S3 buckets and those customers stop paying or leave your service then you are still wearing the cost.  Additionally there will also often be legal requirements to delete customer data once they leave your service and if you are using Compliance mode, you cant. Governance mode is usually optimal for this scenario.

Compliance mode data can ONLY be removed by closing the AWS account completely.

How to set it up for Amazon S3?

 If you want to enable Immutable storage for S3 Object storage you can do it when the bucket is created or afterwards. The only requirement is that bucket versioning is “enabled”. The Setting to enable in AWS S3 is Object Lock. 

To enable for an existing S3 bucket you check that versioning is enabled for the bucket

And assuming it is you can then find and edit the Object Lock setting for the bucket

Once you set enable you will see the warning (as above) that you can’t turn it off for the bucket or suspend versioning.

You can also enable default retention which turns it on for any objects in the bucket and allows the mode to be set. If you enable default retention you can choose either Governance or Compliance mode (which I will talk about further down) and you then specify the number of days to lock an object.

Generally if you are using it for backup products I would not enable default retention and instead use the Backup Vendor (ie Veeam, Veritas Netbackup, etc.) to enable Object Lock in their backups.

To Enable for S3 when you create the bucket you would expand advanced Settings (as per the image below) where you will find the object lock configuration. You can choose to enable Versioning in the settings but if you enable object lock it will do that automatically for you.

How to use it in Amazon S3 Glacier

There is significant differences with how it works in AWS S3 compared with how it works for S3 Glacier or even AWS Backup. Both the latter services use policies to define immutability which can make it easier if you understand the details of how a policy works (which I am going to explain now).

In AWS S3 Glacier immutability is controlled through a Vault Lock Policy which you can define as a json template that would define the deny period and the resources. A sample (modelled on what is in the AWS document under Vault Lock Policies – Amazon S3 Glacier) is below. This one will apply a lock to any object to prevent modification or deletion for a year. The link to AWS documentation also shows you can manage locks based on tags which would be a good approach to compliance

To apply the policy once it is defined you would access the S3 Glacier service in the AWS Management console (if you are doing it from the Browser) and paste this policy in to

And the policy once saved will change the status of the vault to locked.

How to configure for AWS Backup

The last item on the agenda is AWS Backup. This is a relatively newish feature of AWS Backup Vaults which improve immensely the availability of immutability within AWS’ own backup product. AWS Backup in fact offers 2 specific ways to make backup data immutable. The first is through a Vault lock and the second is through the concept of a “Legal Hold.”

Legal Hold’s are specific requirements that data be retained and kept with a specific chain of custody. It is often the result of a court case or some other procedure that has an indefinite requirement to retain data. Once it is turned on no one can change a file or data that is covered by legal hold. After it is no longer required and it is turned off then normal lifecycle policies resume

Once added a Legal hold can only be released by users with specific IAM permissions so it is very important to ensure that this access is tightly controlled. A good rule of thumb would be to allow only the CISO or someone at a C Level (Director) release the legal hold because they will often be ultimately responsible for any response to legal action involving the company.

Moving on from Legal hold there is the Backup Vault Locks.  In AWS Backup, Backup Vault locks are created in a similar way to that of AWS S3. You create a vault lock, define the mode and retention requirements as follows

Remember that in Compliance mode, no one can change or remove the lock or any data protected by the lock, whereas in Governance mode this can be disabled based on IAM permissions. Be wary of using compliance mode with a very long retention period as costs will be a factor

And thats pretty much it on Immutability in these scenarios.

Hopefully this was interesting and informative to someone.