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.  

For more information on how to configure these alerts and notifications, please see our existing course content covering Amazon CloudWatch. 

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.