1 00:00:10,700 --> 00:00:16,410 Welcome back to BackSpace Academy. In this lecture we're going to talk about 2 00:00:16,410 --> 00:00:21,270 encryption on AWS which is a very important subject. 3 00:00:21,270 --> 00:00:27,539 Now I deal with a lot of senior IT managers for quite large companies and a 4 00:00:27,539 --> 00:00:33,480 lot of these people just don't really understand encryption, and it's not their fault , 5 00:00:33,480 --> 00:00:39,600 the problem is the way that encryption is taught can be confusing. 6 00:00:39,600 --> 00:00:46,260 What I do is that I will break it down to very simple building blocks and from 7 00:00:46,260 --> 00:00:51,809 there you will build and further understand how that applies to AWS and I 8 00:00:51,809 --> 00:00:56,640 promise you at the end of this lecture you will well and truly get encryption 9 00:00:56,640 --> 00:01:02,609 on AWS. We'll start off by discussing the two main types of encryption being 10 00:01:02,609 --> 00:01:07,170 symmetric and asymmetric encryption. We'll talk about the key management 11 00:01:07,170 --> 00:01:13,380 service that integrates with many AWS services. We'll talk about the CloudHSM 12 00:01:13,380 --> 00:01:18,840 service that can allow us to securely store and manage our encryption keys. 13 00:01:18,840 --> 00:01:23,009 We'll talk about the secrets manager which can be used for storing our 14 00:01:23,009 --> 00:01:28,560 secrets that are in text files for example our username and password. 15 00:01:28,560 --> 00:01:33,420 We'll talk about the AWS encryption software development kit specifically for 16 00:01:33,420 --> 00:01:38,070 cryptographic operations, and finally we'll talk about how we can encrypt our 17 00:01:38,070 --> 00:01:46,710 data on AWS both at rest and in transit. Symmetric encryption, now that uses the 18 00:01:46,710 --> 00:01:52,409 same encryption key to both encrypt our data and to decrypt our data. So that 19 00:01:52,409 --> 00:01:57,689 requires our sender who is going to be encrypting our data and sending it and 20 00:01:57,689 --> 00:02:02,430 the receiver who is going to be decrypting our data, they need to agree 21 00:02:02,430 --> 00:02:07,459 on the same key and keep it safe. They need to keep it secret and secure 22 00:02:07,459 --> 00:02:13,740 because if that key is intercepted in transit or it's stolen or 23 00:02:13,740 --> 00:02:18,840 some other way it has been compromised then that data can be compromised as 24 00:02:18,840 --> 00:02:21,140 well. 25 00:02:23,300 --> 00:02:29,910 Now to understand asymmetric encryption we need to understand the concept of a 26 00:02:29,910 --> 00:02:35,880 two-way lock. So the easiest way to understand this is to think about, 27 00:02:35,880 --> 00:02:43,740 we've got a padlock here and that padlock has two keys. Now one of those keys turns the 28 00:02:43,740 --> 00:02:50,760 lock in a clockwise direction and it locks that lock, and if you try to turn 29 00:02:50,760 --> 00:02:55,740 the key in the anti-clockwise direction to unlock that lock it won't let you do that, 30 00:02:55,740 --> 00:03:01,500 but if you use your other key now that key only turns in the 31 00:03:01,500 --> 00:03:06,990 anti-clockwise direction, and so you can put the other key into that lock turn to 32 00:03:06,990 --> 00:03:14,220 anti-clockwise and you will unlock that two-way lock . So one key can only lock it, 33 00:03:14,220 --> 00:03:20,400 can only go in one direction, the other key can only unlock, and so what we have 34 00:03:20,400 --> 00:03:28,380 is that we have a public key and that can is use to lock that lock, it cannot 35 00:03:28,380 --> 00:03:34,620 be used to unlock that lock, and then we have a private key now that private key 36 00:03:34,620 --> 00:03:41,760 can be used to unlock that lock, but the private key cannot be used to lock the 37 00:03:41,760 --> 00:03:44,510 lock at all. 38 00:03:44,780 --> 00:03:50,370 So asymmetric encryption, which is also sometimes referred to as public key 39 00:03:50,370 --> 00:03:57,780 encryption uses a pair of keys. A public keys that is only used to encrypt your 40 00:03:57,780 --> 00:04:04,440 data, and a private key which is only ever used to decrypt your data. Now the 41 00:04:04,440 --> 00:04:11,579 public and private key are mathematically linked but, if you have 42 00:04:11,579 --> 00:04:19,169 the public key it's not possible to mathematically work out the private key. 43 00:04:19,169 --> 00:04:24,180 You just wouldn't have a computer with enough resources to carry out that 44 00:04:24,180 --> 00:04:29,820 massive algorithm to do that. So it's not possible to actually create one from the 45 00:04:29,820 --> 00:04:36,810 other. So you may be wondering why do we have a public key and why do we have a 46 00:04:36,810 --> 00:04:42,380 private key and what is the purpose of that. So anyone who has this public key 47 00:04:42,380 --> 00:04:50,760 can encrypt that data for the receiver. So if you want people to send you some 48 00:04:50,760 --> 00:04:55,500 data and encrypt it before they send it to you, what you can do is that you can 49 00:04:55,500 --> 00:05:01,650 send them out your public key and they can use that public kree to encrypt that 50 00:05:01,650 --> 00:05:08,280 data before it is transmitted over to you. They never receive the private key. 51 00:05:08,280 --> 00:05:13,800 That private key is kept with you the receiver of that data and you use that 52 00:05:13,800 --> 00:05:20,099 private key to decrypt the data and that is great because that private key never 53 00:05:20,099 --> 00:05:25,620 leaves you and so if that public key, which is sent out to the transmitter, 54 00:05:25,620 --> 00:05:32,130 if that is ever intercepted, it is of no use to anyone because a public key can never 55 00:05:32,130 --> 00:05:38,639 be used to decrypt data. Only a private key can and that is a magic of 56 00:05:38,639 --> 00:05:46,050 asymmetric encryption and why it is so important. Ok, so let's have a look at a 57 00:05:46,050 --> 00:05:51,599 real-life example. Let's just say that we've launched an ec2 instance and we 58 00:05:51,599 --> 00:05:56,210 want to connect to that instance using secure shell or SSH. 59 00:05:56,210 --> 00:06:00,500 So the first thing that we need to do is obviously we'll need to make sure 60 00:06:00,500 --> 00:06:07,160 that our our security group rules allow a connection on port 22 for SSH. 61 00:06:07,160 --> 00:06:10,130 The other thing that we need to do is that we need to make sure that we download 62 00:06:10,130 --> 00:06:17,780 the PEM file for connection to that ec2 server. Once we've got that, then we can 63 00:06:17,780 --> 00:06:22,849 go through the process of connecting to that ec2 server. The first step is that 64 00:06:22,849 --> 00:06:27,500 we need to make sure that we're running our ssh client on our computer that 65 00:06:27,500 --> 00:06:32,449 we're connecting to, from our office or home or wherever it is, and once we've 66 00:06:32,449 --> 00:06:38,150 got that ssh client and we've got the endpoint for our server, we can initiate 67 00:06:38,150 --> 00:06:45,800 a session with that ec2 server. Once we've done that, the ec2 server will 68 00:06:45,800 --> 00:06:52,370 provide us with a host key and that host key will be our public encryption key 69 00:06:52,370 --> 00:06:59,630 and that will occur when we attempt to connect with that ec2 server. So once 70 00:06:59,630 --> 00:07:05,830 we've got that public key and we've got our PEM private key, we can use 71 00:07:05,830 --> 00:07:12,800 asymmetric cryptography to verify the identity of that ec2 server that we're 72 00:07:12,800 --> 00:07:18,710 connecting to. Once that's done and once we're satisfied and the ec2 server is 73 00:07:18,710 --> 00:07:24,139 satisfied with our identity, then this server will generate a symmetric key and 74 00:07:24,139 --> 00:07:28,820 we use that symmetric key for bi-directional encryption from that 75 00:07:28,820 --> 00:07:34,430 point onwards or for that session, and that way all of the traffic being sent 76 00:07:34,430 --> 00:07:42,139 to and from this ec2 server will be encrypted while it is in transit. 77 00:07:42,139 --> 00:07:50,389 One very important thing to remember is that, what happens if you lose your PEM file? 78 00:07:50,389 --> 00:07:57,500 If that occurs, you will not be able to connect to your ec2 instance and AWS 79 00:07:57,500 --> 00:08:02,120 will not be able to provide it for you because there is your private key and 80 00:08:02,120 --> 00:08:08,870 only you have a copy of that. AWS does not keep a copy of your private key. 81 00:08:08,870 --> 00:08:11,750 So in that situation, what you are going to 82 00:08:11,750 --> 00:08:15,950 have to do is, that you will have to stop that instance. You will have to create 83 00:08:15,950 --> 00:08:21,890 another private key or another key pair and then you're going to have to 84 00:08:21,890 --> 00:08:26,870 associate that key pair by going into the user data, quite a complex process, 85 00:08:26,870 --> 00:08:31,670 and associate that new key pair with that ec2 instance and then you'll be 86 00:08:31,670 --> 00:08:36,940 able to use your new key pair to connect in. 87 00:08:39,240 --> 00:08:47,050 The AWS key management service or KMS for short, that integrates with a lot of 88 00:08:47,050 --> 00:08:53,230 different AWS services and it creates and manages the encryption keys that I 89 00:08:53,230 --> 00:09:01,360 use with those services. It uses a single master key that is secured by AWS. So it 90 00:09:01,360 --> 00:09:06,910 is symmetric encryption. We don't have a public and private key, we just have a 91 00:09:06,910 --> 00:09:14,080 single key. Now that key always remains on AWS and you cannot download that at 92 00:09:14,080 --> 00:09:19,029 all. The key is rotated automatically by the 93 00:09:19,029 --> 00:09:26,529 KMS service every year by default. If automatic key rotation is enabled. If you 94 00:09:26,529 --> 00:09:32,740 want to use the KMS service to encrypt any data then you must have IAM 95 00:09:32,740 --> 00:09:39,310 permissions to use those keys, and so those permissions can also be granted to 96 00:09:39,310 --> 00:09:44,560 other other AWS accounts as well if they would like to decrypt that data. Now the 97 00:09:44,560 --> 00:09:50,320 list of services that integrate with the LMS is growing but if you go to the 98 00:09:50,320 --> 00:09:56,770 Amazon website and go to slash KMS slash features you'll get a good list of all 99 00:09:56,770 --> 00:10:04,540 of these services that integrate with the KMS. Because the KMS service uses 100 00:10:04,540 --> 00:10:09,330 symmetric encryption, you may be questioning the security of that, but 101 00:10:09,330 --> 00:10:14,200 there's no need to be alarmed because we have another process involved with the 102 00:10:14,200 --> 00:10:19,420 KMS and that is called envelope encryption. So the way that works is that 103 00:10:19,420 --> 00:10:24,240 we have a data key that is used to encrypt that data and that is our single 104 00:10:24,240 --> 00:10:30,400 encryption key. Now to make sure that that data key is secure, so if someone 105 00:10:30,400 --> 00:10:37,089 gets hold that key, what the KMS does is it actually encrypts that encryption 106 00:10:37,089 --> 00:10:45,490 key. It encrypts the data key using a KMS master key, and so those master keys are 107 00:10:45,490 --> 00:10:51,250 stored by AWS and they're called your customer master keys or CMKs 108 00:10:51,250 --> 00:10:57,340 for short. Now although symmetric encryption with a single data key is 109 00:10:57,340 --> 00:11:03,820 being used to encrypt that data, the KMS service can actually support symmetric 110 00:11:03,820 --> 00:11:10,510 and asymmetric customer master keys that are going to be used to encrypt that 111 00:11:10,510 --> 00:11:19,870 data key, and those CMK's are stored in a FIPS 140 - 2 compliant hardware 112 00:11:19,870 --> 00:11:27,010 security module. So they are very safely kept. If for whatever reason the data key 113 00:11:27,010 --> 00:11:31,960 is compromised, it's not a problem because it's encrypted using that master 114 00:11:31,960 --> 00:11:33,990 key. 115 00:11:36,300 --> 00:11:44,350 The AWS cloud HSM service is a cloud-based hardware security module or 116 00:11:44,350 --> 00:11:52,660 HSM for short and it is used to secure and store your encryption keys, and it 117 00:11:52,660 --> 00:11:56,490 conforms with the security requirements for cryptographic modules 118 00:11:56,490 --> 00:12:03,940 federal information processing standard or FIPS for short 140 - 2 level 3. 119 00:12:03,940 --> 00:12:09,430 What that means is that your encryption keys that are stored in this HSM module 120 00:12:09,430 --> 00:12:17,920 are extremely secure. You control and manage your keys. AWS does not have 121 00:12:17,920 --> 00:12:23,680 access to your keys, and it's only accessible, these keys are only 122 00:12:23,680 --> 00:12:33,640 accessible, by users that you specify. The Cloud HSM will run inside a VPC inside 123 00:12:33,640 --> 00:12:41,650 of your account. The encryption keys are installed inside of that Cloud HSM will 124 00:12:41,650 --> 00:12:47,589 be accessible by a HSM client application that is running on an ec2 125 00:12:47,589 --> 00:12:54,339 server that you launch, and there are HSM commands within the AWS software 126 00:12:54,339 --> 00:12:58,750 development kit. It's also multiple availability zone as well. 127 00:12:58,750 --> 00:13:09,580 Some use cases for CloudHSM. You may want to use a CloudHSM cluster as a 128 00:13:09,580 --> 00:13:15,790 custom KMS key store instead of using the default KMS key store. You may 129 00:13:15,790 --> 00:13:19,870 want to do that if you want to keep all of your keys in the one location using 130 00:13:19,870 --> 00:13:26,470 Cloud HSM. Another use case you can use it to offload the SSL processing from 131 00:13:26,470 --> 00:13:34,390 your web servers over to CloudHSM. By doing that, cloudHSM will take all of 132 00:13:34,390 --> 00:13:41,290 that processing for the HTTPS requests and take that load off your web servers 133 00:13:41,290 --> 00:13:46,300 and make sure that your web services are more available as a result of that and 134 00:13:46,300 --> 00:13:50,710 reduce the latency as well. You can also use it to protect the 135 00:13:50,710 --> 00:13:55,690 private keys that you use with a third-party certificate authority. So if 136 00:13:55,690 --> 00:14:01,450 you're using another service other than AWS to issue your SSL 137 00:14:01,450 --> 00:14:09,720 certificates, then you can protect those private keys using a CloudHSM as well. 138 00:14:10,100 --> 00:14:16,829 The AWS secrets manager is a cloud-based service to store our secrets and that 139 00:14:16,829 --> 00:14:21,269 could be database credentials, such as a username and password for logging into a 140 00:14:21,269 --> 00:14:26,519 database. It could be our passwords, third party API keys. It could also be 141 00:14:26,519 --> 00:14:30,930 arbitrary text that we can put in there as well that we would like to manage as 142 00:14:30,930 --> 00:14:36,779 a secret. The big advantage of doing that and using the secrets manager is that we 143 00:14:36,779 --> 00:14:41,730 can replace hard coded credentials that we've put in our code. For example, we may 144 00:14:41,730 --> 00:14:46,110 have a application that is a web application that's running on an ec2 145 00:14:46,110 --> 00:14:51,240 server and we may have put hard-coded credentials inside of that code to 146 00:14:51,240 --> 00:14:56,279 connect to something else, and so that's a problem if someone manages to get hold 147 00:14:56,279 --> 00:15:02,610 of our code. They've also got hold of the credentials as well. So instead of doing 148 00:15:02,610 --> 00:15:05,809 that we can replace that with an API call 149 00:15:05,809 --> 00:15:11,699 from that web server over to the AWS secrets manager, and then the secrets 150 00:15:11,699 --> 00:15:17,699 manager can authenticate that server and then handover that secret to that ec2 151 00:15:17,699 --> 00:15:24,059 server. It uses the AWS KMS service to encrypt the secret. So they are encrypted 152 00:15:24,059 --> 00:15:31,769 and secure. The secrets can be created and retrieved using the AWS console, the 153 00:15:31,769 --> 00:15:38,339 AWS CLI, or one of the many software development kits. To create or retrieve a 154 00:15:38,339 --> 00:15:43,500 secret from the secrets manager you will need to have IAM permissions that will 155 00:15:43,500 --> 00:15:49,589 allow that to occur. Ok, here is how we would create a secret 156 00:15:49,589 --> 00:15:56,189 using the command line interface. The commander is secrets manager and then 157 00:15:56,189 --> 00:16:01,050 the command there is create secret, and then we need to provide a name for this 158 00:16:01,050 --> 00:16:05,579 secret, a description for it, and then the actual secret itself. So we can see here 159 00:16:05,579 --> 00:16:10,259 we've got a secret - string and then we define what that secret is and it's a 160 00:16:10,259 --> 00:16:16,379 file so the details of that secret will be in a file called my creds JSON. If 161 00:16:16,379 --> 00:16:22,800 that was successful the command line interface will then output the ARN or 162 00:16:22,800 --> 00:16:27,240 Amazon number for that secret and the name 163 00:16:27,240 --> 00:16:30,840 that you provided for that secret and the version idea of that secret as wel.l 164 00:16:30,840 --> 00:16:37,530 The IAM permissions that are required will be secrets manager create secret 165 00:16:37,530 --> 00:16:43,890 and if you're using a customer manage cmk then you'll also need to have KMS 166 00:16:43,890 --> 00:16:49,860 generate data key permissions as well. Now if we want to retrieve that secret 167 00:16:49,860 --> 00:16:56,610 value we'll need to have the ARN or the name that we provided for that secret 168 00:16:56,610 --> 00:17:00,990 and we of course will need to have IAM permission so we'll need to have secrets 169 00:17:00,990 --> 00:17:06,780 manager get secret value, and again if we're using a customer manage cmk with 170 00:17:06,780 --> 00:17:12,390 the KMS then we'll need to have KMS decrypted permissions as well. So the 171 00:17:12,390 --> 00:17:17,610 command there will be AWS secrets manager and then get secret value and 172 00:17:17,610 --> 00:17:24,300 then secret ID which will be either the ARN or the name that we provided for 173 00:17:24,300 --> 00:17:26,990 that secret. 174 00:17:30,590 --> 00:17:36,930 The AWS encryption software development kit and its associated command-line 175 00:17:36,930 --> 00:17:43,110 interface is a client-side encryption library. So what that means is that you 176 00:17:43,110 --> 00:17:49,260 will install the encryption command-line interface on a computer. Could be an ec2 177 00:17:49,260 --> 00:17:54,180 server. Could be a remote computer whatever it is, or you could install an 178 00:17:54,180 --> 00:17:58,860 application that is running the encryption software development kit as well. 179 00:17:58,860 --> 00:18:03,900 Now this is separate from the AWS command-line interface and the AWS 180 00:18:03,900 --> 00:18:08,460 software development kits. It stands on its own as a separate application. It 181 00:18:08,460 --> 00:18:15,090 supports only symmetric CMKs but it uses envelope encryption to make sure 182 00:18:15,090 --> 00:18:20,570 that that encryption key is secured. Okay let's have a look at an example using 183 00:18:20,570 --> 00:18:26,580 the command-line interface. So the command there is AWS - encryption 184 00:18:26,580 --> 00:18:32,580 - CLI and the parameters that we need to provide first off is encrypted, saying 185 00:18:32,580 --> 00:18:37,110 that we're going to be encrypting this data. We then need to define the input 186 00:18:37,110 --> 00:18:43,560 data and there it is a file hello dot txt. We then need to define the ARN or 187 00:18:43,560 --> 00:18:50,070 the amazon resource number for our master key. We then define a folder where 188 00:18:50,070 --> 00:18:56,580 we can store our metadata output. Now the next one here is encryption context and 189 00:18:56,580 --> 00:19:04,290 that is optional but it is recommended by AWS what that is is a name value pair 190 00:19:04,290 --> 00:19:08,190 or you could put multiple name value pairs in here you just need to separate 191 00:19:08,190 --> 00:19:14,130 them with a space and they further define this encryption job. So when we go 192 00:19:14,130 --> 00:19:18,420 to decrypt we can also provide this encryption context in our decrypt 193 00:19:18,420 --> 00:19:23,550 command and that will make sure that we're getting the right file to decrypt. 194 00:19:23,550 --> 00:19:30,330 So here we've got a name value pair of Department and IT and finally we just 195 00:19:30,330 --> 00:19:34,560 need to define where this is going to be output. So we just got there output and 196 00:19:34,560 --> 00:19:40,020 a dot which will output that to the the actual folder where this command is 197 00:19:40,020 --> 00:19:42,810 being issued from, and so that will create 198 00:19:42,810 --> 00:19:48,300 and encrypted file and it will put that into the folder where that command was 199 00:19:48,300 --> 00:19:55,890 actually issued from, and that file will be called hello text dot encrypted. Okay 200 00:19:55,890 --> 00:20:00,480 when we want to decrypt that file the command there again is a AWS - 201 00:20:00,480 --> 00:20:03,990 encryption - CLI and the parameters there, 202 00:20:03,990 --> 00:20:08,970 first off decrypt to decrypt it, we provide what the input is and there will 203 00:20:08,970 --> 00:20:14,550 be hello dot text dot encrypted and that is the file that is encrypted that we 204 00:20:14,550 --> 00:20:20,550 need to decrypt. We will supply the encryption context, if we supplied an 205 00:20:20,550 --> 00:20:25,170 encryption context previously when we encrypted it. If we don't or if we didn't 206 00:20:25,170 --> 00:20:29,190 then we don't need to worry about that. We need again to provide an output 207 00:20:29,190 --> 00:20:34,950 folder for the metadata and then finally where we're going to output that to. 208 00:20:34,950 --> 00:20:39,180 When we run that command it's going to create a decrypted file and that will be called 209 00:20:39,180 --> 00:20:45,450 hello dot text dot encrypted. So the same name as before but we've a dot decrypted 210 00:20:45,450 --> 00:20:48,740 on the end of that file name. 211 00:20:50,950 --> 00:20:57,590 There are three main options for managing your encryption keys. The first 212 00:20:57,590 --> 00:21:03,230 option is where you control everything. You control the method of encryption for 213 00:21:03,230 --> 00:21:11,120 example AES whatever and you control the key management infrastructure or the KMI 214 00:21:11,120 --> 00:21:15,740 and that will consist of the key storage where that key is going to be stored and 215 00:21:15,740 --> 00:21:21,470 the key management, so who is going to be authorized to access it access that key 216 00:21:21,470 --> 00:21:24,080 and you are the one that controls all of that. 217 00:21:24,080 --> 00:21:29,270 AWS will not be involved in the management of that key. A good example of 218 00:21:29,270 --> 00:21:36,070 that is using client-side encryption where you would encrypt your files 219 00:21:36,070 --> 00:21:42,529 before you upload those to AWS. So you have your computer here and you run an 220 00:21:42,529 --> 00:21:46,760 encryption client software it encrypts that data and then you can upload that 221 00:21:46,760 --> 00:21:50,840 data to s3 and that will be uploaded as encrypted data. 222 00:21:50,840 --> 00:21:55,460 AWS doesn't look after any of that encryption whatsoever. All it does is it 223 00:21:55,460 --> 00:22:03,080 stores that encrypted file for you in S3. The next option is where you can control 224 00:22:03,080 --> 00:22:09,769 the method of encryption and the key management who is authorized to access 225 00:22:09,769 --> 00:22:17,149 that key and AWS will look after securely storing that key for you. A good 226 00:22:17,149 --> 00:22:23,169 example of that is to use the CloudHSM service to securely store your keys 227 00:22:23,169 --> 00:22:29,389 inside of a VPC inside of your account and then your applications that are 228 00:22:29,389 --> 00:22:37,580 running on ec2 can access the CloudHSM and then access that key. 229 00:22:37,580 --> 00:22:43,260 The last option there is where AWS controls everything. So they control the 230 00:22:43,260 --> 00:22:48,750 method of encryption and the entire key management infrastructure, such as the 231 00:22:48,750 --> 00:22:53,820 storage of those keys and the authorization of who can access those 232 00:22:53,820 --> 00:22:58,920 keys. A good example that is to encrypt an s3 bucket using server-side 233 00:22:58,920 --> 00:23:03,990 encryption and using a KMS managed key. That way 234 00:23:03,990 --> 00:23:08,520 AWS will be looking after all of the encryption and they will also be looking 235 00:23:08,520 --> 00:23:13,740 after who can access that key and also looking after the storage and management 236 00:23:13,740 --> 00:23:20,430 of that key as well using the KMS service. We can use encryption with a lot 237 00:23:20,430 --> 00:23:25,650 of the AWS storage services. First up there we can use the AWS backup service 238 00:23:25,650 --> 00:23:30,660 to manage all of our encrypted storage. We can also use encryption with the s3 239 00:23:30,660 --> 00:23:39,300 Glacier, EBS volumes, EFS volumes, CloudWatch logs, Snowballs, Storage Gateway, 240 00:23:39,300 --> 00:23:45,480 Cloudtrail and also with CodeCommit, code deploy and code pipeline but with CodeCommit 241 00:23:45,480 --> 00:23:53,880 we can only use it with KMS managed keys only. We can also use the AWS KMS 242 00:23:53,880 --> 00:24:00,690 service to encrypt our databases as well including RDS Aurora, documentDB are 243 00:24:00,690 --> 00:24:06,570 those MongoDB databases, Neptune the graph databases, ElastiCache, the 244 00:24:06,570 --> 00:24:12,470 database migration service jobs and also DynamoDB. We can use it with server-side 245 00:24:12,470 --> 00:24:16,860 encryption for encryption at rest of that data but we also have another 246 00:24:16,860 --> 00:24:22,830 option with DynamoDB and that is to use a DynamoDB encryption client and that 247 00:24:22,830 --> 00:24:29,750 allows us to encrypt that data both in transit and at rest that is residing in 248 00:24:29,750 --> 00:24:32,750 DynamoDB. 249 00:24:32,830 --> 00:24:39,769 Other AWS services that can be encrypted using the KMS. Kinesis streams and also 250 00:24:39,769 --> 00:24:47,059 Kinesis firehose, SNS, SQS, SES, elastic MapReduce and sagemaker jobs as well. 251 00:24:47,059 --> 00:24:52,370 Now this is not an exhaustive list of all of the services that are available 252 00:24:52,370 --> 00:24:58,519 to be used with the KMS but if you want to get the latest and complete list of 253 00:24:58,519 --> 00:25:04,669 all of the services just go to the Amazon website or the AWS website slash 254 00:25:04,669 --> 00:25:10,610 kms slash features. So that brings us to the end of the encryption lecture and 255 00:25:10,610 --> 00:25:15,649 I'm sure you fully understand it by now and I look forward to seeing you in the 256 00:25:15,649 --> 00:25:18,279 next one.