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

 

Copying Exported Azure Managed Disks

Of the many benefits of Azure Managed Disks, one of the more important ones is the move away from addressing virtual disks as regular blob URIs in standard and premium storage accounts. Azure storage accounts rely on the use of primary and secondary access keys to secure access to the contents of a storage account and there’s no ability to assign granular access permissions at the blob level. If someone has either the primary or secondary access key for a storage account, they essentially have full access to the contents of that storage account including any virtual disks (VHDs) contained within it. The only way to secure the contents of these VHDs is by implementing Azure Disk Encryption (ADE) so that the virtual disks are encrypted at the OS level and copying them through the use of an access key and the Azure Storage REST APIs won’t allow someone to access the contents unless they also have the encryption key used to secure the data.

Enter Azure Managed Disks. With this feature, there is no longer a way to access the VHD blobs via a URI and access to a storage account. Placement of the VHD blobs on Azure storage is managed by the service and Azure Role-Based Access Control can be used to assign specific permissions for a managed disk to one or more users. Managed Disks exposes a variety of operations including read, write, delete and retrieval (export) of a disk via a shared access signature (SAS) URI. For this last part, an administrator can export the managed disk via the Azure Management Portal and they’re receive a URL to use for copying the managed disk to either an Azure storage account or to a location on their local PC.

Copying the VHD via the SAS URI is a bit tricky if you’re trying to use standard tools like Azcopy. To download the VHD to a local PC you can use the hyperlink provided directly in the portal. To copy the VHD to a storage account, though, you can’t use Azcopy. Azcopy requires both READ and LIST SAS permissions to copy a blob. However, the Azure REST SAS API currently only supports read URIs (https://docs.microsoft.com/en-us/rest/api/manageddisks/disks/disks-grant-access). The easiest way I’ve found to complete the copy is to use the Start-AzureStorageBlobCopy cmdlet. This cmdlet starts an asynchronous copy job using the storage REST APIs and works just fine with the read only SAS URI provided by the Azure Portal. Here’s how to accomplish the task:

First, make sure you’re authenticated to Azure and have selected the proper subscription containing the destination storage account for the VHD:

Login-AzureRmAccount

Select-AzureRmSubscription -SubscriptionName <Subscription Name>

Then, get the access key for the destination storage group and create a context to use for the copy job:

$dstkey = Get-AzureRmStorageAccountKey -StorageAccountName <Destination Storage Account Name> -ResourceGroupName <Destination Storage Account Resource Group>

$dstcontext = New-AzureStorageContext -StorageAccountName <Destination Storage Account Name> -StorageAccountKey $dstkey.Value[0]

Lastly, create the copy job and then run the Get-AzureStorageBlobCopyState with the “WaitforComplete” parameter to provide a visual indication of the progress of the copy:

$copyblob = Start-AzureStorageBlobCopy -AbsoluteUri <Export managed disk URL from Portal – Full URL> -DestContext $dstcontext -DestContainer <Destination Container Name> -DestBlob <Destination VHD Filename>

$copyblob | Get-AzureStorageBlobCopyState –WaitForComplete