Microsoft AzureOverview
Migrate BLOB based VHDs to Managed Disks on Virtual Machines to exploit the default features of this configuration. The features include:
- Default Disk Encryption
- Resilience, as Microsoft will manage the disk storage and move around if underlying hardware goes faulty
- Reduction of costs over storage accounts
Rationale
Managed disks are by default encrypted on the underlying hardware, so no additional encryption is required for basic protection. It is available if additional encryption is required. Managed disks are by design more resilient than storage accounts. For ARM-deployed Virtual Machines, Azure Adviser will at some point recommend moving VHDs to managed disks both from a security and cost management perspective.
Impact
There are additional costs for managed disks based off of disk space allocated. When converting to managed disks, VMs will be powered off and back on.
Remediation guidance
From Azure Console
- Using the search feature, go to
Virtual Machines - Select the virtual machine you would like to convert
- Select
Disksin the menu for the VM - At the top select
Migrate to managed disks - You may follow the prompts to convert the disk and finish by selecting `Migrate' to start the process
NOTE VMs will be stopped and restarted after migration is complete.
Using Powershell
Stop-AzVM -ResourceGroupName $rgName -Name $vmName -ForceConvertTo-AzVMManagedDisk -ResourceGroupName $rgName -VMName $vmNameStart-AzVM -ResourceGroupName $rgName -Name $vmName
References:
- https://learn.microsoft.com/en-us/azure/virtual-machines/windows/convert-unmanaged-to-managed-disks
- https://learn.microsoft.com/en-us/security/benchmark/azure/security-controls-v3-data-protection#dp-4-enable-data-at-rest-encryption-by-default
- https://learn.microsoft.com/en-us/azure/virtual-machines/faq-for-disks
- https://azure.microsoft.com/en-us/pricing/details/managed-disks/
Multiple Remediation Paths
Azure
SERVICE-WIDE (RECOMMENDED when many resources are affected): Assign Azure Policy initiatives at management group/subscription scope and trigger remediation tasks.
az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>
ASSET-LEVEL: Apply the resource-specific remediation steps above to the listed non-compliant resources.
PREVENTIVE: Embed Azure Policy checks into landing zones and IaC workflows to block or auto-remediate drift.
References for Service-Wide Patterns
- Azure Policy overview: https://learn.microsoft.com/en-us/azure/governance/policy/overview
- Azure Policy remediation: https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources
- Azure Policy initiative structure: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/initiative-definition-structure
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- Azure: assign policy initiatives at management group/subscription scope and run remediation tasks.
az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
Query logic
These are the stored checks tied to this control.
Azure VMs with unmanaged disks
Connectors
Covered asset types
Expected check: eq []
{
vms(where: { diskAttachments_SOME: { NOT: { vhdURI: "" } } }) {
...AssetFragment
}
}
