
close
close
Security threats keep coming! Learn how to protect your organization.
In this post, I will explain how you can use Application Security Groups (ASGs) in addition with Network Security Groups (NSGs) to create secure network designs for virtual machines in Azure.
Before you read this post, you should read Understanding Application Security Groups in the Azure Portal to understand the purpose of ASGs and how to deploy them.
In a previous post, How to Secure A Network Using NSGs, I explained how you could secure a reference architecture for a web application that is deployed using virtual machines in an Azure virtual network. In the design, the service has three tiers, each of which is deployed into its own subnet and secured with a dedicated NSG resource:
advertisment
Securing a web service using NSGs [Image Credit: Aidan Finn]
If you “zoomed out” on the above design, you might say that there is an external tier (the web servers) and an internal or backend tier (everything else). What if we could flatten the above design to just 2 subnets/2 NSGs, but still have the same levels of effective firewall security? What if we could replace 10.0.2.0/24 and 10.0.3.0/24 with human-friendly labels? Application Security Groups (ASGs) can be used as follows:
If we took the above network example and used ASGs, it might look like the below diagram. In this design we have:
advertisment
Securing a web service using NSGs and ASGs [Image Credit: Aidan Finn]
The purpose of this NSG is to allow web server traffic from the Internet to the web servers in the Web Tier subnet. We can do something like this:
If web traffic comes in through the external load balancer then it will be allowed by one of those rules. We are creating a specific rule to allow probe traffic from the external load balancer; this is because the last rule will deny all other traffic from the virtual network. We don’t want any other traffic in the virtual network getting into these virtual machines – this includes blocking communications between the web servers. Anything else from the Internet will be blocked by the default DenyAllInbound rule.
If you want to extend this, you might add a rule (Priority 500) to allow SSH or RDP from an allowed source IP address, such as a “jump box” virtual machine in a dedicated subnet or peered virtual network.
The purpose of this NSG is twofold:
advertisment
The rule set will look as follows, assuming that application is hosted on TCP 8080 and the data tier is based on SQL Server running in the guest OS of the database virtual machines:
As with the Web Tier NSG, you might also allow SSH/RDP traffic from a trusted source, as well as database management traffic from the same/different trusted source.
Which is better: using NSGs or using NSGs with ASGs? For me, it’s an “it depends” situation. In simpler designs, I am leaning towards splitting tiers of a service across subnets. I have encountered several scenarios recently, though, where the subnet design could be very complex and using ASGs will reduce the number of subnets and make it easier to document & troubleshoot NSG rules.
More in Microsoft Azure
Build 2022: Microsoft's Intelligent Data Platform Combines Data and Analytics
May 25, 2022 | Rabia Noureen
Microsoft Revises Restrictive Cloud Licensing Policies to Avoid EU Antitrust Probe
May 19, 2022 | Rabia Noureen
Microsoft's Azure AD Conditional Access Service Can Now Require Reauthentication
May 13, 2022 | Rabia Noureen
Microsoft Addresses Cross-Tenant Database Vulnerability in Azure PostgreSQL
Apr 29, 2022 | Rabia Noureen
Microsoft Simplifies IT Monitoring with New Azure Managed Grafana Service
Apr 19, 2022 | Rabia Noureen
Most popular on petri