Amazon AWS Certified SysOps Administrator Associate – Security and Compliance for SysOps Part 4

9. [SAA/DVA] Encryption 101

So first an overview of encryption mechanism and the first one is going to be encryption in flights. Then why would we want even encryption in flights? Well, we want encryption in flight. Because if I send a very sensitive secret, for example, my credit card to a server to make a payment online, I want to make sure that no one else on the way where my network packet is going to travel can see my credit card number.

And so I want to make sure that when I make a payment online, I have that green lock, I have that Https website, which guarantees me that it is an SSL enabled website and I will get encryption in flights. And so when you have encryption in flight, the datsa will be encrypted before I send it and then the server will be decrypting it after receiving it.

But only myself and the server know how to do these things. Now the SSL certificates are what’s going to help with the encryption. And so another way to see it is Https. So anytime we’ve been dealing with an Amazon service and it had an Https endpoint that guaranteed us that it was encryption in flight. And now the whole web, almost the whole web needs to run on SSL and Https.

Basically when you have this enabled, you’re protected against the man in the middle attack. And so this guarantees that when you have that green lock and that the service certificate is valid, that no one can retrieve your sensitive information. So let’s do a quick example here is us, and we want to talk to an Https website on AWS. Could be DynamoDB, it could be whatever you want.

And then what we’re going to do is that we’re going to have to drive a super secret data, we’re going to encrypt it with SSL encryption and send this over the network. And then the website will receive that data and know how to decrypt it. Okay, very simple, the idea of it. But the execution is not as easy. So this is how much it’ll give you. The good news is that all programming languages know how to do SSL encryption and decryption. And all the libraries do this for you, so you don’t have to worry about anything. This is not something you have to deal with directly.

The second thing is going to be called server side encryption at rest. And so that is when the data is encrypted after being received by the server. So before that the server was receiving data, decrypting it, and using it in its decrypted form here, the server is going to store the data on its disk. And so we need to know that the server is storing the data in an encrypted form because in case the server gets hijacked by someone else, we don’t want someone else to be able to decrypt the data. And so the data will be decrypted before being sent back to our clients.

So thanks to a key, usually called the data key, then that data is going to be stored in an encrypted form, and the encryption and decryption keys must be managed somewhere, usually called a Kms or key management service. And the server must have the right to talk to that key management service. So here’s our object, and we’re going to transfer it, for example, to EBS. So it’s going to be transferred over whatever mechanism, and EBS will use a data key. And using the data key, it will perform encryption of that data. And now it’s stored in an encrypted form. And then the day we need to retrieve that data, for whatever reason, then EBS, the service will do decryption for us using that data key again. And we’ll get the encrypted data and back to us over Http or CTPs, for example.

So this is how server side encryption works. And as you can see, the server side itself or the service manages the encryption and the decryption and uses a data key it has access to. So this is for server side encryption at rest, and we’ve seen that many AWS services do use that encryption at rest. Now let’s talk about client side encryption. And in client side encryption, the data will be encrypted by the client and the client is us, and the server will never be able to decrypt that data. The data will then be decrypted by a receiving client. So all in all, the data is just stored on the server, but the server doesn’t know what the data means. And the server, as best practice, should never be able to decrypt the data anyway. And for this, we could leverage something called envelope encryption.

But I have a whole lecture on this later on because this is pretty advanced, but the exam will ask you about envelope encryption. So for now, let’s just do an abstraction of it. And so we have our object and on our client, we’re going to use a data key and we’re going to encrypt our data client side, okay, so we perform encryption with that data key. Now we send that data to any store of data we want. Could be FTP, it could be S three, it could be whatever you want, really. You put your data wherever you want in Amazon or somewhere else, and then when you receive it, your client will receive an encrypted object. And if it has access to the data key, if it can manage to retrieve the data key from somewhere, then it will be able to perform a decryption and get the decrypted objects as a result.

So, as you can see now the encryption happens client side, okay, the server, the data store does not know how to decrypt or encrypt the data. It just receives encrypted data. And so that’s quite secure as well. So we’re the three kinds of encryption you can get overall, except envelope encryption. That we’ll show you later on. So this is not using Kms just yet. This is just an abstraction of how encryption works. I know this may be a little bit simplified, but hopefully that clears up what encryption it is. And in the next lecture, we’re going to do a deep dive into Kms.

 10. [SAA/DVA] KMS Overview

So we’ve seen encryption in this course, but now let’s do a deep dive into Kms or key management service. So usually anytime you hear encryption within an Asbest service, it’s most likely going to be Kms. And Kms is great because with the Kms keys, you can easily control who and what can access your data. And it’s this will manage all the encryption keys for us. Kms is fully integrated with I Am for authorization. So that makes the management of these rules very simple and centralized.

Kms is at the center of AWS and it was going to be integrated into pretty much everything. So your EBS volumes, you encrypt them your story for doing service ad encryption of your objects, Amazon Redshift to encrypt your data, RDS as well to encrypt the underlying data SSM, the parameter storage will see in the next hands on to perform and encrypt some secrets, et cetera, et cetera, et cetera. And to use Kms, not only can you use it with the services you have, but you can also use it with the CLI or any AWS SDK. So now let’s talk about customer master keys or CMK.

And there are two types of Kms. The first efforting of Kms are called symmetric keys and they’re as 256 bit type of encryption keys. And they were the first offering you use single encryption keys for encrypting and decrypting data. And this is why it’s called a symmetric encryption key. Now, a lot of services that are integrated with Kms actually use the hood, the symmetric customer master keys. They are also necessary, as we’ll see when we do envelope encryption. And with Kms, when you generate a symmetric key, you actually never get access to the key unencrypted. You must use the Kms API to use that key and you actually never see the key. The second types of keys you have in Kms are Asymmetric key and they belong to the RSA and ECC key pairs. So with Asymmetric, this time you have two keys. You have a public key for encryption and a private key for decryption.

And this is the basics, for example, of how SSL works. So how do we use these keys? Well, we can use them for encryption and decrypting. So with a public key we encrypt, and with a private key we decrypt. Or also a new use case in Kms called sign verify operations. Now, the public key is something you can download because it is public, but again, access to the private key is impossible. So the use case of Asymmetric keys would be to do encryption outside of AWS by users who can’t call the Kms API. So, from an exam perspective, I think what you’re going to be testing the most on is going to be symmetric keys. I’m going to spend most of my time on Kms on symmetric keys. But you need to know that asymmetric keys have a public and private key that is used to encrypt, decrypt, or assign verify operations. And the use case is to do encryption outside of AWS by users who cannot call the AKMs API. Okay, so now let’s go into the symmetric key in more details.

So you’re able to fully manage the keys and the policies. So you can create these keys, you can define rotation policies, disable them, enable them, and then through cloud trail integration, you’re able to audit the key usage. So see who use the keys and when. There are three types of customer master keys. There is the AWS manage service default master key, which is free. So this is the idea. When you go into EBS volume and use the AWS EBS key, this is going to be free. Then if you create your own key, this is one dollars per month and there is no free tier.

And if you import your own key so if you’re going to generate them outside of Kms, even though it’s not very recommended, then it’s also going to be one dollars per month. And then for Kms, you’re going to pay for each API call done to Kms. So we’re talking about three cents per ten thousand calls. So when would you use Kms? Well, anytime you need to share some sensitive information, you would use Kms, such as database passwords, credentials for an external service, a private key of SSL certificates.

So anything you need to encrypt it is going to be secret. Kms is the way to go. Now, the idea is that with Kms, the real value is that we actually don’t see the keys to encrypt the data or decrypt. So the whole security belongs with AWS to use that key. We’re able to, but we can send data to Kms to decrypt and encrypt. And so that’s the real value of Kms. On top of it, Kms can rotate these keys for extra security. So the idea with encryption is that you would never, ever, ever store any of your secrets. So database, password, et cetera, et cetera, in tightex and especially in your code. So what you should do is that you should encrypt these secrets instead, so you can encrypt them, and then you can store them in code or environment variables. And that’s fine because they are encrypted.

So Kms has a limit, and you can only encrypt up to 4 data per call. And so if you want to have more data encrypted, which is most often going to be the case, then you need to use something called envelope encryption, which is advanced, and you only need to know in the Certified Developer Exam. So we’ll see this in the certified developer courses. So to give access to Kms to someone, then you need to make sure that the key policy allows the user to access the key, as well as the Im policy to allow the API call. And when these two things are together, then you get access to your Kms key. It should make a lot of sense when we go into the hands on.

Another thing is that your Kms keys are bound to a specific region. So that means that when you create a Kms Key in region A, it could not be transmitted over to region B. So let’s say we have an encrypted EBS volume with Kms and the Kms Key in the region EU West Two, and would like to copy that volume across to a new region, for example, AP Southeast Two. So because Kms keys are linked to a specific region, you would need to do a specific operation. So here’s the process. And this applies to EBS volumes, redshift, snapshots, pretty much everything that is encrypted with AWS Kms. So first you would create a snapshot of your volume and any snapshots made from an encrypted volume is also encrypted with Kms and the same key. Then you need to copy that snapshot over to the new region. But you will specify a new Kms Key to reencrypt the data with. So it’ll be Kms key B in the other region. And now you have a snapshot encrypted with Kms in the other region but with a new key. And finally, when you recreate a volume from that snapshot, then that volume will be encrypted with a new Kms Key B. So it’s super important to see here that because Kms keys are bound to a specific region, when you copy snapshots over, they have to be re encrypted.

Now, let’s talk about Key policies. To control access to Kms. We saw there was im policies and key policies. So Key Policies are similar to S Three Bucket Policies or any kind of Resource policies we see in this course. But the difference is that you cannot control access without them. So if you don’t specify a Key policy, then no one can access your key. And so, as such, the default Kms Key Policy by default is very permissive. It’s created by default if you don’t provide a specific Kms Key policy and it’s going to give access to the root user, which means that your entire account has the right to use this Kms Key on top of only if they have the Im Policy available, obviously.

So, to give users access to Kms keys using this default Kms Key policy, very simple. You just create the correct Im Policy and attach it to the user. If you define a custom Kms Key Policy, then you would specifically define the users and the roles that can access the specific Kms Key and define who can administer the key. And finally, this is going to be very helpful when you do cross account access of your Kms Key. So let’s finally talk about cross account copying of snapshots now that we know about Key policies. So when you create a snapshot, it would be encrypted with your own CMK, then you would with a touching.