Recently introduced by Amazon S3, Object Lock stores objects using a write-once-read-many (WORM) model. Cloudian’s HyperStore v7.2 fully supports Object Lock, including all relevant S3 APIs and access control with permissions and bucket and IAM policies. Application users can now use Amazon SDKs with HyperStore software or appliances deployed in their on-premises infrastructure to protect data against ransomware threats and meet compliance requirements.
Specifically, Object Lock prevents object version deletion during a user-defined retention period. Immutable S3 objects are protected using object- or bucket-level configuration of WORM and retention attributes. The retention policy is defined using the S3 API or bucket-level defaults. Objects are locked for the duration of the retention period, and legal hold scenarios are also supported. This functionality provides both data protection—including extra protection against accidental or malicious deletion as well as ransomware—and regulatory compliance (SEC Rule 17a-4(f), FINRA Rule 4511, CFTC Regulation 1.31, as validated in the independent compliance assessment found here).
This is part of an extensive series of guides about ransomware data recovery.
DOWNLOAD THE RANSOMWARE PROTECTION BUYER’S GUIDE
Object Lock has two protection modes.
-
- Compliance. This is the stricter mode, intended for regulatory compliance. Deletes of WORM-protected objects are disallowed even for the root account. Once in Compliance mode, retention configuration cannot be relaxed; in particular, the retention time period cannot be decreased and the mode cannot be changed.
- Governance. This is primarily intended for data protection against security vulnerabilities such as unintended deletion, compromised credentials, or rogue actors, including those conduct ransomware attacks. A type of “privileged” delete can be defined to permit the deletion of WORM-protected objects. The retention configuration can be changed in prescribed ways including elevating the protection mode to Compliance.
The retention period for the Object Lock is specified in two independent, overlapping ways: (1) A “retain-until-date” specifying the time/date until the object is protected and (2) An ON/OFF “legal hold” setting. The below diagram is an example where both a retain-until-date and legal hold are used for the same object. While the object is protected by either the retain-until-date or the legal hold, it cannot be deleted.
Image source: https://www.slideshare.net/AmazonWebServices/best-practices-for-amazon-s3-and-amazon-glacier-stg203r2-aws-reinvent-2018
The workflow for using Object Lock has the following steps:
- Create a bucket with Object Lock enabled.
- Set bucket default retention settings. (optional)
- For an individual object, set retention settings (optional).
Creating a bucket. Object Lock cannot be enabled on pre-existing buckets. Using the x-amz-object-lock-enabled: True in the create bucket operation is the only way to enable Object Lock for the bucket, and it cannot be altered later—it is a permanent choice. Another important note is that this step will automatically enable versioning for the bucket and not allow suspending versioning later.
Bucket default retention settings. Optionally, default retention settings can be assigned to a bucket using the new PUT Bucket Object Lock configuration API. Then all subsequent objects written to the bucket will inherit the retention settings. This API is only allowed if Object Lock has been enabled when the bucket was created. The below example sets testbucket3’s default retention settings to GOVERNANCE mode and 30 days after object creation.
The bucket default settings can be changed multiple times, but the retention settings of previously created objects are not changed. If an object is created with individual object retention settings, then those take precedence over the bucket default settings.
Individual object retention settings. An object’s retention settings can be set when the object is created (e.g., by a PUT Object) or after the object has been created. All of the object creation APIs include the optional Object Lock parameters (x-amz-object-lock-mode, x-amz-object-lock-retain-until-date, and x-amz-object-lock-legal-hold) including PUT Object, PUT Object Copy, POST Object, and Multi-Part Upload Initiate/Complete. If the object is already created, then the new PUT Object retention and PUT Object legal hold APIs are used. The below example sets legal hold ON for a specific object key and version-id.
Access control using bucket policies or IAM policies is an important part of the Object Lock functionality. New permissions have been defined for Object Lock. The s3:BypassGovernanceRetention permission is important since it is required to delete a WORM-protected object in Governance mode (it is not effective for Compliance mode). New bucket/IAM policy conditions have also been defined. For example, the s3:object-lock-retain-until-date condition can limit the allowed retention dates on an object. The below policy example allows a PUT Object retention only if the lock-mode is GOVERNANCE, and the retain-until-date value is less than “2021-01-01T00:00:00Z”.
The new Object Lock functionality plays an important role in multiple use cases. One example is combatting ransomware through the ability to restore an uninfected copy protected through Object Lock. Another example is e-discovery where a legal hold can be easily enforced by setting legal-hold ON for the affected data. A third example is a simple way to protect against inadvertent data deletions. By setting a retention mode on a bucket, an extra set of auditable steps to confirm permissions to delete data is then required. The power of a standard S3 and IAM APIs is evident as other software such as data protection systems can reliably use the Object Lock APIs to enforce enhanced data protection policies. Cloudian HyperStore’s fully compatible S3 Object Lock is available and ready to use today!
Learn more about ransomware protection in our detailed guide to ransomware backup and view recent attacks in the ransomware list.