You may now be thinking: CloudHSM sounds like the cherry-pick for cryptography, so why would I want to use anything else?
First, you need to consider whether you have an actual use case for AWS CloudHSM. For instance, does your corporate security require that you store your keys on HSMs fully under your control? Or are you looking to offload Secure Sockets Layer (SSL)/TLS processing from some of your web servers to an HSM? If the answer to these questions is no, then you should not use AWS CloudHSM, simply because you don’t have a need for it.
The second consideration to make concerns costs. When using AWS CloudHSM, you have to set up a cluster composed of two or more HSMs for resiliency purposes. This cluster bears a non-indifferent run cost associated with it (slightly over 2,000 US dollars (USD) per month, at the time of writing this).
The third consideration is that AWS KMS, as with any other AWS service, has some associated quotas, among which are the number of concurrent cryptographic operations that can be performed within a specific AWS Region at any one time in a given AWS account. When you use keys managed by KMS, the default value for the number of operations is in the thousands or even tens of thousands of operations per second, depending on the AWS Region where you operate. When you use a custom key store with KMS in combination with AWS CloudHSM, the default value for that quota is somehow lower (1,800 operations per second at the time of writing). On top of that, differently from other KMS quotas, that specific quota cannot be increased in the case of a custom key store. Thus, if you use a custom key store and need to process a very large number of concurrent cryptographic operations per second, you might be throttled by KMS at some point. So, another account in the same Region or the same account in another AWS Region is entitled to the same quota managed separately.
The vast majority of KMS users out there who don’t use custom key stores remain of course unaffected by this non-adjustable quota. That said, if you reach the specific quota for your KMS setup, your requests for cryptographic operations will be throttled by KMS and you would need to handle that situation by finding a means of reducing your request rates.
Regardless of the approach you select, what really matters in the end is that you encrypt your data. There is no excuse not to do so since AWS offers you all the tools to do so.
Now, how can you make sure that all your data is encrypted at rest in your AWS environment? Some services such as Amazon S3 or Amazon EC2 allow you to enforce data encryption by default. For the services that don’t, and also to make sure that part of your data has not been left unencrypted, you should verify that encryption at rest is used systematically on storage services such as Amazon S3, Amazon RDS, or Amazon Elastic Block Store (EBS) volumes.
For that purpose, it is recommended to leverage AWS Config managed rules to check that your data is indeed encrypted at rest across the various AWS storage services, but we will talk a bit more about AWS Config in the Detecting incidents section of this chapter.
Beyond encryption, you also want to take some additional measures to protect your data, as discussed in the subsections below.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
