OS disks on platform-managed keys where customer-managed keys are expected
What does ZopNight detect here?
Every Azure managed disk is already encrypted at rest with a platform-managed key, so RC-1300 does not hunt for "unencrypted" disks. Instead the rule fires when no diskEncryptionSet is attached to the OS disk, a customer-managed-key gap relevant to PCI-DSS, HIPAA, and ISO 27001 key-control requirements. A secondary path covers ADE explicitly disabled.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1300 |
| Category | compliance |
| Severity | high |
| Metric | none — pure configuration read |
| Source | vm_encryption.go |
Where it applies
Encryption is not the question, key custody is
Azure’s server-side encryption is always on: no managed disk exists unencrypted at rest. A naive “disk encryption not enabled” check therefore flags nothing real, or worse, flags every VM that hasn’t layered guest-level encryption on top. The meaningful compliance question on Azure is who controls the key. With a platform-managed key (PMK), Microsoft operates the entire key lifecycle. With a customer-managed key (CMK) in Key Vault via a Disk Encryption Set, your organisation controls rotation, access policy, and, decisively, revocation. Frameworks like PCI-DSS, HIPAA, and ISO 27001 often require exactly that control.
The two firing paths and the one abstain rule
The primary signal is os_disk_cmk_enabled, which the discoverer derives from whether a
diskEncryptionSet is attached to the OS disk’s managed-disk properties. An explicit
"false" means PMK-only and fires the CMK-gap finding; any other value skips. The secondary
path catches ade_enabled set to "false", meaning Azure Disk Encryption
(BitLocker/dm-crypt) explicitly turned off in ARM, which the discoverer only records when encryptionSettings
carries a literal false. Absent metadata always abstains: an earlier revision treated missing
encryptionSettings as “not encrypted” and false-flagged every non-ADE VM in the fleet,
because absent simply means ADE was never configured while SSE kept doing its job.
Reading a disk’s encryption type
az disk show -g <rg> -n <os-disk-name> \ --query "{type:encryption.type, des:encryption.diskEncryptionSetId}"EncryptionAtRestWithPlatformKey with a null DES confirms the PMK-only state this rule
flags; EncryptionAtRestWithCustomerKey clears it.
Moving a disk onto your own key
Create a Key Vault key and a Disk Encryption Set backed by it, then attach:
az disk update -g <rg> -n <disk> --disk-encryption-set <des-id>. Unlike some cloud
encryption migrations, no data copy is required. Azure re-wraps the data-encryption key under
the new key hierarchy. Budget the operational side instead: a deleted or disabled Key Vault
key makes every disk under that DES unreadable, so key rotation and soft-delete policies
deserve more design time than the attachment itself. Detection is Reader-only; ZopNight
changes no key configuration.