Protecting Azure Backups with Resource Guard – Part 1

Hello geeks!

I recently was asked to talk about Azure Backup with a customer. Whenever I’m asked about a service my order of operations is to read through the public documentation, lab it out, talk to peers about it, and then put together key findings, best practices, and a deployable lab. I’ve published the package I put together for Azure Backup on GitHub.

When doing my research into Azure Backup, I came across an interesting limitation. The Recovery Services Vaults (RSVs), which orchestrate and manage storage of the Virtual Machine (VM) backup, must be created in the same subscription as the VMs being backed up. This surprised me, because it puts the resource being backed up and the backup itself within the same authorization boundary.

If you’ve done any work in AWS, you know best practice is to store the backups of the EC2 instances in a separate AWS account to ensure you aren’t stacking both the resources and backup in the same security boundary. The Code Spaces hack is a great example of what happens when you don’t do this. In the Azure scenario, I’m forced to take the risk of an attacker gaining Owner-level permissions of the subscription and locking/destroying both my resource and backup creating quite nasty ransomware scenario. What the heck Microsoft?

Thankfully, in 2021 Microsoft introduced a really creative feature to address this risk in the form of Resource Guard. A Resource Guard is an Azure resource that can be created in the same subscription, a different subscription in the same Azure AD tenant, or even a subscription in a different Azure AD tenant! When associated to an RSV, a user looking to make risky modifications to it (such as removing soft delete) must have permissions on BOTH the Resource Guard and the RSV. This means it can support separate authorization boundaries at the subscription level or even completely separate identity and authentication boundaries at the tenant.

Resource Guard isn’t something I often hear discussed by Microsoft folks when explaining Azure Backup to customers. Given what I’ve explained above, it should become quite obvious this is a critical feature to incorporate into your design if you plan on using Azure Backup.

In the next post in this short series, I’ll walk through a demonstration of the feature in action using the lab in this repository with the addition of a second Azure AD tenant as pictured in the image below. See you next post!

Azure Backup Lab for this series

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s