Storage accounts where anonymous blob access is allowed

Permission to expose is not the same as exposure

The flag this rule reads, ARM allowBlobPublicAccess on the storage account, does not make any data public by itself. Containers default to no public access, and a blob only becomes anonymously readable after someone opens its container individually. What the flag does is keep that door unlockable: while it is true, a single container-level setting change, by any principal with the right role, publishes data to the unauthenticated internet with no further approval.

Query the flag fleet-wide

az storage account list \
  --query "[?allowBlobPublicAccess == \`true\`].{name:name, rg:resourceGroup}" \
  -o table

What the rule can prove and what it cannot

Detection is fail-closed on the account-level flag: the discoverer stamps public_access_enabled from control-plane state, the rule fires only on an explicit “true”, and an absent flag produces nothing. What it cannot do today is enumerate container-level access, because no producer collects it. So a finding proves the account permits anonymous access but only infers that exposure is possible. It never claims your blobs are reachable. Confirming actual exposure would require walking every container’s public-access setting, a producer that does not yet exist. This evidence boundary is exactly why severity stops at high, the tier for a permissive configuration, instead of critical, the tier for confirmed exposure.

The account switch beats container audits

Chasing individual public containers is a treadmill: any future container can be opened tomorrow. Disabling allowBlobPublicAccess at the account overrides every container setting beneath it in one move, current and future. That is the same pattern as a subscription-wide policy, applied per account. CIS and the Azure Security Benchmark both track this control at the account level for that reason.

Before you disable it

Some accounts serve genuinely public content: static websites, published downloads, public images. Flipping the flag on those breaks anonymous readers immediately, so inventory what depends on anonymous access first, then move authorized consumers to SAS tokens or Microsoft Entra authorization. For everything else:

az storage account update -n <account> -g <rg> --allow-blob-public-access false

Detection runs entirely under the built-in Reader role; ZopNight makes no writes here, and there is no cost dimension. The finding is worth acting on because the remediation is one reversible command.