Coming Soon: GET:IT Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET Coming Soon: GET:IT Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET
Microsoft Azure

How Do I Apply NSG Policies To Applications in Azure?

In this post, I will describe a preview feature of Network Security Groups, called Application Security Groups, which allows you dynamically assign firewall policies to groups of Azure virtual machines.


Network Security Groups

Azure has a built-in, distributed Layer-4 stateful firewall system called Network Security Groups (NSGs). An NSG is a firewall policy, defining a collection of inbound and outbound allow or deny rules for network traffic. A collection of default rules are included and administrators typically add inbound rules to allow traffic into applications or services running on virtual machines, and optionally add outbound rules to control data leakage.

Sponsored Content

Say Goodbye to Traditional PC Lifecycle Management

Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.

NSGs can be and are by default in the Azure Portal, assigned to the NICs of virtual machines on a 1:1 basis but that doesn’t really scale well. Instead, we should create and assign NSGs at the subnet level. The source and destinations in the firewall rules can be tags/locations such as Azure SQL,Virtual Network, or a network/specific address.

When we create inbound rules, it is recommended that we be as specific as possible with the destination address. In a well-structured virtual network, each subnet is treated as a security domain. For example, the subnet might be the web server subnet and an NSG might allow TCP 443 into However, some (including Azure Security Center’s recommendations) would prefer that individual machine addresses were specified as the destination instead.

A Problem with Dynamism

The problem with the best practice specific destination approach is that systems change. Let’s assume that you have created rules to allow traffic into 4 virtual machines:,,, and That’s great for your regular load of web servers. But what if you enabled Auto-Scaling?

Auto-Scaling will dynamically add and reduce the number of web servers in your deployment based on a set of administrator-defined rules. If demand for the application increases, the number of web servers increase. If demand subsides, the number of web servers decreases. In the case of an increase, new web servers will appear with the next available IP addresses in the subnet. Someone is going to have to add those IP addresses to the NSG rules.

New Azure machines aren’t automatically added to the NSG policy [Image Credit: Aidan Finn]
New Azure Machines Aren’t Automatically Added to the NSG Policy [Image Credit: Aidan Finn]

Maybe I didn’t create a “web server” subnet. Maybe it’s a subnet with lots of machines coming and going, so I have no idea what IP addresses the web servers will have.

Beyond Addresses

How many of your servers’ IP addresses do you know without looking them up? I can remember 3 phone numbers, so I haven’t a hope of recalling the addresses of an n-tier application. What if we could refer to our machines with some kind of network label?

Even if I wasn’t using Auto-Scaling, it would be much easier and quicker for me to say, “these machines are web servers – allow traffic into all of them”. And if I created a new web server, I would like an easy way to extend the policy to it, without figuring out the IP address, more so if I’m working with dynamic IP addresses.

Application Security Groups

Microsoft has added a new feature to NSGs called Application Security Groups. This is an opt-in preview requiring you to register the ARM providers at the time of writing. With this feature you can:

  1. You create an Application Security Group. For example, we create one called webservers.
  2. Then you create an NSG.
  3. Create an inbound security rule to allow TCP 443 with Internet as the source tag and the Application Security Group, webservers, as the destination.
  4. Create a new virtual network interface with membership of the webservers Application Security Group and create a web server with this network adapter.

Application Security Groups abstract the addressing of Azure virtual machines in NSGs [Image Credit: Aidan Finn]
Application Security Groups Abstract the Addressing of Azure Virtual Machines in NSGs [Image Credit: Aidan Finn]

Step 4 is repeated for each web server that is created. Without having to know any IP addresses, secure web traffic is being allowed into specific machines only. More web servers can be added, and by the network interfaces being members of webservers, the inbound security rule is dynamically applied to the new machines.

Some Restrictions

At this time, the following restrictions apply:

  • All network interfaces in an Application Security Group must be connected to the same virtual network.
  • If you specify Application Security Groups as the destination and source of an NSG rule, then the source and destination network interfaces must also be in the same virtual network.
  • You must use either Azure CLI or PowerShell to deploy Application Security Groups. An “unmanageable” object for the Application Security Group does appear in the resource group in the Azure Portal.
  • At this time, it appears (I haven’t found a workaround yet) that a network interface can only join an Application Security Group when you create the network interface.

Related Topics:


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (0)

Leave a Reply

Aidan Finn, Microsoft Most Valuable Professional (MVP), has been working in IT since 1996. He has worked as a consultant and administrator for the likes of Innofactor Norway, Amdahl DMR, Fujitsu, Barclays and Hypo Real Estate Bank International where he dealt with large and complex IT infrastructures and MicroWarehouse Ltd. where he worked with Microsoft partners in the small/medium business space.
Live Webinar: Active Directory Security: What Needs Immediate Priority!Live on Tuesday, October 12th at 1 PM ET

Attacks on Active Directory are at an all-time high. Companies that are not taking heed are being punished, both monetarily and with loss of production.

In this webinar, you will learn:

  • How to prioritize vulnerability management
  • What attackers are leveraging to breach organizations
  • Where Active Directory security needs immediate attention
  • Overall strategy to secure your environment and keep it secured

Sponsored by: