Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure Network Security Perimeter creates logical network boundaries around your platform-as-a-service (PaaS) resources that you deploy outside your virtual networks. By establishing a secure perimeter, network security perimeter helps you control public network access to resources like Azure Storage accounts and Azure Key Vault.
By default, network security perimeter restricts public access to PaaS resources within the boundary. You can grant exceptions through explicit access rules for inbound and outbound traffic. This approach helps prevent data exfiltration while maintaining necessary connectivity for your applications.
For access patterns that involve traffic from virtual networks to PaaS resources, see What is Azure Private Link?
Features of a network security perimeter include:
- Resource-to-resource access communication within perimeter members, which prevents data exfiltration to nonauthorized destinations.
- External public access management with explicit rules for PaaS resources associated with the perimeter.
- Access logs for audit and compliance.
- Unified experience across PaaS resources.
Important
Network security perimeter is now generally available in all Azure public cloud regions and in Azure Government regions (US Gov Virginia, US Gov Texas, US Gov Arizona, US DoD East and US DoD Central). For information on supported services, see Onboarded private link resources for supported PaaS services.
Components of a network security perimeter
A network security perimeter includes the following components:
| Component | Description |
|---|---|
| Network security perimeter | Top level resource defining logical network boundary to secure PaaS resources. |
| Profile | Collection of access rules that apply on resources associated with the profile. |
| Access rule | Inbound and outbound rules for resources in a perimeter to allow access outside the perimeter. |
| Resource association | Perimeter membership for a PaaS resource. |
| Network identifier | A public IP address or prefix associated with a service endpoint subnet, enabling network security perimeter to identify and authorize inbound traffic from IaaS resources. Used with standard service endpoint. |
| Diagnostics settings | Extension resource hosted by Microsoft Insights to collect logs & metrics for all resources in the perimeter. |
Note
For organizational and informational safety, don't include any personally identifiable or sensitive data in the network security perimeter rules or other network security perimeter configurations.
Network security perimeter properties
When creating a network security perimeter, you can specify the following properties:
| Property | Description |
|---|---|
| Name | A unique name within the resource group. |
| Location | A supported Azure region where the resource is located. |
| Resource group name | Name of the resource group where the network security perimeter should be present. |
Access modes in network security perimeter
Administrators add PaaS resources to a perimeter by creating resource associations. You can make these associations in two access modes. The access modes are:
| Mode | Description |
|---|---|
| Transition mode (formerly Learning mode) | - Default access mode. - Helps network administrators understand the existing access patterns of their PaaS resources. - Recommended mode of use before transitioning to enforced mode. |
| Enforced mode | - Set by the administrator. - By default, denies all traffic except intra-perimeter traffic unless an Allow access rule exists. |
To learn more about moving from transition mode (formerly learning mode) to enforced mode, see Transitioning to a network security perimeter.
Why use a network security perimeter?
A network security perimeter provides a secure perimeter for communication of PaaS services deployed outside the virtual network. It allows you to control network access to Azure PaaS resources. Some common use cases include:
- Create a secure boundary around PaaS resources.
- Prevent data exfiltration by associating PaaS resources to the perimeter.
- Enable access rules to grant access outside the secure perimeter.
- Manage access rules for all the PaaS resources within the network security perimeter in a single pane of glass.
- Enable diagnostic settings to generate access logs of PaaS resources within the perimeter for audit and compliance.
- Allow private endpoint traffic without the need for explicit access rules.
How does a network security perimeter work?
When you create a network security perimeter and associate PaaS resources with the perimeter in enforced mode, you deny all public traffic by default. This setup prevents data exfiltration outside the perimeter.
Use access rules to approve public inbound and outbound traffic outside the perimeter. Approve public inbound access by using the network and identity attributes of the client, such as source IP addresses and subscriptions. Approve public outbound access by using FQDNs (Fully Qualified Domain Names) of the external destinations.
By using standard service endpoint, a network security perimeter can also authorize inbound traffic by using network identifiers — public IP addresses or prefixes associated with service endpoint subnets. This approach provides scalable, identity-based IaaS-to-PaaS connectivity without requiring individual IP-based access rules.
For example, when you create a network security perimeter and associate a set of PaaS resources with the perimeter, such as Azure Key Vault and Azure Storage, in enforced mode, you deny all incoming and outgoing public traffic to these PaaS resources by default. To allow any access outside the perimeter, create the necessary access rules. Within the same perimeter, create profiles to group PaaS resources with similar sets of inbound and outbound access requirements.
Onboarded private link resources
A network security perimeter-aware private link resource is a PaaS resource that you can associate with a network security perimeter. Currently, the onboarded private link resources are as follows:
| Private link resource name | Resource type | Resources | Public cloud Availability | Gov Cloud Availability |
|---|---|---|---|---|
| Azure Monitor | Microsoft.Insights/dataCollectionEndpoints Microsoft.Insights/ScheduledQueryRules Microsoft.Insights/actionGroups Microsoft.OperationalInsights/workspaces |
Log Analytics Workspace, Application Insights, Alerts, Notification Service | Generally available | Not Available |
| Azure AI Search | Microsoft.Search/searchServices | Generally Available | Not Available | |
| Azure App Configuration | Microsoft.AppConfiguration/configurationStores | Public Preview | Not Available | |
| Cosmos DB | Microsoft.DocumentDB/databaseAccounts | Public Preview | Not Available | |
| Event Hubs | Microsoft.EventHub/namespaces | Generally Available | Not Available | |
| Key Vault | Microsoft.KeyVault/vaults | Generally Available | Generally Available | |
| SQL DB | Microsoft.Sql/servers | Public Preview | Not Available | |
| Storage | Microsoft.Storage/storageAccounts | Generally Available | Generally Available | |
| Azure OpenAI service | Microsoft.CognitiveServices(kind="OpenAI") | Public Preview | Not Available | |
| Microsoft Foundry | Microsoft.CognitiveServices/accounts Microsoft.CognitiveServices(kind="AIServices") |
Generally Available | Generally Available | |
| Azure Service Bus | Microsoft.ServiceBus/namespaces | Generally Available | Not Available | |
| Event Grid | Microsoft.EventGrid/domains | Public Preview | Not Available |
Important
The following onboarded services are in public preview with Network Security Perimeter:
- Azure App Configuration
- Cosmos DB
- SQL DB
- Azure OpenAI Service
- Event Grid
These previews are provided without a service level agreement, and don't use them for production workloads. Certain features might not be supported or might have constrained capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.
Note
For information about currently unsupported scenarios, refer to the respective private link resource documentation.
Where is network security perimeter available?
Network security perimeter is currently available in all Azure public cloud regions and in Azure Government regions (US Gov Virginia, US Gov Texas, US Gov Arizona, US DoD East, and US DoD Central).
Supported access rule types
Network security perimeter supports the following access rule types:
| Direction | Access rule type |
|---|---|
| Inbound | Subscription-based rules |
| Inbound | IP-based rules (check respective onboarded private link resources for v6 support) |
| Inbound | Service tags |
| Outbound | FQDN-based rules |
Note
Intra-perimeter traffic and inbound access rules that are subscription-based don't support authentication via shared access signature (SAS) token. In these scenarios, requests that use an SAS token are rejected and display an authentication error. Use an alternative supported authentication method per your specific resource.
Limitations of a network security perimeter
Logging limitations
While enabling access logs for network security perimeter, the Log Analytics workspace to associate with the network security perimeter needs to be located in one of the Azure Monitor supported regions.
Note
For PaaS resource logs, use Log Analytics Workspace, Storage, or Event Hub as the log destination associated to the same perimeter as the PaaS resource.
Microsoft Sentinel limitations
The following limitations are known:
- Network security perimeters aren't supported for Log Analytics workspaces enabled for Microsoft Sentinel. If you enable a network security perimeter on the workspace, analytic rules are automatically disabled. For more information, see Prerequisites for deploying Microsoft Sentinel.
- Azure Backup isn't supported for Storage Accounts enabled with network security perimeter. Don't associate a storage account with network security perimeter if you enable backups or if you plan to use Azure Backup.
- Querying workspaces with private link from Advanced hunting isn't supported.
Scale limitations
Network security perimeter functionality can be used to support deployments of PaaS resources with common public network controls with following scale limitations:
| Limitation | Description |
|---|---|
| Number of network security perimeters | Supported up to 100 as recommended limit per subscription. |
| Profiles per network security perimeters | Supported up to 200 as recommended limit. |
| Number of rule elements per profile | Supported up to 200 for inbound and outbound each as hard limit. |
| Number of PaaS resources across subscriptions associated with the same network security perimeter | Supported up to 1000 as recommended limit. |
Other limitations
Network security perimeter has other limitations as follows:
| Limitation/Issue | Description |
|---|---|
| Missing field in network security perimeter access logs | Network security perimeter access logs can be aggregated. If the fields 'count' and 'timeGeneratedEndTime' are missing, consider the aggregation count as 1. |
| Association creations through SDK fails with permission issue | 'Status: 403 (Forbidden); ErrorCode: AuthorizationFailed' might be received while performing action 'Microsoft.Network/locations/networkSecurityPerimeterOperationStatuses/read' over scope '/subscriptions/xyz/providers/Microsoft.Network/locations/xyz/networkSecurityPerimeterOperationStatuses/xyz'. Until the fix, use permission 'Microsoft.Network/locations/*/read' or use WaitUntil.Started in CreateOrUpdateAsync SDK API for association creations. |
| Resource names cannot be longer than 44 characters to support network security perimeter | The network security perimeter resource association created from the Azure portal has the format {resourceName}-{perimeter-guid}. To align with the requirement name field can't have more than 80 characters, resources names would have to be limited to 44 characters. |
Note
Refer to individual PaaS documentation for respective limitations for each service.