How to implement a centralized immutable backup solution with AWS Backup

Many organizations around the world, such as government agencies, financial institutions, and nonprofits, are required to maintain and securely store their data long term to comply with regulatory and business requirements. One way to fulfill such requirements is via a centralized immutable backup solution that creates and stores secure and immutable backups of their data outside production accounts in separate and secure vault accounts.

In this blog post, we walk through different AWS Backup features that you can use to implement a centralized immutable backup solution to implement protections against unauthorized access to your backup data in your central backup account. By creating immutable backups, you can implement guardrails against ransomware and malicious activity. You can also minimize any impact to your business operations or workloads in the scenario of a data security event.

Solution overview

AWS Backup enables companies to centralize and automate data protection for AWS services across compute, storage, and database functions within their organizations. Additionally, with the use of AWS Organizations and AWS Backup, companies are able to centrally deploy data protection and immutable backup policies to configure, manage, and govern backup activity across all AWS accounts and supported resources to protect critical backup recovery points.

For this solution, we use an example where data stores in the AWS management account (A) part of the management organizational unit (OU) are backed by AWS Backup to create a backup in a central AWS backup account (B) part of the central backup organizational unit (OU) to achieve a cross-account backup copy. The centralized immutable backup solution is built to add security at both the data plane and control plane for AWS Backup data and infrastructure.

We walk through each of the following features to apply security guardrails to the AWS Backup stored in the central backup account (B):

1. Central Backup Vault Lock: The guardrail at the data backup level.
2. Central backup vault access policy: The guardrail at the data backup level.
3. AWS Organizations service control policies (SCPs): The guardrail at the account level.
4. Amazon EventBridge notifications: The guardrail at the account level.

Figure 1: How to implement a centralized immutable backup solution with AWS Backup

At a high level, the following steps are involved in setting up the centralized immutable backup solution for the data backup stored in the central backup account (B) in your organization. As part of this post, we provide you with an AWS CloudFormation template that accomplishes the following steps.

• Create an AWS Key Management Service (KMS) customer managed key in the central backup account (B), which is used to encrypt the AWS Backup vault in the central backup account (B).
• Create an AWS Backup vault in the central backup account (B) and assign the previously created KMS key. The backup vault will have all the following guardrails in place to protect the data from unauthorized access:
  • AWS Backup Vault Lock
  • Vault access policy
• Create a CloudFormation custom resource in the management account that will create an Organizations SCP to deny everyone except the authorized admin of the account to perform mutative or management operations on the central backup vault.
• If all the previously described guardrails are breached, create an EventBridge rule in the central backup account (B) to notify when someone other than the authorized admin of the account performs any mutative or management operations on the central backup vault.

Prerequisites

The following are the prerequisites for implementing the solution:

• An AWS Identity and Management (IAM) account with administrator privileges for the services used in this solution
• All AWS accounts for use with AWS Backup belong to AWS Organizations, including a delegated administration account. For more information, see the tutorial on Creating and configuring an organization.
• All features and SCPs are enabled in AWS Organizations through the AWS Organizations console.
• The IAM roles required for deployment of StackSets. Please refer to the documentation on creating IAM roles for deploying StackSets

Implementing the solution

For this post, we set up an organizational structure that has two different organizational units (OUs), with the management account (A) present in the management OU and the central backup account (B) present in the central backup OU. For more information about setting up AWS Organizations, see Getting Started with AWS Organizations.

Figure 2: An organizational structure that has two different organizational units (OUs)

Next, validate that cross-account backups have been enabled in AWS Backup in the management account. You must also validate that you have opted in to backing up the required data store in each Region where you want to use AWS Backup for the particular data store.

Figure 3: Validate that cross-account backups have been enabled in AWS Backup in the management account

Before you start, make a note of the following information:

• AWS account ID of the central backup account.
• Organization unit ID of the central backup OU.
• Organizations ID

Walkthrough

Complete the following steps to implement this solution.

Step 1: Deploy central backup vault in the central backup account (B)

In this step, you deploy the central backup vault with all the guardrails at the vault level in the central backup account (B). The guardrails include:

• Vault access policy: This is a resource-based policy present at the AWS Backup vault. To learn more about vault access policy, read the documentation on setting access policies on backup vaults.

As part of the implementation, the vault access policy is implemented at the central backup vault, which allows only the Backup vault administrator and CloudFormation StackSet execution role to perform the following actions:

• • StartCopyJob
  • StartRestoreJob
  • PutBackupVaultLockConfiguration
  • DeleteBackupVaultLockConfiguration
  • PutBackupVaultAccessPolicy

• AWS Backup Vault Lock: The AWS Backup Vault Lock helps implement a write-once-read-many (WORM) model for your backups. Implementing the AWS Backup Vault Lock can protect your backups from accidental or malicious deletion by any user or role, including “Root.” To learn more about vault access policy, read the AWS Backup Vault Lock documentation.

As part of the implementation, the vault lock is enabled on the central backup vault with the following configuration, which is taken as an input parameter as part of the CloudFormation stack creation.

• • MinRetentionDays
  • MaxRetentionDays
  • ChangeableForDays

To deploy the central backup vault, we use AWS CloudFormation StackSets. A stack set lets you create stacks in AWS accounts across Regions by using a single CloudFormation template. Since the central backup vault could be either in the same Region or multiple Regions in the central backup account (B), we recommend using CloudFormation StackSets. If you want to read more about CloudFormation StackSets, refer to the blog post on using AWS CloudFormation StackSets for multiple accounts in an AWS Organization.

1. Sign in to your management account and select the appropriate AWS Region (preferably your AWS Organizations home Region)
2. Navigate to the AWS CloudFormation StackSets console in the AWS Region being used, select StackSets, and create a new StackSet using aws-backup-central-backup-account.yaml
3. On the Permissions section, select the Self-service permissions. We choose the following settings:
   • IAM role name: AWSCloudFormationStackSetAdministratorRole
   • IAM execution role name: AWSCloudFormationStackSetExecutionRole
4. Enter the StackSet name. In our example, we use Central-Backup-Vault. Under the Parameters section, enter values for the following parameters:
   • pBackupKeyAlias – The alias name for the customer managed KMS key to encrypt the central backup vault.
   • pCentralBackupVaultName – The name of the central backup vault.
   • pOrganizationId – The ID of the organization.
   • pBackupVaultAdmin – The role ARN of the central backup vault admin and the ARN of AWSCloudFormationStackSetExecutionRole should be passed.

NOTE: The parameters take a comma delimited list, but only two roles are allowed since the SCP template allows only two roles due to the nature of the centralized immutable backup solution.

• • pMinRetentionDays – The minimum retention days for the backup when being stored in the central backup vault.
  • pMaxRetentionDays – The minimum retention days for the backup when being stored in the central backup vault.
  • pChangeableForDays – The days during which the vault lock can be modified or deleted.

5. In the Set deployment options, choose Deploy stacks in organizational units and provide the OU ID containing the central backup account (B). In case there are other accounts that are part of the same OU, you can also deploy the StackSet to the central backup account (B). In the Specify Regions section, select a single AWS Region where you want to deploy the member account’s IAM roles from the dropdown list
6. On the Review page, validate the parameters and check the box I acknowledge that AWS CloudFormation might create IAM. Then select Submit.
7. In the Stack instances section, validate the StackSet deployment and wait for the status to change from an OUTDATED to a CURRENT stack instance.

Figure 4: The example parameter values for the central backup vault CloudFormation template

Step 2: Deploy service control policy in the management account (A)

You can modify or delete the vault access policy. You can disable the vault lock or alter the settings during the cooling-off period. To add additional guardrails at the AWS account, deploying the CloudFormation stack in the management account (A) creates a service control policy to restrict mutative or management operations on the central backup vault to authorized IAM principals.

1. Sign in to the console in the management account (A).
2. Search for CloudFormation and create the stack using the aws-scp-management-account.yaml.
3. Enter the Stack name. In our example, we use Central-Backup-Vault-SCP. Under the Parameters section, enter values for the following parameters:

• • pLambdaFunctionName – The name of the Lambda function that gets created.
  • pLambdaIAMRoleName – The name of the IAM execution role that will be associated with the Lambda function
  • pServiceControlPolicyName – The service control policy name that is created by the Lambda function.
  • pCentralBackupVaultArn – The ARN of the central backup vault that was created as part of step 1.
  • pCentralBackupVaultAdmin – The role ARN of the central backup vault admin.
  • pCloudFormationRole – The role ARN of AWSCloudFormationStackSetExecutionRole should be passed.
  • pTargetType – The supported target type as Account_Id and Organization_Unit to associate the service control policy to either one of the target types.
  • pTargetId – For the target Id, enter the 12-digit account ID of the central backup account (B) if the target type is Account_Id and enter the organization unit ID of the central backup account if the target type is Organization_Unit.

NOTE: In case you would like to add more than one role as admin role, add additional admin roles in the parameter section of the template.

Figure 5: The example parameter values for the SCP CloudFormation template

4. Select the check box to acknowledge that the template creates IAM resources and choose Create Stack.
5. When the CloudFormation stack status changes to CREATE_COMPLETE, navigate to the Resources tab and validate that all the resources have been created successfully.

Step 3: Deploy EventBridge rule in the central backup account (B)

In case the service control policy is compromised, an additional layer of security can be implemented using an EventBridge rule, which can be configured in the central backup account (B) for the sensitive APIs configured in the service control policy to take action or notify the appropriate teams. In this step, you deploy the EventBridge rule, which will the appropriate teams when any mutative or management operations are performed on the central backup vault by anyone other than the authorized admin of the account. As part of deployment, the EventBridge rule, Amazon SNS topic, and SNS topic policy are created. Follow these steps to successfully deploy the resources:

1. Repeat steps 1–3 from Step 1 using the template aws-eventrule-central-account.yaml.
2. Enter the StackSet name. In our example, we use Central-Backup-Vault-Notification-Event. Under the Parameters section, enter values for the following parameters:
   • ptopicName – The SNS topic name that is created.
   • psubscriptionEmail – The email ID that will receive a notification when any mutative or management operations are performed on the central backup vault.
   • pEventName – The EventBridge rule name that is created.
   • pBackupVaultAdmin – The role ARN of the central backup vault admin and the ARN of AWSCloudFormationStackSetExecutionRole should be passed.

NOTE: The parameters take a comma delimited list, but only two roles are allowed since the SCP template allows only two roles due to the nature of the centralized immutable backup solution.

• • pBackupVaultName – The backup vault name that is created as part of Step 1.

3. Repeat steps 5–7 from Step 1.

Figure 6: The example parameter values for the EventBridge rule CloudFormation template

Validate the centralized immutable backup solution

The following steps help validate that the centralized immutable backup solution has been implemented successfully.

1. Sign in to the console in your central backup account (B) using the backup vault administrator role.
2. On the AWS Backup console, choose Protected resources and create an on-demand backup.
3. Select any of the existing data sources in your account and use the following configuration for backup creation:

a. Select Create backup now.
b. Retention period – 1 day
c. Backup vault – Select the central backup vault created in Step 1.
d. Choose Default role.

4. Create on-demand backup.

Figure 7: On-demand backup creation while validating the central immutable backup solution.

Though the authorized admin is creating the backup, the backup creation will fail due to the Backup Vault Lock configuration requiring the minimum retention days to be 5.

Figure 8: On-demand backup failure while validating the central immutable backup solution.

If you follow the same steps but give the retention period value as 6 days, then you will notice the backup creation will be successful.

Figure 9: Successful on-demand backup while validating the central immutable backup solution

Once the backup creation is completed, follow these steps:

1. Navigate to Backup vaults from the AWS Backup console.
2. Select the backup vault (central-backup-vault) that was created in Step 1.
3. Delete the recovery point that was created in the previous step.

Figure 10: Unable to delete the recovery point because the vault lock feature is enabled

Though the authorized admin is performing the deletion operation, they are unable to delete the recovery point because the vault lock feature is enabled.

You have successfully implemented the centralized immutable backup solution for your central backup vault. In case you want to incorporate the centralized immutable backup solution into your centralized backup at scale across AWS services using AWS Backup, please follow the steps in this AWS Storage blog post. You can use the centralized immutable backup template provided in the previously shown steps while deploying the central backup vault and follow the remaining steps.

Cleaning up

To avoid incurring future charges, delete the resources. First, delete the stack instances, then delete the StackSets from the AWS CloudFormation console. To delete the resources in the management account, perform deleting the stack.

Conclusion

In this blog post, we showed you how to build a centralized immutable backup solution for data backups stored in a central backup account. As part of the centralized immutable backup solution, we discussed AWS Backup Vault Lock, which utilizes a WORM (write-once-read-many) method for backups. We also discussed AWS Backup vault access policies, which protect recovery points stored in the backup vault from being deleted by unauthorized users, and service control policies, which restrict management APIs to authorized users at the organizations level. Furthermore, we covered using Amazon EventBridge notifications as a proactive approach when management and data actions are performed by unauthorized users. Now that you know some mechanisms to secure your centralized immutable backup solution in AWS, you can use this guide to determine the right backup architectures to fit your organization’s user case.

You can also find some additional blogs relating to AWS Backup in the developer guide. If you have feedback or comments on this post, submit comments in the comments section. If you have any questions about this post, start a thread on the re:Post.