How IAM is used to securely manage access
Managing user identities with long term credentials in IAM
Managing access using IAM user groups & roles
Using IAM policies to define and manage permissions
Key Management Service (KMS)
AWS Web Application Firewall
AWS Firewall Manager
Using AWS Network Firewalls to Secure Your VPCs
AWS Security Hub Overview
Other AWS Security Services
AWS Secrets Manager
The course is part of this learning path
This section of the AWS Certified Solutions Architect - Professional learning path introduces the key identity management, security, and encryption services within AWS relevant to the AWS Certified Solutions Architect - Professional exam. Core to security is AWS Identity & Access Management commonly referred to as IAM. This service manages identities and their permissions that can access your AWS resources, so understanding how this service works and what you can do with it will help you to maintain a secure AWS environment. IAM is an important service in ensuring your resources are secure.
Want more? Try a Lab Playground or do a Lab Challenge!
- Learn about identity and access management on AWS, including users, groups & roles, IAM policies, MFA, identity federation, and cross-account access
- Learn the fundamentals of AWS Web Application Firewall (WAF), including what it is, when to use it, how it works, and why use it
- Understand how to configure and monitor AWS WAF
- Learn about AWS Firewall Manager and its components
- Learn how to configure AWS Shield
- Learn the fundamentals of AWS Cognito
Hello and welcome to this lecture where I want to explain the interaction between the two AWS encryption services, AWS Key Management Service and AWS CloudHSM.
When working with AWS KMS, you are able to create custom key stores. A key store is effectively a storage location which can store and protect your cryptographic keys used to encrypt and decrypt your data in AWS. When working with AWS KMS, the default key stores are managed by KMS and are stored on HSMs managed by AWS, and so as a user of KMS you have no control over these HSMs which underpin the cryptographic storage of KMS.
However, if you have specific compliance controls that you need to adhere to, where you might require a greater level of control of your key stores. By creating a custom key store you can leverage the power of your CloudHSM cluster which you have full management of, as explained in the previous lecture.
A benefit of AWS KMS is that it has a wide range of integrations with other AWS services, allowing you to perform server-side encryption often at the click of a button with minimal configuration required. This makes it a great choice when protecting your data.
KMS creates and stores Customer Master Keys (CMKs) which is the main key type in KMS and there are two types of customer master keys. Firstly, those which are managed and created by you and I, as customers of AWS, which can be created by using KMS and then those that are managed and created by AWS themselves.
CMKs that are generated and created by us as customers, rather than AWS, provide the ability to implement greater flexibility, such as being able to manage the key, including rotation, governing access and key policy configuration, along with being able to both enable and disable the key when it is no longer required.
So, if within your organisation you want to use the seamless integration of KMS with many AWS services, but require the security and compliance of maintaining your own key material outside of KMS then you can create a custom key store backed by your CloudHSM cluster.
The custom key store is a resource managed from within KMS, but allows you to store your key material within your managed HSMs of your CloudHSM cluster. This allows you to use the key material located within your HSM cluster to create the CMKs that KMS uses to implement encryption across different AWS services. CMKs created from your custom key store are 256-bit, non-exportable AES symmetric keys that never leave the HSM unencrypted. All cryptographic operations made with the CMK happens within the HSM cluster
So as you can see from this diagram, AWS services use CMKs managed by KMS using existing integration, but your CMKs can either come from the default key store created and stored by HSMs managed by AWS, or by using the custom key store which are managed by you allowing you to control access to your key material used within the CMKs.
Bear in mind that each HSM Cluster can only be associated with one custom key store for KMS, and both the cluster and the KMS creation of the custom key store must be within the same region. KMS is a regional service, and keys can’t be used between multiple regions. If you want to create CMKs within your custom key store, then your cluster must have at least 2 HSMs activated in different availability zones.
As a part of the process to create your custom key store you must upload the trust anchor certificate for the cluster to KMS, and this certificate is generated when the cluster is first initialized. Also, you must create a dedicated Crypto User called kmsuser (without 2 factor authentication) and generate a password, which you then provide to KMS. Going forward KMS will use this kmsuser CU to perform its operations in addition to rotating the password every time the user is authenticated.
Danny has over 20 years of IT experience as a software developer, cloud engineer, and technical trainer. After attending a conference on cloud computing in 2009, he knew he wanted to build his career around what was still a very new, emerging technology at the time — and share this transformational knowledge with others. He has spoken to IT professional audiences at local, regional, and national user groups and conferences. He has delivered in-person classroom and virtual training, interactive webinars, and authored video training courses covering many different technologies, including Amazon Web Services. He currently has six active AWS certifications, including certifications at the Professional and Specialty level.