Azure Networking Audit

Azure VNet Networking Security Audit

Cloud resource audit for Azure Virtual Network (VNet) architecture, network security posture, and hybrid connectivity. This skill evaluates provider-specific Azure networking constructs — VNet design, NSG priority- based rules, Azure Firewall rule collection groups, ExpressRoute circuits, VNet Peering topology, UDR forced tunneling, and Application Gateway placement — not generic cloud networking advice.

Scope covers VNet-layer networking: address space planning, subnet delegation, NSG filtering, Azure Firewall inspection, hybrid connectivity via ExpressRoute and VPN Gateway, and route management. Out of scope: Azure Front Door CDN policies, Azure WAF custom rule authoring, application-layer routing in Application Gateway path rules, and Azure DNS zone management. Reference references/cli-reference.md for read-only Azure CLI commands organized by audit step, and references/vnet-architecture.md for the VNet packet flow model, NSG evaluation order, and ExpressRoute routing architecture.

When to Use

• VNet architecture design review — validating address space allocation, subnet delegation, and service endpoint configuration
• Post-migration networking audit — verifying VNet connectivity, NSG rules, and UDR entries after workload migration
• Security assessment — identifying overly permissive NSG rules, default NSG exposure, and missing Azure Firewall policies
• Connectivity troubleshooting — diagnosing ExpressRoute BGP peering failures, VPN Gateway tunnel drops, or VNet Peering asymmetric routing
• Compliance preparation — documenting VNet segmentation, NSG justification, and Azure Firewall logging for auditors
• Cost optimization review — identifying unused public IPs, orphaned NICs, and underutilized Application Gateway instances

Prerequisites

• Azure CLI authenticated (az account show succeeds)
• RBAC permissions — Reader role on target subscription, or granular read permissions: Microsoft.Network/virtualNetworks/read, Microsoft.Network/networkSecurityGroups/read, Microsoft.Network/azureFirewalls/read, Microsoft.Network/expressRouteCircuits/read, Microsoft.Network/virtualNetworkGateways/read, Microsoft.Network/routeTables/read, Microsoft.Network/networkInterfaces/read
• Target scope identified — specific subscription, resource group(s), and VNet name(s). Multi-subscription audits require az account set per subscription
• Network Watcher enabled — NSG Flow Logs and effective security rules require Network Watcher in the target region. If disabled, document as Critical

Procedure

Follow these six steps sequentially. Each step builds on prior findings, moving from inventory through security analysis to optimization.

Step 1: VNet Inventory and Design Assessment

Enumerate all VNets in the target subscription and assess architectural design.

az network vnet list --output table
az network vnet show --name <vnet-name> --resource-group <rg>
az network vnet subnet list --vnet-name <vnet-name> --resource-group <rg>

For each VNet, evaluate:

• Address space allocation: Primary and additional address spaces. Check RFC 1918 compliance, overlapping address spaces across peered VNets (blocks VNet Peering), and sufficient space for growth.
• Subnet layout: Identify subnets by purpose — workload subnets, AzureFirewallSubnet (required name for Azure Firewall), GatewaySubnet (required for VPN Gateway and ExpressRoute Gateway), AzureBastionSubnet. Verify required named subnets exist for deployed services.
• Subnet delegation: Check delegations to Azure services (Microsoft.Sql/managedInstances, Microsoft.Web/serverFarms). Delegated subnets restrict which resources can deploy — a subnet delegated to SQL Managed Instance cannot host VMs or other services.
• Service endpoints vs Private Endpoints: Service endpoints route PaaS traffic over Azure backbone but don't remove public endpoints on the PaaS resource. Private Endpoints create a private IP within the VNet for the PaaS service, removing public exposure entirely. Audit whether data services (Storage, SQL, Key Vault) use Private Endpoints (preferred for zero-trust) or service endpoints (legacy approach with broader exposure).
• DDoS Protection: Verify whether DDoS Protection Standard is enabled on the VNet. Basic DDoS protection is automatic for all Azure resources; Standard adds volumetric attack mitigation, cost protection guarantees, and access to the DDoS Rapid Response team.

Step 2: NSG Rule Audit

Audit Network Security Groups using Azure's priority-based evaluation model.

az network nsg list --output table
az network nsg rule list --nsg-name <nsg-name> --resource-group <rg> --include-default --output table

NSG rules evaluate by priority (lowest number = highest priority, range 100–4096). First match wins.

• Priority ordering conflicts: An Allow at priority 200 cannot be overridden by a Deny at 300. Verify Deny rules have lower priority numbers than conflicting Allows — inverse of AWS NACL logic.
• Default NSG rules: Azure creates three default inbound rules (AllowVNetInBound 65000, AllowAzureLoadBalancerInBound 65001, DenyAllInBound 65500) and three outbound defaults (AllowVNetOutBound, AllowInternetOutBound, DenyAllOutBound). These cannot be deleted but are overridden by any custom rule with lower priority number.
• Internet inbound: NSG rules permitting inbound from * or the Internet service tag. SSH/RDP from Internet is Critical; HTTPS on an Application Gateway subnet may be acceptable. The Internet service tag covers all public IP space excluding VNet, peered VNet, and on-premises address ranges.
• Effective security rules: NSGs apply at both subnet and NIC level. Azure evaluates subnet NSG first (inbound), then NIC NSG — traffic must pass both. Use az network nic show-effective-nsg to see the combined effective rules with resolved priorities. A rule allowed by subnet NSG but denied by NIC NSG is effectively denied.
• Application Security Groups (ASGs): ASGs group NICs for use as source/destination in NSG rules instead of IP ranges. Audit ASG membership for correctness.
• Unused NSGs: NSGs not associated with any subnet or NIC are cleanup candidates.

Step 3: Azure Firewall and Network Security

Evaluate Azure Firewall policies, rule collection groups, and threat intelligence.

az network firewall list --output table
az network firewall policy rule-collection-group list --policy-name <policy> --resource-group <rg>

• Rule collection group priority: Azure Firewall processes rule collection groups by priority (lowest first). DNAT rules process first, then Network rules, then Application rules.
• DNAT rules: Translate inbound traffic to private IPs. Verify each DNAT rule maps to a valid backend. Stale DNAT rules pointing to decommissioned hosts create exposure.
• Network rules: Permit/deny by IP, port, protocol. Audit for overly broad rules (* source/destination, wide port ranges).
• Application rules: Filter outbound by FQDN/URL. Verify application rules enforce FQDN restrictions for workload internet access.
• Threat intelligence mode: Azure Firewall supports threat intelligence filtering in Alert or Deny mode. Verify production firewalls use Deny mode.
• IDPS: Azure Firewall Premium supports signature-based IDPS. Verify mode (Alert vs Alert and Deny) and that bypass rules are justified.
• Azure Firewall subnet: AzureFirewallSubnet must be /26 or larger with a public IP and UDRs routing traffic through it.

Step 4: Connectivity Analysis

Evaluate hybrid and inter-VNet connectivity through ExpressRoute, VPN Gateway, and VNet Peering.

ExpressRoute:

az network express-route show --name <circuit> --resource-group <rg>
az network express-route peering list --circuit-name <circuit> --resource-group <rg>

• Circuit status: Verify ExpressRoute circuit shows "Provisioned" (provider side) and "Enabled" (Azure side). "NotProvisioned" means the provider has not completed circuit setup — no traffic will flow.
• BGP peering state: Check Azure Private Peering and Microsoft Peering BGP session state. State should be "Connected" — "Idle" or "Active" without "Connected" indicates peering negotiation failure (ASN mismatch, VLAN ID mismatch, or provider issue).
• Advertised routes: Verify on-premises routes are visible in Azure via az network express-route list-route-tables and Azure VNet routes are advertised back to on-premises. Missing routes cause silent traffic drops.

VPN Gateway:

az network vpn-connection show --name <conn> --resource-group <rg>

• Connection status: Should show "Connected". "Connecting" indicates IKE/IPsec parameter mismatch.
• Gateway SKU: Basic SKU lacks BGP and zone-redundancy. VpnGw2+ recommended for production.

VNet Peering:

az network vnet peering list --vnet-name <vnet> --resource-group <rg> --output table

• Peering state: Both sides must show "Connected". "Initiated" means reciprocal peering missing.
• Transit settings: AllowGatewayTransit on hub and UseRemoteGateways on spoke enable shared ExpressRoute/VPN. Verify settings match hub-spoke intent.
• Address space overlap: VNet Peering requires non-overlapping address spaces. Compare both VNets.
• Forwarded traffic: AllowForwardedTraffic must be enabled on both peering links for transit routing through Azure Firewall in the hub.