Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Azure Service Bus supports integration with a network security perimeter.
A network security perimeter helps safeguard network traffic between Azure Service Bus and other platform as a service (PaaS) offerings like Azure Key Vault. By confining communication solely to Azure resources within its boundaries, a network security perimeter blocks unauthorized attempts to access other resources.
With a network security perimeter:
- PaaS resources associated with a specific perimeter can, by default, communicate with only other PaaS resources within the same perimeter.
- You can actively permit external inbound and outbound communication by setting explicit access rules.
- Diagnostic logs are enabled for PaaS resources within the perimeter for audit and compliance.
Integrating Service Bus within this framework enhances messaging capabilities while providing robust security measures. This integration improves platform scalability and reliability. It also strengthens data protection strategies to mitigate risks associated with unauthorized access or data breaches.
By operating as a service under Azure Private Link, a network security perimeter facilitates secure communication for PaaS services deployed outside the virtual network. It enables seamless interaction among PaaS services within the perimeter and facilitates communication with external resources through carefully configured access rules. It also supports outbound resources such as Azure Key Vault for customer-managed keys (CMKs). This support further enhances its versatility and utility in diverse cloud environments.
Scenarios for network security perimeters in Service Bus
Azure Service Bus supports scenarios that require access to other PaaS resources. CMKs require communication with Azure Key Vault. For more information, see Configure customer-managed keys for encrypting Azure Service Bus data at rest.
For legacy geo-disaster recovery (alias-based pairing), both the primary and secondary namespaces must be associated with the same network security perimeter. If only the primary is associated, pairing fails.
Network security perimeter rules don't govern private link traffic through private endpoints.
Create a network security perimeter
Create your own network security perimeter resource by using the Azure portal, Azure PowerShell, or the Azure CLI.
Associate Service Bus with a network security perimeter in the Azure portal
You can associate your Service Bus namespace with a network security perimeter directly from the Service Bus namespace in the Azure portal:
On the page for your Service Bus namespace, under Settings, select Networking.
Select the Public access tab.
In the Network security perimeter section, select Associate.
In the Select network security perimeter dialog, search for and select the network security perimeter that you want to associate with the namespace.
Select a profile to associate with the namespace.
Select Associate to complete the association.
Verify the association by using the Azure CLI
To verify that your namespace is associated with a network security perimeter:
az servicebus namespace network-rule-set show \
--name <namespace-name> \
--resource-group <resource-group>
When the association exists, the publicNetworkAccess field shows SecuredByPerimeter.
Troubleshoot
Feature availability
Some capabilities of network security perimeters require feature flags to be registered on your subscription. If you encounter a "This feature isn't available for given subscription" error when configuring access rules or perimeter links, or if your namespace doesn't appear in the list of associable resources when configuring a network security perimeter, register the required feature flag and re-register the network provider:
| Capability | Feature flag | Registration command |
|---|---|---|
| NSP resource association | AllowNetworkSecurityPerimeter |
az feature register --namespace Microsoft.Network --name AllowNetworkSecurityPerimeter |
| Cross-perimeter links | AllowNspLink |
az feature register --namespace Microsoft.Network --name AllowNspLink |
| Service tag inbound rules | EnableServiceTagsInNsp |
az feature register --namespace Microsoft.Network --name EnableServiceTagsInNsp |
After the registration, propagate the change:
az provider register -n Microsoft.Network
Feature flag propagation can take up to 15 minutes.
Namespace association with a network security perimeter
When you're creating a legacy geo-disaster recovery pairing, the primary and secondary namespaces must be associated with the same network security perimeter. If you encounter a "DisasterRecoveryConfigSecondaryMustHaveAssociationsUnderSameNSP" error, associate the secondary namespace with the same perimeter, and then retry the pairing.