SCS-C01 Amazon AWS Certified Security Specialty – Domain 5 – Data Protection part 7

22. S3 Encryption

Hi, everyone, and welcome back to the Knowledge Portal video series. So, S Three is back, and today, yet again, we are going to talk about one more important topic, which is S Three encryption. So it seems that the most of the things that we discuss about all are important, and this truly is important. So let me give you a very simple example for this particular use case. For those who are wondering, is SRE encryption really required? Now let me show you. I have my external hard disk drive. So generally, I have a lot of data in this. Now, generally, when I go out, sometimes I really have to worry because I have a lot of personal data. And if this hard disk drive gets misplaced or it gets lost, and any unauthorized person who gets access to my external hard disk drive, he can simply plug it in his laptop and he can download all of my personal data.

So, really scary. So sometimes I just put my hard disk drive at home, and I never carry it outside. But this is not a solution. So the problem is, if the data within your hard disk drive is unencrypted, and if your hard disk drive gets stolen, then hacker really have access to all of your data. Now, one of the ways in which we can protect is we can use encryption. So in this case, what happens if all the data within your hard disk drive is encrypted? And even if your hard disk drive is stolen, the hacker will not have access to the data. He’ll only have access to the encrypted data. And this is one of the requirements which most of the people need. And this is one of the reasons why the hard disk drive manufacturers are coming up with a pre built in encryptions. So it’s always good to be proactive.

So you see, Western Digital external hard disk drives, they come up with hardware based encryption. So the hardware based encryption is in build, so no need to use external tools like TrueCrypt, et cetera. And just within few clicks, you can encrypt your entire hard disrep. And this is very important. Now, the question is, what about S Three? S Three is also a storage device. And as it’s a storage device, the data within the storage device has to be encrypted specifically if it is a sensitive information. And this is one of the use case of many of the compliance requirements. And this is one of the reasons why Amazon has provided us way to encrypt the data within S Three also. So there are three ways in which we can encrypt the data in S Three. The first is the server side encryption with Amazon S Three managed keys.

So in very simple, you can call it SSE. So what happens here is that you just select a one option, and AWS will encrypt all of your data with Amazon managed keys. So here you don’t have to worry about which keys you will use to encrypt the rotation of the keys, the expiry of the keys, no need to worry about all those things. Amazon will take care of everything. The second option here, server side encryption with AWS Kms managed keys or ssems. So for some users it might be like I don’t want Amazon to use their own keys for encryption. So what I can do is I can have my own Kms and that Kms keys can be used by the AWS to encrypt your data. Now, in this particular scenario where Kms keys are used again this AWS uses the envelope based encryption which we already discussed in the previous lecture where data keys are generated from the customer master key and that data key is used to encrypt the data.

And if some users who do not want Kms also, then AWS has given the third option which is called as the SSE or customer provided keys. So I can generate my own symmetric encryption key in my computer and I can pass that symmetric key to the AWS and AWS will use that key to encrypt the data. So, three options which are available and let’s go to our console and let’s explore on how we can achieve this. So this is my AWS console. So let’s do one thing. Let me create a bucket. Let’s name it as KP Labs hyphen Encryption and Region. We’ll select Mumbai. Okay, so this is the bucket that we have created. Now let’s upload one data over here. Let’s upload this text file. These are the older operations so no need to worry about. So this is done. So now what has happened is that our text file is uploaded.

Now, the problem is that this particular file is unencrypted so it will stay unencrypted within the S three storage also. Now what we can do is we can go to details over here and we can select the server side encryption and we can set it to AES 256 and I’ll click on Save. Let me go back down. Okay, now if you’ll see this particular is saved. So if I go to properties over here just to verify now you see it is using a server side encryption with 256 bit as key. So this is the first option of AWS managed keys. Note that you really don’t have any control on which keys AWS uses. Nothing. You just have to click on one option and save as simple. Now what happens is this is the scenario where the file is already uploaded. We can also look into the second scenario where you are uploading a file.

So while uploading this file before you click on Start upload over here, just go to set details and select the server side encryption. Now again, there are two options use the AWS S three service master key. This we already looked earlier and the second is Kms. So I’ll select the Kms over here and here by default it is showing the default Kms Master key. Now, before we select the Kms, one very important thing I would really like you to know that S three bucket as we discuss are region specific so this particular bucket resides in the Mumbai region. So now if you want to encrypt the data with Kms then you need to have a Kms key in the same region which is Mumbai. So till now we were creating a Kms key in North Virginia region and you cannot use the Kms key of North Virginia region to encrypt the files in S three bucket of Mumbai region that will not work.

So what I did, I went to Mumbai and I created one Kms key Kplabs hyphen Mumbai. And now what we will do is we will use this key as a Kms Identifier for uploading the data. So I’ll use Kms kplabs PEM. Let me click on Open, set details, use server side encryption Kms. And this is the key that it is showing. So I’ll put this key, it has extracted the key ID and let me click on Upload. Let’s wait down. Okay, now you see it is done and my Kplabs PEM file is uploaded. So if you go to properties and you just want to verify the serverside encryption, you see it is using the Kms master key, which is KP Labs Hyphen, Mumbai. And the third part, which we discussed, that you can even provide your own customer site key. And AWS will use that key to encrypt the data.

Now, one interesting thing that I wanted to show you for S three bucket policy is that you can actually restrict whether data which has been uploaded is encrypted or not. So for a simple example if a client is uploading an unencrypted data then with a bucket policy we can restrict that particular upload. So let me show you on how that works. Let’s go to permission. I’ll add a bucket policy. I have a sample bucket policy over here. Let me paste it. And here I’ll give the bucket name, which is kplab’s Hyphen Encryption. And same here. Kplabs hyphen encryption. So generally what happens in this bucket policy is Amazon will look for the action which is put object.

So when anyone tries to upload a file, this action is generally happens. Now, within this, there is a condition where it checks if the server side encryption option is selected. If it is not selected for either Kms or the first S Three managed keys, then the bucket or the S Three will not allow you to upload a file. So let’s look into this example. I’ll save this particular bucket policy. Okay, now it is saved. Let’s go back here and now let me try to upload one file I’ll upload one file now I’m not going to select any of the encryption thing and let me try on uploading. So if you look down. You see the operation has failed. This is because of the bucket policy.

So from now, you will not be able to upload any unencrypted file in this bucket. So what to do now? So now, whenever you want to upload a file, you need to select the encryption schema. So now I use the server side encryption, I’ll use the master key and I’ll click on upload. And now if you look down, it is uploaded. So once again, very important use case scenario for S Three and the bucket policy as well. So this is the basic about the S three encryption and we also look into an interesting bucket policy. So this is it about this lecture, I hope this has been informative for you. And again, if you have any doubts, feel free to contact us and I’ll be more than happy to help you. Thanks for watching. 

23. Revising ELB Listener Configuration

Everyone and welcome back to the Knowledge Pool video series. And in today’s lecture we are going to speak about the ELB listeners. So let’s get started and look into what the ELB listeners are all about. So, just to revise, whenever you configure an ELB, we must configure one or more listeners. So, just wanted to show you that whenever you create a load balancer in the first page itself, you see there’s a listener configuration. So in the listener configuration, we must select the configuration that we need according to the use case that we have for our organization. Now, the listener configuration is basically divided into two parts. One is for the front end connection and second is for the back end connection. So if you see the first two columns, which is the load balancer protocol and the load balancer port, these are the front end configuration.

And then you have the instance protocol and the instance port. These are for the back end connections. So if you just have Http 80 http 80, what this basically means is that load balancer will be listening on port 80 and it will forward all the traffic to the back end on port 80. So let’s just revise before we go more further. So I have my load balancer which is up and running. And if you look into the listeners, I have one listener configuration where the load balancer port is 80 and the instance port is also 80. So what this basically means is that load balancer is listening on port 80 and whatever traffic that it gets, it will forward the traffic to the back end instance on port 80. So I have an instance which is configured over here and I am also connected to the instance. And here you will see that I have my NGINX which is running on port 80 and this is where the load balancer will be sending the traffic to.

So if I just open this up, you see I have a default NGINX page which is up and running. So this is the reason why we should have a proper listener configuration both for the front end and for the back end. So if my NGINX is running on port 80 80, then I have to change the instance port from 80 to 80 80. Perfect. So these are the basics about the listener configuration part. Now, there are two major type of listeners that we should be aware about. One is the Http and Https base and second is the TCP and SSL base. So again, this is quite important. Like whenever you go ahead and create a listener, there are four protocols which are present which are Http, https, TCP and SSL. So the first type that we broadly classify is the Http and Https based and the second type is the TCP and secure TCP base.

So these are the two types based on which the load balancer are broadly classified into. And let’s look into the Http and Https base. So depending upon the use case that you have in your organization, you need to select a specific type of listener. So let’s look into some of the use cases and we’ll look into what are the configuration parameters that we must set in order to achieve it. Now, one of the very simple use case is the basic Http load balancer. So this is something that we had seen where the load balancer is listening on port 80 and it will forward the traffic to the port 80 of the instance. So this is a very basic Http load balancer. So during that, the front end protocol that must be configured is Http and the backend protocol that must be configured is also Http.

So this is what the basic Http load balancer looks like. So on the left hand side you have the front end and on the right hand side you have the back end. So in this the ALB will be listening idly on port 80 and it will forward the traffic to port 80 in the back end instance. So this is a very basic Http load balancer. Now, the second type of use case is the website using ELB to offload the SSL decryption. So this is basically a website which uses Https. So we can use the ELB to offload the SSL encryption and decryption related functionality. So in that cases, the Https, the front end protocol should be Https and the back end protocol should be Http. So what do I mean by this? So when you use Https to Http, that means the ELB is responsible for the entire SSL negotiation.

Thus the SSL certificate must be configured at the ELV end. So from the client to the ELV, the entire data or the entire traffic will be encrypted. Now, from the ELB to the back end instance we have the normal Http protocol. So here the data is in plain text, but from the client to the ELB the data is in cipher text. So whenever you select the Https as the front end protocol, then the SSL must ideally be deployed in the ELB. So let’s look into how that would work. So, when I use the Https over here, you see when I select an Https, basically we have to configure the SSL certificate as well as the cipher related parameters. So here you see, it is asking me to store the private key, the certificate body as well as the certificate change.

So whenever you use the Https as a front end protocol, that means that the ELB will be responsible for the SSL negotiation. So all the SSL negotiation will be the responsibility of ELB and the instance does not have to worry about all those things. So this is the second type of configuration. Now the third type of configuration is specifically for the website needing end to end encryption. Now, I’ll give you one of the use case because in the organization that I used to work with, we had this approach where from client to ELB, everything was encrypted. And from ELB to the back end instance, things were in the plaintext mode. Now, we went to a compliance, there’s one famous compliance called as PCI DSS, and the auditor actually asked us to encrypt this portion as well.

So not only this portion, but on the right hand side, the entire traffic must be encrypted. So there are a lot of use cases that you might have to go through. And this is the reason why you have the third use case where website needing end to end encryption. So what you can do here, you can have an Https on the front end. There will be a SSL negotiation here, there will also be an Http on the back end and there will be a backend authentication over here. So the SSL certificate must be deployed in the ELB as well in the back end. So you have to basically deploy the certificate both on the ELP and in the back end instance as well.

So from the client to ELB, the traffic will be encrypted. From the ELB to the instance, the traffic will be encrypted. So nowhere in the network, the traffic is going through plain text, everywhere the traffic is encrypted. So this is a high level overview about the Http and Https type of load balancer. There are second type calls, TCP and SSL. Now, again, within the TCP and SSL there are various config parameters. So what we’ll be doing is in the upcoming lectures, we’ll actually go into much more depth and understand more about the difference between the Http and the TCP based load balancer. So with this we’ll conclude the lecture and I look forward to seeing you in the next lecture.