HSM stands for Hardware Security Module, but what is a hardware security module? It’s a physical tamper-resistant hardware appliance that is used to protect and safeguard cryptographic material and encryption keys.
The AWS CloudHSM service provides HSMs that are validated to Federal Information Processing Standards (FIPS) 140-2 Level 3, which is often required if you are going to be using your CloudHSM for document signing or if you intend to operate a public certificate authority for SSL certificates.
The objectives of this course are to explain:
- What AWS CloudHSM is and does
- The architecture of CloudHSM and its implementation
- Access Control of your HSM Cluster
- How to use CloudHSM as a custom key store in KMS, the Key Management Service
- Monitoring and Logging
This course is intended for anyone who is:
- Responsible for protecting data stored within AWS
- Looking to utilize a managed service to help perform cryptographic operations
- Preparing for an AWS certification that requires you to have knowledge of securing data
To get the most out of this course, you should have a basic awareness of the fundamentals of AWS and some of its core services, such as VPC architecture. Some basic cryptography knowledge would also be beneficial, but not essential.
Hello and welcome to the final lecture of this course where I will summarize the key points taken from each of the previous lectures.
I started the course by explaining what AWS CloudHSM is and in this lecture we learnt that:
- CloudHSM is an enterprise-class service used to store and secure encryption key management which can be used as a root of trust for an enterprise when it comes to data protection allowing you to deploy secure and compliant workloads within AWS.
- HSM stands for Hardware Security Module which is a physical tamper-resistant hardware appliance used to protect and safeguard cryptographic material and encryption keys
- AWS CloudHSM is validated to FIPS 140-2 Level 3
- CloudHSMs are NOT multi-tenant devices
- It can be used to
- Create, store and manage cryptographic keys
- Manage cryptographic hash functions
- Perform cryptographic data signing and signature verification
- Generate cryptographically secure random data
- Asymmetric encryption involves two separate keys. One is used to encrypt the data and a separate key is used to decrypt the data.
- Symmetric encryption uses a single key to both encrypt and also decrypt the data.
- The Key Management Service, known as KMS is another AWS encryption service
- KMS HSMs are managed by AWS
- CloudHSMs allow the customer to manage the HSM
In the next lecture I look at the architecture and implementation of the AWS CloudHSM service where I explained the following points:
- An HSM cluster is a grouping of different HSMs which will act as a single unit when configured and deployed.
- HSMs must be deployed in a VPC
- Multiple HSMs provides an element of high availability
- If one HSM fails, AWS will automatically deploy another one within your cluster
- An Elastic Network Interface (ENI) is placed within each subnet of your deployment
- The HSM itself actually resides in a different AWS owned VPC located in the same AZ
- The ENI acts as an interface between your network and the HSM residing in an AWS-owned VPC.
- When you create a cluster, CloudHSM will create a service-linked role allowing permission to send log data to CloudWatch
- It will also create a security group to control which resources can communicate with the cluster
- Your cluster will need to be initialized before you can connect to the ENIs
- You need to add EC2 instances to the clusters security group and install and configure the AWS CloudHSM client to enable communication between the 2 resources
- When all resources are in place, you can activate your cluster
I then shifted focus over to access control to understand how CloudHSM managed security from that perspective. In this lecture we learnt that:
- CloudHSM has its own users and security held on the HSMs themselves utilizing a role-based access control method.
- Different types of users have different levels of controls
- There are 4 user types, these being
- Precrypto Office (PRECO)
- Crypto Office (CO)
- Crypto User (CU)
- Appliance User (AU)
- The Precrypto Office (PRECO) user is a temporary user with read-only access to the cluster, used to activate your cluster. As a part of this process, you must change the password of the user which will change the user type to the Crypto Office (CO) user.
- The Crypto Office User contains a more advanced permission set than that of the PRECO user as has the ability to carry out user management tasks and administrative level functions
- The Crypto User (CU) is used predominantly to perform the cryptographic operations and key management functions
- The Appliance User (AU) performs cloning and synchronization across your cluster and it exists on all HSMs.
- The HSM are designed with protection against brute force login attacks
I then took a quick look at how AWS KMS has a level of integration with CloudHSM, and during this lecture I covered the following:
- KMS allows you to create custom key stores.
- A key store is used to store and protect your cryptographic keys
- KMS Default key stores are managed by KMS and are stored on HSMs managed by AWS
- Custom key stores allow you to leverage the power of 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.
- 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
- Each HSM Cluster can only be associated with one custom key store for KMS
- KMS and the Cluster must be in the same region
- You must upload the trust anchor certificate for the cluster to KMS to create a custom key store
- You must also create a dedicated Crypto User called kmsuser
In the final lecture, I covered an overview of logging and monitoring, the key takeaways from this lecture were:
- CloudHSM is able to push metric data to Amazon CloudWatch.
- CloudWatch can record and monitor a number of different metrics relating to CloudHSM to determine its health, connection details, user capacity and more
- Using CloudWatch allows you to be alerted and notified if any configured metric thresholds are met
- AWS CloudTrail can track and record all API calls relating to CloudHSM
- When an API request is initiated, such as a ‘CreateHsm’ call, AWS CloudTrail captures the request as an event and records this event within a log file
- Each API call represents a new event within the log file.
- CloudTrail records and associates identifying metadata with all the events. For example, the identity of the caller, the timestamp of when the request was initiated and the source IP address.
- CloudWatch Logs can record your HSM Audit Logs
- CloudHSM Audit logs are logs that are generated by your AWS CloudHSM Clients using the CloudHSM client daemon.
- Audit logs can’t be disabled or turned off, and they contain records of requests that have been initiated using the AWS CloudHSM command lines tools and software libraries.
- Audit logs used by CloudHSM are sent to Amazon CloudWatch Logs
- Cloudwatch Logs allow to monitor the logstream in real time and set up metric filters to search for specific events that you need to be alerted on or respond to
That now brings me to the end of this lecture and to the end of this course, and so you should now have a greater understanding of AWS CloudHSM and how it can be configured and deployed within your VPC.
Feedback on our courses here at Cloud Academy is valuable to both us as trainers and any students looking to take the same course in the future. If you have any feedback, positive or negative, it would be greatly appreciated if you could contact firstname.lastname@example.org.
Thank you for your time and good luck with your continued learning of cloud computing. Thank you.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.