Azure Network Security Perimeter

Azure Network Security Perimeter refers to the collection of network security controls that protect Azure resources from unauthorized access and attacks. This includes both perimeter-level defenses (at the boundary of a virtual network) and internal segmentation controls. The primary components are Azure Firewall, Network Security Groups (NSGs), Application Security Groups (ASGs), Azure DDoS Protection, and User-Defined Routes (UDRs). The exam focuses on how these components work together to enforce a defense-in-depth strategy.

Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It is a stateful firewall as a service with built-in high availability and unrestricted cloud scalability. You can create, enforce, and log application and network connectivity policies across subscriptions and virtual networks.

How it works: - Azure Firewall uses a static public IP address for your virtual network resources, allowing outside firewalls to identify traffic originating from your virtual network. - It is fully integrated with Azure Monitor for logging and analytics. - It supports both application (FQDN-based) and network (IP-based) filtering rules. - It can be deployed in a hub-and-spoke topology or directly in a VNet. - It supports DNAT (Destination Network Address Translation) to translate inbound traffic to private IP addresses. - It integrates with Azure Security Center and Azure Sentinel for threat intelligence.

Key features tested on the exam: - Application rules: Allow or deny outbound traffic based on fully qualified domain names (FQDNs). For example, allow access to *.windowsupdate.com. - Network rules: Allow or deny traffic based on source IP, destination IP, port, and protocol. - DNAT rules: Translate inbound traffic to internal resources. - Threat intelligence-based filtering: Enable alert and deny mode for malicious IPs and domains. - DNS proxy: Forward DNS queries from VMs to a custom DNS server. - TLS inspection (preview): Decrypt and inspect TLS traffic. - Web categories: Filter traffic based on web categories (e.g., social media, gambling).

Default values and limits: - Maximum throughput: 30 Gbps (Azure Firewall Premium can scale up to 100 Gbps). - Maximum number of rules: 10,000 per firewall policy. - Maximum number of public IP addresses: 250. - Maximum number of rule collection groups: 50. - Maximum number of DNAT rules: 500. - Maximum concurrent connections: 2 million.

NSGs are a fundamental network security control in Azure. They act as a distributed, stateless firewall at the subnet or NIC level. NSGs contain a list of security rules that allow or deny inbound and outbound traffic. Each rule specifies source, destination, port, and protocol.

How NSGs work: - NSGs are stateful for inbound traffic (return traffic is automatically allowed) but stateless for outbound (return traffic must be explicitly allowed). However, this is a common misconception: NSGs are actually stateful for both directions. For inbound rules, if you allow port 80 from the internet, the return traffic is allowed regardless of outbound rules. For outbound rules, if you allow outbound traffic to the internet, the return traffic is allowed regardless of inbound rules. This behavior is often tested. - NSGs can be associated with a subnet or a virtual network interface (NIC). When associated with a subnet, the rules apply to all VMs in that subnet. When associated with a NIC, the rules apply only to that specific VM. - Each NSG has a set of default rules that cannot be deleted but can be overridden with higher-priority rules. - The priority range is 100-4096. Lower numbers have higher priority.

Default rules: - AllowVNetInBound: Allow inbound traffic from within the virtual network (priority 65000). - AllowAzureLoadBalancerInBound: Allow inbound traffic from Azure Load Balancer (priority 65001). - DenyAllInbound: Deny all other inbound traffic (priority 65500). - AllowVNetOutBound: Allow outbound traffic to within the virtual network (priority 65000). - AllowInternetOutBound: Allow outbound traffic to the internet (priority 65001). - DenyAllOutBound: Deny all other outbound traffic (priority 65500).

Exam-critical details: - NSGs are evaluated based on the effective rules, which are the combination of subnet-level and NIC-level NSGs. When both are applied, the NIC-level rules override subnet-level rules? No — they are additive. The actual effective rule is the union of both, with the most restrictive rule winning? Actually, NSG rules are evaluated in priority order. If a rule at the subnet level denies traffic and a rule at the NIC level allows it, the deny rule (higher priority? No, priority is per NSG, not cross-NSG). The effective rules are the combination of both NSGs. If a subnet NSG denies traffic and a NIC NSG allows it, the traffic is denied because the subnet NSG is evaluated first? No, this is a common trap. The correct behavior: When both subnet and NIC NSGs are applied, the traffic must pass both NSGs. So if the subnet NSG denies, traffic is denied regardless of the NIC NSG. If the subnet NSG allows, then the NIC NSG is evaluated. So effectively, the most restrictive rule applies.

ASGs allow you to group virtual machines logically by application workload, rather than by IP address. You can then use ASGs as source or destination in NSG rules. This simplifies rule management, especially when VMs are dynamically scaled.

How ASGs work: - You create an ASG and assign it to a VM's NIC. - In an NSG rule, you can specify the ASG as the source or destination, instead of IP ranges. - When a VM is added to an ASG, the NSG rules automatically apply to that VM. - ASGs are scoped to a single resource group. - A VM can be in up to 20 ASGs. - ASGs cannot be used with Azure Firewall rules.

Azure DDoS Protection protects against distributed denial-of-service attacks. There are two tiers: Basic (free, automatically enabled) and Standard (paid, for production workloads).

DDoS Protection Basic: - Automatic, always-on monitoring and mitigation of common network-layer attacks. - No configuration required. - Mitigation triggers when attack traffic exceeds thresholds.

DDoS Protection Standard: - Tailored protection for Azure virtual networks. - Includes mitigation reports, flow logs, and alerting. - Covers volumetric attacks (e.g., UDP floods), protocol attacks (e.g., SYN floods), and resource-layer attacks (e.g., DNS amplification). - Provides cost protection: if your resource is scaled up due to an attack, you get a credit for the additional costs. - Integrates with Azure Monitor and Azure Security Center. - Application to a specific virtual network (not per VM). - Mitigation policies are adaptive based on traffic patterns.

UDRs override Azure's default routing behavior. They are used to force traffic through a firewall or virtual appliance. For example, you can create a route that sends all internet-bound traffic to Azure Firewall for inspection.

How UDRs work: - Routes are stored in route tables, which are associated with subnets. - Each route contains an address prefix (destination) and a next hop type. - Next hop types: VirtualNetworkGateway, VNetLocal, Internet, VirtualAppliance, or None. - Forcing traffic through a firewall: Set next hop type to VirtualAppliance and specify the firewall's private IP. - The route table must be associated with the subnet containing the VMs. - Azure Firewall must have an additional route (0.0.0.0/0 to Internet) to forward traffic after inspection.

In a typical hub-and-spoke topology:

Azure Firewall deployment (PowerShell):

# Create a public IP
$pip = New-AzPublicIpAddress -Name "fw-pip" -ResourceGroupName "rg" -Location "eastus" -AllocationMethod Static -Sku Standard

# Create firewall subnet (must be named AzureFirewallSubnet)
$subnet = New-AzVirtualNetworkSubnetConfig -Name "AzureFirewallSubnet" -AddressPrefix "10.0.1.0/24"

# Create VNet
$vnet = New-AzVirtualNetwork -Name "vnet" -ResourceGroupName "rg" -Location "eastus" -AddressPrefix "10.0.0.0/16" -Subnet $subnet

# Create firewall
$fw = New-AzFirewall -Name "fw" -ResourceGroupName "rg" -Location "eastus" -VirtualNetworkName "vnet" -PublicIpName "fw-pip"

NSG rule (CLI):

az network nsg rule create \
  --resource-group rg \
  --nsg-name myNSG \
  --name AllowSSH \
  --priority 100 \
  --source-address-prefixes 192.168.1.0/24 \
  --destination-port-ranges 22 \
  --access Allow \
  --protocol Tcp

UDR to force traffic through firewall (PowerShell):

$route = New-AzRouteConfig -Name "DefaultRoute" -AddressPrefix 0.0.0.0/0 -NextHopType VirtualAppliance -NextHopIpAddress 10.0.1.4
$rt = New-AzRouteTable -Name "myRouteTable" -ResourceGroupName "rg" -Location "eastus" -Route $route
$subnet = Get-AzVirtualNetworkSubnetConfig -Name "subnet" -VirtualNetwork $vnet
$subnet.RouteTable = $rt
Set-AzVirtualNetwork -VirtualNetwork $vnet

In a typical enterprise deployment, a multinational company uses Azure to host its customer-facing web application and internal ERP system. The network security perimeter is designed as follows:

Scenario 1: E-commerce platform The company has a three-tier application: web servers, application servers, and database servers, all in a spoke VNet. Azure Firewall in the hub VNet inspects all inbound and outbound traffic. Inbound HTTPS traffic goes through the firewall's DNAT rule to the web tier's internal load balancer. Outbound traffic from the web tier to the internet (e.g., credit card processing) is forced through the firewall with application rules allowing only specific FQDNs. The database tier has an NSG that allows only the app tier on port 1433. ASGs group the web and app servers, so when new instances are added during peak shopping seasons, NSG rules automatically apply. DDoS Protection Standard is enabled on the hub VNet's public IP. This setup handled 50,000 concurrent users with 99.99% uptime. Misconfiguration: Initially, the route table was not applied to the spoke subnet, so outbound traffic bypassed the firewall, leading to a security breach. After adding the route, traffic was properly inspected.

Scenario 2: Healthcare data processing A healthcare provider processes patient data in Azure, requiring HIPAA compliance. They use Azure Firewall Premium for TLS inspection to decrypt and inspect HTTPS traffic to detect malware. The firewall logs are sent to Azure Sentinel for threat hunting. NSGs are used to isolate development, staging, and production environments in separate spoke VNets. UDRs force all traffic between spokes through the firewall. A common mistake is forgetting to add routes for spoke-to-spoke traffic, resulting in traffic bypassing the firewall. The solution requires careful planning of IP address spaces to avoid overlap. Performance: With 10 Gbps throughput, the firewall handles 1 million concurrent connections. When misconfigured with too many rules (over 10,000), rule evaluation slows down, causing latency. Regularly reviewing rule effectiveness is critical.

Scenario 3: Hybrid network with VPN A company connects its on-premises network to Azure via VPN gateway. The hub VNet contains Azure Firewall and the VPN gateway. UDRs in the hub force all on-premises traffic to the firewall for inspection before reaching spoke VNets. NSGs on spoke subnets allow only traffic from the firewall's private IP. A common issue: if the route table on the GatewaySubnet doesn't point to the firewall, traffic from on-premises bypasses it. Also, ensure the firewall's network rules allow the VPN gateway's public IP range for management traffic. This setup provides a secure hybrid perimeter.