Virtual Network Security

Azure Virtual Network (VNet) security encompasses the controls and services that protect network traffic within and between VNets, and between VNets and the internet or on-premises networks. The primary goal is to enforce the principle of least privilege: only necessary traffic is allowed, and all other traffic is denied by default. The AZ-500 exam focuses on five key technologies: Network Security Groups (NSGs), Azure Firewall, Azure DDoS Protection, Service Endpoints, and Private Link.

An NSG is a stateful, distributed firewall that filters traffic to and from Azure resources within a VNet. It operates at OSI layers 3 (network) and 4 (transport). NSGs contain a list of security rules that are evaluated in priority order (lowest number first). Each rule specifies: - Source and destination: IP addresses, service tags, or application security groups - Port and protocol: TCP, UDP, or Any (including ICMP) - Direction: Inbound or outbound - Action: Allow or Deny - Priority: 100-4096 (lower number = higher priority)

NSGs are stateful: if you allow inbound traffic on port 443, the outbound response traffic is automatically allowed regardless of outbound rules. Similarly, if you allow outbound traffic, the inbound response is allowed. This statefulness applies only to flows initiated by an allowed rule; it does not allow unsolicited inbound traffic.

Default rules: Every NSG has three default inbound rules and three default outbound rules. Inbound: 1. AllowVNetInBound (priority 65000): Allows all traffic within the VNet. 2. AllowAzureLoadBalancerInBound (priority 65001): Allows traffic from Azure Load Balancer health probes. 3. DenyAllInBound (priority 65500): Denies all other inbound traffic. Outbound: 1. AllowVNetOutBound (priority 65000): Allows all outbound traffic within the VNet. 2. AllowInternetOutBound (priority 65001): Allows all outbound traffic to the internet. 3. DenyAllOutBound (priority 65500): Denies all other outbound traffic.

Service tags: Azure provides predefined service tags (e.g., Internet, VirtualNetwork, AzureLoadBalancer, Sql, Storage) that represent groups of IP addresses for Azure services. Using service tags simplifies rule creation and automatically updates as IP ranges change.

Application Security Groups (ASGs): ASGs allow you to group VMs logically (e.g., by application tier) and reference the group in NSG rules. For example, you can create a rule that allows traffic from the "Web" ASG to the "App" ASG on port 8080. This decouples network security from IP addresses.

NSG flow logs: To monitor traffic, you can enable NSG flow logs (via Network Watcher) which capture information about allowed and denied traffic. Flow logs are sent to a storage account or Log Analytics workspace for analysis.

Azure Firewall is a managed, cloud-native network security service that provides stateful filtering, threat intelligence, and high availability. It is deployed in a dedicated subnet called AzureFirewallSubnet (minimum /26). Unlike NSGs, Azure Firewall operates at layers 3-7, enabling application-level filtering.

Key features: - Application rules: Allow or deny outbound HTTP/HTTPS traffic based on FQDNs (fully qualified domain names). For example, you can allow access to *.microsoft.com but block *.example.com. - Network rules: Filter traffic based on source/destination IP, port, and protocol (similar to NSGs but with additional capabilities). - DNAT rules: Inbound destination network address translation to expose internal resources (e.g., map public IP:port to private IP:port). - Threat intelligence: Based on Microsoft threat intelligence feeds, it can alert and deny traffic from/to known malicious IPs and domains. - TLS inspection: Optionally decrypt and inspect outbound TLS traffic (requires a certificate). - Logging and analytics: Integrated with Azure Monitor and Log Analytics.

Firewall policy: A global resource that contains rule collections (application, network, DNAT, and threat intelligence) and can be associated with multiple firewalls. This enables centralized management.

Availability: Azure Firewall is zone-redundant and supports availability zones. It scales automatically based on traffic load.

Forced tunneling: You can configure the firewall to send all outbound traffic to an on-premises network via a VPN or ExpressRoute for inspection.

Azure DDoS Protection (Standard tier) defends Azure resources against distributed denial-of-service attacks. It is always-on and uses adaptive tuning to learn normal traffic patterns.

Tiers: - Basic: Automatically enabled on all Azure resources, provides protection against common network-layer attacks. - Standard: Provides enhanced protection for VNet resources. Includes attack analytics, alerts, and mitigation reports. Costs approximately $2,944/month per 100 resources (as of 2025).

How it works: DDoS Protection monitors traffic and triggers mitigation when it detects a deviation from baseline. It uses a combination of scrubbing, rate limiting, and protocol validation. Protection is applied at the VNet level, not per resource.

Metrics: You can monitor DDoS attacks via Azure Monitor metrics such as "Inbound packets dropped" and "TCP SYN packets."

Service Endpoints extend your VNet identity to Azure services (e.g., Azure Storage, Azure SQL Database) over the Azure backbone network. When enabled, traffic from a VNet to the service goes directly over the Microsoft network, not the public internet. The service sees the traffic as coming from the VNet's private IP addresses, not the public IP of the VM.

How to configure: Enable a service endpoint on a subnet for a specific service (e.g., Microsoft.Storage). Then configure the service's firewall to allow access only from that subnet's IP range. This restricts access to the service from only your VNet.

Limitations: Service Endpoints only work for PaaS services that support them. They do not provide private IP connectivity (the service still has a public endpoint). For private IP connectivity, use Private Link.

Private Link provides private connectivity to Azure PaaS services (e.g., Azure Storage, Azure SQL Database) or your own services behind Azure Load Balancer. It uses a private endpoint—a network interface with a private IP from your VNet—that connects to the service over the Microsoft backbone. Traffic never traverses the public internet.

Private Endpoint: A resource that creates a NIC in your VNet with a private IP. It is associated with a private link service (the target service). For example, you can create a private endpoint for an Azure SQL Server; then the SQL Server becomes accessible via private IP only (if public access is disabled).

Private Link Service: You can create your own private link service behind a Standard Load Balancer, allowing consumers to connect privately from their VNets.

DNS configuration: Private endpoints require DNS resolution to the private IP. Azure automatically creates a private DNS zone (e.g., privatelink.database.windows.net) that maps the service's FQDN to the private IP.

In a typical secure architecture, you combine these technologies:

For example, a web application might have:

Creating an NSG rule with Azure CLI:

az network nsg rule create \
  --resource-group myRG \
  --nsg-name myNSG \
  --name AllowHTTP \
  --priority 100 \
  --direction Inbound \
  --source-address-prefixes Internet \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges 80 \
  --protocol Tcp \
  --access Allow

Deploying Azure Firewall with policy (Azure CLI):

# Create firewall policy
az network firewall policy create \
  --name myPolicy \
  --resource-group myRG

# Add a network rule collection
az network firewall policy rule-collection-group collection add-filter-collection \
  --policy-name myPolicy \
  --resource-group myRG \
  --name myNetworkRules \
  --priority 100 \
  --collection-type Network \
  --action Allow \
  --rule-name AllowSSH \
  --rule-type NetworkRule \
  --source-addresses 10.0.0.0/24 \
  --destination-addresses 10.1.0.4 \
  --destination-ports 22 \
  --protocols TCP

Enabling DDoS Protection Standard on a VNet:

az network ddos-protection create \
  --resource-group myRG \
  --name myDdosProtection \
  --vnets myVNet \
  --location eastus

Creating a private endpoint for Azure SQL Database:

az network private-endpoint create \
  --resource-group myRG \
  --name myPrivateEndpoint \
  --vnet-name myVNet \
  --subnet mySubnet \
  --private-connection-resource-id $(az sql server show -g myRG -n mySqlServer --query id -o tsv) \
  --group-id sqlServer \
  --connection-name myConnection

A large retailer migrating its e-commerce platform to Azure needed to protect against DDoS attacks and secure access to databases. They deployed a hub-and-spoke VNet topology with Azure Firewall in the hub for centralized inspection. NSGs on each spoke subnet enforced micro-segmentation: web servers only allowed inbound HTTP/HTTPS, app servers only allowed traffic from web servers on port 8080, and database servers only allowed traffic from app servers on port 1433. DDoS Protection Standard was enabled on the hub VNet. Private endpoints were used for Azure SQL Database and Azure Storage (for backups). During a Black Friday sale, they experienced a SYN flood attack; DDoS Protection mitigated it without impacting legitimate traffic. The NSGs prevented lateral movement when a web server was compromised; the attacker could not reach the database directly. Performance was monitored via NSG flow logs and Azure Firewall logs; they found that forced tunneling through the firewall introduced 2ms latency, which was acceptable. Misconfiguration risk: initially, the NSG for the app subnet mistakenly allowed all inbound traffic from the internet (priority 100) due to a copy-paste error, exposing the app servers. This was caught during a security review and fixed.

A healthcare provider required HIPAA compliance for a patient portal. They used Service Endpoints for Azure SQL Database and Azure Cosmos DB to ensure traffic stayed on the Microsoft backbone. However, they later switched to Private Link to meet strict compliance requirements that mandated data never touch the public internet. They created private endpoints for each service and disabled public access. They also configured Azure Firewall to log all outbound traffic and used Log Analytics to audit for data exfiltration. The firewall's threat intelligence blocked outbound connections to known malicious IPs. One challenge was DNS resolution: they had to configure custom DNS servers to resolve the private endpoint FQDNs. They also used NSG flow logs to investigate an anomaly where a VM was sending large amounts of data to an unknown IP; the logs showed the traffic was denied by an NSG rule, preventing a potential breach. Scale: they managed 50 VNets across multiple regions, using Azure Firewall policies for consistent rule enforcement.