The course is part of these learning pathsSee 1 more
AWS CloudHSM is the name of Amazon’s original encryption key solution. HSM stands for Hardware Security Module and in the solution provided by AWS, it is a Safenet Luna appliance hosted at AWS. The appliance is single tenant and exclusive to each customer. AWS only manages the hardware and base operation but does not manage the keys or even have the ability to access the key management system within the HSM.
- Anyone that needs to know more about the Amazon Hardware Security Module branded CloudHSM that is provided as a dedicated hardware appliance.
- Anyone preparing for an Amazon Certifications as well as security officers that have a responsibility to ensure data is protected in an environment at Amazon Web Services.
- Due to the advanced nature of the CloudHSM topic, this course is not designed to be your first course about Amazon Web Services.
- It is a very good idea to complete the Key Management Service course if you are trying to make a decision between the two encryption offerings.
- To teach you the basics of AWS CloudHSM
- What it will cost to implement
- Comparison of KMS to AWS CloudHSM
- How to implement a key and encrypt data
- Which services can be used with CloudHSM
- Why you might use AWS CloudHSM
- Other uses for AWS CloudHSM
What you'll learn:
- CloudHSM Basics: An overview of CloudHSM basics, along with terminally, and use cases.
- What is CloudHSM: In this very detailed lesson, the presentation includes information about performance, scalability, availability, costs, and best practices.
- CloudHSM Operations: How to set-up the HSM controller as well as how to provision and de-provision HSM.
CloudHSM operations. In this lesson, I will cover how to install and set up the CloudHSM controller instance, plus adding the CloudHSM CLI to the controller instance, how to provision a CloudHSM, de-provisioning of CloudHSM, and what you can look for in CloudTrail for logging. Installing the controller instance. Actually, before you could provision a CloudHSM, you need to set up your VPC and set up a public and private subnet. I'm going to assume you have this knowledge. If not, go back and look over the lesson on VPC setup and EC2 setup. Deploy a Linux instance to the public subnet of your VPC using a unique SSH key that is only shared with the administrators of the CloudHSM appliances.
I recommend using an AWS Linux instance, but you can use just about any version of Linux to administer CloudHSM. This is just a basic instance so a t2.micro would typically work for most users. It keeps the cost to a minimum. If you like, you can stop the instance when administration is not necessary to save some on cost, but also to make it another step in the administration to manage the CloudHSM infrastructure.
Installing the CloudHSM CLI on the controller. Once the EC2 Linux is running, you will need to install CloudHSM CLI on the instance. The CloudHSM CLI is a Python application so if you don't already have Python 2.7 installed, you'll need to do that first. To check for Python, issue the following command, python2.7 -V. If Python 2.7 isn't installed, use the following command to install it on AWS Linux, sudo yum install python27.
You will also need PIP installed so first verify if PIP is installed with the following command, pip -V. If PIP isn't available, issue the following command to download PIP, curl -O https://bootstrap.pypa.io/get-pip.py.
Next, install PIP with the following command, sudo python2.7 get pip.py. So, now that Python 2.7 and PIP are installed, you can install CloudHSM CLI with the following command, sudo yum install aws-cloudhsm-cli. And finally, you can verify that CloudHSM is installed with the following command, cloudhsm version. Now that the CLI is installed, the CLI controller instance will need to be configured.
There are five steps to configure the CLI. Authentication, SSH connections, passwords, configuration files, client certificates. Authentication, the CLI for CloudHSM is linked to your AWS IAM access key and secret key. There are a few ways to pass your CloudHSM CLI. The recommended method is to set credentials in the configuration file and specify the --conf_file parameter with each CloudHSM CLI command. I will cover more on the configuration file in a few slides. Another way to pass the credentials is to use the boto config file which would look something like this. If you want all users to use the same credentials, you could save the file to the /etc directory as boto.config, but then every user has the same credentials and everyone shows up in the logs as the same user.
A better way is to save the configuration file in the user's home directory as .boto with unique user IDs on the controller. The final way to pass credentials with each command is as a parameter key. This is not recommended. The primary reason to not use this is it would be very easy to expose your credentials to the next user and then your IAM keys are now exposed to every privileged user that you are allowed access to your controller can perform AWS commands. SSH connection, as you might have already suspected, there is an SSH connection between the CloudHSM controller instance and the CloudHSM appliance.
Many of the commands require SSH in order to complete. To enable this capability, the recommended method is to add a few lines to your .ssh/config file. A sample would be something like this, Host <<hsm_ip>, User manager and IdentityFile. You can add several of these lines, one for each CloudHSM appliance. Just swap the hsm_ip for the appliance IP and the private SSH key pair for the private key pair file that matches the public key file used to provision your CloudHSM appliance.
There are ways to password protect the private key pair file, but that isn't supported. Thus, I would not recommend using password on the private key pair file. Passwords, each CloudHSM appliance has a password and it's very important you keep track of the passwords. There is a password worksheet that you can use to track passwords. I would recommend that you keep this file in a secure electronic location and keep a printout in a secure location. AWS provides a sample sheet which you can use or you can make your own.
The important point here is to keep track of the CloudHSM appliances and the passwords for each CloudHSM appliance. Configuration files, as I mentioned a few slides ago, there is a configuration file needed to connect between the controller instance and the CloudHSM appliance. Many of the CloudHSM commands require a passing of credentials. A sample configuration file looks like this, cloudhsmcli. You got an access key, secret key, the region, and then the hapg_arms and your so_password.
Client certificates, a certificate is a file that contains the Base64-encoded X.509 v3 PEM certificate. Each CloudHSM client has a private key and a cert that is used to authenticate with a CloudHSM partition or group. You create an HSM client with the create client command, passing the certificate to the command. You create an HSM client with the create client command and you pass the certificate in that command. You need to store the certificate in a specific directory depending on the OS. The directory is created when the SafeNet Luna software is installed and the certificate locations are listed as follows.
Now, you might be wondering how do you create a certificate. There are several ways to create a certificate. I'm going to cover two methods that you can use to create the certificate in the next slide. A SafeNet Luna Certificate is required to make these connections as I just mentioned. One method is with the Luna SA command. This method requires the Luna SA client software to be installed in your client and uses the vtl command. On a Linux client, you would just simply use the following listed command, sudo vtl createCert -n and then some client name. Or in Windows, it's vtl createCert -n client name.
The variable client name can be anything that is unique and does not contain any spaces or special characters. Then you must use this name with the tack tack label parameter in the create client command. You need to include the tack tack certificate filename parameter when you create client command. OpenSSL Toolkit is another method to create the public and private keys. There are several commands involved. To crate a private key, you can use the following command, openssl genrsa -out <luna_client_cert_dir>/<client_name>Key.pem2048. You need to generate a public key to pair with the private key. This following command will create the public key. Now note, OpenSSL will prompt for several fields. Most of these fields are information only. The only required field is the common name field that has to be the same as the client name. And just as you have to use this name in the label parameter with the create client command, to leave a field blank, just simply enter a period.
Again, you have to pass the client name.pem file with a certificate filename parameter in the client command. Provisioning, so now that you have the VPC, the subnets, and the controller instance installed, configured with the CLI, you can actually provision your first CloudHSM. You will need a few items before you provision the CloudHSM, the private subnet ID, the AWS ARN for the IAM role, the SSH public key, and a Syslog IP endpoint. That's mostly recommended, not required. Then you can issue the sample command, cloudhsm create-hsm --conf_file cloudhsm.conf --subnet-id --ssh-public-key --iam-role and syslog-ip endpoint.
Now, you can de-provision your CloudHSM of course. Before you can do that, you have to erase the keys. The best method to do this is to attempt to log in three times to the CloudHSM with an invalid password. This will cause the keys to be erased and now you can de-provision the appliance. Then you have to de-classify the logs with the following command, lunash:> syslog rotate. Then you can delete the logs with the following command, lunash:> syslog cleanup. Then you can issue the following command from your controller instance, cloud delete-hsm --hsm-arn <<arn>> --conf_file and the config_file. CloudTrail logging. Now, I've made the assumption that CloudTrail is enabled, which should be one of the very first tasks done right after you create your first IAM user ID. With CloudTrail enabled, all the API calls are logged.
The logged files are stored to S3 for as long as you like or for as long as the lifecycle policy allows for the objects to persist. The tricky part with CloudTrail is that all actions are logged and not in any particular order. The format for CloudTrail logs is JSON. You will need to parse the JSON files with some sort of tool to really get information from the CloudTrail logs. There are many tools available such as Splunk and Alert Logic just to name two. You can also use AWS as a service to generate reports based on CloudTrail logs. Analysis of CloudTrail logs is a bit beyond the concept of this course. Just know, if you need the information, it is there. And with the proper tools, you can get the information that has occurred with the CloudHSM API. So, in conclusion, you have learned what CloudHSM is and how it is similar to KMS but also different. Both provide encryption keys, only one is certified to third party standards, CloudHSM. CloudHSM only works in a VPC and requires private subnets to launch the appliance. A controller instance is required and additional software is necessary.
There is a cost per appliance and an hourly cost, but there are no keys or IO costs. It is up to you to monitor the scalability and high availability. There are specific use cases where CloudHSM is the best and right solution and can be the only solution that meets the requirements. So proceed with encryption. And remember, always protect your data. And finally, before I forget, I'd like to remind you to please provide us with your feedback so that I can improve this course and make it more useful to you to help you learn what you need to know about Amazon CloudHSM and be successful with Amazon Web Services.
Tom an active AWS Consultant creating and deploying AWS solutions for over five years. He has worked on numerous projects that involve everything from small lean startups on a tight budget to massive commercial Enterprises that have large-scale budgets with large-scale requirements that must be met even no matter the cost. Tom has worked for several of our United States government agencies taking the agencies to the cloud by migrating solutions from on-premise data centers to the AWS cloud in a secure solution while reducing their overall cost to operate and maintain the solution.
Personally Tom spends his available time riding his bicycle, sampling a good wine or two, enjoying a good meal and watching Formula One races.