1. Home
  2. Training Library
  3. Identity Management, Security, and Encryption (SAP-C02)

Monitoring & Logging

Contents

keyboard_tab
Course Introduction
1
Introduction
PREVIEW2m 40s
How IAM is used to securely manage access
3
IAM Features
PREVIEW10m 39s
Managing user identities with long term credentials in IAM
5
Creating IAM Users
PREVIEW5m 3s
Using IAM policies to define and manage permissions
12
Cross-account access
Key Management Service (KMS)
17
What is KMS?
PREVIEW8m 25s
18
Components of KMS
PREVIEW11m 6s
AWS Web Application Firewall
22
AWS Firewall Manager
26
Policies
12m 16s
AWS Shield
AWS Secrets Manager

The course is part of this learning path

Start course
Overview
Difficulty
Intermediate
Duration
5h 31m
Students
17
Description

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

Learning Objectives

  • 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
Transcript

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.

About the Author
Students
26892
Courses
22
Learning Paths
11

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.