‫So now let's talk about object encryption
‫in Amazon S3.
‫So you can encrypt objects in S3 buckets using one
‫of the following four methods.
‫The first one is server-side encryption, SSE,
‫and you have multiple flavors of it.
‫So you have SSE-S3,
‫which is server-side encryption with Amazon S3-managed keys,
‫and that is enabled by default
‫for your buckets and your objects.
‫Then we have SSE-KMS, where we encrypt this time
‫with a KMS key to manage the encryption key.
‫Then we have SSE-C to use customer-provided key,
‫so this time we provide the own encryption key.
‫And don't worry, we'll see all of these
‫in great details in the next slide,
‫so this is just an overview.
‫And then we have client-side encryption
‫when we want to encrypt everything client side
‫and then upload it to Amazon S3.
‫So at the exam it's important to understand
‫which ones are for which situation,
‫so let's do a deep dive into all of those
‫and understand the specificities of them.
‫So the first one is Amazon S3 for SSE-S3 encryption.
‫So in this case, the encryption is using a key
‫that's handled, managed and owned by AWS.
‫You never have access to this key.
‫The object is going to be encrypted server side by AWS
‫and the security type of the encryption is a AES-256.
‫Therefore, you must set the header
‫to "x-amz-server-side-encryption": "AES256"
‫to request Amazon S3 to encrypt the object
‫for you using the SSE-S3 mechanism.
‫Now SSE-S3 is enabled by default
‫for new buckets and new objects.
‫So how does that work?
‫We have Amazon S3, and we have our user.
‫The user, you, you're going to upload a file
‫with the correct header,
‫and then it will be an object under Amazon S3.
‫Amazon S3 will pair it with the S3-owned key, okay,
‫because we're using the SSE-S3 mechanism.
‫And then we'll perform encryption
‫by mixing the key and the object,
‫and that will be what will be stored on your S3 buckets.
‫So that's for the simpler one, SSE-S3.
‫Then we have SSE-KMS.
‫So this time, instead of relying on the key
‫that is owned by AWS and the S3 service,
‫you want to manage your own keys yourself using
‫the KMS service, the Key Management Service.
‫So the advantages using KMS
‫is that you have user control over this key,
‫so you can create keys yourself within KMS,
‫and you can edit the key usage using CloudTrail.
‫So anytime someone uses a key in KMS,
‫this is going to be logged in a service
‫that logs everything that happens in AWS called CloudTrail.
‫So for this, we must have a header called
‫the "x-amz-server-side-encryption": "aws:kms"
‫and then the object will be encrypted server side.
‫So anything SSE, of course, is server side.
‫So how does that work?
‫Well, again, we upload the object,
‫this time with a different header,
‫and in the header we actually specify
‫the KMS key we want to use.
‫Then the object is appearing in Amazon S3,
‫and this time the KMS key that's going to be used
‫is coming out of the AWS KMS.
‫So these two things together are going to be blended
‫and then you're gonna get encryption,
‫and that's the file is going to end up in the S3 buckets.
‫So now to read that file from the S3 bucket,
‫not only do you need access to the object itself
‫but also to the underlying KMS key that was used
‫to encrypt this object.
‫So this is another level of security.
‫So SSE-KMS has some limitations
‫because while now that you upload
‫and download files from Amazon S3,
‫you need to leverage a KMS key.
‫The KMS key has its own APIs, for example,
‫GenerateDataKey, and when you decrypt,
‫you're going to use the Decrypt API, and so therefore,
‫you're going to do API calls into the KMS service.
‫Each of these API calls is going to count
‫towards the KMS quotas of API calls per second,
‫so based on the region,
‫you have between 5,000 and 30,000 requests per second,
‫although they can be increased using
‫the Service Quotas Console.
‫And so if you have a very, very high throughput S3 bucket,
‫and everything is encrypted using KMS keys,
‫you may go into a thread link kind of use case.
‫So this is something the exam may test you on.
‫Next we have the SSE-C type of encryption.
‫So this time the keys are managed outside of AWS,
‫but it still server-side encryption
‫because we send the key to AWS.
‫But Amazon S3 will never store
‫the encryption key you provide.
‫After they're used, they're being discarded.
‫So in that case, because we transmit a key into Amazon S3,
‫we must use HTTPS and we must pass the key
‫as part of HTTP headers for every request being made.
‫So how does that work?
‫The user is going to upload a file as well as the key,
‫but the user manages the key outside of AWS.
‫Then, Amazon S3 will use the client's provided key
‫and the object to perform some encryption
‫and then put the file as encrypted into an S3 bucket.
‫And of course, to read that file,
‫the user must again provide the key
‫that was used to encrypt that file.
‫Finally, we have the client-side encryption.
‫So this is easier to implement
‫if we leverage some client library
‫such as the Client-Side Encryption Library.
‫And the idea with client-side encryption
‫is that the clients must encrypt data themselves
‫before sending data to Amazon S3.
‫And also, you can retrieve the data from Amazon S3,
‫and then the decryption of the data happens
‫on the client outside of Amazon S3.
‫Therefore the clients fully manages the keys
‫and the encryption cycle.
‫So how does that work?
‫We have a file and we have a client's key
‫that's outside of AWS.
‫The client itself is going to provide
‫and perform the encryption,
‫so now we have an encrypted file,
‫and that file as is can be sent into Amazon S3 for upload.
‫So we've seen all the levels of encryption of objects,
‫but now let's talk about encryption in transit.
‫So encryption in transit, or in flight,
‫is also called SSL or TLS,
‫and basically your Amazon S3 bucket has two endpoints,
‫the HTTP endpoint that is not encrypted
‫and the HTTPS endpoint that has encryption in flights.
‫So anytime you visit a website
‫and you see that green lock or lock,
‫usually that means it's using encryption in flights,
‫meaning the connection between you
‫and the target server is secure and fully encrypted.
‫Therefore, when you're using Amazon S3,
‫it's fully recommended to use HTTPS
‫to have secure transmission of data, of course,
‫and if you use the SSE-C type of mechanism,
‫you must use the HTTPS protocol.
‫Now this is not something to worry about in real life
‫because while most clients would use
‫the HTTPS endpoint by default.
‫Now how would you go about forcing encryption in transits?
‫For this, we could use a bucket policy.
‫So you attach a bucket policy to your S3 bucket,
‫and you attach this statement which is saying
‫that you deny any GetObject operation
‫if the condition is "aws:SecureTransport": "false".
‫So SecureTransport is going to be true whenever using HTTPS
‫and false whenever you're not using an encryption,
‫an encrypted connection,
‫and so, therefore, any user trying to use HTTP
‫on your bucket is going to be blocked,
‫but users using HTTPS may be allowed.
‫Okay, so that's it for encryption,
‫I hope you liked it, and I will see you in the next lecture.