You are an Azure Administrator responsible for a classic three-tier application deployed in a single Azure Virtual Network (VNet). The VNet is segmented into three subnets: 'WebSubnet' for front-end web servers, 'AppSubnet' for middle-tier application servers, and 'DbSubnet' for back-end database servers. You must implement network traffic filtering to secure the application, ensuring that each tier can only communicate with the necessary components. Describe how you would configure Network Security Groups (NSGs) to achieve this security posture. Explain the core concepts of NSG rules, priority, and association.

Securing a Three-Tier Architecture with Network Security Groups (NSGs)

A Network Security Group (NSG) is a fundamental resource in Azure for filtering network traffic to and from Azure resources within an Azure Virtual Network (VNet). It functions as a stateful, Layer 4 firewall, containing a list of security rules that allow or deny network traffic based on a 5-tuple: source IP address, source port, destination IP address, destination port, and protocol (TCP, UDP, ICMP, or Any).

To secure the described three-tier application, the best practice is to create a dedicated NSG for each subnet. This approach provides granular control and adheres to the principle of least privilege, ensuring each tier is isolated and only exposed to required traffic.

Strategy: One NSG per Subnet

We will create and associate three distinct NSGs:

• NSG-Web: Associated with the WebSubnet.
• NSG-App: Associated with the AppSubnet.
• NSG-Db: Associated with the DbSubnet.

Detailed Rule Configuration

1. NSG-Web (for WebSubnet)

This NSG's primary role is to allow legitimate web traffic from the internet to the web servers and allow the web servers to communicate with the application tier.

• Inbound Rules:
  • Priority 100: Allow TCP traffic on ports 80 (HTTP) and 443 (HTTPS) from the `Internet` service tag. This allows external users to access the web application.
  • Priority 200: Allow TCP traffic on port 3389 (RDP) or 22 (SSH) from a specific, trusted administrative IP address range. This is for secure management of the web servers.
• Outbound Rules:
  • Priority 100: Allow TCP traffic to the `AppSubnet` IP address range on the specific port the application servers are listening on (e.g., port 8080). This enables the front-end to communicate with the middle-tier.

2. NSG-App (for AppSubnet)

This NSG will only allow traffic from the web tier and permit communication to the database tier. It should block all direct traffic from the internet.

• Inbound Rules:
  • Priority 100: Allow TCP traffic on the application port (e.g., 8080) from the `WebSubnet` IP address range.
  • Priority 200: Allow TCP traffic on port 3389 (RDP) or 22 (SSH) from a trusted administrative IP address range for secure management.
  • Priority 400: Deny all traffic from the `Internet` service tag. While the default `DenyAllInbound` rule would eventually block this, an explicit deny rule with a higher priority makes the security intent clear.
• Outbound Rules:
  • Priority 100: Allow TCP traffic to the `DbSubnet` IP address range on the database port (e.g., 1433 for SQL Server).

3. NSG-Db (for DbSubnet)

This is the most protected tier. It should only accept traffic from the application tier and should generally have no outbound access to the internet.

• Inbound Rules:
  • Priority 100: Allow TCP traffic on the database port (e.g., 1433) from the `AppSubnet` IP address range.
  • Priority 200: Allow TCP on port 3389 (RDP) or 22 (SSH) from a trusted administrative IP address range for secure database management.
• Outbound Rules:
  • Priority 4000: Deny all outbound traffic to the `Internet` service tag. This prevents potential data exfiltration from the database servers.

Core NSG Concepts

Rule Priority

Rules are processed in order of priority. The lower the number, the higher the priority (range is 100 to 4096). Azure processes rules until it finds the first match for the traffic pattern, and then it stops processing. For example, if an `Allow` rule with priority 200 matches the traffic, a `Deny` rule with priority 300 for the same traffic will be ignored. This is why specific `Allow` rules must have a lower priority number than broader `Deny` rules.

NSG Association

An NSG can be associated with either a subnet, a network interface (NIC), or both.

• Subnet Association: When an NSG is associated with a subnet, its rules are applied to all resources (e.g., VMs) within that subnet. This is the recommended approach for managing security at scale as it provides a consistent baseline for all resources in the subnet.
• NIC Association: Associating an NSG directly with a VM's NIC allows for more granular, per-VM security rules. This can be used to create exceptions for a specific machine within a subnet.

When both are applied, traffic is evaluated against both sets of rules. For inbound traffic, the subnet-level NSG is processed first, followed by the NIC-level NSG. For outbound traffic, the NIC-level NSG is processed first, followed by the subnet-level NSG. Traffic is only permitted if it is allowed by the rules in both NSGs.

Default Rules

Every NSG is created with a set of default rules that cannot be deleted, but can be overridden by creating new rules with a higher priority (lower number). Key default rules include `AllowVnetInBound`, `AllowAzureLoadBalancerInBound`, and `DenyAllInBound` at priority 65500. Our custom rules with priorities like 100 and 200 will always be processed before these default rules.