Secure Objects in an S3 Bucket

Learn how to secure objects in S3 buckets against deletion for compliance and governance purposes.

S3 offers multiple ways to secure objects in the bucket by either restricting objects in the bucket or applying a standardized security pattern on all of the objects. Let’s dive to learn multiple ways we can protect objects stored in our bucket.

S3 Object Locks

S3 Object Locks prevent overwriting or deletion of an object. It is based on the WORM (write-one-read-many) model. Object Locks only work on versioning-enabled S3 buckets. We can lock a specific object version, which associates the lock information with the metadata of the version.

Object Lock provides two ways to manage the retention: retention period and legal holds.

Retention period

We lock the object for a specified amount of time. We can set up a unique or default object retention period on a bucket. Furthermore, we can set up maximum and minimum allowed retention periods using the s3:object-lock-remaining-retention-days condition key in the bucket policy. This ensures that users can only specify retention periods that fall within a predefined range, enforcing data retention policies and preventing users from setting overly restrictive or insufficient retention periods.

This mode offers two ways to lock an object:

  • Compliance: When an object is locked in compliance mode, it can not be overwritten or deleted even the root user. Also, we can not shorten the retention period or modify the retention mode.

  • Governance: When an object is locked in governance mode, it can only be overwritten or modified by users with special permissions.

Tip: Testing out Object Locks in governance mode is a good practice before locking objects in compliance mode.

Legal hold

We lock the object for an indefinite amount of time. It remains in action until we explicitly remove it. Legal holds are independent of retention periods. For example, consider an object with a retention period and legal hold. If the retention period expires before removing the legal hold, the object will remain protected. Similarly, if the legal hold is removed before the retention period expires, the object can not be overwritten or deleted.

Press + to interact
S3 Object Locks
S3 Object Locks

Important: A locked version of an object can not be deleted by S3 life cycle policies. It maintains the object lock irrespective of the storage class.

S3 Glacier Vault Lock

A vault is defined as a container for archiving objects. S3 Glacier supports vault operations specific to an AWS region. A vault can only be deleted if there are no objects in it.

S3 Vaults allow us to apply S3 Vault Locks to control vault access. Vault Locks are defined in the IAM policy document to enforce compliance controls. However, they are different from the vault access policy.The resource based policy attached to the S3 Glacier Vault. Vault Lock policies can be locked to prevent any changes in the future. They are commonly used for compliance purposes and are not subjected to frequent changes. On the other hand, vault access policies are subjected to frequent modifications to grant temporary access to certain users.

Press + to interact
Vault access policy vs. S3 Glacier Vault Lock
Vault access policy vs. S3 Glacier Vault Lock

S3 objects encryption

Data stored in S3 buckets needs to be protected at rest while stored in disks and in transit. To protect data when it is being transmitted to and from S3 buckets, we can use Secure Socket Layer/Transport Layer Security (SSL/TLS) or client-side encryption. In the context of Amazon S3, it’s important to note that SSL/TLS is primarily utilized for securing data in transit rather than for securing data stored within Amazon S3 buckets.

S3 offers the following two main options to protect data:

Server-side encryption

By default, S3 encrypts data before storing them on disks using S3 managed keys (SSE-S3). These objects are automatically encrypted at no additional cost and performance latency.

We can also specify a different type of encryption using:

  • Server-side encryption with AWS Key Management Service (AWS KMS) keys (SSE-KMS)

  • Dual-layer server-side encryption with AWS KMS keys (DSSE-KMS)

  • Server-side encryption with customer-provided keys (SSE-C)

We can specify the type of encryption with the PUT request.

Client-side encryption

We can use client-side encryption to ensure that the data is secure at rest on the client side and when transmitted from the client to the S3 bucket. In this type of encryption, the S3 bucket receives the encrypted data and can not decrypt it. Also, it can not detect if the data is encrypted and treats it as regular objects.

S3 offers a client-side encryption library called Amazon S3 Encryption Client. It’s designed to seamlessly integrate with AWS services, enabling developers to easily encrypt data on the client side before uploading it to the S3 bucket.

Press + to interact
Client-side encrytion vs server-side encryption
Client-side encrytion vs server-side encryption

Get hands-on with 1300+ tech skills courses.