Azure Storage 'Selected Networks' Firewall Still Allows Trusted Azure Services Through

Symptom

A platform team locks down an Azure Storage account by switching its networking configuration from ‘All networks’ to ‘Selected networks’, adding only the subnet IDs for their application tier. Storage firewall diagnostics show the expected default-deny posture, and manual test requests from outside the approved subnets return the expected 403 network rule violation. Despite this, security review later finds that a different team’s Azure Backup vault, an unrelated Cognitive Services resource, and an Azure Monitor diagnostic pipeline in another subscription have all been reading and writing blobs in the account, none of which appear in the allowed subnet or IP rule list.

False Assumption

The team assumed that setting the storage account’s public network access to ‘Selected networks’ and adding only their own subnets was sufficient to restrict access to those subnets alone. They treated the firewall configuration screen as a complete allow-list, not realising a separate toggle, ‘Allow Azure services on the trusted services list to access this storage account’, remains enabled by default and is evaluated independently of the subnet and IP rules.

Root Cause

Azure Storage account network rules and the trusted-services exception are two distinct, independently evaluated controls, not a single unified allow-list. When ‘Allow trusted Microsoft services to access this storage account’ is enabled, a defined set of first-party Azure services (including Azure Backup, Azure Site Recovery, Azure Monitor, and others documented under the Microsoft cloud security benchmark’s networking and identity guidance) can reach the storage account using their own managed identity or resource-based authorisation, entirely bypassing the subnet and IP-based firewall rules. This exception exists to keep first-party platform integrations functional after a customer restricts network access, but it is enabled by default and is easy to overlook because it sits below the subnet/IP rule list in the portal rather than beside it as an equivalent rule.

Impact

Any resource that authenticates as one of the trusted Azure services, in this subscription or another one the account owner does not control, can read or write storage data even though the account’s own firewall rules only name a small internal subnet list. This breaks the intended blast-radius assumption behind ‘Selected networks’: the network boundary the team believed they had built does not hold against trusted-service traffic, and access review based solely on subnet and IP rules will materially understate who or what can reach the data.

Diagnosis

Confirm the exception is active and identify what it is granting access to before changing anything.

• Review the storage account’s Networking blade (or the equivalent resource properties) for the public network access setting and confirm it is set to ‘Selected networks’ rather than ‘Disabled’.
• Check whether ‘Allow Azure services on the trusted services list to access this storage account’ (the resourceAccessRules/trusted-services exception) is enabled, separately from the subnet and IP rule list.
• List which resources in the tenant use managed identities or resource instance rules that fall under Microsoft’s documented trusted-services categories, and cross-reference storage access logs (where diagnostic logging is enabled) for read/write activity from identities outside the intended subnet list.
• Treat any access attributed to a trusted-service identity as expected only if that specific integration (for example, a named backup vault) was deliberately approved; otherwise flag it for review.

Correction

Narrow the exception to only the specific trusted-service integrations the account genuinely needs, rather than leaving the blanket toggle enabled.

Where the platform supports it, replace the blanket trusted-services exception with resource instance rules that name the specific resource (for example, a specific Backup vault resource ID) permitted to bypass the network rule, and disable the account-wide trusted-services exception once those explicit resource instance rules are in place. This preserves the specific integrations that must keep working while removing the open-ended exception that grants any resource in the trusted-services category implicit access.

Validation

Confirm that only the explicitly approved resource instances retain access and that the blanket exception no longer applies.

• Re-open the storage account’s Networking configuration and confirm ‘Allow trusted Microsoft services’ is now disabled (or scoped to resource instance rules only, if the platform surfaces that distinction).
• Confirm each previously observed unexpected caller (the unrelated Cognitive Services resource and any other unapproved consumer) can no longer authenticate against the account; expect a 403 network rule violation from those identities after the change.
• Confirm the approved integration (for example, the named Backup vault) that was granted an explicit resource instance rule continues to function without new access errors during its next scheduled operation.
• Review storage diagnostic logs, where enabled, for a period after the change to confirm no further trusted-service traffic from unapproved resources is being accepted.

Rollback

If disabling the blanket exception breaks a legitimate integration that was not correctly captured in a resource instance rule, re-enable the account-wide trusted-services toggle immediately to restore the previous access state while the missing integration is identified and given an explicit resource instance rule.

• Stop condition: any approved service integration reports authentication or access failures within its normal operating window after the change.
• Rollback action: re-enable ‘Allow Azure services on the trusted services list to access this storage account’ on the storage account’s networking configuration, restoring the prior default-exception behaviour.
• Recovery path: once the missing integration is identified, add an explicit resource instance rule for that specific resource, then disable the blanket exception again and re-run validation.

Prevention

Document the trusted-services exception as a named, reviewed control rather than an implicit default whenever a storage account’s networking is scoped to ‘Selected networks’. During any future network lockdown of a storage account, explicitly record which trusted-service integrations are required, prefer resource instance rules over the blanket exception, and include the trusted-services setting in access reviews and infrastructure-as-code definitions so it cannot silently drift back to an open default during subsequent changes.