1 00:00:01,810 --> 00:00:04,100 ‫Okay so now let's talk about encryption. 2 00:00:04,100 --> 00:00:06,050 ‫And we've seen encryption a little bit in this course 3 00:00:06,050 --> 00:00:08,010 ‫but now lets try to formalize what it means. 4 00:00:08,010 --> 00:00:11,070 ‫So there are two types of encryptions happening within AWS. 5 00:00:11,070 --> 00:00:12,620 ‫You have encryption at rest 6 00:00:12,620 --> 00:00:14,290 ‫and encrypted in transit. 7 00:00:14,290 --> 00:00:15,500 ‫So data at rest 8 00:00:15,500 --> 00:00:17,910 ‫means that the data is stored or archived 9 00:00:17,910 --> 00:00:19,790 ‫on a physical device. 10 00:00:19,790 --> 00:00:21,380 ‫So that could be a hard drive, 11 00:00:21,380 --> 00:00:22,590 ‫or like a hard disc. 12 00:00:22,590 --> 00:00:25,510 ‫It could be an RDS instance because it's a database. 13 00:00:25,510 --> 00:00:27,980 ‫It could be an S3 Glacier Deep Archive, 14 00:00:27,980 --> 00:00:29,830 ‫or any kind of S3 buckets actually, 15 00:00:29,830 --> 00:00:30,690 ‫these kinds of things, right. 16 00:00:30,690 --> 00:00:32,630 ‫It's at rest because it's not moving, 17 00:00:32,630 --> 00:00:34,500 ‫it's written somewhere. 18 00:00:34,500 --> 00:00:35,470 ‫So for example, 19 00:00:35,470 --> 00:00:38,830 ‫we can have encrypted data at rest on an EFS network drive 20 00:00:38,830 --> 00:00:42,820 ‫or we can have encrypted data at rest on Amazon S3. 21 00:00:42,820 --> 00:00:44,720 ‫But there's a second kind of encryption 22 00:00:44,720 --> 00:00:46,230 ‫which is in transit. 23 00:00:46,230 --> 00:00:47,930 ‫In transit means that encryption, 24 00:00:47,930 --> 00:00:51,980 ‫while the data is being moved from one place to another. 25 00:00:51,980 --> 00:00:54,400 ‫And so that means in motion. 26 00:00:54,400 --> 00:00:57,400 ‫And so, for example, it says whenever you transfer data 27 00:00:57,400 --> 00:01:01,340 ‫from your on premises data centers to AWS, 28 00:01:01,340 --> 00:01:04,210 ‫or when you move from between an EC2 instance 29 00:01:04,210 --> 00:01:05,580 ‫and a DynamoDB table for example 30 00:01:05,580 --> 00:01:07,580 ‫because it's writing data or retrieving data 31 00:01:07,580 --> 00:01:11,920 ‫or in this example of there from EFS to Amazon S3. 32 00:01:11,920 --> 00:01:14,040 ‫So in transit means that 33 00:01:14,040 --> 00:01:17,040 ‫the data is transferred on the network. 34 00:01:17,040 --> 00:01:19,070 ‫And so there are two kinds of encryption, 35 00:01:19,070 --> 00:01:21,260 ‫there's encryption at rest and encryption in transit. 36 00:01:21,260 --> 00:01:22,970 ‫They use different techniques, okay. 37 00:01:22,970 --> 00:01:25,940 ‫But ideally, because we want our data to be encrypted 38 00:01:25,940 --> 00:01:27,160 ‫and protected all the time. 39 00:01:27,160 --> 00:01:30,260 ‫We want to encrypt data in both states to protect it. 40 00:01:30,260 --> 00:01:33,210 ‫For this, we leveraged something called encryption keys 41 00:01:33,210 --> 00:01:34,530 ‫and I'm going to stop right there 42 00:01:34,530 --> 00:01:35,363 ‫because you don't need to know 43 00:01:35,363 --> 00:01:37,950 ‫how the encryption keys work at the CCP level. 44 00:01:37,950 --> 00:01:40,630 ‫But just so you know that's using these encryption keys 45 00:01:40,630 --> 00:01:41,980 ‫we can encrypt the data. 46 00:01:41,980 --> 00:01:44,280 ‫That means that someone who does not have access 47 00:01:44,280 --> 00:01:45,800 ‫to these encryption keys, 48 00:01:45,800 --> 00:01:47,390 ‫even if they had access to our data 49 00:01:47,390 --> 00:01:49,360 ‫they could not decrypt it and they could not read it, 50 00:01:49,360 --> 00:01:51,630 ‫and therefore it's protected. 51 00:01:51,630 --> 00:01:54,410 ‫So the encryption service at the center of AWS 52 00:01:54,410 --> 00:01:57,390 ‫is called KMS, key management service. 53 00:01:57,390 --> 00:01:59,450 ‫So anytime you hear encryption for a service 54 00:01:59,450 --> 00:02:01,340 ‫it's most likely going to be KMS. 55 00:02:01,340 --> 00:02:04,710 ‫And so with KMS we don't have access to the keys. 56 00:02:04,710 --> 00:02:07,180 ‫AWS will manage the keys for us 57 00:02:07,180 --> 00:02:09,600 ‫and we just define who can access these keys. 58 00:02:09,600 --> 00:02:11,690 ‫So there is an opt-in for encryption. 59 00:02:11,690 --> 00:02:13,620 ‫So for example, for EBS volumes 60 00:02:13,620 --> 00:02:16,700 ‫you can choose to encrypt them with KMS. 61 00:02:16,700 --> 00:02:17,533 ‫For the S3 buckets, 62 00:02:17,533 --> 00:02:18,366 ‫you also have the option 63 00:02:18,366 --> 00:02:20,320 ‫to do service side encryption of objects. 64 00:02:20,320 --> 00:02:21,510 ‫For Redshift databases, 65 00:02:21,510 --> 00:02:23,330 ‫you can do the encryption of your database. 66 00:02:23,330 --> 00:02:25,090 ‫For RDS the same thing. 67 00:02:25,090 --> 00:02:27,253 ‫For EFS you can encrypt your files. 68 00:02:27,253 --> 00:02:29,360 ‫And there's also some services 69 00:02:29,360 --> 00:02:32,240 ‫that have encryption automatically happen no matter what, 70 00:02:32,240 --> 00:02:35,130 ‫for example CloudTrail Logs, S3 Glacier 71 00:02:35,130 --> 00:02:36,513 ‫and Storage Gateway. 72 00:02:37,370 --> 00:02:39,630 ‫The second service used to perform encryption 73 00:02:39,630 --> 00:02:41,370 ‫is called cloud HSM. 74 00:02:41,370 --> 00:02:42,530 ‫So with KMS, 75 00:02:42,530 --> 00:02:45,770 ‫it is AWS who manages the software for encryption. 76 00:02:45,770 --> 00:02:47,378 ‫But with CloudHSM, 77 00:02:47,378 --> 00:02:51,410 ‫AWS will just provision to us the encryption hardware 78 00:02:51,410 --> 00:02:54,800 ‫but we are managing the keys ourselves. 79 00:02:54,800 --> 00:02:56,790 ‫So a dedicated hardware for us, 80 00:02:56,790 --> 00:02:57,970 ‫it's called an HSM module, 81 00:02:57,970 --> 00:02:59,850 ‫so hardware security module 82 00:02:59,850 --> 00:03:01,470 ‫and it looks like this. 83 00:03:01,470 --> 00:03:03,862 ‫And so with this aspect 84 00:03:03,862 --> 00:03:06,890 ‫AWS will give us the hardware and their infrastructure 85 00:03:06,890 --> 00:03:11,190 ‫but we manage our own encryption keys entirely, not AWS. 86 00:03:11,190 --> 00:03:14,010 ‫And to make sure that no one can to have our keys 87 00:03:14,010 --> 00:03:17,010 ‫by sneaking into the data center of AWS, 88 00:03:17,010 --> 00:03:19,210 ‫the HSM device is tamper resistant. 89 00:03:19,210 --> 00:03:20,510 ‫That mean if someone try to tamper it, 90 00:03:20,510 --> 00:03:21,740 ‫it will fail. 91 00:03:21,740 --> 00:03:25,620 ‫And there is FIPS 140-2 Level 3 compliance 92 00:03:25,620 --> 00:03:28,350 ‫which is a security standard. 93 00:03:28,350 --> 00:03:30,300 ‫So CloudHSM, how does that work? 94 00:03:30,300 --> 00:03:32,140 ‫Well, AWS will manage the hardware. 95 00:03:32,140 --> 00:03:34,040 ‫So they will manage the device I just showed you. 96 00:03:34,040 --> 00:03:36,190 ‫But we use the CloudHSM service 97 00:03:36,190 --> 00:03:39,050 ‫with the CloudHSM client to manage the keys 98 00:03:39,050 --> 00:03:41,543 ‫and obviously the connection between our clients 99 00:03:41,543 --> 00:03:43,770 ‫and CloudHSM is encrypted 100 00:03:43,770 --> 00:03:46,470 ‫so that we can manage the keys securely. 101 00:03:46,470 --> 00:03:49,990 ‫So what types of customer master keys exist in AWS. 102 00:03:49,990 --> 00:03:52,980 ‫Customers master key by the way is CMK. 103 00:03:52,980 --> 00:03:55,230 ‫So don't 104 00:03:56,240 --> 00:03:57,770 ‫confuse it for something called 105 00:03:57,770 --> 00:03:59,660 ‫customer managed CMK 106 00:03:59,660 --> 00:04:02,430 ‫which means customer managed customer master keys 107 00:04:02,430 --> 00:04:06,580 ‫which is the kind of keys we've been using in AWS so far. 108 00:04:06,580 --> 00:04:09,830 ‫So this customer managed CMK 109 00:04:09,830 --> 00:04:11,850 ‫are the keys that we create, manage 110 00:04:11,850 --> 00:04:14,150 ‫and use ourselves, AWS users. 111 00:04:14,150 --> 00:04:17,470 ‫And we can create them, enable them or disable them. 112 00:04:17,470 --> 00:04:20,700 ‫We can define a rotation policy for these keys, 113 00:04:20,700 --> 00:04:23,090 ‫for example a new key generated every year 114 00:04:23,090 --> 00:04:25,350 ‫while the old keys of course preserved. 115 00:04:25,350 --> 00:04:28,250 ‫And we can bring our own key. 116 00:04:28,250 --> 00:04:31,999 ‫They are different from AWS managed CMK, 117 00:04:31,999 --> 00:04:34,740 ‫which are created, managed and used 118 00:04:34,740 --> 00:04:36,680 ‫on the customer's behalf by AWS. 119 00:04:36,680 --> 00:04:38,390 ‫So we don't have access to them. 120 00:04:38,390 --> 00:04:41,810 ‫They're used specifically and only by AWS services. 121 00:04:41,810 --> 00:04:43,698 ‫So they will have the form of 122 00:04:43,698 --> 00:04:48,120 ‫AWS/S3, AWS/ebs and redshift and so on. 123 00:04:48,120 --> 00:04:51,470 ‫The third type of key is AWS owned CMK 124 00:04:51,470 --> 00:04:55,120 ‫which are a collection of CMK that service owns and manages 125 00:04:55,120 --> 00:04:57,450 ‫to use across multiple accounts. 126 00:04:57,450 --> 00:05:00,820 ‫And AWS can use those to protect resources in your accounts 127 00:05:00,820 --> 00:05:04,700 ‫but we don't have access to even view these keys. 128 00:05:04,700 --> 00:05:07,300 ‫And the last type is CloudHSM keys. 129 00:05:07,300 --> 00:05:08,880 ‫It's called the custom key store. 130 00:05:08,880 --> 00:05:10,740 ‫In this case, the keys are generated 131 00:05:10,740 --> 00:05:13,770 ‫directly from your own CloudHSM hardware device. 132 00:05:13,770 --> 00:05:17,280 ‫And all of the cryptographic operations 133 00:05:17,280 --> 00:05:19,060 ‫do not happen within KMS, 134 00:05:19,060 --> 00:05:21,660 ‫they happen directly within the cloud HSM cluster 135 00:05:21,660 --> 00:05:24,520 ‫which may be a security requirement 136 00:05:24,520 --> 00:05:25,750 ‫for some companies. 137 00:05:25,750 --> 00:05:26,660 ‫So that's it. 138 00:05:26,660 --> 00:05:28,280 ‫We'll have a good look at the hands-on 139 00:05:28,280 --> 00:05:29,910 ‫to see how all these work. 140 00:05:29,910 --> 00:05:31,810 ‫So I will see you in the next lecture.