NSG

  • An Azure Network Security Group (NSG) is a core component of Azure’s security fabric. Leveraging an NSG, you can filter traffic to and from Azure resources that you have commissioned on an Azure Virtual Network (VNet). At its core, an NSG is effectively a set of access control rules you assign to an Azure resource.
  • You can associate an NSG with a subnet or the network interface of an Azure VM
  • In accordance with Best practices, it’s recommended to scope NSGs at the subnet level or network interface, not both
  • An ASG is a logical grouping of virtual machines that allows you to apply security rules at scale.  For example, if you have a group of VM’s serving a web application, the VM’s can be placed in an ASG called “webappvms”.  The webappvms group can then be added to a rule within an NSG allowing HTTP (TCP) traffic over port 80.  This alleviates the need to add individual IP addresses to the security rule.
  • Azure Firewall is a highly available, managed firewall service that filters network and application level traffic.  It has the ability to process traffic across subscriptions and VNets that are deployed in a hub-spoke model

Application Security Groups (ASG) are a feature within Azure that helps simplify the management of Network Security Group (NSG) rules

In Azure, there are two security features that can be used to manage both inbound and outbound traffic to resources:  Azure Firewall and Network Security Groups (NSGs).

An NSG filters traffic at the network layer and consists of security rules that allows or denies traffic based on 5-tuple information:
1. Protocol – such as TCP, UDP, ICMP
2. Source – IP address,
3. Source port
4. Destination
5. Destination port

Azure Firewall and NSG Comparison

  • An NSG is a firewall, a very basic one.  It’s a software defined solution that filters traffic at the Network layer.  However, Azure Firewall is more robust.  It’s a managed firewall service that can filter and analyze L3-L4 traffic, as well as L7 application traffic.  Azure Firewall provides the same capabilities as an NSG, plus more.
  • Service Tags  these are labels that represent a range of IP addresses for particular services such as Azure Key Vault, Data Lake, Container Registry, etc.  These are managed by Microsoft and cannot be customized.  You can learn more about them here. As an example, here’s a Service tag I have configured for Event Hub in an outbound NSG rule.  This same rule can also be created in Azure Firewall
  • FQDN Tags – represent a group of fully qualified domain names of Microsoft services such as Windows Update or Azure Backup.  Like Service tags, they are maintained by Microsoft and cannot be customized.  There are a significantly fewer number of  FQDN tags than Service tags.  Go here to see the list of FQDN tags. 

You typically want to use NSGs when you are protecting network traffic in or out of a subnet. An example would be a subnet that contains VMs that require RDP access (TCP over 3389) from a Jumpbox

Azure Firewall is the solution for filtering traffic to a VNet from the outside.  For this reason, it should be deployed in it’s own VNet and isolated from other resources.  Azure Firewall is a highly available solution that automatically scales based on its workload.  Therefore, it should be in a /26 size subnet to ensure there’s space for additional VMs that are created when it’s scaled ou