Exploring Network Security Perimeters in Azure:

Spring is here again and I’m pleased to once again be contributing a post as part of the Azure Spring Clean event organised by Joe Carlyle and Thomas Thornton. Continuing on from last year’s post on Azure Networking where I discussed default outbound access, this year’s post will focus on a new service called Network Security Perimeter.

In this post, we’ll dive into the fundamentals of Azure’s Network Security Perimeter, explore its key features, and discuss how you can leverage it to create logical network isolation boundaries, control external access, and maintain secure communication within your Azure environment.

What is Network Security Perimeter?

Azure’s Network Security Perimeter (NSP) is a service designed to bring uniformity and centralised security control to your Azure PaaS services. Specifically, where access via the PaaS service’s public endpoint is being used. Nowadays, we have private endpoints available for almost every Azure PaaS service, this allows that service to be connected privately via a NIC resource attached to an Azure virtual network. As a result you can provide a fully private connection to an Azure platform service without having to traverse the Internet to get to its public endpoint. This is a best practice and most organisations will adopt this were possible these days. However, it is not always possible to make use of private endpoints and there are occasions when you might have no choice but to use the public endpoint of the platform service. In my experience, this is usually when integrating with third party services, particularly those that are cloud based and that simply do not have the capability of making a connection to your private network.

By their nature, public endpoints are globally available over the Internet so it is important to secure your own instance of this endpoint as best as possible.

The experience for this varies somewhat between services although it has become more consistent over time. Nowadays, you will usually find a networking section within the service in the Azure portal where you can specify allowed networks and IP addresses.

One of the primary issues with this however, is that it needs to be configured on a per resource basis. Therefore, the more resources that you have to manage, the more overhead there is to manage and maintain these security settings.

This is where Network Security Perimeter is designed to come in. It operates similar to the likes of Azure Firewall Manager or Azure Virtual Network Manager where you can create policies and configurations centrally and push these out to managed resources. This provides a central location for policy management and allows for consistent and streamlined security enforcement across your entire environment.

An important thing to note here is that you can create multiple secure network perimeters within your environment allowing you to group PaaS resources together and allow or deny access between those perimeters. This would be somewhat similar to an N-tier solution architecture where you may want to isolate and segment application layers from each other.

NSPs can be configured to control both inbound and outbound access to and from your PaaS services also. This gives you greater control over your network traffic, enhancing security by ensuring that only authorised traffic can reach your PaaS services.

As this service is still in preview there are a number of limitations currently in place, most specifically the supported services and scale limitations that are available today. You can review a list of these limitations here.

The following PaaS services are currently supported by NSP:

• Application Insights
• Alerts, Notification Service
• Azure AI Search
• Cosmos DB
• Event Hubs
• Key Vault
• Log Analytics Workspace
• SQL DB
• Storage

Network Security Perimeter Deployment:

The NSP resource deployment is fairly straightforward. At the time of writing, you will need to register a preview feature before you can deploy but the service itself can be used to manage access to resources across multiple regions. Therefore, for some customers you may just require a single NSP resource however for best practice you will likely want to use an NSP per application or workload for management and security purposes.

The management itself comes in the form of a profile. A profile is a set of configuration policies in the form of inbound and outbound access rules which can be associated with one or more Azure resources. If you need a different set of rules for a resource then you just create a new profile, up to 200 per NSP are supported.

Logging is set up on the NSP level with a whole bunch of new diagnostics available:

• Public inbound access allowed by NSP access rules
• Public inbound access denied by NSP access rules
• Public outbound access allowed by NSP access rules
• Public outbound access denied by NSP access rules
• Inbound access allowed within same perimeter
• Public inbound access allowed by PaaS resource rules
• Public inbound access denied by PaaS resource rules
• Public outbound access allowed by PaaS resource rules
• Public outbound access denied by PaaS resource rules
• Private endpoint traffic allowed
• Cross perimeter outbound access allowed by perimeter link
• Cross perimeter inbound access allowed by perimeter link
• Outbound attempted to same or different perimeter

Profiles and rules:

As mentioned, the profile is where you define your access rules and you can decide to associate multiple resources to the same profile or else create a series of different profiles within the NSP. Think of a profile as a collection of access rules.

Within the rules themselves, inbound rules allow you to associate trusted IP addresses and/or trusted Azure subscriptions which will allow access to all associated resources on that subscription-level*. At this time, it does not seem to be possible to get more granular than this but there is a reference in the Azure portal that it may be possible to allow access between NSP resources explicitly (possibly a future feature).

For use of the outbound access rules, you can only specify allowed destination FQDNs at this time. One interesting point here that I noticed in the small print is that any resources associated within the same NSP service will not require an access rule*, i.e. they are already considered as trusted by each other. This is an important design consideration as if you plan to use a single NSP for multiple workloads then these resources would be inherently trusted which is probably something that you would not want to have.

*However, in order for this feature to work, you will need to make use of a Managed Identity as otherwise, outbound access to other resources within the same perimeter or across linked perimeters will be denied.

Access Modes and transitioning public network access to NSP:

A feature of Azure’s Network Security Perimeter (NSP) is its ability to support learning and enforced access modes. These modes are designed to help organisations transition from the existing public access controls to enforcement via NSPs. This operates in a similar manner to detection and protection mode with Azure WAF.

In learning mode, the NSP monitors and logs traffic to your PaaS services and can be configured to not enforce any restrictions. This mode is particularly useful during the initial stages of implementing NSP, allowing you to understand traffic patterns. Any existing PaaS-level network/firewall restrictions will still take effect.

In this mode, you will be able to either enable or disable the public endpoint access setting on the PaaS resource, which is really just a more centralised way to control this rather than going into each resource individually to configure this setting. NSP rules will be evaluated first and if not matching then PaaS resource-level network security rules will be evaluated as a fallback. This allows you to use the NSP logs to verify if your NSP profile has been configured correctly.

There is a third access mode option here called SecuredByPerimeter, this mode passes the evaluation control over to the NSP profile only. In other words, this option indicates that you are managing inbound/outbound access via the NSP service rather than via the PaaS resource-level network controls as you would have done in the past.

Once you’ve gathered sufficient data and refined your policies, you can switch to enforced mode. In this mode, NSP actively enforces the policies that you’ve defined, blocking any traffic that doesn’t comply with your rules. Once enforced, any PaaS resource-level network security settings configured on the PaaS resource itself are ignored and will not be able to override the NSP profile.

You can selectively control the effective public network access per resource within your NSP profile. This allows you to transition the security configuration of individual resources to be NSP managed in a staged manner.

Testing:

A simple test is to apply an NSP profile to a storage account and restrict the public access to it. A successful block by the NSP will produce an authorization failure message to the user.

This can be observed in more detail in the Log Analytics workspace if you have enabled logging for your NSP service.

Once the inbound access rule has been amended to permit access from my source IP address I can see the matching rule and the allow action in the resulting logs.

Conclusion :

In conclusion, Azure’s Network Security Perimeter (NSP) represents a significant step forward in centralising and streamlining security management for Azure PaaS services, particularly when public endpoints are in use. By offering a unified approach to defining and enforcing network security policies, NSP reduces the administrative overhead of managing access controls on a per-resource basis. Its ability to create logical network isolation boundaries, control inbound and outbound traffic, and support both learning and enforced modes makes it a powerful tool for enhancing security in complex Azure environments. While still in public preview, NSP shows great promise for organisations looking to strengthen their cloud security posture. As the service evolves and more features are added, it will likely become an essential component of Azure’s security ecosystem. For now, it’s worth exploring NSP in non-production environments to understand its capabilities and prepare for its eventual adoption in production scenarios. Stay tuned for further updates as this service matures, and don’t forget to check out the Azure Spring Clean event for more insights and best practices from the Azure community!

Don’t Miss Out on Smarter Azure Savings!

Cloud costs piling up or unsure where to begin with Azure? We've got you covered.
Gomsu is now offering limited-time discounted deals on Microsoft Azure — designed to help you get powerful cloud solutions without breaking your budget.

 Visit www.gomsu.in to explore these offers.
Have questions? Confused about your cloud needs? We’re just a message away — and always ready to help.