Basic protections for your S3 buckets

S3 is one of the most popular storage services in AWS due to its simplicity. You can easily store large amounts of data for multiple purposes at a relatively low cost.

Regardless of your use case, I imagine you want your precious data to be stored securely, not only because of the trouble you could face with regulators, but because it's simply the right thing to do.

Today, I am going to talk about some basic safeguards that you can implement in S3 to help secure your data with no extra cost.

Let's start with a classic one.

Encryption

Encryption is the process of taking readable information, like your secret master plan that will make you rich, and converting it into unreablable format so that only authorized parties can access it.

I won't bore you with technical details but the key point is that encryption is important.

Most encryption you will see fall into two categories: at rest, and in transit. You may also hear about encryption in use, but that one is out of scope for this article.

Encryption at rest

In simple terms, encryption at rest deals with data that sits idle, waiting in your storage to be used. You can think of encryption at rest as having a safe where you store a top secret notebook, only authorized parties, the ones that know the code, can open the safe and access your data.

There are two main encryption methods in S3:

• Server-side -> AWS encrypts the data for you before saving it on disks
• Client-side -> You encrypt the data before uploading it to S3

The good thing is that buckets have encryption at rest configured by default. That way, all the objects you upload will be using Server-side encryption with AMazon S3 managed keys (SSE-S3). ALl this will be transparent to you and free of charge.

For most use-cases, SSE-S3 will be more than enough, but if you want more control, you can opt to encrypt your data using a KMS key you control.

Encryption in transit

The other encryption category we mentioned is encryption in transit. This one is in charge of protecting the data as it moves around, like when it moves from AWS to your devices as you download it.

Encryption in transit is important to guarantee the secret of communications. If there was no encryption, anyone that intercept your network traffic could read into your emails and know what your last purchase at Amazon was.

This type of encryption is achieved using asymmetric encryption, which relies on a pair of keys, a public key and a private key, to establish a secure channel between two parties for sharing information.

Think of a mailbox that anyone can drop letters into, but only the owner can open.

The mailbox slot is like the public key: anyone can use it to send a message securely. The key that opens the mailbox is the private key: only the owner has it. Even if someone watches you drop a letter into the mailbox, they cannot read it because they do not have the key.

Asymmetric encryption works the same way. If someone were to intercept your emails, the contents would appear as gibberish because that person does not have access to the private key used to protect the communication channel.

S3 buckets allow you to access your data using either HTTP (unencrypted) or HTTPS (encrypyed) endpoints. It is highly recommended to only allow access via the latter. To enforce this, you can apply the following bucket policy:

{
    "Version":"2012-10-17",              
    "Statement": [{
        "Sid": "RestrictToTLSRequestsOnly",
        "Action": "s3:*",
        "Effect": "Deny",
        "Resource": [
            "arn:aws:s3:::<yourBucket>",
            "arn:aws:s3:::<yourBucket>/*"
        ],
        "Condition": {
            "Bool": {
                "aws:SecureTransport": "false"
            }
        },
        "Principal": "*"
    }]
}

Public/Private buckets

In AWS you have two types of buckets, public and private. As you may have already guessed by their names, public buckets can be accessed by anyone in the world whereas private ones are only accessible to authorized individuals.

Luckily for all, new buckets are private by default so you would need to go on the extra mile to make it public.

But hey, mistakes can happen.

To ensure you have a layered defense that prevents someone from simply turning a private bucket into a public one, consider enabling the Block Public Access feature.

Now, this feature can be enabled at three levels: bucket, account, and organization:

• Block Public Access (Bucket) -> This is the level you are most likely to have enabled by default when a bucket is private.
• Block Public Access (Account) -> This level blocks public access to all buckets across an account.
• Block Public Access (Organization) -> If you work at a company that have a large AWS organization, you can turn this feature on at the org level so no buckets within your org can be made public.

Least privilege

You may have already come across the principle of least privilege, but if not, let me introduce it. Least privilege is a security concept that states you should grant an entity (such as a person, application, or service account) only the minimum set of permissions required to perform a specific task, and no more.

Applying this principle helps reduce the risk of accidental misuse or malicious activity. Therefore, to ensure your data is protected in S3, you must carefully scope IAM permissions so that users and services can access only the buckets and actions they truly need.

For example, if you have a bucket that stores marketing information, only the Marketing team should have access to it.

Keep in mind that least privilege is not a one-off exercise. It requires ongoing maintenance and regular audits as responsibilities change, teams are reorganized, or access requirements evolve over time.

Versioning & MFA delete

If you want to further protect your data against malicious or accidental deleition, you can enable versioning and MFA delete on buckets.

When versioning is enabled on a bucket, S3 keeps multiple versions of an object instead of permanently replacing or removing it. This allows you to recover previous versions of a file if it is deleted or modified by mistake. FYI, this feature cannot be disabled once it's enabled on a bucket and it comes with extra cost due to the multiple versions stored!

To go one extra step further, you can enable MFA Delete. MFA Delete requires users to provide multi-factor authentication (MFA) in addition to their credentials when performing sensitive operations such as permanently deleting an object version or suspending versioning on a bucket. This adds an extra layer of security by ensuring that even if credentials are compromised, critical destructive actions cannot be performed without physical access to the MFA device.

Together, versioning and MFA Delete provide an effective safeguard against data loss, whether caused by human error or malicious activity.