Encrypt your S3 Object

The idea behind Encrypting your S3 object is that you upload objects onto Amazon S3 and these are servers of AWS so you may want to make sure that these objects are not accessible for example, if someone gets into the Amazon servers or you wanna make sure you get adhere to some security standards set up by your company. As such, Amazon gives you four methods to encrypt objects in Amazon S3.

1. The first one is called SSE S3. This is to encrypt S3 objects, using keys handled and managed by AWS.
2. The second one is SSE-KMS. It leverages AWS key management service to manage your encryption keys.
3. The third one is SSE-C. It is used when you manage your own encryption keys.
4. Finally Client-side encryption.

Now we're going to do a deep dive on all of those so don't worry.

SSE-S3

This is an encryption where the keys used to encrypt the data are handled and managed by Amazon S3. The object is going to be encrypted server side. SSE means server-side encryption and it's type of encryption is AES-256, which is in logarithm. So for this to upload an object and set the SSE S3 encryption you must set a header called X-amz-server-side-encryption AES-256. X-amz stands for X Amazon and its server-side encryption is AES-256. This is how you remember the name of the header. Let's have a look in detail. We have an object and it is un-encrypted. We have it written out and we want to upload it into Amazon history and perform some SSE-S3 encryption. So for this we're going to upload the objects onto Amazon S3. You can use the HTTP protocol or the HTTPS protocol and you can add the header that we said, the X-amz-server-side-encryption AES256. Because of this header, Amazon S3 knows that it should apply its own S3 managed data key and using the S3 Managed Key and the object, some encryption will happen and the object will be stored encrypted into your Amazon S3 buckets. Very simple, but here in this instance the data key is entirely owned and managed by Amazon S3.

SSE-KMS

KMS is a key management service which is an encryption service. SSE-KMS is used when you have your encryption keys are handled and managed by the KMS service. Why will you use KMS over SSEs which are free? Well, it gives you control over who has access to what keys and also gives you an audit trail. Each object is going to be again encrypted server side and for this to work, we must set the header X Amazon service side encryption to be a value AWS KMS. So the idea is exactly the same because it is server-side encryption. We have the object we uploaded using HTTP and then we have the header. Amazon S3 knows to apply the KMS customer master key you have defined on top of it and using this customer master key and your object there's some encryption that will happen and the file will be stored in your S3 buckets under the SSE-KMS encryption scheme.

SSE-C

It stands for server-side encryption using the keys that you provide yourself outside of AWS. So in this case, Amazon S3 does not store the encryption key you provide so it will absolutely have to use it because it needs to do encryption after which that key will be discarded. Now, to transmit the data into AWS, you must use HTTPS because you're going to send a secret to AWS and so you must have encryption in transit. Encryption key must be provided in the HTTP headers for every HTTP request made because it's going to be discarded every single time. So we have the object and we want to have it encrypted in Amazon S3 but we want to provide ourselves the client side data key to perform the encryption. So we send both of these things over HTTPS so it's an encrypted connection between you, the clients and Amazon S3. The data key is in the header so therefore Amazon S3 received the exact same object and the client provided data key. And then again, it is server-side encryption so Amazon S3 will perform at the incorporeal using these two things and store the encrypted object into your S3 buckets. If you wanted to retrieve that file from Amazon S3 using SSE-C you would need to provide the clients' side data key that was used before. It requires a lot more management on your end because you manage to do the data keys and AWS in general does not know which data keys you have used. So it's a bit more involved.

Clients Side Encryption.

The encryption is performed by the clients. You as a client encrypt the object before uploading it into Amazon S3. Some client libraries can help you do this for example, the Amazon S3 encryption clients is a way to perform that Client Side Encryption and as I said, clients must encrypt data before sending it to S3. And then in case you receive data that is encrypted using client side encryption, then you are solely responsible for decrypting the data yourself as well so you need to make sure you have the right key available.

So, as I said, in Client Side Encryption the customer entirely manages the keys and the encryption cycle. Let's have an example. Amazon S3 this time is just the buckets where it's not doing any encryption for us because it is Client-Side Encryption not Server Side encryption. And so in the clients we'll use Encryption SDK for example, the S3 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 and then we are going to just upload that already encrypted object into Amazon S3.

Okay. So that's the four types of encryptions hopefully that makes sense.

Encryption in Transit - SSL TLS

Encryption in flight is also called SSL TLS because it uses SSL and TLS certificates. It exposes HTTP endpoint that is not encrypted and it exposes HTTPS end point which is encrypted and provide what's called encryption in flight which relies on SSL and TLS certificates. So you're free to use the end points you want but if you use the console, for example you would be using HTTPS and most clients would by the way use HTTPS endpoint by default and so if you're using HTTPS, that means that there is data transfer between your clients and Amazon S3 is going to be fully encrypted and that's, what's called encryption in transit. And one thing to know is that in case you're using SSE-C so server-side encryption and the key is provided by your clients then HTTPS is mandatory.