Do not use Azure Firewall connection logs as Azure Files operation records

Source facts

In its secured-virtual-hub guidance, Microsoft says Azure Firewall network-rule entries for Azure Files private endpoints are generated when the client first connects or mounts the share. Individual create, read, update and delete operations do not produce corresponding firewall entries because they use that persistent TCP connection.

The same guidance says network-rule logs omit FQDN information and should be filtered using the address and port. The article’s architecture scope is a secured virtual hub, not a firewall in a conventional hub VNet. Microsoft Learn.

Applicability

Identify the client, share endpoint, firewall path, and connection interval under investigation. Keep the question of whether the initial connection was inspected separate from the question of which files were subsequently accessed.

DSE recommendation

DSE recommends labeling firewall evidence as connection-level evidence in the investigation record. Ask the file-service owner to identify and validate an appropriate additional evidence source for any operation-level requirement. Do not interpret the absence of one firewall entry per file action as proof of either bypass or inactivity.

Verification

In an approved test, establish a fresh share connection and perform a small set of harmless, recorded file operations. Correlate the initial connection with address-and-port firewall evidence. Compare the individual operations with the separately selected file evidence, documenting any gaps. Preserve the tested architecture and time boundaries so conclusions are not generalized to an untested traffic path.

Official references

Microsoft Learn: Secure traffic destined to private endpoints in Azure Virtual WAN. Source retrieved September 9, 2026.