Hello and welcome to this final lecture in this course where I shall provide a summary of the key points taken from each of the previous lectures. 

I started this course by explaining what exactly KMS was and a high-level overview of Symmetric and Asymmetric cryptography. In this lecture, we learned that unencrypted data is known as plaintext or cleartext, and data encryption is the mechanism in which information is altered, rendering the plaintext data unreadable, which is then known as ciphertext. To decrypt encrypted data, an encryption key is required to revert the ciphertext back into a readable format of plaintext. A key is simply a string of characters used in conjunction with the encryption algorithm. Symmetric cryptography uses a single key, which is used to both encrypt and also decrypt the data. Asymmetric cryptography uses two separate keys. One is used to encrypt the data, and another separate key is used to decrypt the data. One key is considered the private key and the other is considered the public key. KMS is used to store and generate encryption keys that can be used by other AWS services and applications to encrypt your data. AWS administrators do not have access to your keys within KMS and they cannot recover your keys for you should you delete them. KMS is used for encryption at rest only, and KMS works seamlessly with AWS CloudTrail to audit and track how your encryption keys are being used and by whom.

Following this lecture, I then moved on to talking about the different components of KMS, and the main points from this lecture were as follows. Customer Master Keys, CMKs, are the main key type within KMS. CMKs can generate, encrypt, and decrypt data encryption keys known as DEKs. Data encryption keys are used outside of the KMS service by other AWS services to perform encryption. And there are two types of Customer Master Keys, customer managed and AWS managed. Customer managed CMKs provide greater flexibility, such as being able to manage the key, including rotation, Key policy configuration, and enable and disable the key. Any CMKs created within KMS are protected by FIPS, validated cryptographic modules. Data encryption keys are created by the CMK and are used to encrypt your data of any size. The CMK can create a plaintext data encryption key and an encrypted version of the data encryption key, and both of these keys are then used to complete the encryption process. Plaintext data is encrypted with the plaintext data key and plaintext data keys are deleted from memory after use. Envelope encryption is the process of having one key encrypted by another key, and Key policies are a security feature that allows you to define who can use and access a particular key within KMS. Key policies are tied to CMKs as a resource-based policy, and Grants allow you to delegate a subset of your own access to a CMK for principals. 

Next I covered and explained the different methods of implementing permissions against your CMKs, and throughout this lecture, I explained that access to use CMKs is not possible through the use of IAM policies alone. To manage access to your CMKs, you must use a Key policy. And there are three different ways of granting access to the use of a CMK, Key policies, Key policies with IAM policies, and Key policies with Grants. Looking at Key policies, there are resource-based policies which are tied to your CMK, they are JSON-based, much like IAM policies are, the syntax follows the same as IAM policies. A Key policy is required for all CMKs, and KMS will configure the root user of the AWS account full access to the CMK which allows access to be given to the CMK by normal IAM policies for users and roles. Without the root account having full access in the Key policy, IAM can't be used to manage access for other users. Key Administrators and Users can also be configured within the Key policy. And Key Administrators can only administer the CMK and not use it to perform any encryption functions. Users of the CMK define which users should be allowed to perform any encryption using this CMK, and users are also able to use Grants. Using Key policies with IAM policies. Key policies can only be used with IAM policies if you have the following entry within the Key policy allowing the root full KMS access to the CMK. Using Key policies with Grants, you can also assign permissions using Grants alongside Key policies. Grants allow you to delegate your permissions to another AWS principal within your account, Grants need to be created using the AWS KMS APIs, Grants are attached to a CMK, much like Key policies are, and to create a Grant, you use the Create-Grant API. When creating the Grant, you need to specify the CMK identifier, the grantee principal to gain the permissions, and the required level of operations that the grantee can perform. Permissions can then be adopted programmatically by the grantee, and Grants generate a GrantToken and a GrantID. And GrantTokens allow the GrantID to perform the operations with immediate effect without having to wait for eventual consistency to complete. 

The final lecture focused on how to manage your keys and their lifecycle. This lecture highlighted the following points. Key rotation follows security best practices, and the simplest method of rotating CMKs in KMS is to use this automatic key rotation. And the automatic key rotation rotates keys every 365 days. During the automatic key rotation, the only part that changes of the CMK is the backing key, and the backing key is the cryptographic element that is used when the encryption process is taking place. All existing backing keys are retained during and after rotation, and rotating keys does not remove the threat of a security breach. Automatic key rotation is not possible with imported key material. CMKs in the state of disabled or pending deletion will not be rotated, and it's not possible to manage the key rotation for any AWS-managed CMKs. These are rotated every 1,095 days, or three years. Manual key rotation is the process of replacing the current CMK with a new CMK. For any applications that reference the CMK-ID of the oldie key, you will then need to update and point them to the new CMK-ID following a manual rotation or update the Alias name of the key with the new CMK-ID Target. Key material is the backing key, the component that completes and implements the encryption and decryption process on behalf of the CMK itself. It is possible to create CMKs without any key material at all, allowing you to import your own, and the process for importing your own key material follows four main points. Creating your CMK with no key material, download a wrapping key, which is also referred to as a public key, and an import token, and these will remain active for 24 hours, encrypt your key material using the wrapping key, and then import your key material that is now encrypted into KMS and associate it with your currently empty CMK. Deleting a key can have significant impact against your data if there are services that are still using it without your knowledge, and KMS enforces a scheduled deletion process, which can range from seven to 30 days to help manage and identify if the key is still in use. Keys scheduled for deletion can't be used to perform encryption or decryption actions, neither can the backing keys for the CMK be rotated. By analyzing AWS CloudTrail event logs, you can look for events relating to the use of the CMK, such as an encrypt action against the CMK-ID. AWS also recommends that you set up a CloudWatch alarm to identify anyone trying to use this key to perform any encryption or decryption requests. And you should consider disabling a key instead of deleting a key, as this will still take the key out of operation, however, you can reinstate it again at any point should you need it. 

That now brings me to the end of this lecture and to the end of this course. You should now have a greater understanding of the AWS Key Management Service, and through the use of different keys, how it can provide a level of encryption of your data across a range of AWS services. 

If you have any feedback on this course, positive or negative, please do contact us at support@cloudacademy.com. Your feedback is greatly appreciated. 

Thank you for your time and good luck with your continued learning of cloud computing. Thank you.