Restrict Azure Storage Account Access to Microsoft Dynamics 365 Business Central SaaS Only

Deploy an Azure Function as the controlled proxy between Business Central SaaS and Azure Storage, allow inbound Function requests only from the Dynamics365BusinessCentral service tag, and give the Function private access to the Storage account.

Recommended architecture

Business Central SaaS
        |
        | HTTPS, allowed source:
        | Dynamics365BusinessCentral service tag
        v
Azure Function proxy
        |
        | VNet integration + private endpoint
        | Managed identity authorization
        v
Azure Storage account
Public network access: Disabled

Microsoft publishes the Dynamics365BusinessCentral service tag, but it represents addresses used by all Business Central environments. It cannot be narrowed to one environment, tenant, or Business Central region.^1^

For an Azure Storage destination in the same or paired region, Microsoft specifically documents the Function proxy pattern. Directly adding Business Central public IP ranges to the Storage firewall is not reliable because same-region Azure service traffic uses internal Azure addresses; Storage IP firewall rules do not restrict that traffic.^2^

Implementation

1. Identify the Business Central region
   • Open Dynamics 365 Business Central admin center.
   • Select the production or sandbox environment.
   • Record its Azure Region field.^3^
   • Deploy the Function in the same Business Central region where available. The documented Storage pattern also applies when Storage is in the same or paired region.
2. Deploy an HTTP-triggered Azure Function
   • Make its API narrowly scoped—for example, upload a document to one container rather than accepting arbitrary Storage operations.
   • Configure the Function to reject requests that are not authenticated and authorized for the intended integration. The service tag alone identifies a Business Central network source, not your particular tenant or environment.
3. Restrict inbound Function traffic
   • In the Function App, open Networking → Access restrictions.
   • Add an Allow rule whose source type is Service Tag and value is:

          Dynamics365BusinessCentral
     

   • Give it a higher priority than deny rules.
   • Remove broad allow rules. Once access-restriction entries exist, App Service applies an implicit deny at the end of the list.^4^
4. Connect the Function privately to Storage
   • Integrate the Function with a VNet.
   • Create the appropriate Storage private endpoint—such as blob—in that VNet.
   • Configure and link private DNS so the Storage FQDN resolves to the private endpoint from the Function.
   • In Storage account → Networking, set Public network access to Disabled after validating the private path.
   With public access disabled, only private-endpoint requests are accepted. Microsoft recommends private endpoints when private connectivity is required or the public endpoint should be disabled.^5^
5. Authorize the Function with least privilege
   • Enable a managed identity on the Function.
   • Grant only the required Storage data role at the smallest practical scope, such as the target blob container.
   • Avoid using a Storage account key as a long-lived application credential. Microsoft recommends Microsoft Entra authorization with managed identities and narrowly scoped data-plane roles.^5^
6. Update the Business Central extension
   • Replace direct calls to the Storage endpoint with calls to the Function endpoint.
   • Keep Storage-specific credentials and operations inside the proxy.

Published Business Central IP ranges

The current ranges can be retrieved from the service tag:

$tags = Get-AzNetworkServiceTag -Location eastus2
$bc = $tags.Values |
    Where-Object Name -eq 'Dynamics365BusinessCentral'

"Change number: $($bc.Properties.ChangeNumber)"
$bc.Properties.AddressPrefixes

The ChangeNumber can be monitored to detect updates.^1^

These ranges are useful for destinations that support IP allow-listing but not service tags. They do not provide ranges for one Indian environment or one tenant: the Business Central tag is global and shared across environments. For Storage in the same or paired region, do not substitute these addresses for the proxy/private-endpoint design.

Resulting security boundary

This design provides:

• No public network path to Storage.
• Function ingress limited to Business Central service infrastructure.
• Private Function-to-Storage connectivity.
• Identity-based, least-privilege Storage authorization.
• Optional tenant/environment-level enforcement in the Function’s authentication and application logic.

The network service tag by itself cannot guarantee “only this specific Business Central environment”; that final distinction must be enforced through authentication and authorization at the Function proxy.

References

1. Use Azure security service tags to restrict network access from/to Business Central
2. Guidelines and limitations for the Azure Storage firewall
3. Data movement across geographies for Business Central Copilot and agent capabilities
4. Azure Functions networking options (consumption-plan)
5. Secure your Azure Storage account