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 provide an overview of the architecture of CloudHSM and the general steps of implementation to help you understand its deployment.
Let me start with the CloudHSM Cluster. When you implement CloudHSM, you will begin by creating a cluster. This cluster is simply a grouping of different HSMs which will act as a single unit when configured and deployed. Having multiple HSMs provides an element of high availability as you are able to select multiple different subnets, one from each availability zone that your VPC operates in, to deploy an HSM into. Any requests to your CloudHSM cluster are then automatically load-balanced between the HSMs in the cluster, and if one HSM fails, AWS will automatically deploy another one within your cluster. As a result, running a VPC is a prerequisite of implementing your cluster.
During the deployment of your HSMs, it’s actually an Elastic Network Interface (ENI) that is placed within the subnet that you select of your VPC. The HSM itself actually resides in a different AWS-owned VPC, and located in the same AZ as you select during its deployment. So it’s the ENI that is deployed in your VPC which acts as an interface between your network and the HSM residing in an AWS-owned VPC.
When you create the cluster, CloudHSM will do 2 things. Firstly, a new service-linked role will be created ‘AWSServiceRoleForCloudHSM’ which gives CloudHSM the permission to send log data to CloudWatch Logs log groups and log streams on your behalf. For those familiar with IAM policies, the policy looks as shown.
Secondly, CloudHSM will also create a new security group for the cluster (cloudhsm-cluster-clusterID-sg). This is an important security group as it controls which resources can communicate with the HSMs. The security group itself will allow both inbound and outbound connectivity over TCP ports 2223-2225, which enables each of your HSMs within your cluster to communicate with each other. When this security group is created by CloudHSM, no other resources are associated with it.
Once your cluster has been defined and created in the different subnets and availability zones that you have selected, it will have been provisioned in an ‘uninitialized state’. From this point, you can create your HSMs in each availability zone that you selected and ‘initialize’ the cluster. As this is a beginner course, I will not dive into this initialization process, however, if you would like a detailed technical understanding of how to perform this step, please refer to the AWS documentation here.
When your cluster is initialized you can then connect to your cluster HSM network interfaces, and one of the easiest ways to do this is via an EC2 instance provisioned in the same VPC. There are 2 steps which must be carried out for your EC2 instances to interact with the HSMs. Firstly, you must configure a security group. And secondly, you need to install the AWS CloudHSM client software on your instance.
So, firstly, the security group. You must add your instance to the cloudhsm-cluster-clusterID-sg security group. As we already know, this security group allows your HSMs to communicate with each other, but this same security group is also used to define which EC2 instances can communicate with your CloudHSMs, which must be manually added to the security group. If you want to connect to your CloudHSM using a Windows EC2 instance then you must add a rule to this SG using RDP with port 3389, if using a Linux instance then you must select SSH using port 22.
Next, you must install the client and command-line tools. To do this, connect to your instance that you added to the security group as I just mentioned.
If using a Linux instance, then you need to run a command, and this command will be different depending on the OS you are running. For a list of commands relating to the following OS’s please refer to this AWS resource.
Once you have installed the client and tools, you need to modify the client configuration to enable you to connect to your cluster. Firstly you need to copy your issuing certificate (created when you initialize your cluster) to /opt/cloudhsm/etc/customerCA.crt
You must also run the following command, replacing the red text with your HSMs IP address
sudo /opt/cloudhsm/bin/configure -a <IP address>
If you are using a Windows instance, then you will need to download the installation from here.
After running the MSI file, you will need to copy the self-signed issuing certificate to the following.
And then finally, you need to run the following command to configure the client software replacing the text in red with your own HSM details.
C:\Program Files\Amazon\CloudHSM\configure.exe -a <HSM IP address>
So let’s take a quick logical look at how the infrastructure would look like at this stage.
So as you can see, we have the customer VPC split across 3 different availability zones and subnets, each with an EC2 client containing the HSM client software and an HSM ENI. Each EC2 client can communicate with ANY of the HSM ENI across the different subnets within the cluster using the cloudhsm-cluster security group. These ENIs then communicate with the HSMs located in an AWS-owned VPC.
We also have the IAM role that has been created allowing HSM to send log data to CloudWatch Logs log groups and log streams on your behalf.
Once your infrastructure is in place and you have configured your CloudHSM connectivity, you simply need to activate your HSM cluster before use.
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.