S3 Encryption for Objects

  • Data protecting data while in transit (as it travels to and from Amazon S3) and at rest (while it is stored on disks in Amazon S3 data centers).
  • You can protect data in transit using Secure Socket Layer/Transport Layer Security (SSL/TLS) or client-side encryption. You have the following options for protecting data at rest in Amazon S3:

Server-Side Encryption — Request Amazon S3 to encrypt your object before saving it on disks in its data centers and then decrypt it when you download the objects.

There are 3 methods of encrypting objects in S3 with Ser

  1. SSE-KMS: leverage AWS Key Management Service to manage encryption keys
  2. SSE-C: when you want to manage your own encryption keys (Customer key)

Client-Side Encryption — Encrypt data client-side and upload the encrypted data to Amazon S3. In this case, you manage the encryption process, the encryption keys, and related tools.

Server-side encryption with Amazon S3-managed encryption keys (SSE-S3)

  • Server-side encryption protects data at rest.
  • Amazon S3 encrypts each object with a unique key.
  • The object is encrypted server-side with a 256-bit Advanced Encryption Standard (AES-256)
  • Must set header: “x-amz-server-side-encryption”: “AES256”

So let’s have a look above example.

  • We’re going to upload the objects onto Amazon S3 using the HTTP protocol or the HTTPS protocol.
  • Using the S3 Managed Key and the object encryption will happen and be stored into your Amazon S3 buckets.

Server-side encryption with AWS KMS (SSE-KMS)

  • SSE-KMS: encryption using keys handled & managed by KMS
  • KMS Advantages: user control + audit trail
  • Object is encrypted server side
  • Must set header: “x-amz-server-side-encryption”: ”aws:kms”
  • Using this header Amazon S3 knows to apply the KMS customer master key.
  • There’s some encryption that will happen and the file will be stored in your S3 buckets under the SSE-KMS encryption scheme.

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

  • SSE-C: server-side encryption using data keys fully managed by the customer outside of AWS
  • Amazon S3 does not store the encryption key you provide
  • HTTPS must be used
  • Encryption key must provided in HTTP headers, for every HTTP request made
  • We send both of these things over HTTPS with an encrypted connection between you and and Amazon S3.
  • So therefore Amazon S3 received the exact same object and the client provided data key.
  • Then again, it is server-side encryption so Amazon S3 will perform at the encryption using these two things and store the encrypted object into your S3 buckets.
  • If you wanted retrieve that file from Amazon S3 using SSE-C you would need to provide same at clients’ side data key that was used to encrypt.
  • So it requires a lot more management on your end because you manage to do the data keys.

Client-Side Encryption

  • Client library such as the Amazon S3 Encryption Client.
  • Clients must encrypt data themselves before sending to S3.
  • Clients must decrypt data themselves when retrieving from S3.
  • Customer fully manages the keys and encryption cycle

So let’s have an example

  • So in the clients we’ll use Encryption SDK, will provide the object and our client’s side data key.
  • The encryption will happen client side so the object is going to be fully encrypted on the client side.
  • Then we are going to just upload that already encrypted object into Amazon S3.

Encryption in transit (SSL/TLS)

  • Amazon S3 exposes HTTP endpoint: non encrypted and HTTPS endpoint: encryption in flight
  • You’re free to use the endpoint you want, but HTTPS is recommended
  • Most clients would use the HTTPS endpoint by default
  • HTTPS is mandatory for SSE-C.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store