With the latest release of Rubrik we announced integration into an AWS feature called S3 Object Lock – thus, I’ve been somewhat diving into the tech over the past couple months. S3 Object lock is essentially a feature within Amazon S3 that allows you store your objects using a write once, read many (WORM) model. What this basically means is, with S3 Object Lock enabled, once you write an object into your bucket, it can’t be changed or deleted for the amount of time, or retention, that you specify. This integration is huge for Rubrik – We’ve always provided immutability for backups ingested into our core platform, however many customers take advantage of AWS S3 in order to store or archive older backups to meet their long term retention needs – with this integration, we are now able to ensure that WORM not only applies to data on-premises, but to that which is archived into the cloud as well! With that, let’s take a closer look at Amazon S3 Object Lock itself…
S3 Object Lock – Governance or Compliance?
S3 Object Lock can be deployed in one of two modes; Governance Mode or Compliance Mode, and there is a big difference between the two. First up, Governance Mode protects objects for a specified amount of retention – but it really only protects it from being modified or deleted by most users. When Governance Mode is utilized, it is still possible to grant specific users with the s3:BypassGovernanceRetention permission, which will essentially allow them to either override or flat out remove the retention settings.
Compliance Mode, as you may have already guessed, means that no users, not even your root user within your AWS account will be able to delete or modify the objects which have been locked during the specified retention period. Therefore, be very careful when you specify the retention period as you will be paying for the data stored until that time has expired. The only way, which I am aware to delete objects protected within S3 Object Lock in compliance mode is to delete the entire AWS account – not an ideal situation
So which should you use? Well, Rubrik utilizes Compliance Mode, as we are wanting to guarantee that the archived data cannot be changed during the retention period. Organizations which have strict compliance requirements to store data may want to explore this as well. Anyone looking to simply test out the feature, or those organizations that don’t have to adhere to strict regulations may want to explore the use of governance mode.
Specifying Retention
As I mentioned earlier you should be very careful and ensure that your retention period is well thought out before you set it, as it can’t be changed after the fact when using Compliance Mode. Retention is specified when enabling Object Lock, and can be set to a number of days or years – you must set a retention, at a minimum of 1 day.
Legal Hold, another type of retention is also available within S3 Object Lock. Legal Hold essentially provides the same protection, the same WORM based model, however it has no expiration date at all. IE: You want to hold this data indefinitely as you may need it for legal reasons, thus the name. Legal Hold will ensure the data remains locked until you explicitly remove it, at which point, you can do what you like with it. Just as with governance mode, a user with explicit permissions will need to be utilized in order to remove the legal hold.
Now something to keep in mind is that retention can be placed on the bucket as a whole as well as on individual objects. If an object is placed into an S3 Object Locked bucket with no retention, it will inherit the default bucket retention, whereas if you specify a retention (Retain Until Date) on the object during upload, it will override the default set retention. If enforcing the default retention is something you wish for, you can simply deny users the ability to configure object retention settings.
Object Lock is applied at the version level
This one is important, as when I was first exploring the feature it kind of threw me for a loop. The retention settings are applied to an objects version, not the object itself. Let’s go through a scenario to explain this.
- You upload an object to a bucket with a default retention of 30 days – the object is now locked for 30 days. Let’s call it ObjV1
- You then change the default retention period to 60 days. At this point, any new objects uploaded (without a retain till date) will inherit the 60 days retention. The existing object, ObjV1 maintains it’s 30 day retention.
- After 20 days, you upload the same object again. Here, I expected this to fail as it would be overwriting the original, however, instead, a new version of the object is created (ObjV2), and assigned our new default retention of 60 days.
- In another 20 days you upload the same object again (ObjV3), specifying a Retain Till Date of 90 days in the future – at this point, we now have
- ObjV1 – Currently not locked at all as it’s retention as been reached
- ObjV2 – Currently locked for another 40 days
- ObjV3 – Currently locked for 90 days.
So the gist of this is, uploads and puts and modifications will succeed on the objects as it simply just creates new object versions or delete markers. If you attempted to specifically delete or modify a locked object at the version level, it will fail!
So to wrap up
Amazon S3 Object Lock is a great way to ensure that your data remains consistent with the time you placed it within your buckets. Other than your normal S3 capacity charges, there is no additional cost associated with S3 Object Lock – With the threat of ransomware on the rise, and tons of bad actors looking to exfiltrate your data, S3 Object Lock seems like a no brainer in today’s crazy world. In the case of Rubrik, S3 Object Lock allows us to extend our Zero Trust Data Security Platform into AWS, ensuring that all of your data, whether it be on-premises or archived off to AWS will be available at the time you need it most. If you want to learn more about Rubrik’s integration with S3 Object Lock, check out this webinar I did with Peter Imming from AWS and Kev Johnson from Rubrik!
