Overview
Ensure that OS disks (boot volumes) and data disks (non-boot volumes) are encrypted with CMK (Customer Managed Keys). Customer Managed Keys can be used with either ADE (Azure Disk Encryption) or SSE (Server Side Encryption).
Rationale
Encrypting the IaaS VM's OS disk (boot volume) and Data disks (non-boot volume) ensures that the entire content is fully unrecoverable without a key, thus protecting the volume from unwanted reads. PMK (Platform Managed Keys) are enabled by default in Azure-managed disks and allow encryption at rest. CMK is recommended because it gives the customer the option to control which specific keys are used for the encryption and decryption of the disk. The customer can then change keys and increase security by disabling them instead of relying on the PMK key that remains unchanging. There is also the option to increase security further by using automatically rotating keys so that access to disk is ensured to be limited. Organizations should evaluate what their security requirements are, however, for the data stored on the disk. For high-risk data, using CMK is a must, as it provides extra steps of security. If the data is low risk, PMK is enabled by default and provides sufficient data security.
**Impact: **
Using CMK/BYOK will entail additional management of keys.
NOTE You must have your key vault setup to utilize this.
Remediation guidance
From Azure Console
Note Disks must be detached from VMs to have encryption changed.
- Go to
Virtual machines - For each virtual machine, go to
Settings - Click on
Disks - Click the ellipsis (...), then click
Detachto detach the disk from the VM - Now search for
Disksand locate the unattached disk - Click the disk then select
Encryption - Change your encryption type, then select your encryption set
- Click
Save - Go back to the VM and re-attach the disk
Using PowerShell
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$vmName = 'MySecureVM';
$KeyVaultName = 'MySecureVault';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGname -VMName $vmName -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $KeyVaultResourceId;
NOTE During encryption it is likely that a reboot will be required, it may take up to 15 minutes to complete the process.
NOTE 2 This may differ for Linux Machines as you may need to set the -skipVmBackup parameter
Default Value
By default, Azure disks are encrypted using SSE with PMK.
References
- https://learn.microsoft.com/azure/security/fundamentals/azure-disk-encryption-vms-vmss
- https://learn.microsoft.com/en-us/azure/security-center/security-center-disk-encryption?toc=%2fazure%2fsecurity%2ftoc.json
- https://learn.microsoft.com/azure/security/fundamentals/data-encryption-best-practices#protect-data-at-rest
- https://learn.microsoft.com/azure/virtual-machines/windows/disk-encryption-portal-quickstart
- https://learn.microsoft.com/en-us/rest/api/compute/disks/delete
- https://learn.microsoft.com/en-us/rest/api/compute/disks/update#encryptionsettings
- https://learn.microsoft.com/en-us/azure/security/benchmarks/security-controls-v2-data-protection#dp-5-encrypt-sensitive-data-at-rest
- https://learn.microsoft.com/en-us/azure/virtual-machines/windows/disks-enable-customer-managed-keys-powershell
- https://learn.microsoft.com/en-us/azure/virtual-machines/disk-encryption
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.
'OS and Data' disks are encrypted with CMK
Connectors
Covered asset types
Expected check: eq []
{vms(where:{diskAttachments_SOME:{disk:{,encryptionKey:null}}}){...AssetFragment}}
Microsoft Azure