Are network security groups attached to virtual intefaces, subnets or VNets?

In Microsoft Azure, Network Security Groups (NSGs) are used to control inbound and outbound traffic for resources. NSGs can be attached to subnets or network interfaces (NICs), but not directly to virtual networks (VNets). Here’s a detailed explanation:

1. Attached to Subnets

When an NSG is associated with a subnet, it applies to all resources (e.g., VMs, load balancers) within that subnet.
This is useful for enforcing security rules at the subnet level, such as allowing or denying traffic between subnets.
Example: You can attach an NSG to a subnet containing web servers to allow HTTP/HTTPS traffic from the internet while blocking other traffic.

How to Attach an NSG to a Subnet:

In the Azure portal, go to the Subnet settings of your virtual network.
Select the subnet and associate it with an existing NSG or create a new one.

2. Attached to Network Interfaces (NICs)

When an NSG is associated with a network interface (NIC), it applies only to the specific VM or resource that uses that NIC.
This allows for more granular control over traffic to and from individual resources.
Example: You can attach an NSG to a NIC for a specific VM to allow RDP/SSH access only from certain IP addresses.

How to Attach an NSG to a NIC:

In the Azure portal, go to the Network Interface settings of your VM.
Select the NIC and associate it with an existing NSG or create a new one.

3. Not Attached to Virtual Networks (VNets)

NSGs cannot be directly attached to a virtual network (VNet) as a whole.
Instead, you must attach NSGs to subnets or NICs within the VNet to enforce traffic rules.

Key Points to Remember:

Hierarchy of NSG Rules:
- If an NSG is attached to both a subnet and a NIC, the rules are evaluated in the following order:
  - Subnet-level NSG rules are evaluated first.
  - NIC-level NSG rules are evaluated next.
- If a rule at either level denies traffic, the traffic is blocked, regardless of the other level’s rules.
Default NSG Rules:
- Every NSG includes a set of default rules that allow basic connectivity (e.g., inbound traffic from the VNet, outbound traffic to the internet).
- You can add custom rules to override or supplement the default rules.
Multiple NSGs:
- A single NSG can be associated with multiple subnets or NICs.
- A single subnet or NIC can have only one NSG associated with it at a time.
Use Cases:
- Subnet-level NSGs: Ideal for enforcing broad security policies across multiple resources.
- NIC-level NSGs: Ideal for fine-grained control over individual resources.

Example Scenario:

Suppose you have a virtual network with the following subnets:

Web-Subnet: Contains web servers.
App-Subnet: Contains application servers.
DB-Subnet: Contains database servers.
You can attach an NSG to the Web-Subnet to allow HTTP/HTTPS traffic from the internet.
Attach another NSG to the App-Subnet to allow traffic only from the Web-Subnet.
Attach a third NSG to the DB-Subnet to allow traffic only from the App-Subnet.

For a specific VM in the App-Subnet, you can attach an NSG to its NIC to allow SSH access only from your office IP address.

Summary:

NSGs can be attached to subnets or network interfaces (NICs).
They cannot be attached directly to virtual networks (VNets).
Use subnet-level NSGs for broad policies and NIC-level NSGs for granular control.