‫Okay so now let's talk about encryption.
‫And we've seen encryption a little bit in this course
‫but now lets try to formalize what it means.
‫So there are two types of encryptions happening within AWS.
‫You have encryption at rest
‫and encrypted in transit.
‫So data at rest
‫means that the data is stored or archived
‫on a physical device.
‫So that could be a hard drive,
‫or like a hard disc.
‫It could be an RDS instance because it's a database.
‫It could be an S3 Glacier Deep Archive,
‫or any kind of S3 buckets actually,
‫these kinds of things, right.
‫It's at rest because it's not moving,
‫it's written somewhere.
‫So for example,
‫we can have encrypted data at rest on an EFS network drive
‫or we can have encrypted data at rest on Amazon S3.
‫But there's a second kind of encryption
‫which is in transit.
‫In transit means that encryption,
‫while the data is being moved from one place to another.
‫And so that means in motion.
‫And so, for example, it says whenever you transfer data
‫from your on premises data centers to AWS,
‫or when you move from between an EC2 instance
‫and a DynamoDB table for example
‫because it's writing data or retrieving data
‫or in this example of there from EFS to Amazon S3.
‫So in transit means that
‫the data is transferred on the network.
‫And so there are two kinds of encryption,
‫there's encryption at rest and encryption in transit.
‫They use different techniques, okay.
‫But ideally, because we want our data to be encrypted
‫and protected all the time.
‫We want to encrypt data in both states to protect it.
‫For this, we leveraged something called encryption keys
‫and I'm going to stop right there
‫because you don't need to know
‫how the encryption keys work at the CCP level.
‫But just so you know that's using these encryption keys
‫we can encrypt the data.
‫That means that someone who does not have access
‫to these encryption keys,
‫even if they had access to our data
‫they could not decrypt it and they could not read it,
‫and therefore it's protected.
‫So the encryption service at the center of AWS
‫is called KMS, key management service.
‫So anytime you hear encryption for a service
‫it's most likely going to be KMS.
‫And so with KMS we don't have access to the keys.
‫AWS will manage the keys for us
‫and we just define who can access these keys.
‫So there is an opt-in for encryption.
‫So for example, for EBS volumes
‫you can choose to encrypt them with KMS.
‫For the S3 buckets,
‫you also have the option
‫to do service side encryption of objects.
‫For Redshift databases,
‫you can do the encryption of your database.
‫For RDS the same thing.
‫For EFS you can encrypt your files.
‫And there's also some services
‫that have encryption automatically happen no matter what,
‫for example CloudTrail Logs, S3 Glacier
‫and Storage Gateway.
‫The second service used to perform encryption
‫is called cloud HSM.
‫So with KMS,
‫it is AWS who manages the software for encryption.
‫But with CloudHSM,
‫AWS will just provision to us the encryption hardware
‫but we are managing the keys ourselves.
‫So a dedicated hardware for us,
‫it's called an HSM module,
‫so hardware security module
‫and it looks like this.
‫And so with this aspect
‫AWS will give us the hardware and their infrastructure
‫but we manage our own encryption keys entirely, not AWS.
‫And to make sure that no one can to have our keys
‫by sneaking into the data center of AWS,
‫the HSM device is tamper resistant.
‫That mean if someone try to tamper it,
‫it will fail.
‫And there is FIPS 140-2 Level 3 compliance
‫which is a security standard.
‫So CloudHSM, how does that work?
‫Well, AWS will manage the hardware.
‫So they will manage the device I just showed you.
‫But we use the CloudHSM service
‫with the CloudHSM client to manage the keys
‫and obviously the connection between our clients
‫and CloudHSM is encrypted
‫so that we can manage the keys securely.
‫So what types of customer master keys exist in AWS.
‫Customers master key by the way is CMK.
‫So don't
‫confuse it for something called
‫customer managed CMK
‫which means customer managed customer master keys
‫which is the kind of keys we've been using in AWS so far.
‫So this customer managed CMK
‫are the keys that we create, manage
‫and use ourselves, AWS users.
‫And we can create them, enable them or disable them.
‫We can define a rotation policy for these keys,
‫for example a new key generated every year
‫while the old keys of course preserved.
‫And we can bring our own key.
‫They are different from AWS managed CMK,
‫which are created, managed and used
‫on the customer's behalf by AWS.
‫So we don't have access to them.
‫They're used specifically and only by AWS services.
‫So they will have the form of
‫AWS/S3, AWS/ebs and redshift and so on.
‫The third type of key is AWS owned CMK
‫which are a collection of CMK that service owns and manages
‫to use across multiple accounts.
‫And AWS can use those to protect resources in your accounts
‫but we don't have access to even view these keys.
‫And the last type is CloudHSM keys.
‫It's called the custom key store.
‫In this case, the keys are generated
‫directly from your own CloudHSM hardware device.
‫And all of the cryptographic operations
‫do not happen within KMS,
‫they happen directly within the cloud HSM cluster
‫which may be a security requirement
‫for some companies.
‫So that's it.
‫We'll have a good look at the hands-on
‫to see how all these work.
‫So I will see you in the next lecture.