Configure Azure Storage firewalls and virtual networks
Azure Storage provides a layered security model. This model enables you to control the level of access to your storage accounts that your applications and enterprise environments demand, based on the type and subset of networks or resources that you use.
When you configure network rules, only applications that request data over the specified set of networks or through the specified set of Azure resources can access a storage account. You can limit access to your storage account to requests that come from specified IP addresses, IP ranges, subnets in an Azure virtual network, or resource instances of some Azure services.
Storage accounts have a public endpoint that's accessible through the internet. You can also create private endpoints for your storage account. Creating private endpoints assigns a private IP address from your virtual network to the storage account. It helps secure traffic between your virtual network and the storage account over a private link.
The Azure Storage firewall provides access control for the public endpoint of your storage account. You can also use the firewall to block all access through the public endpoint when you're using private endpoints. Your firewall configuration also enables trusted Azure platform services to access the storage account.
An application that accesses a storage account when network rules are in effect still requires proper authorization for the request. Authorization is supported with Microsoft Entra credentials for blobs, tables, file shares and queues, with a valid account access key, or with a shared access signature (SAS) token. When you configure a blob container for anonymous access, requests to read data in that container don't need to be authorized. The firewall rules remain in effect and will block anonymous traffic.
Turning on firewall rules for your storage account blocks incoming requests for data by default, unless the requests originate from a service that operates within an Azure virtual network or from allowed public IP addresses. Requests that are blocked include those from other Azure services, from the Azure portal, and from logging and metrics services.
You can grant access to Azure services that operate from within a virtual network by allowing traffic from the subnet that hosts the service instance. You can also enable a limited number of scenarios through the exceptions mechanism that this article describes. To access data from the storage account through the Azure portal, you need to be on a machine within the trusted boundary (either IP or virtual network) that you set up.
Note
We recommend that you use the Azure Az PowerShell module to interact with Azure. To get started, see Install Azure PowerShell. To learn how to migrate to the Az PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.
Scenarios
To secure your storage account, you should first configure a rule to deny access to traffic from all networks (including internet traffic) on the public endpoint, by default. Then, you should configure rules that grant access to traffic from specific virtual networks. You can also configure rules to grant access to traffic from selected public internet IP address ranges, enabling connections from specific internet or on-premises clients. This configuration helps you build a secure network boundary for your applications.
You can combine firewall rules that allow access from specific virtual networks and from public IP address ranges on the same storage account. You can apply storage firewall rules to existing storage accounts or when you create new storage accounts.
Storage firewall rules apply to the public endpoint of a storage account. You don't need any firewall access rules to allow traffic for private endpoints of a storage account. The process of approving the creation of a private endpoint grants implicit access to traffic from the subnet that hosts the private endpoint.
Important
Azure Storage firewall rules only apply to data plane operations. Control plane operations are not subject to the restrictions specified in firewall rules.
Some operations, such as blob container operations, can be performed through both the control plane and the data plane. So if you attempt to perform an operation such as listing containers from the Azure portal, the operation will succeed unless it is blocked by another mechanism. Attempts to access blob data from an application such as Azure Storage Explorer are controlled by the firewall restrictions.
For a list of data plane operations, see the Azure Storage REST API Reference. For a list of control plane operations, see the Azure Storage Resource Provider REST API Reference.
Configure network access to Azure Storage
You can control access to the data in your storage account over network endpoints, or through trusted services or resources in any combination including:
- Allow access from selected virtual network subnets using private endpoints.
- Allow access from selected virtual network subnets using service endpoints.
- Allow access from specific public IP addresses or ranges.
- Allow access from selected Azure resource instances.
- Allow access from trusted Azure services (using Manage exceptions).
- Configure exceptions for logging and metrics services.
About virtual network endpoints
There are two types of virtual network endpoints for storage accounts:
Virtual network service endpoints are public and accessible via the internet. The Azure Storage firewall provides the ability to control access to your storage account over such public endpoints. When you enable public network access to your storage account, all incoming requests for data are blocked by default. Only applications that request data from allowed sources that you configure in your storage account firewall settings will be able to access your data. Sources can include the source IP address or virtual network subnet of a client, or an Azure service or resource instance through which clients or services access your data. Requests that are blocked include those from other Azure services, from the Azure portal, and from logging and metrics services, unless you explicitly allow access in your firewall configuration.
A private endpoint uses a private IP address from your virtual network to access a storage account over the Microsoft backbone network. With a private endpoint, traffic between your virtual network and the storage account are secured over a private link. Storage firewall rules only apply to the public endpoints of a storage account, not private endpoints. The process of approving the creation of a private endpoint grants implicit access to traffic from the subnet that hosts the private endpoint. You can use Network Policies to control traffic over private endpoints if you want to refine access rules. If you want to use private endpoints exclusively, you can use the firewall to block all access through the public endpoint.
To help you decide when to use each type of endpoint in your environment, see Compare Private Endpoints and Service Endpoints.
How to approach network security for your storage account
To secure your storage account and build a secure network boundary for your applications:
Start by disabling all public network access for the storage account under the Public network access setting in the storage account firewall.
Where possible, configure private links to your storage account from private endpoints on virtual network subnets where the clients reside that require access to your data.
If client applications require access over the public endpoints, change the Public network access setting to Enabled from selected virtual networks and IP addresses. Then, as needed:
- Specify the virtual network subnets from which you want to allow access.
- Specify the public IP address ranges of clients from which you want to allow access, such as those on on-premises networks.
- Allow access from selected Azure resource instances.
- Add exceptions to allow access from trusted services required for operations such as backing up data.
- Add exceptions for logging and metrics.
After you apply network rules, they're enforced for all requests. SAS tokens that grant access to a specific IP address serve to limit the access of the token holder, but they don't grant new access beyond configured network rules.
network security perimeter (preview)
network security perimeter (preview) allows organizations to define a logical network isolation boundary for PaaS resources (for example, Azure Blob Storage and SQL Database) that are deployed outside their virtual networks. The feature restricts public network access to PaaS resources outside the perimeter. However, you can exempt access by using explicit access rules for public inbound and outbound traffic. By design, access to a storage account from within a network security perimeter takes the highest precedence over other network access restrictions.
Currently, network security perimeter is in public preview for Azure Blobs, Azure Files (REST), Azure Tables, and Azure Queues. See Transition to a network security perimeter.
The list of services that have been onboarded to network security perimeter can be found here.
For services that are not on this list as they have not yet been onboarded to network security perimeter, if you would like to allow access you can use a subscription-based rule on the network security perimeter. All resources within that subscription will then be given access to that network security perimeter. For more information on adding subscription-based access rule, refer here.
Important
Private endpoint traffic is considered highly secure and therefore isn't subject to network security perimeter rules. All other traffic, including trusted services, will be subject to network security perimeter rules if the storage account is associated with a perimeter.
Limitations
This preview doesn't support the following services, operations, and protocols on a storage account:
- Object replication for Azure Blob Storage
- Lifecycle management for Azure Blob Storage
- SSH File transfer protocol (SFTP) over Azure Blob Storage
- Network file system (NFS) protocol with Azure Blob Storage and Azure Files.
- Server message block (SMB) protocol with Azure Files can only be achieved through IP allowlisting at this time.
- Azure Blob Inventory
We recommend you don't enable network security perimeter if you need to use any of these services, operations, or protocols. This is to prevent any potential data loss or data exfiltration risk.
Warning
For storage accounts that are associated with a network security perimeter, in order for customer managed keys (CMK) scenarios to work, ensure that the Azure Key Vault is accessible from within the perimeter to which the storage account has been associated.
Associate a network security perimeter with a storage account
To associate a network security perimeter with a storage account, follow these common instructions for all PaaS resources.
Restrictions and considerations
Before implementing network security for your storage accounts, review the important restrictions and considerations discussed in this section.
- Azure Storage firewall rules only apply to data plane operations. Control plane operations are not subject to the restrictions specified in firewall rules.
- Review the Restrictions for IP network rules.
- To access data by using tools such as the Azure portal, Azure Storage Explorer, and AzCopy, you must be on a machine within the trusted boundary that you establish when configuring network security rules.
- Network rules are enforced on all network protocols for Azure Storage, including REST and SMB.
- Network rules don't affect virtual machine (VM) disk traffic, including mount and unmount operations and disk I/O, but they do help protect REST access to page blobs.
- You can use unmanaged disks in storage accounts with network rules applied to back up and restore VMs by creating an exception. Firewall exceptions aren't applicable to managed disks, because Azure already manages them.
- Classic storage accounts don't support firewalls and virtual networks.
- If you delete a subnet that's included in a virtual network rule, it will be removed from the network rules for the storage account. If you create a new subnet by the same name, it won't have access to the storage account. To allow access, you must explicitly authorize the new subnet in the network rules for the storage account.
- When referencing a service endpoint in a client application, it's recommended that you avoid taking a dependency on a cached IP address. The storage account IP address is subject to change, and relying on a cached IP address may result in unexpected behavior. Additionally, it's recommended that you honor the time-to-live (TTL) of the DNS record and avoid overriding it. Overriding the DNS TTL may result in unexpected behavior.
- By design, access to a storage account from trusted services takes the highest precedence over other network access restrictions. If you set Public network access to Disabled after previously setting it to Enabled from selected virtual networks and IP addresses, any resource instances and exceptions that you previously configured, including Allow Azure services on the trusted services list to access this storage account, will remain in effect. As a result, those resources and services might still have access to the storage account.
Authorization
Clients granted access via network rules must continue to meet the authorization requirements of the storage account to access the data. Authorization is supported with Microsoft Entra credentials for blobs and queues, with a valid account access key, or with a shared access signature (SAS) token.
When you configure a blob container for anonymous public access, requests to read data in that container don't need to be authorized, but the firewall rules remain in effect and will block anonymous traffic.
Change the default network access rule
By default, storage accounts accept connections from clients on any network. You can limit access to selected networks or prevent traffic from all networks and permit access only through a private endpoint.
You must set the default rule to deny, or network rules have no effect. However, changing this setting can affect your application's ability to connect to Azure Storage. Be sure to grant access to any allowed networks or set up access through a private endpoint before you change this setting.
Note
We recommend that you use the Azure Az PowerShell module to interact with Azure. To get started, see Install Azure PowerShell. To learn how to migrate to the Az PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.
Go to the storage account that you want to secure.
In the service menu, under Security + networking, select Networking.
Choose what network access is enabled through the storage account's public endpoint:
Select either Enabled from all networks or Enabled from selected virtual networks and IP addresses. If you select the second option, you'll be prompted to add virtual networks and IP address ranges.
To restrict inbound access while allowing outbound access, select Disabled.
Select Save to apply your changes.
Grant access from a virtual network
You can configure storage accounts to allow access only from specific subnets. The allowed subnets can belong to a virtual network in the same subscription or a different subscription, including those that belong to a different Microsoft Entra tenant. With cross-region service endpoints, the allowed subnets can also be in different regions from the storage account.
You can enable a service endpoint for Azure Storage within the virtual network. The service endpoint routes traffic from the virtual network through an optimal path to the Azure Storage service. The identities of the subnet and the virtual network are also transmitted with each request. Administrators can then configure network rules for the storage account that allow requests to be received from specific subnets in a virtual network. Clients granted access via these network rules must continue to meet the authorization requirements of the storage account to access the data.
Each storage account supports up to 400 virtual network rules. You can combine these rules with IP network rules.
Important
When referencing a service endpoint in a client application, it's recommended that you avoid taking a dependency on a cached IP address. The storage account IP address is subject to change, and relying on a cached IP address may result in unexpected behavior.
Additionally, it's recommended that you honor the time-to-live (TTL) of the DNS record and avoid overriding it. Overriding the DNS TTL may result in unexpected behavior.
Required permissions
To apply a virtual network rule to a storage account, the user must have the appropriate permissions for the subnets that are being added. A Storage Account Contributor or a user who has permission to the Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action Azure resource provider operation can apply a rule by using a custom Azure role.
The storage account and the virtual networks that get access can be in different subscriptions, including subscriptions that are a part of a different Microsoft Entra tenant.
Configuration of rules that grant access to subnets in virtual networks that are a part of a different Microsoft Entra tenant are currently supported only through PowerShell, the Azure CLI, and REST APIs. You can't configure such rules through the Azure portal, though you can view them in the portal.
Azure Storage cross-region service endpoints
Cross-region service endpoints for Azure Storage became generally available in April 2023. They work between virtual networks and storage service instances in any region. With cross-region service endpoints, subnets no longer use a public IP address to communicate with any storage account, including those in another region. Instead, all the traffic from subnets to storage accounts uses a private IP address as a source IP. As a result, any storage accounts that use IP network rules to permit traffic from those subnets no longer have an effect.
Configuring service endpoints between virtual networks and service instances in a paired region can be an important part of your disaster recovery plan. Service endpoints allow continuity during a regional failover and access to read-only geo-redundant storage (RA-GRS) instances. Network rules that grant access from a virtual network to a storage account also grant access to any RA-GRS instance.
When you're planning for disaster recovery during a regional outage, create the virtual networks in the paired region in advance. Enable service endpoints for Azure Storage, with network rules granting access from these alternative virtual networks. Then apply these rules to your geo-redundant storage accounts.
Local and cross-region service endpoints can't coexist on the same subnet. To replace existing service endpoints with cross-region ones, delete the existing Microsoft.Storage endpoints and re-create them as cross-region endpoints (Microsoft.Storage.Global).
Managing virtual network and access rules
You can manage virtual network and access rules for storage accounts through the Azure portal, PowerShell, or the Azure CLI v2.
If you want to enable access to your storage account from a virtual network or subnet in another Microsoft Entra tenant, you must use PowerShell or the Azure CLI. The Azure portal doesn't show subnets in other Microsoft Entra tenants.
Go to the storage account for which you want to configure virtual network and access rules.
In the service menu, under Security + networking, select Networking.
Check that you've chosen to enable public network access from selected virtual networks and IP addresses.
To grant access to a virtual network by using a new network rule, under Virtual networks, select Add existing virtual network. Select the Virtual networks and Subnets options, and then select Add. To create a new virtual network and grant it access, select Add new virtual network. Provide the necessary information to create the new virtual network, and then select Create. Currently, only virtual networks that belong to the same Microsoft Entra tenant appear for selection during rule creation. To grant access to a subnet in a virtual network that belongs to another tenant, use PowerShell, the Azure CLI, or REST API.
To remove a virtual network or subnet rule, select the ellipsis (...) to open the context menu for the virtual network or subnet, and then select Remove.
Select Save to apply your changes.
Important
If you delete a subnet that's included in a network rule, it will be removed from the network rules for the storage account. If you create a new subnet by the same name, it won't have access to the storage account. To allow access, you must explicitly authorize the new subnet in the network rules for the storage account.
Grant access from an internet IP range
You can use IP network rules to allow access from specific public internet IP address ranges by creating IP network rules. Each storage account supports up to 400 rules. These rules grant access to specific internet-based services and on-premises networks and block general internet traffic.
Restrictions for IP network rules
The following restrictions apply to IP address ranges:
IP network rules are allowed only for public internet IP addresses.
IP address ranges reserved for private networks (as defined in RFC 1918) aren't allowed in IP rules. Private networks include addresses that start with 10, 172.16 to 172.31, and 192.168.
You must provide allowed internet address ranges by using CIDR notation in the form 16.17.18.0/24 or as individual IP addresses like 16.17.18.19.
Small address ranges that use /31 or /32 prefix sizes are not supported. Configure these ranges by using individual IP address rules.
Only IPv4 addresses are supported for configuration of storage firewall rules.
Important
You can't use IP network rules in the following cases:
- To restrict access to clients in same Azure region as the storage account. IP network rules have no effect on requests that originate from the same Azure region as the storage account. Use Virtual network rules to allow same-region requests.
- To restrict access to clients in a paired region that are in a virtual network that has a service endpoint.
- To restrict access to Azure services deployed in the same region as the storage account. Services deployed in the same region as the storage account use private Azure IP addresses for communication. So, you can't restrict access to specific Azure services based on their public outbound IP address range.
Configuring access from on-premises networks
To grant access from your on-premises networks to your storage account by using an IP network rule, you must identify the internet-facing IP addresses that your network uses. Contact your network administrator for help.
If you're using Azure ExpressRoute from your premises, you need to identify the NAT IP addresses used for Microsoft peering. Either the service provider or the customer provides the NAT IP addresses.
To allow access to your service resources, you must allow these public IP addresses in the firewall setting for resource IPs.
Managing IP network rules
You can manage IP network rules for storage accounts through the Azure portal, PowerShell, or the Azure CLI v2.
Go to the storage account for which you want to manage IP network rules.
In the service menu, under Security + networking, select Networking.
Check that you've chosen to enable public network access from selected virtual networks and IP addresses.
To grant access to an internet IP range, enter the IP address or address range (in CIDR format) under Firewall > Address Range.
To remove an IP network rule, select the delete icon (
) next to the address range.Select Save to apply your changes.
Grant access from Azure resource instances
In some cases, an application might depend on Azure resources that can't be isolated through a virtual network or an IP address rule. But you still want to secure and restrict storage account access to only your application's Azure resources. You can configure storage accounts to allow access to specific resource instances of trusted Azure services by creating a resource instance rule.
The Azure role assignments of the resource instance determine the types of operations that a resource instance can perform on storage account data. Resource instances must be from the same tenant as your storage account, but they can belong to any subscription in the tenant.
You can add or remove resource network rules in the Azure portal:
Sign in to the Azure portal.
Locate your storage account and display the account overview.
In the service menu, under Security + networking, select Networking.
Check that you've chosen to enable public network access from selected virtual networks and IP addresses.
Scroll down to find Resource instances. In the Resource type dropdown list, select the resource type of your resource instance.
In the Instance name dropdown list, select the resource instance. You can also choose to include all resource instances in the current tenant, subscription, or resource group.
Select Save to apply your changes. The resource instance appears in the Resource instances section of the page for network settings.
To remove the resource instance, select the delete icon (
) next to the resource instance.
Grant access to trusted Azure services
Some Azure services operate from networks that you can't include in your network rules. You can grant a subset of such trusted Azure services access to the storage account, while maintaining network rules for other apps. These trusted services will then use strong authentication to connect to your storage account.
You can grant access to trusted Azure services by creating a network rule exception. The Manage exceptions section of this article provides step-by-step guidance.
Trusted access for resources registered in your Microsoft Entra tenant
Resources of some services can access your storage account for selected operations, such as writing logs or running backups. Those services must be registered in a subscription that is located in the same Microsoft Entra tenant as your storage account. The following table describes each service and the allowed operations.
| Service | Resource provider name | Allowed operations |
|---|---|---|
| Azure Backup | Microsoft.RecoveryServices |
Run backups and restores of unmanaged disks in infrastructure as a service (IaaS) virtual machines (not required for managed disks). Learn more. |
| Azure Data Box | Microsoft.DataBox |
Import data to Azure. Learn more. |
| Azure DevTest Labs | Microsoft.DevTestLab |
Create custom images and install artifacts. Learn more. |
| Azure Event Grid | Microsoft.EventGrid |
Enable Azure Blob Storage event publishing and allow publishing to storage queues. |
| Azure Event Hubs | Microsoft.EventHub |
Archive data by using Event Hubs Capture. Learn More. |
| Azure File Sync | Microsoft.StorageSync |
Transform your on-premises file server to a cache for Azure file shares. This capability allows multiple-site sync, fast disaster recovery, and cloud-side backup. Learn more. |
| Azure HDInsight | Microsoft.HDInsight |
Provision the initial contents of the default file system for a new HDInsight cluster. Learn more. |
| Azure Import/Export | Microsoft.ImportExport |
Import data to Azure Storage or export data from Azure Storage. Learn more. |
| Azure Monitor | Microsoft.Insights |
Write monitoring data to a secured storage account, including resource logs, Microsoft Defender for Endpoint data, Microsoft Entra sign-in and audit logs, and Microsoft Intune logs. Learn more. |
| Azure networking services | Microsoft.Network |
Store and analyze network traffic logs, including through the Azure Network Watcher and Azure Traffic Manager services. Learn more. |
| Azure Site Recovery | Microsoft.SiteRecovery |
Enable replication for disaster recovery of Azure IaaS virtual machines when you're using firewall-enabled cache, source, or target storage accounts. Learn more. |
Trusted access based on a managed identity
The following table lists services that can access your storage account data if the resource instances of those services have the appropriate permission.
| Service | Resource provider name | Purpose |
|---|---|---|
| Azure FarmBeats | Microsoft.AgFoodPlatform/farmBeats |
Enables access to storage accounts. |
| Azure API Management | Microsoft.ApiManagement/service |
Enables access to storage accounts behind firewalls via policies. Learn more. |
| Microsoft Autonomous Systems | Microsoft.AutonomousSystems/workspaces |
Enables access to storage accounts. |
| Azure Cache for Redis | Microsoft.Cache/Redis |
Enables access to storage accounts. Learn more. |
| Azure AI Search | Microsoft.Search/searchServices |
Enables access to storage accounts for indexing, processing, and querying. |
| Azure AI services | Microsoft.CognitiveService/accounts |
Enables access to storage accounts. Learn more. |
| Azure Container Registry | Microsoft.ContainerRegistry/registries |
Through the ACR Tasks suite of features, enables access to storage accounts when you're building container images. |
| Microsoft Cost Management | Microsoft.CostManagementExports |
Enables export to storage accounts behind a firewall. Learn more. |
| Azure Databricks | Microsoft.Databricks/accessConnectors |
Enables access to storage accounts. |
| Azure Data Factory | Microsoft.DataFactory/factories |
Enables access to storage accounts through the Data Factory runtime. |
| Azure Backup Vault | Microsoft.DataProtection/BackupVaults |
Enables access to storage accounts. |
| Azure Data Share | Microsoft.DataShare/accounts |
Enables access to storage accounts. |
| Azure Database for PostgreSQL | Microsoft.DBForPostgreSQL |
Enables access to storage accounts. |
| Azure IoT Hub | Microsoft.Devices/IotHubs |
Allows data from an IoT hub to be written to Blob Storage. Learn more. |
| Azure DevTest Labs | Microsoft.DevTestLab/labs |
Enables access to storage accounts. |
| Azure Event Grid | Microsoft.EventGrid/domains |
Enables access to storage accounts. |
| Azure Event Grid | Microsoft.EventGrid/partnerTopics |
Enables access to storage accounts. |
| Azure Event Grid | Microsoft.EventGrid/systemTopics |
Enables access to storage accounts. |
| Azure Event Grid | Microsoft.EventGrid/topics |
Enables access to storage accounts. |
| Microsoft Fabric | Microsoft.Fabric |
Enables access to storage accounts. |
| Azure Healthcare APIs | Microsoft.HealthcareApis/services |
Enables access to storage accounts. |
| Azure Healthcare APIs | Microsoft.HealthcareApis/workspaces |
Enables access to storage accounts. |
| Azure IoT Central | Microsoft.IoTCentral/IoTApps |
Enables access to storage accounts. |
| Azure Key Vault Managed HSM | Microsoft.keyvault/managedHSMs |
Enables access to storage accounts. |
| Azure Logic Apps | Microsoft.Logic/integrationAccounts |
Enables logic apps to access storage accounts. Learn more. |
| Azure Logic Apps | Microsoft.Logic/workflows |
Enables logic apps to access storage accounts. Learn more. |
| Azure Machine Learning studio | Microsoft.MachineLearning/registries |
Enables authorized Azure Machine Learning workspaces to write experiment output, models, and logs to Blob Storage and read the data. Learn more. |
| Azure Machine Learning | Microsoft.MachineLearningServices |
Enables authorized Azure Machine Learning workspaces to write experiment output, models, and logs to Blob Storage and read the data. Learn more. |
| Azure Machine Learning | Microsoft.MachineLearningServices/workspaces |
Enables authorized Azure Machine Learning workspaces to write experiment output, models, and logs to Blob Storage and read the data. Learn more. |
| Azure Media Services | Microsoft.Media/mediaservices |
Enables access to storage accounts. |
| Azure Migrate | Microsoft.Migrate/migrateprojects |
Enables access to storage accounts. |
| Azure ExpressRoute | Microsoft.Network/expressRoutePorts |
Enables access to storage accounts. |
| Microsoft Power Platform | Microsoft.PowerPlatform/enterprisePolicies |
Enables access to storage accounts. |
| Microsoft Project Arcadia | Microsoft.ProjectArcadia/workspaces |
Enables access to storage accounts. |
| Azure Data Catalog | Microsoft.ProjectBabylon/accounts |
Enables access to storage accounts. |
| Microsoft Purview | Microsoft.Purview/accounts |
Enables access to storage accounts. |
| Azure Site Recovery | Microsoft.RecoveryServices/vaults |
Enables access to storage accounts. |
| Security Center | Microsoft.Security/dataScanners |
Enables access to storage accounts. |
| Singularity | Microsoft.Singularity/accounts |
Enables access to storage accounts. |
| Azure SQL Database | Microsoft.Sql |
Allows writing audit data to storage accounts behind a firewall. |
| Azure SQL Servers | Microsoft.Sql/servers |
Allows writing audit data to storage accounts behind a firewall. |
| Azure Synapse Analytics | Microsoft.Sql |
Allows import and export of data from specific SQL databases via the COPY statement or PolyBase (in a dedicated pool), or the openrowset function and external tables in a serverless pool. Learn more. |
| Azure Stream Analytics | Microsoft.StreamAnalytics |
Allows data from a streaming job to be written to Blob Storage. Learn more. |
| Azure Stream Analytics | Microsoft.StreamAnalytics/streamingjobs |
Allows data from a streaming job to be written to Blob Storage. Learn more. |
| Azure Synapse Analytics | Microsoft.Synapse/workspaces |
Enables access to data in Azure Storage. |
| Azure Video Indexer | Microsoft.VideoIndexer/Accounts |
Enables access to storage accounts. |
If your account doesn't have the hierarchical namespace feature enabled on it, you can grant permission by explicitly assigning an Azure role to the managed identity for each resource instance. In this case, the scope of access for the instance corresponds to the Azure role that's assigned to the managed identity.
You can use the same technique for an account that has the hierarchical namespace feature enabled on it. However, you don't have to assign an Azure role if you add the managed identity to the access control list (ACL) of any directory or blob that the storage account contains. In that case, the scope of access for the instance corresponds to the directory or file to which the managed identity has access.
You can also combine Azure roles and ACLs together to grant access. To learn more, see Access control model in Azure Data Lake Storage.
We recommend that you use resource instance rules to grant access to specific resources.
Manage exceptions
In some cases, like storage analytics, access to read resource logs and metrics is required from outside the network boundary. When you configure trusted services to access the storage account, you can allow read access for the log files, metrics tables, or both by creating a network rule exception. You can manage network rule exceptions through the Azure portal, PowerShell, or the Azure CLI v2.
To learn more about working with storage analytics, see Use Azure Storage analytics to collect logs and metrics data.
Go to the storage account for which you want to manage exceptions.
In the service menu, under Security + networking, select Networking.
Check that you've chosen to enable public network access from selected virtual networks and IP addresses.
Under Exceptions, select the exceptions that you want to grant.
Select Save to apply your changes.
Next steps
- Learn more about Azure network service endpoints.
- Dig deeper into security recommendations for Azure Blob storage.