Restricting Managed Disk Export

One of the big benefits of Managed Disks in Azure is that a VM’s VHD(s) are stored in a storage account which is managed by Azure and no longer has a public endpoint like page blobs did in the unmanaged disk model. One potential downside to this old approach was that anyone with the primary or secondary access key to the storage account where the VM’s VHDs were stored could simply connect to the storage account and download the VHD. Without encryption technologies like ADE or DMCrypt, this meant that person had a working copy of your VM’s disks and full access to the data on them.

With Managed Disks, VHDs no longer have a public blob endpoint but the console does provide the ability to export the managed disk which creates a temporary SAS URI and the ability to connect to the blob and download via your browser or via the Azure Storage REST API.

snip_20171208113940

The concern that some might have is that any administrator with access to the Managed Disk resource(s) can simply export the VHDs and run off with the data. First, you should be always auditing actions such as these via the Activity Log. Second, you can block the ability to do this in the first place by using RBAC in Azure. Here is the full list of Azure Role-Based Access Control operators. The two operations specific to Managed Disk export are:

  • Microsoft.Compute/disks/beginGetAccess/action (Get Disk SAS URI)
  • Microsoft.Compute/disks/endGetAccess/action (Revoke Disk SAS URI)

To block these operations, you need to add them to the NotActions for a custom role and then assign that custom role to your administrators. For example, this is the JSON definition for a custom role that is equivalent to a contributor but blocks managed disk export and snapshot operations specifically. Full documentation for creating custom roles here: https://docs.microsoft.com/en-us/azure/active-directory/role-based-access-control-custom-roles.

snip_20171208114701

Here’s a simple PowerShell script which will list all of the RBAC roles in the current selected subscription and identify whether or not these operations are listed either in the Action or NotAction. You can run this against a specific subscription to see if there’s a role defined to block these operations and then look at that role in the Web Portal to see who is assigned that role.

snip_20171208114812.png

 

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 )

Google+ photo

You are commenting using your Google+ 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 )

w

Connecting to %s