Encrypting Data-at-Rest and Data-in-Transit

AWS recommends encryption as an additional access control to complement the identity, resource, and network-oriented access controls already described. AWS provides a number of features that enable customers to easily encrypt data and manage the keys. All AWS services offer the ability to encrypt data at rest and in transit. AWS KMS integrates with the majority of services to let customers control the lifecycle of and permissions on the keys used to encrypt data on the customer’s behalf. Customers can enforce and manage encryption across services integrated with AWS KMS through the use of policy and configuration tools. 

AWS services’ use of server-side encryption is the easiest way for a customer to ensure encryption is implemented correctly and applied consistently. Customers can control when data is decrypted, by whom, and under which conditions as it passed to and from their applications and AWS services. Because access to encrypt or decrypt the data within the service is independently controlled by AWS KMS policies under the customer’s control, customers can isolate control over access to the data, from access to the keys. This isolation model is a powerful additional logical separation control that can be applied across a customer’s AWS environment. 

In addition to controlling how server-side encryption happens within AWS services, customers can choose to encrypt data within their own application environment using AWS KMS with client-side encryption, thereby taking AWS services out of their trust boundary. Application-level, client-side encryption can be used to ensure a consistent security posture as data traverses within a customer’s own service architecture, whether in AWS, on-premises, or in a hybrid model. The use of AWS KMS to manage the lifecycle of and permissions on keys provides a consistent access control mechanism for all encryption keys, regardless of where they are used. 

In order to prevent unauthorized use of encryption keys outside the boundary of AWS KMS, the service utilizes hardware security modules (HSMs) to protect customer key material while in use. These HSMs are validated under Federal Information Processing Standard (FIPS) 140-2 with physical tamper response controls. The HSMs are designed so that plaintext keys cannot be used outside the HSM by anyone, including AWS employees. The only way keys can be used is when an authenticated and authorized customer request is received by the service. In response to the request, AWS KMS enables the customer’s key to be used within the HSM for an encryption or decryption operation. Customer keys can only be used within the AWS region in which they were created. The HSMs in AWS KMS are designed as multi-tenant in the sense that any customer’s key could be used in any HSM within the region. Like other AWS services that utilize multi-tenancy, AWS KMS is designed to isolate usage of keys only to the customer that owns the keys. There is no mechanism for an unauthorized user to cause a customer’s key to be used. AWS KMS transparently manages the durability and availability of customer keys and can scale to support any number of keys at the rate customers’ applications need to use them. Customers simply manage the lifecycle and permissions on keys using the same authentication and authorization controls available to every other AWS service. Every request made of AWS KMS is logged to AWS CloudTrail to provide an audit of when keys were used and under what circumstances. AWS KMS is in scope for all accreditation programs supported by AWS that relate to data protection.

For customers with requirements to directly manage the HSM device that generates, stores, and uses their encryption keys, AWS CloudHSM is available as an option. AWS CloudHSM offers a dedicated FIPS 140-2 Level 3 validated HSM and affords the flexibility of integrating with customer applications using industry-standard APIs such as PKCS#11, Java Cryptography Extensions (JCE), and Microsoft CryptoNG (CNG) libraries. It enables organizations to export keys to most other commercially available HSMs for use in hybrid architectures. AWS automates the time-consuming administrative tasks around these HSMs such as hardware provisioning, software patching, network routing, and creating encrypted backups of key stores. Customers are responsible for scaling their CloudHSM environment and managing the crypto accounts and credentials within the HSM. Like AWS KMS, CloudHSM is designed so that plaintext keys cannot be used outside the HSM by anyone, including AWS employees.

Customers can combine the ease-of-use and integration with AWS services offered by AWS KMS with AWS CloudHSM by using the AWS KMS custom key store option. Customers logically attach an AWS CloudHSM cluster to an AWS KMS key identifier so that requests made to the key are authorized by AWS KMS, but executed on the customer’s dedicated CloudHSM.

To protect data in transit, AWS encourages customers to leverage a multi-level approach. All network traffic between AWS data centers is transparently encrypted at the physical layer. All traffic within a VPC and between peered VPCs across regions is transparently encrypted at the network layer when using supported Amazon EC2 instance types. At the application layer, customers have a choice about whether and how to use encryption using a protocol like Transport Layer Security (TLS). All AWS service endpoints support TLS to create a secure HTTPS connection to make API requests.

For customer-managed infrastructure within AWS that needs to terminate TLS, AWS offers several options including load balancing services (e.g., Elastic Load Balancing, Network Load Balancer, and Application Load Balancer), Amazon CloudFront (a content delivery network), and Amazon API Gateway. In order to implement a TLS connection, each of these endpoint services allows customers to upload their own digital certificates to bind a cryptographic identity to the endpoint. Digital certificates are notoriously difficult to manage at scale because they expire and need to be rotated. AWS simplifies the process of generating, distributing, and rotating digital certificates with AWS Certificate Manager (ACM). ACM offers publicly trusted certificates at no cost that can be used in AWS services that require them to terminate TLS connections to the Internet. ACM also offers the ability to create a private certificate authority to automatically generate, distribute and rotate certificates to secure internal communication among customer-managed infrastructure.

Using services like AWS KMS, AWS CloudHSM, and AWS ACM, customers can implement a comprehensive data at rest and data in transit encryption strategy across their AWS ecosystem to ensure all data of a given classification shares the same security posture.