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 this lecture which will look at how to monitor and log events from AWS CloudHSM.
As with most other AWS services, CloudHSM is able to push metric data to Amazon CloudWatch. For those unfamiliar with Amazon CloudWatch, it is a global service that has been designed to be your window into the health and operational performance of your applications and infrastructure.
It’s able to collate and present meaningful operational data from your resources allowing you to monitor and review their performance. This gives you the opportunity to take advantage of the insights that CloudWatch presents, which in turn can trigger automated responses or provide you with the opportunity and time to make manual operational changes and decisions to optimize your infrastructure if required.
The following are the current metrics that CloudWatch can record and monitor at the time of writing this course.
- HsmUnhealthy: This determines if a HSM is not performing as expected. When CloudHSM identifies a faulty HSM it is automatically replaced for you by the service.
- HsmTemperature: If the processor of the HSM reaches a temperature of 110 degrees centigrade then this system will automatically shut down.
- HsmKeysSessionOccupied: This will display the number of session keys that are in operation with a particular HSM.
- HsmKeysTokenOccupied: This will display the number of token keys that are in operation with a particular HSM.
- HsmSslCtxsOccupied: Displays the number of encrypted channels to the HSM.
- HsmSessionCount: Displays the number of open connections to the HSM.
- HsmUsersAvailable: This displays the number of additional users that can be created on the HSM.
- HsmUsersMax: This displays the maximum number of users that can be created on the HSM instance.
- InterfaceEth2OctetsInput: Calculates the total traffic sent to the HSM.
- InterfaceEth2OctetsOutput: Calculates the total traffic sent from the HSM.
Using CloudWatch you are able to configure alerts and notifications if any of these metrics reach a specific threshold allowing you to take corrective action.
When it comes to logging in CloudHSM there are a couple of different options to consider.
- Firstly, we have AWS CloudTrail to track and record all API calls relating to CloudHSM.
- We also have CloudWatch Logs for HSM Audit Logs.
So let’s take a look at both of these options in a bit more detail, starting with AWS CloudTrail.
AWS CloudTrail is a service that has a primary function to record and track all AWS API requests made. These API calls can be programmatic requests initiated from a user using an SDK, the AWS command-line interface, from within the AWS management console or even from a request made by another AWS service, such as 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 which is then stored on S3. Each API call represents a new event within the log file. CloudTrail also records and associates other 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.
Here is an excerpt from a CloudTrail log that captures this request of CreateHsm as the “eventName.”
For more information on AWS CloudTrail and how it is configured and a deeper understanding of the logs, please see our existing course here.
Let me now take a quick look at Audit logs. CloudHSM Audit logs are logs that are generated by your AWS CloudHSM Clients using the CloudHSM client daemon. These logs can be retrieved by viewing the file on the client, or by entering a simple command, it’s all dependent on the OS that the client is running. Use the following AWS resource to find the best method for your OS.
The Audit logs are an essential feature that 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, containing all commands that have been submitted from the client. This allows a full audit of all the actions and requests that have made changes to the HSM, such as the creation and deletion of clusters, users, and keys.
These audit logs are used by CloudHSM which are then sent to Amazon CloudWatch Logs, and this is where the permissions from the AWSServiceRoleForCloudHSM role I explained in a previous lecture come into effect. Much like the creation of these logs themselves, having them sent to CloudWatch is also mandatory which can’t be disabled.
When data is fed into Cloudwatch Logs you are able 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. This allows CloudWatch Logs to act as a central repository for real-time monitoring of log data.
For more information on Amazon CloudWatch Logs and how they are managed, please see our existing course here.
Interpreting the logs is a fairly straightforward process, the following shows an example of a log entry that shows the creation of a Key Pair.
Let me just run through the different fields quickly.
Time: This shows the date and time that the event occurred on the HSM using the UTC time zone.
Sequence No: This number increments by 1 for every new event stored within the same log stream.
Reboot counter: This is a A 32-bit persistent ordinal counter that is incremented when the HSM hardware is rebooted.
Command type(hex): This is used to define the command’s category.
Opcode: This shows which command was carried out, in this example the generation of a new key pair.
Session handle: A value to represent which session the command was carried out on.
Response: This determines if the command was successful or not.
Log type: This signifies which log type of the CloudHSM log that recorded the request.
The last 2 entries show the values of the Private and Public key handles that were created as a result of the command issued.
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.