Have you seen Azure environments with resources that have public access allowed or just some limitations to the IP addresses in place? Well, I have.
The way to secure these PaaS resources like Storage Accounts, Key Vaults and SQL Servers for example was to put them in a virtual network, create networks security groups (NSG), create Private Endpoints and allow connections to the resources through the NSG to the Private Endpoint. This was done resource by resource and is a lot of work when there are multiple resources as well as hard to maintain without making security gaps.
The above is probably the reason why I have seen more environments with PaaS resources open to internet than ones with network restrictions while going security assessments for customers.
What if I told you that there is an easy and secure solution to all that hassle? The answer is below and beware, this is a bit longer of a post.
Network Security Perimeter
In November 2024, Microsoft introduced a significant enhancement to Azure’s security capabilities: the Network Security Perimeter (NSP). With NSP you can create a singular ruleset instead of separate NSG rules to every resource. The below picture is an example from Microsoft and a link to the documentation.
What it essentially does, for supported resources, is it removes the need for Private Endpoints, virtual networks and NSG´s. The supported resources as of March, 2025 are:
- Azure Monitor
- Azure AI Search
- Cosmos DB
- Event Hubs
- Key Vault
- SQL DB
- Storage
Network Security Perimeter is available on all public cloud regions, but it is worth to note, that access logs from it can currently be only stored in East US, East US 2, North Central US, South Central US, West US and West US 2.
How does it work?
I won’t go too much into details but in a nutshell, here are some info about NSP´s:
- One Network Security Perimeter can contain up to 200 Profiles and it can have up to 1000 PaaS resources associated with it.
- One Profile can have total of 200 Inbound and Outbound rule elements
- Profiles has two modes:
- Learning mode (Default): Helps admins to understand the existing access patterns
- Enforced mode: All traffic is denied, except the traffic allowed within the profiles.
The key thing here is the profile which defines the inbound and outbound rules to the perimeter. Much like Network Security Groups do but slightly different.
A little demonstration
Demo one with a Key Vault:
To set up the test I created some NSP supported resources that have default networking settings (Public access that is enabled from all networks):
I also have a Linux machine on the same subscription with access to all of the above resources. Below picture shows that I can read a secret value from the keyvault:
The managed identity of the VM has Key Vault Secrets User assigned on the Key Vault in question and i´m logged in with it.
Now, since all of the PaaS resources are open to the world, I need to secure them so that only my VM can access them. I create an Network security perimeter and associate the selected resources to it:
I don’t create inbound or outbound rules right now because of the demo, but you can. The NSP is created and you can see the resources associated with it as well as the profile assigned to them. Notice that they both are in learning mode.
Let’s change that and change the mode to Enforced:
After enforcing we can see that the access mode changed and the Effective public network access status changed:
That’s confusing but nevertheless, it is not possible to connect to the resource because I did not do any inbound rules on NSP creation as can be seen below:
I run the same command as before and tried to read the secret but I now get an error code explaining that the request was blocked because of NSP rules.
Now I obviously need to access that secret and to do so I need to make an inbound rule.
When creating an inbound rule, there are two options. IP address range or Subscription, i’m going to create a Subscription based rule so that the Linux VM I have, can access the vault.
After the inbound rule is created and I try again with the VM, it works again:
Demo two with a Storage Account:
Now that the Key Vault is working nicely it´s time to gain access to the Storage Account. The inbound profile was set up to allow access from that subscription to the NSP so when I try and go to read my container on the storage account via a browser on my machine. I get greeted with this:
Time to do some magic in the profile again and this time i´m just going to add my IP as an inbound rule for demo purposes.
After doing the rule and refreshing the browser in the storage account view I can access the blob.
Just to confirm that the NSP is working, I was denied access when trying from another IP-address.
Conclusion
First of all, sorry for the long post and I hope that it was worth the read. Network security perimeter is in Public Preview at the time (March, 2025) and is currently free. You should expect some sort of price tag either for it or for the service level of the PaaS service that supports it once it is in General Availability.
Me myself am ready for some costs as this greatly improves the security posture of your cloud environment and you get to get those critical and/or production PaaS resources behind a secure perimeter away from the grasp of the internet.
One big benefit that I did not cover here is the outbound rules as well. You get to control where the secured services can send data to by defining an FQDN where outbound traffic is allowed.
Management of Network security perimeter also seems a lot simpler (at least in my testing environment) than managing a virtual network, network security groups and private endpoints. I can only imagine the benefit especially in larger environments where complexity is greater.
There are many Azure environments where the benefits of cloud have been fully embraced. Meaning that PaaS resources have been taken into use with default setting and are accessed via the internet. The access however is not controlled on the network level that often. I hate the term silver bullet, but in a way, the network security perimeter is sort of one. It is easy to implement and gets resources behind a perimeter where you know that anyone cannot try to access them via the internet.
Make sure to check my previous post about Azure identities: Securing Azure Identities: The “New” Perimeter in Cybersecurity
Leave a Reply