Data encryption at rest for AWS Verified Access
AWS Verified Access encrypts data at rest by default, using AWS owned KMS keys. When encryption of data at rest happens by default, it helps reduce the operational overhead and complexity that are involved in protecting sensitive data. At the same time, it enables you to build secure applications that meet strict encryption compliance and regulatory requirements. The following sections provide the details of how Verified Access uses KMS keys for data encryption at rest.
Verified Access and KMS keys
AWS owned keys
Verified Access uses KMS keys to automatically encrypt personally identifiable information (PII). This happens by default, and you can't yourself view, manage, use, or audit the use of the AWS owned keys. However, you don't have to take any action or change any programs to protect the keys that encrypt your data. For more information, see AWS owned keys in the AWS Key Management Service Developer Guide.
While you can't disable this layer of encryption or select an alternate encryption type, you can add a second layer of encryption over the existing AWS owned encryption keys by choosing a customer managed key when you create your Verified Access resources.
Customer managed keys
Verified Access supports the use of symmetric customer managed keys that you create and manage, to add a second layer of encryption over the existing default encryption. Because you have full control of this layer of encryption, you can perform such tasks as:
-
Establishing and maintaining key policies
-
Establishing and maintaining IAM policies and grants
-
Enabling and disabling key policies
-
Rotating key cryptographic material
-
Adding tags
-
Creating key aliases
-
Scheduling keys for deletion
For more information, see Customer managed keys in the AWS Key Management Service Developer Guide.
Note
Verified Access automatically enables encryption at rest using AWS owned keys to protect personally identifiable data at no charge.
However, AWS KMS charges will apply when you use a customer managed key. For more information
about pricing, see the AWS Key Management Service
pricing
Personally identifiable information
The following table summarizes the personally identifiable information (PII) that Verified Access uses, and how it is encrypted.
Data type | AWS owned key encryption | Customer managed key encryption (Optional) |
---|---|---|
Trust provider (user-type) User-type trust providers contain OIDC options such as AuthorizationEndpoint, UserInfoEndpoint, ClientId, ClientSecret, and so on, which are considered PII. |
Enabled | Enabled |
Trust provider (device-type) Device-type trust providers contain a TenantId, which is considered PII. |
Enabled | Enabled |
Group policy Provided during creation or modification of Verified Access group. Contains rules for authorizing access requests. Might contain PII such as username and email address, and so on. |
Enabled | Enabled |
Endpoint policy Provided during creation or modification of Verified Access endpoint. Contains rules for authorizing access requests. Might contain PII such as username and email address, and so on. |
Enabled | Enabled |
How AWS Verified Access uses grants in AWS KMS
Verified Access requires a grant to use your customer managed key.
When you create Verified Access resources encrypted with a customer managed key, Verified Access creates a grant on your behalf by sending a CreateGrant request to AWS KMS. Grants in AWS KMS are used to give Verified Access the access to a customer managed key in your account.
Verified Access requires the grant to use your customer managed key for the following internal operations:
-
Send Decrypt requests to AWS KMS to decrypt the encrypted data keys so that they can be used to decrypt your data.
-
Send RetireGrant requests to AWS KMS to delete a grant.
You can revoke access to the grant, or remove the service's access to the customer managed key at any time. If you do, Verified Access won't be able to access any of the data that's encrypted by the customer managed key, which affects operations that are dependent on that data.
Using customer managed keys with Verified Access
You can create a symmetric customer managed key by using the AWS Management Console, or the AWS KMS APIs. Follow the steps for Creating a symmetric encryption key in the AWS Key Management Service Developer Guide.
Key policies
Key policies control access to your customer managed key. Every customer managed key must have exactly one key policy, which contains statements that determine who can use the key and how they can use it. When you create your customer managed key, you can specify a key policy. For more information, see Key policies in the AWS Key Management Service Developer Guide.
To use your customer managed key with your Verified Access resources, the following API operations must be permitted in the key policy:
-
kms:CreateGrant
– Adds a grant to a customer managed key. Grants control access to a specified KMS key, which allows access to grant operations Verified Access requires. For more information, see Grants, in the AWS Key Management Service Developer Guide.This allows Verified Access to do the following:
-
Call
GenerateDataKeyWithoutPlainText
to generate an encrypted data key and store it, because the data key isn't immediately used to encrypt. -
Call
Decrypt
to use the stored encrypted data key to access encrypted data. -
Set up a retiring principal to allow the service to
RetireGrant
.
-
-
kms:DescribeKey
– Provides the customer managed key details to allow Verified Access to validate the key. -
kms:GenerateDataKey
– Allows Verified Access to use key for encrypting data. -
kms:Decrypt
– Allow Verified Access to decrypt the encrypted data keys.
The following is an example key policy you can use for Verified Access.
"Statement" : [ { "Sid" : "Allow access to principals authorized to use Verified Access", "Effect" : "Allow", "Principal" : { "AWS" : "*" }, "Action" : [ "kms:DescribeKey", "kms:CreateGrant", "kms:GenerateDataKey", "kms:Decrypt" ], "Resource" : "*", "Condition" : { "StringEquals" : { "kms:ViaService" : "verified-access.region.amazonaws.com", "kms:CallerAccount" : "111122223333" } }, { "Sid": "Allow access for key administrators", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action" : [ "kms:*" ], "Resource": "arn:aws:kms:region:111122223333:key/key_ID" }, { "Sid" : "Allow read-only access to key metadata to the account", "Effect" : "Allow", "Principal" : { "AWS" : "arn:aws:iam::111122223333:root" }, "Action" : [ "kms:Describe*", "kms:Get*", "kms:List*", "kms:RevokeGrant" ], "Resource" : "*" } ]
For more information, see Creating a key policy and troubleshooting key access in the AWS Key Management Service Developer Guide.
Specifying a customer managed key for Verified Access resources
You can specify a customer managed key to provide a second layer encryption for the following resources:
When you create any of these resources using the AWS Management Console, you can specify a customer managed key in the Additional encryption -- optional section. During the process, select the Customize encryption settings (advanced) check box, then enter the AWS KMS key ID you want to use. This can also be done when modifying an existing resource, or by using the AWS CLI.
Note
If the customer managed key used to add additional encryption to any of the above resources is lost, the configuration values for the resources will no longer be accessible. The resources can be modified however, by using the AWS Management Console or AWS CLI, to apply a new customer managed key and reset the configuration values.
AWS Verified Access encryption context
An encryption context is an optional set of key-value pairs that contain additional contextual information about the data. AWS KMS uses the encryption context as additional authenticated data to support authenticated encryption. When you include an encryption context in a request to encrypt data, AWS KMS binds the encryption context to the encrypted data. To decrypt data, you include the same encryption context in the request.
AWS Verified Access encryption context
Verified Access uses the same encryption context in all AWS KMS cryptographic operations, where
the key is aws:verified-access:arn
and the value is the resource Amazon Resource
Name (ARN). Below are the encryption contexts for Verified Access resources.
Verified Access trust provider
"encryptionContext": { "aws:verified-access:arn": "arn:aws:ec2:region:111122223333:VerifiedAccessTrustProviderId" }
Verified Access group
"encryptionContext": { "aws:verified-access:arn": "arn:aws:ec2:region:111122223333:VerifiedAccessGroupId" }
Verified Access endpoint
"encryptionContext": { "aws:verified-access:arn": "arn:aws:ec2:region:111122223333:VerifiedAccessEndpointId" }
Monitoring your encryption keys for AWS Verified Access
When you use a customer managed KMS key with your AWS Verified Access resources, you can use AWS CloudTrail to track requests that Verified Access sends to AWS KMS.
The following examples are AWS CloudTrail events for CreateGrant
,
RetireGrant
, Decrypt
, DescribeKey
, and
GenerateDataKey
, which monitor KMS operations called by Verified Access to access
data that's encrypted by your customer managed KMS key: