Skip to content

S3 Encryption

Links: 101 AWS SAA Index

Encryption

  • You are uploading sensitive data to S3 and you wouldn’t want your data to be compromised if someone gets into the AWS server.
  • Encryption is for a specific version ID. So if the object was not encrypted and you upload an object with the same name and encryption enabled then only the latest version of the object will have encryption and not the previous ones.
  • Encryption is of type AES - 256
  • You can enable default encryption on the bucket level so all the objects uploaded to it will be encrypted.
  • For encryption in transit AWS exposes HTTP and HTTPS (using TLS/SSL) endpoint.
  • There are 4 ways of encrypting objects in S3.
  • Summary
    • attachments/Pasted image 20220423094258.jpg

SSE - S3

  • Keys are handled and managed by S3
  • Objects are encrypted on the server side.
  • To use this you must use the following header: “x-amz-server-side-encryption”:”AES256”
  • You have no control over the keys or any kind of audit trail.
Enabled by default for new buckets and new objects.

SSE - KMS

  • Keys are handled and managed by AWS KMS.

  • We can use the following keys:

    • KMS managed keys
    • KMS CMK (Customer Master Keys)
    • CMK can be customer generated

  • KMS gives us more control and an audit trail.

  • We can rotate the keys if we want.
  • Objects are encrypted on the server side.
  • To use this you must use the following header: “x-amz-server-side-encryption”:”aws:kms”
  • There's also an optional x-amz-server-side-encryption-aws-kms-key-id header which specifies the ID of the AWS KMS master encryption key that was used for the object.
    • If the header is not present in the request, Amazon S3 assumes the default KMS key.
When to go for SSE KMS over SSE S3

We should go for SSE - KMS if the company does not want to spend time managing and rotating the keys, but it does want to control who can access those keys.

If you see terms like audit trail, envelope encryption, automatic key rotation.

Metadata, which can be included with the object, is not encrypted by any encryption method while being stored on Amazon S3. Therefore, AWS recommends that customers not place sensitive information in Amazon S3 metadata.
  • SSE KMS limits:
    • If you use SSE-KMS, you may be impacted by the KMS limits
    • When you upload, it calls the GenerateDataKey KMS API
    • When you download, it calls the Decrypt KMS API
    • These count towards the KMS quota per second (5500, 10000, 30000 req/s based on region)
    • You can request a quota increase using the Service Quotas Console

SSE - C

  • Keys are handled and managed by customer outside of AWS
    • Use SSE-C over SSE-KMS when customer wants to have control over the keys.
  • Objects are encrypted on the server side.
  • AWS doesn’t store the encryption key.
  • HTTPS is mandatory.
  • Encryption key must be provided in the HTTPS headers for every request.
  • Since you are managing the keys you would need to provide the key when you are requesting and file from S3 so that AWS can decrypt the object
  • To use it we have to use AWS CLI, AWS SDK or AWS S3 rest endpoint. We cannot use the web client.
  • Headers used for providing key information: x-amz-server-side-encryption-customer-algorithm, x-amz-server-side-encryption-customer-key, x-amz-server-side-encryption-customer-key-MD5
  • The customer must provide the encryption keys, no other keys can be used.

Client Side Encryption

  • You encrypt the object before uploading it to S3.
  • When you fetch something from S3 you must also decrypt it on the client side.
  • In this case the customer manages the keys and the encryption cycle.
  • Client side encryption can happen with the following keys:
    • Client managed keys
    • KMS CMK
When client side encryption is the right choice

Both the master keys and the unencrypted data should never be sent to AWS to comply with the strict compliance and regulatory requirements of the company. In this case we use Client side encryption with client side master key. If question had only mentioned unencrypted data as the requirement then we could have used Client side encryption with KMS CMK.

There is no auditing when we use client side encryption with client keys.

If the question mentions auditing in client side encryption then go for KMS key.

Miscellaneous

  • Optionally, we can force encryption using a bucket policy and refuse any API call to PUT an S3 object without encryption headers (SSE-KMS or SSE-C)
Bucket Policies are evaluated before Default Encryption

Last updated: 2023-03-04