Recently Veeam released Veeam Backup for AWS. A new product providing cloud-native data protection to AWS workloads, whether they are born in the cloud or migrated to the cloud. With this new release of Veeam Backup for AWS, new considerations, specifically how to build a backup environment, must be put in place. Isolated accounts leveraging built-in AWS security boundaries are needed to be implemented. As such, a “Backup DMZ” should be used to protect all the data that is being backed up.
Importance of an isolated backup account
Within the AWS public cloud, an AWS account is an isolated security boundary requiring its own security permissions, root accounts, MFA settings and IAM roles. Through this model AWS can provide isolation to different environments, for example, keeping Dev & Test separate from Production, or different departments. From a backup perspective, it is imperative that we create a separate isolated account to store all the backup data in. This makes sure that in the event that someone or something with rogue intentions gains access to the production account, the backup data stored in the other account cannot be accessed.
As you can see in the diagram, an account is the security boundary protecting that data from any other account or workload. Unless granted through IAM roles, no user from any of the production or backup accounts can access workloads or data in the production accounts.
To create a true Backup DMZ, IAM roles must be created within the production account that give secure access to the service running in the backup account. These are no reciprocal roles, so giving access to a service running in the backup account does not allow access from the production account into the backup account.
This allows for the logical isolation of accounts and provides a true Backup DMZ or isolated backup account to protect the data.
People in the past have spoken about how they always believe their accounts in AWS to be secure, but attacks on root accounts, incorrectly configured IAM roles, or any other misconfiguration can easily occur. Several companies throughout the years have seen ransomware or brute force attacks occur in the public cloud and destroy their data. Think about someone gaining root access to an AWS account and deleting all the workloads running in EC2. If you have backups stored in S3 you may feel safe, but if they’re in the same AWS account, that root access user can also go and delete all the backup data from within S3. By leveraging a Backup DMZ or separate backup account, even with root access to the production account, the rogue attacker has no access to the backed up protected data in the other account. This makes for an extremely safe and reliable way to protect and restore your data to either the existing account or a new account after an incident has occurred.
Backup for AWS has all the required features to
leverage these security capabilities in AWS, and if you’re interested in trying
it out, go to the