As companies put more data in S3 it becomes a larger and more lucrative target for bad actors. Cybersecurity provider SonicWall reported recorded 1,748 ransomware attempts per customer through during the first three quarters of 2021 and another report from Positive Technologies states that cybercriminals can penetrate 93 percent of company networks.
Ransomware attacks involving S3 data are often done by stealing the victim's data or encrypting it with a key known only to the attacker. In either case the data is held hostage for a payment. In most, but not all, cases the data is returned upon receipt of the payment. This is often a successful attack vector given the impact of losing targeted data can be fatal for many companies.
Companies traditionally use a layered approach to protecting their S3 data including bucket policies, IAM roles, service control policies and permission boundaries. These are all great parts of a defense but if an attacker gains access to an admin account it is still possible for them to ransom your S3 data. This is where Object Lock comes in.
Object lock is a means of preventing an object version from being deleted. The word version is important there. Object Lock is only available on versioned objects and does not prevent the creation of new versions. It can, however, guarantee that a specific version will not be modified or deleted.
An aside about S3 versioning. Objects in S3 are immutable. Strictly speaking, there is no such thing as “updating” an object. If you perform a PUT on a non-versioned object a new object is created with the same key and the previous object is deleted. It “looks” like an update, but it is actually a replace. So far, this is all consistent with HTTP semantics. The difference with versioned objects is that if you perform a PUT, the previous object gets a version tag and the newly PUT object becomes the current version.
Most operations act on the current version, though you can specify a version ID to a GET or DELETE operation. An object version that has been Object-Locked cannot be deleted (though other versions of that object can be).
Object Locks exist for either a specific time period called the “retention period” or indefinitely via a “legal hold”. During an object’s retention period, or when there is a legal hold enabled, the object cannot be deleted. A retention period can be extended as needed, and a legal hold can be disabled. So, what’s to prevent an attacker from removing a legal hold or shortening the retention period?
In governance mode a user with the s3:BypassGovernanceRetention permission can shorten a retention period thus effectively removing the lock. Similarly, a user with the s3:PutObjectLegalHold permission can remove the legal hold. However, and this critical, in compliance mode no one can shorten the retention period. If you set an Object-Locked object into in compliance mode with a five-year retention period then that object will absolutely live for five years. Not even AWS can break that lock. This has led to at least one case of a company setting a ten-year lock on petabytes of data only to find that they didn’t need the data but were going to be paying to store it for ten years. Note that compliance mode does not prevent the removal of a legal hold.
| | Governance Mode | Compliance Mode || Change Legal hold | Requires special permission | Requires special permission || Extend retention period | Requires special permission | Requires special permission || Shorten retention period | Requires special permission | No one, including AWS can shorten the retention period |
Object Lock has some similarities to Vault Lock but their respective use cases are very different. Vault Lock is designed to protect a Glacier vault from modification. Objects are placed in a Glacier vault with the assumption that there is very little likelihood they will be accessed. In fact, given the petabyte scale of many workloads (especially genomic or machine learning workloads), retrieval from a vault would be cost prohibitive. Vaults are used to store one-day-its-possible-we-might-need it objects.
Object Lock however is used to protect data that may be subject to active usage. Consider the case of drug trial data. Such data is heavily used initially and then generally not used again. However, the FDA can require trial calculations to be re-run using the original data. If that data is no longer available a drug’s approval could be canceled.
First, note that Object Lock only works on buckets that have versioning enabled. Also, you can only enable Object Lock for a bucket when you first create it. (Not withstanding that last comment AWS will turn on Object Lock for an existing bucket if requested).
Object Lock operates on a per object basis which leads to the question: How do you lock a large number of objects? Here are two options for operating on a large number of objects: lifecycle rules and S3 Batch Operations. Lifecycle rules allow a limited set of objects to be performed on all objects in a bucket or those objects that match a filter pattern. These operations are concerned with versions and storage class. There is no option to set locking.
S3 Batch is designed to perform a set of actions on a list of objects. You create a job, give it an action to perform and a list of objects to perform the action upon. The list of objects is contained in a manifest which is a CSV file created either by hand or via S3 Inventory. As can be seen in the list below, S3 Batch supports Object Lock operations.
Creating the manifest for a batch operation can be as simple or complex as you need it to be. S3 Inventory can list all objects in a bucket or filter by prefix. You can specify which fields to report on for each object.
Obviously using S3 Inventory for Object Lock management will be easier if you are controlling all objects in a bucket or if you have a predefined naming scheme that will allow for filtering by prefix. If you'd like to lock a large set of files that don’t meet one of those criteria you may need to create the CSV file manually. In either case, you'd typically set up a manifest to set or extend the retention period of the selected objects.
Before using Object Lock you should understand the usage patterns for your objects. If your objects are short-lived, undergo frequent updates or are not mission critical then Object Lock might not be appropriate. Some companies have seen so much growth in their use of S3 objects that they may not be fully aware of all the ways their objects are being used.
One approach that can be useful when dealing with unknown usage patterns is to start by setting short retention periods and using governance mode on a select group of objects. If there are applications that run into failures under this regime then an administrator can remove the lock or shorten the retention period until the application’s behavior is understood. While governance mode provides less protection than compliance mode it combines a quite high level of protection along with the ability to be modified quickly.
After running in governance mode for a trial period one can switch to compliance mode, initially with relatively short retention periods before moving to a longer period.
Object Lock is not for all objects, but for your most critical data it can provide strong protection to help your CISO get a good night’s sleep. It's worth considering especially if you are storing data that is classified as PHI, PII or is otherwise senstive to your business or your customer's privacy.
Sym provides intelligent guardrails for access to sensitive cloud infrastructure, data and apps. Sym can help prevent security breaches, including ransomware attacks, without slowing your team down. It's quick, easy and free to try us out.
