Managed disks reporting encryption at rest disabled
What does ZopNight detect here?
Azure managed disks are always server-side encrypted, and the discoverer only ever records encryption_at_rest as true, so RC-1326 abstains on every real disk today. The rule exists as a tripwire: if a provider ever reports an unencrypted disk, the finding fires at high severity immediately.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1326 |
| Category | compliance |
| Severity | high |
| Metric | none — pure configuration read |
| Source | disk_encryption.go |
Where it applies
A finding you should never actually see
On today’s Azure, this rule cannot fire. Managed disks are server-side encrypted at rest unconditionally. The platform applies encryption with platform-managed keys to every managed disk, and there is no API, flag, or portal setting that turns it off. The discoverer honestly reflects that: it derives encryption_at_rest from the disk’s ARM encryption block, and on the current provider contract the value it emits is always “true”. The rule’s firing condition is an explicit “false”, so on real Azure data it abstains on every disk, every run.
Why keep a dormant rule
Deliberate tripwire design. The evaluation is cheap, and the condition it watches for, a provider reporting an unencrypted disk, is exactly the kind of contract change that should surface loudly rather than silently. If a future discoverer version, a new disk type, or a provider-side change ever produces encryption_at_rest as “false”, a high-severity compliance finding appears immediately with no code change. Contrast that with the rule’s own history: its first version read a tag that no producer ever wrote, which made it dead in a way nobody could observe. Fail-closed on missing metadata, fire only on explicit evidence. The dormancy is the correct behavior, not an oversight.
Verify a disk’s encryption story yourself
az disk show -n <disk> -g <rg> \ --query "{name:name, encryption:encryption.type, sku:sku.name}"Expect EncryptionAtRestWithPlatformKey on a default disk. That value is the platform confirming what this rule assumes.
The decisions that remain open
Since baseline encryption is guaranteed, the real compliance questions on Azure disks live one level up: whether platform-managed keys are sufficient or your framework demands customer-managed keys from Key Vault, and whether double encryption at rest is warranted for the most sensitive volumes. Those are ownership and defense-in-depth decisions, not on/off decisions, and they are outside this rule’s scope, which covers only the baseline. ZopNight reads the disk metadata through Azure Resource Graph under the built-in Reader role, performs no writes for this rule, and attaches no savings figure: the finding class is purely about encryption posture, and on Azure the platform has already closed it.