Protecting Data at Rest – Determining Security Requirements and Controls – SAP-C02 Study Guide

Protecting Data at Rest

The first task is to protect the data at rest, that is, where it is stored. AWS best practices recommend that you encrypt the data—no exception. Your data must be encrypted, whether you decide to use object storage, file storage, block storage, databases, or anything else. Many AWS services (storage, compute, and others) integrate with AWS Key Management Service (KMS), which they use for cryptographic operations (such as generating data keys, data encryption, and decryption). A notable exception is Amazon S3, which not only uses KMS for encryption but, for historical reasons, also has its own built-in server-side encryption mechanism (SSE-S3).

Data Encryption

The following are the main reasons why you should always use encryption at rest:

  • The risk, when failing to encrypt data, of sensitive information leaking or falling into the wrong hands bears a much higher cost than the cost of encrypting all data, sensitive or not.
  • AWS storage services support data encryption at rest out of the box.
  • There is no noticeable penalty (in terms of compute) for encrypting your data. Computer chips have long undergone significant improvements over the years and can now deal with cryptographic operations very efficiently.

The following subsections discuss the various options for encrypting the data, starting with AWS KMS and AWS CloudHSM. AWS KMS integrates seamlessly with many AWS services, so it is your go-to service to take a standardized approach on data encryption in your AWS environment.

AWS KMS and AWS CloudHSM

AWS KMS relies on a fleet of hardware security modules (HSMs) to store cryptographic material—that is, the keys being used to perform cryptographic operations such as encrypting and decrypting your data. Those HSMs consist of specific tamper-proof security hardware validated under the US NIST Federal Information Processing Standard (FIPS) 140-2 program, in charge of assessing cryptographic modules. Such HSMs are managed by AWS on your behalf and validated at FIPS 140-2 level 3.

For some organizations, however, it may not be enough to meet their own corporate security requirements and they may require that their cryptographic material be secured within HSMs that they manage themselves. For such requirements, AWS provides a service called AWS CloudHSM where you fully control your own HSMs. Such HSMs are validated at FIPS 140-2 level 3.

You can manage and interact with your HSMs, deployed with AWS CloudHSM, through a set of command-line tools and libraries. The AWS CloudHSM Client SDK provides standard mechanisms such as, for instance, a Public Key Cryptography Standard (PKCS) #11 API to perform cryptographic operations following the Organization for the Advancement of Structured Information Standards (OASIS) standard or a Java Cryptography Extension (JCE) provider to offload cryptographic operations to AWS CloudHSM from Java applications.

However, you can also leverage AWS CloudHSM through AWS KMS. With AWS KMS, you can indeed opt to use a custom key store for which the keys are stored on an AWS CloudHSM cluster that you control. It allows you to keep leveraging the AWS services integrated with AWS KMS while making sure that the HSMs protecting your cryptographic material remain fully under your control if that is required by your organization’s corporate security policies.