How encryption works in AWS Backup

Customers in all industries use AWS Backup for centralized and automated data protection across AWS services and hybrid workloads. You can use AWS Backup to create backups and independently encrypt all supported AWS resources.

AWS Backup supports cross-account backup, enabling you to securely copy your backups across your AWS accounts within your AWS organizations, making it easy to centrally manage backup tasks across accounts. For a successful cross-account copy of encrypted backups, it’s essential to understand how AWS Backup handles encryption, as some AWS services support their own encryption and not independent encryption by AWS Backup. For cross-account copies to complete successfully for a data source that does not support AWS Backup encryption, it is necessary to encrypt both the data source and the destination backup vault with a customer managed AWS Key Management Service (AWS KMS) key. Furthermore, the customer managed KMS key should be shared with the destination account service-linked role.

In this blog, we walk through how encryption works within AWS Backup by comparing a service that supports independent encryption with AWS Backup, Amazon DynamoDB, with a service that does not support independent encryption, Amazon RDS, across three different cross-account copy scenarios. With the AWS Backup encryption background and different scenarios we walk through in this post, you can better understand how AWS Backup can help you keep your data secure and compliant through encryption. You can also learn how to successfully copy encrypted backups across accounts, regardless of the AWS encryption method on those backups.

AWS Backup encryption background

AWS Backup’s independent encryption means encryption is handled by the AWS Backup vault. The AWS Backup vault’s AWS KMS key is used to encrypt the backup, and AWS Backup is responsible for the secure copy to the destination vault, without needing to share the source account’s AWS KMS key with the destination account.

For AWS services that do not support independent encryption, AWS Backup will use the data source key to encrypt the data rather than the AWS Backup vault’s KMS key. For cross-account copies, the data source should be encrypted with a customer managed key, which is shared with the service-linked role “AWSServiceRoleForBackup” in the destination account. The cross-account AWS Backup vault should be encrypted with the customer managed KMS key for the copy job to be successful. The blog “Create and share encrypted backup across accounts and Regions using AWS Backup” talks about permissions required to perform cross-account copying of backups for resources, which rely on service-dependent encryption in AWS Backup.

AWS Backup encryption scenarios

In the following scenarios, we compare AWS Backup support for independent encryption in Amazon DynamoDB with advanced features enabled, and Amazon RDS, which does not support independent encryption in AWS Backup.

For each scenario, we walk you through how AWS Backup encrypts the DynamoDB table and RDS instance. We use an AWS Backup in the AWS management account (A) in the us-east-2 (Ohio) Region and copy the backup to AWS account (B) in us-east-2 (Ohio) Region.

1. Scenario 1: The source backup vault and destination backup vault are encrypted with a customer managed key, while the data store is encrypted with an AWS managed KMS key.
   1. Perform a copy job from AWS management account (A) to central AWS backup account (B)
   2. Verify the status of the copy job for the DynamoDB table and Amazon RDS instance.
2. Scenario 2: The source backup vault is encrypted with a customer managed KMS key, the destination backup vault is encrypted with an AWS managed KMS key but the data store is encrypted with a customer managed KMS key.
   1. Review the KMS key policy of the customer managed CMK used by the DynamoDB table.
   2. Perform a copy job from AWS management account (A) to central AWS backup account (B)
   3. Verify the status of the copy job for the DynamoDB table and Amazon RDS instance.
3. Scenario 3: The source backup vault is encrypted with an AWS managed KMS key, the destination backup vault is encrypted with a customer managed KMS key, but the data store is encrypted with a customer managed KMS key.
   1. Modify the KMS key policy of the customer managed CMK used by the RDS instance
   2. Perform a copy job from AWS management account (A) to central AWS backup account (B)
   3. Verify the status of the copy job for the DynamoDB table and Amazon RDS instance.

Prerequisites

1. All AWS accounts for use with AWS Backup belong to AWS Organizations, including a delegated administration account. For more information, see the documentation on creating and configuring an organization.
2. AWS Backup’s cross-account backup enabled. See the documentation to enable cross-account backup.
3. AWS Backup’s advanced features for DynamoDB enabled. See the documentation to enable advanced features for DynamoDB backups.
4. Create an AWS Backup vault and use a customer managed key or Amazon managed KMS key to encrypt the Backup vault both in the AWS management account (A) and central AWS backup account (B). See the documentation to Create a backup vault encrypted with customer managed key.
5. Set the access policy on the Backup vault in the central AWS backup account (B) to allow the default service role [AWSBackupDefaultServiceRole] to perform CopyIntoBackupVault. Refer to the documentation on Setting access policies on backup vaults.
6. Create one DynamoDB table encrypted with a customer managed KMS key and another one encrypted with an Amazon managed KMS key in the AWS management account (A).
7. Create one RDS instance encrypted with a customer managed KMS key and another one encrypted with an Amazon managed KMS key in the AWS management account (A).

Scenario walkthrough

We use two account IDs, 82XXXX68953 and 24XXXX475648, for the AWS management account (A) and the central AWS backup account (B), respectively. Both accounts are part of the same organization. For the blog walkthrough, we have the following resources deployed:

AWS management account (A):

1. DynamoDB table [source-user-table] encrypted with a customer managed KMS key [sourceCmkKey-DynamoDb].
2. DynamoDB table [source-table-aws-managed-encrypted] encrypted with an Amazon managed KMS key.
3. RDS instance [source-rds-cmk-encrypted] encrypted with a customer managed KMS key [sourceCmkKey-rds].
4. RDS instance [source-rds-aws-managed] encrypted with an Amazon managed KMS key.
5. AWS Backup vault [Crossaccount_copy_source_vault] encrypted with a customer managed KMS key [sourceCmkKey-BackupVault].
6. AWS Backup vault [Crossaccount_copy_source_vault_aws_managed_key] encrypted with an Amazon managed KMS key.

Central AWS backup account (B):

1. AWS Backup vault [Crossaccount_copy_destination_vault] encrypted with a customer managed KMS key [destinationCmkKey-BackupVault].
2. AWS Backup vault [Crossaccount_copy_destination_vault_aws_managedkey] encrypted with an Amazon managed KMS key.

SCENARIO 1

In this scenario, we use a copy job for the DynamoDB table and RDS instance from the backup vault to the destination backup vault. Both the source and destination account utilize a customer-managed KMS key.

Figure 1: Architecture diagram describing Scenario 1.

a. Perform a copy job from AWS management account (A) to central AWS backup account (B)

DynamoDB table:

After selecting the backup of the DynamoDB stored in backup vault [Crossaccount_copy_source_vault], we perform the following steps to copy the backup to the destination backup vault [Crossaccount_copy_destination_vault].

1. Choose the destination Region of the central backup account.
2. Toggle the copy to another account’s vault. Paste the ARN of the destination account backup vault [arn:aws:backup:us-east-2:24XXXXX75648:backup-vault:Crossaccount_copy_destination_vault].
3. Choose the lifecycle for the recovery point being stored in the target account backup vault.

Figure 2: Copy job operation for the DynamoDB table.

RDS instance:

We perform the previous steps for the backup of the RDS instance stored in the backup vault [Crossaccount_copy_source_vault].

b. Verify the status of the copy job for the DynamoDB table and Amazon RDS instance.

DynamoDB table:

The status of the copy job was successful for DynamoDB because the DynamoDB with advanced features enabled supports encryption, and the encryption occurs in the AWS Backup vault. Also, in terms of the KMS key permissions, since the AWS Backup service handles copy operation, no additional permissions are required on the customer managed KMS key.

Figure 3: Copy job status is Completed for the DynamoDB table.

RDS instance

The status of the copy job was Failed for the RDS instance backup. The AWS Backup does not support encryption for the RDS instance. Hence the KMS key used to encrypt the data source will be used to encrypt the backup. Since the Amazon managed KMS key permissions cannot be modified, the copy operation failed for the RDS instance.

Figure 4: Copy job status Failed for the RDS DB instance.

SCENARIO 2

In this scenario, we perform a copy job operation for the DynamoDB table and RDS instance from the source backup vault, which uses a customer managed KMS key to a destination backup vault, which uses an Amazon managed KMS key.

Figure 5: Architecture diagram describing Scenario 2.

a. Review the KMS key policy of the customer managed CMK used by the DynamoDB table

The KMS key encryption for the DynamoDB backup is handled at the AWS Backup. Hence, for successful backup creation, the service role used to create the backup should be given “Decrypt” permission on the customer managed CMK. But for the copy job, since the operation is handled by the AWS Backup service, no additional changes are required in the backup vault’s customer managed KMS key [sourceCmkKey-BackupVault] policy is required.

Figure 6: KMS key permissions for the customer managed KMS key used to encrypt the DynamoDB table.

As per Figure 6, the service role used to create the backup has decrypt permissions on the customer managed KMS key [sourceCmkKey-DynamoDb], which is used to encrypt the DynamoDB table.

Figure 7: KMS key permissions for customer managed KMS key used to encrypt source backup vault.

As per Figure 7, the customer managed KMS key [sourceCmkKey-BackupVault] used to encrypt the backup vault has only the admin management permissions of the KMS key.

b. Perform a copy job from the AWS management account (A) to central the AWS backup account (B)

As mentioned in Scenario 1, the copy job operation was performed on backups for DyanmoDB and the RDS instance present in the source backup vault [sourceCmkKey-BackupVault].

c. Verify the status of the copy job for the DynamoDB table and Amazon RDS instance

DynamoDB

The status of the copy job was successful for DynamoDB as DynamoDB, with the advanced features enabled, supports encryption, and the encryption occurs in the AWS Backup vault. Also, in terms of the KMS key permissions, since AWS Backup service handles copy operation, no additional permissions are required on the customer managed KMS key.

RDS instance

The status of the copy job was Failed for the RDS instance backup. For the cross-account copy to be successful for the AWS Backup data source that does not support encryption, the data source should be encrypted with customer managed KMS key, and the destination backup vault should be encrypted with the customer managed KMS key as well. In this scenario, since the destination backup vault was encrypted with the Amazon managed KMS key, the cross-account job failed.

Figure 8: Copy job status is Failed for the RDS DB instance.

SCENARIO 3

In this scenario, we perform a copy job operation for the customer managed KMS key encrypted DynamoDB table and RDS instance from source backup vault (utilizing an Amazon managed key) to the destination backup vault (utilizing a customer-managed KMS key).

Figure 9: Architecture diagram for Scenario 3.

a. Modify the KMS key policy of the customer managed CMK used by the RDS instance

Because the data source does not support encryption in AWS Backup, the data source customer managed key will be used to encrypt the backup. During cross-account copy operation, the service-linked role in the destination account is used to perform the copy job. Hence, the customer managed key used to encrypt the RDS instance should be shared with the AWS Backup service-linked role AWSServiceRoleForBackup in the destination account.

Figure 10: KMS key permissions for customer managed KMS key used to encrypt RDS DB instance.

b. Perform a copy job from AWS management account (A) to central AWS backup account (B)

As mentioned in the earlier scenarios, the copy job operation was performed on backups for DyanmoDB and the RDS instance present in the source backup vault [sourceCmkKey-BackupVault].

c. Verify the status of the copy job for the DynamoDB table and the Amazon RDS instance

DynamoDB

As in the earlier scenarios, the DynamoDB backup copy operation was successful in this scenario as well.

RDS instance

Since both the data source (the RDS instance) and the destination backup vault were encrypted using the customer managed KMS key, the copy job was successful.

Figure 11: Copy job status is Completed for the RDS DB instance.

Cleaning up

To avoid incurring future charges, clean up AWS Backup resources, KMS keys, DynamoDB table, and RDS instance that were created to walk through the scenarios.

Conclusion

In this blog post, we covered how AWS Backup support for encryption works. Also, by demonstrating several scenarios, we compared AWS support for encryption for DynamoDB tables and RDS instances. We validated the encryption of backups performed by AWS Backup, removing the need for additional permissions for customer managed keys. The same steps are applicable for other data sources, such as Amazon EFS and virtual machines, for which AWS Backup supports both encryption and cross-account backup.

For cross-account copies to complete successfully for a data source that does not support encryption in AWS Backup, it is necessary that both the data source and the destination backup vault be encrypted with a customer managed KMS key. Furthermore, the customer managed KMS key should be shared with the destination account service-linked role [AWSServiceRoleForBackup]. The same steps are applicable for any other data stores that rely on service-dependent encryption in AWS Backup.

Thanks for reading this blog post. You can also find some additional blogs relating to AWS Backup in the developer guide. If you have and feedback or questions about this post, submit comments in the comments section.