October 17, 2022 Margus Danil BackupTechnologyUpdates

cloud backupfeaturesimmutabilityimmutable bucketobject locks3 bucket

Latest Feature Spotlight: Immutability

S3 Immutability

Data is business critical for all organisations. That is also the primary reason why cybercriminals target companies – they try to gain access to it. To mitigate this risk, data should be backed up regularly as a default part of a company’s data retention requirement. But these days even having solid data retention rules is not enough anymore, as criminals are now targeting backups of repositories as well and will modify or erase them. So how can we protect our data and make sure it is intact for its entire retention period? There is a way – immutable backup is the solution to avoid these scenarios.

Immutability as a feature for S3 buckets for better data retention

Immutability is a S3 storage system feature that has the capability to prevent unauthorised change and deletion of the data in S3 buckets. When immutability is enabled for a repository in your bucket you ensure that the most recent copy of your data is safe, recoverable and available for you at any time. Immutability locks the files in your storage bucket by providing it protection from accidental deletion or malware infection even if root user or admin is compromised.

You can also set immutability to be used for a specific retention period. For example, if it is set for 30 days, then you cannot delete or modify files during that period..

Scenarios where data retention should include immutability

You might think that your data is safe when you have an extra copy of it stored on your external hard drive or in free or low cost cloud storage like Google Drive or Dropbox. But it is actually not in case of ransomware.

Quite often companies are protecting themselves against ransomware by buying expensive defense systems. However, in most cases it would be best to prepare for the worst case scenario when all other defense systems have failed. When you have immutable backups of your data in place you can avoid paying the hefty ransom.

How object lock works

You might even be doing everything by the book, but the truth is that many data backup best practices are not resistant to ransomware attacks. For example, if your data is being replicated to a remote location, it does not provide you with protection against ransomware, because the data backup process overwrites clean data with infected data. Even if you have different versions of data, it is difficult to pinpoint exactly during what period of time and when your data was infected.

A good old 3-2-1 backup retention system should be interpreted in a way that there are three copies of data, two copies are on local, but on different storage mediums and one copy is an immutable storage backup on the cloud.

Although ransomware is the most associated threat when considering the need for immutability, there are also other, more probable threats to protect your data from. For example, it can protect your data from human error aka the case of a user accidentally deleting or overwriting your storage repository. Or even when done on purpose by your colleague because of malicious intent or any other unknown reasons. In both cases, when you have an immutable copy of your data, all of your files and other data can be easily restored.

Object lock and servers

Conclusion

In case of ransomware or accidental deletion it is necessary to have backup of your data that cannot be modified, overwritten or deleted. Immutable backup copies as a necessary part of a company’s data retention management policy ensures that you always have your recent data (files, databases, server snapshots etc) safe and protected for your retrieval at any time. In case of a cyber attack, you are able to restore your operations easily after cleaning up your repositories from infected data. 

Read about why another useful feature called versioning is important here.

Read about the differences of archiving and backing up here.

Leave a Reply

Your email address will not be published. Required fields are marked *

Comment *