Data Protection in AWS

One of the most common areas of interest from customer executives regarding their move to AWS is data protection. Data protection can take many forms (e.g., backups, high availability, long-term storage), but the focus for this blog post will be encryption. This post has been co-written with Scott Conklin, an encryption expert from our AWS Professional Services team.

Customers have many reasons for wanting to encrypt their data in AWS, some of which include:

• to protect proprietary/business sensitive data
• to meet compliance/regulatory requirements
• to align with cloud security best practices here, here, and here

Regardless of the reasons why customers want to encrypt, there are some common questions that we receive from customer CISOs, Chief Compliance Officers, Chief Risk Officers, and other executives charged with the protection of their company’s data.

With AWS, customers have several options for encrypting their data and managing keys on the platform:

1. AWS Key Management Service: AWS Key Management Service (KMS) provides customers with centralized control of their encryption keys. Customers can easily create, import, and rotate keys as well as define usage policies and audit that usage from the AWS Management Console or by using the AWS SDK or CLI. The master keys in KMS, whether imported by the customer or created on the customer’s behalf by KMS, are stored in highly durable storage in an encrypted format to ensure that they are protected and can be retrieved when needed.
2. AWS Cloud HSM:AWS CloudHSM is a cloud-based hardware security module (HSM) that enables customers to easily generate and use their own encryption keys with AWS services. With CloudHSM, customers can manage their own encryption keys using FIPS 140-2 Level 3 validated HSMs. It is a fully managed service that automates time-consuming administrative tasks, such as hardware provisioning, software patching, high availability, and backups.
3. AWS Market Place Solutions : AWS offers a wide variety of third-party vendor solutions in the AWS Marketplace, which gives customers the choice to use a third party key management solution that they may already be familiar with.
4. Bring your own/roll your own encryption solution: Customers with existing on-premise encryption solutions may be able to extend these solutions for use within AWS. Common examples include Thales/SafeNet or open-source solutions like dm_crypt + LUKS.

Common Questions from Enterprise Executives

1. What level of administrative access do AWS personnel have to AWS KMS? Can AWS personnel extract my company’s encryption keys and decrypt my company’s data?

AWS KMS is designed so that no one, including AWS employees, can retrieve your plain text keys from the service. The service uses FIPS 140-2 validated hardware security modules (HSMs) to protect the confidentiality and integrity of your keys regardless of whether you request KMS to create keys on your behalf, create them in an AWS CloudHSM cluster, or import them into the service. More granular details about KMS, its backend architecture, as well as protections and operations, can be found in the AWS Cryptographic Details Whitepaper.

2. What level of administrative access do AWS personnel have to AWS Cloud HSM? Can AWS personnel extract my company’s encryption keys and decrypt my company’s data?

Separation of duties and role-based access control is inherent in the design of CloudHSM. AWS has a limited credential to the HSM that permits us to monitor and maintain the health and availability of the HSM, take encrypted backups, and to extract and publish audit logs to your CloudWatch Logs. AWS personnel are unable to export or use your keys.

3. What are some use cases for AWS KMS vs AWS CloudHSM?

AWS KMS is primarily used for encryption of data at rest, such as EBS volumes, database snapshots, and S3 objects. Forty-five AWS services are integrated with KMS to let you encrypt your data managed within those services. You can also use KMS master keys with the AWS Encryption SDK to encrypt/decrypt data directly within your own applications. The authentication methods and access policies for using and administrating keys in KMS is integrated with AWS Identity and Access Management.

AWS CloudHSM is primarily used for application-specific encryption such as database encryption using Total Data Encryption, TLS offloading, hash functions, and sign/verify operations using public key cryptography. The authentication methods and access policies for using and administrating keys in CloudHSM is explicitly not integrated with AWS Identity and Access Management. Instead, you must manage your own credentials and use cryptographic interfaces like PKCS#11, JCE, or CNG.

4. What if I need a level of control for KMS that is normally satisfied by an HSM?

 At the 2018 AWS re:Invent conference, KMS launched the custom key store feature to give customers the choice to create, store, and use their KMS keys in hardware security modules (HSMs) that they control. The new feature was designed for customers with stringent compliance requirements for managing encryption keys. These customers can now use KMS backed by CloudHSM to manage their keys and control access to their encrypted data in 45 AWS services. By choosing to use a KMS custom key store rather than the default KMS key store, customers have a level of control over their KMS keys that is comparable to the use of on-premises HSMs.

5. What are the core differences between AWS managed CMKs versus customer managed CMKs?

AWS Managed CMKs are CMKs (Customer Master Keys) in your account that are created and managed by KMS. This CMK is unique to your AWS account and region. These keys are only used by the specific AWS service to encrypt data on your behalf.

Customer managed CMKs are CMKs that you create, manage, and use directly within your application or with supported AWS services. This includes enabling and disabling the CMK, rotating its cryptographic material, and establishing the IAM policies and key policies that govern access to the CMK, as well as using the CMK in cryptographic operations. Customers can allow an AWS service to use a customer managed CMK on their behalf, but customers retain control of the CMK.

6. Can I bring my own key to KMS? If I bring my own key, is it more secure?

Customers can absolutely bring their own key (BYOK). No, it is not necessarily more secure. This is a common misconception. Customers are welcome to generate key material outside of AWS, import it, and associate it with a customer managed CMK key ID. This may allow them to meet a compliance requirement to generate and store a copy of master keys outside of AWS. However, once the key material is imported, it is protected and used in the same way that a KMS-generated customer managed CMK is, so it can be highly available. There are very specific use-cases where BYOK is desired; however, customers find using KMS and KMS-generated key material much easier from a manageability and operations standpoint, all while giving them the same level of security.

7. How do I rotate keys on encrypted data? What if I use AWS KMS generated keys? What if I want to bring my own key?

AWS will automatically rotate CMKs on a customer’s behalf! This is done once every three years on AWS managed CMKs and once every year on customer managed CMKs. Customers are able to rotate customer managed CMKs manually if they wish to have a frequency greater than one year or if customers need to manually rotate due to imported key material. More details can be located in the AWS KMS Developer Guide under Rotating Keys.

Data protection is extremely important to all of our customers. We encourage customers to encrypt where possible and we offer a variety of service options to make it easy for customers to encrypt their data and manage their encryption keys. Need more information? Consult our product pages and extensive documentation or reach out to your account management team.

– Clarke
LinkedIn
Twitter