Azure Virtual Networks: Network Security Group Association

Introduction to Network Security Group Association

Network Security Groups (NSGs) are a fundamental component of Azure networking, providing network security at the network layer. An NSG contains a list of security rules that allow or deny network traffic to resources connected to Azure Virtual Networks (VNets). Associating an NSG with a subnet or a network interface (NIC) allows you to control inbound and outbound traffic flow.

This document explains how NSGs are associated with resources within your Azure Virtual Networks and the implications of these associations.

Association Levels

NSGs can be associated with your virtual network resources at two primary levels:

Subnet Association

Associating an NSG with a subnet applies the NSG's security rules to all network interfaces (NICs) within that subnet. This is the most common and recommended approach for securing resources within a subnet. All traffic to and from resources within the subnet will be evaluated against the NSG's rules.

Benefits:

  • Centralized Security: Apply consistent security policies to all resources in a subnet.
  • Simplicity: Easier to manage security for groups of resources.
  • Scalability: Automatically applies to new resources added to the subnet.

NIC Association

An NSG can also be directly associated with a Network Interface (NIC) of a virtual machine or other Azure resource. When an NSG is associated with a NIC, its rules are applied to that specific NIC, overriding subnet-level rules if there's a conflict (though this is generally not a recommended practice for complex environments).

Benefits:

  • Granular Control: Apply specific security rules to individual resources.
  • Exception Handling: Useful for specific scenarios where a resource needs different security from its subnet.
Important: If an NSG is associated with both a subnet and a NIC within that subnet, the rules from both NSGs are applied. For inbound traffic, the rules are processed separately and then the most restrictive rule (Deny over Allow) is applied. For outbound traffic, the rules are processed separately and then the most restrictive rule (Deny over Allow) is applied. However, for simplicity and better manageability, it's generally advised to associate NSGs at the subnet level.

How NSG Association Works

When traffic enters or leaves a virtual machine (or any resource connected to a VNet), Azure checks for associated NSGs:

  1. Inbound Traffic:
    • The NSG associated with the NIC is evaluated first.
    • If no NSG is associated with the NIC, the NSG associated with the Subnet is evaluated.
    • If both are associated, rules from both are processed, with the most restrictive rule determining the outcome.
  2. Outbound Traffic:
    • The NSG associated with the NIC is evaluated first.
    • If no NSG is associated with the NIC, the NSG associated with the Subnet is evaluated.
    • If both are associated, rules from both are processed, with the most restrictive rule determining the outcome.

Azure processes the security rules within an NSG in order of priority, starting from the lowest priority number (0) to the highest. As soon as a rule matches the traffic, processing stops for that rule set.

Best Practices for NSG Association

  • Prefer Subnet Association: For most scenarios, associate NSGs with subnets to enforce consistent security policies and simplify management.
  • Leverage Custom NSGs: Create custom NSGs for different security zones or tiers (e.g., web tier, application tier, database tier).
  • Use Descriptive Names: Name your NSGs and rules clearly to indicate their purpose.
  • Minimize NIC Associations: Reserve NIC-level associations for specific, well-understood exceptions.
  • Regularly Review Rules: Periodically audit your NSG rules to ensure they are still relevant and effective.
  • Use Service Tags: Utilize Azure service tags (e.g., Internet, AzureLoadBalancer) in your NSG rules for easier management and better readability.

Example Scenario

Consider a virtual network with two subnets: WebSubnet and AppSubnet.

  • You can associate an NSG called WebNSG with WebSubnet to allow inbound HTTP/HTTPS traffic from the internet and deny all other inbound traffic.
  • You can associate another NSG called AppNSG with AppSubnet to allow inbound traffic only from WebSubnet on specific application ports and deny all other inbound traffic.

This setup ensures that only web servers in WebSubnet can receive internet traffic, and only application servers in AppSubnet can receive traffic from the web servers.


# Example of creating and associating an NSG (Conceptual)

# 1. Create NSG
az network nsg create --resource-group MyResourceGroup --name WebNSG

# 2. Add rules to WebNSG (e.g., allow HTTP/S from Internet)
az network nsg rule create --resource-group MyResourceGroup --nsg-name WebNSG --name AllowHttpS --protocol Tcp --priority 100 --destination-port-range 80 443 --access Allow --direction Inbound --source-address-prefix Internet

# 3. Associate WebNSG with WebSubnet
az network vnet subnet update --resource-group MyResourceGroup --vnet-name MyVNet --name WebSubnet --network-security-group WebNSG

Conclusion

Network Security Group association is a powerful mechanism for implementing network security in Azure. By strategically associating NSGs with subnets and NICs, you can effectively control traffic flow, protect your resources, and meet your organization's security requirements. Understanding the order of evaluation and best practices is key to designing robust and manageable network security architectures in Azure.