5.1 Virtual Network Security & Micro-segmentation

4.1 Virtual Network Security & Micro-segmentation

In Microsoft Azure, the Virtual Network (VNet) forms the fundamental private network boundary for cloud workloads. A robust security strategy requires designing isolated subnets, enforcing stateful traffic inspection via Network Security Groups (NSGs), implementing workload-centric micro-segmentation with Application Security Groups (ASGs), securing PaaS traffic through Service Endpoints, and strictly governing inter-VNet routing.

---

Azure Virtual Network (VNet) Design Baselines

A secure VNet deployment begins with structured IP address space allocation and subnet segregation according to workload security tiers:

1. Non-Overlapping CIDR Spaces

When designing VNets, allocate non-overlapping IPv4/IPv6 CIDR blocks (e.g., 10.100.0.0/16) across all cloud regions and on-premises sites connected via VPN or ExpressRoute. Overlapping address spaces break IP routing and create complex NAT requirements.

2. Dedicated Gateway & Management Subnets

Azure reserves specific subnets with precise naming conventions for native infrastructure services:

• AzureFirewallSubnet: Reserved exclusively for Azure Firewall instances. Requires a minimum subnet size of /26 (/24 recommended for operational scaling). Cannot have NSGs attached.
• GatewaySubnet: Dedicated to Azure Virtual Network Gateways (VPN or ExpressRoute). Requires at least /27 (/26 recommended).
• AzureBastionSubnet: Reserved for Azure Bastion host provisioning. Minimum /26 subnet required.
• RouteServerSubnet: Dedicated to Azure Route Server BGP peering.

3. Tiered Workload Isolation

Subnets should segment workloads by risk profile and data sensitivity (e.g., Web-Tier-Subnet (10.100.1.0/24), App-Tier-Subnet (10.100.2.0/24), Data-Tier-Subnet (10.100.3.0/24)). Direct internet inbound access should be denied by default on all internal tiers.

---

Network Security Groups (NSGs) & Stateful Filtering

A Network Security Group (NSG) contains stateful access control rules that allow or deny inbound or outbound network traffic. NSGs can be linked to subnets, individual Network Interfaces (NICs), or both.

Stateful Inspection Behavior

NSGs are stateful. If an inbound rule permits traffic (e.g., HTTP on port 80), the NSG automatically allows return outbound response traffic for that connection, regardless of outbound rules. Similarly, allowed outbound connections automatically permit return inbound responses.

Rule Priorities & Evaluation Mechanics

• Priority integers range from 100 to 4096.
• Rules are processed in sequential order from lowest priority number to highest.
• Evaluation stops as soon as a rule matches the connection parameters (Source IP/ASG, Source Port, Destination IP/ASG, Destination Port, Protocol). Sub-sequential rules are ignored.

Default Inbound & Outbound Rules

Every NSG contains non-modifiable default rules with priorities starting at 65000:

Critical Security Warning: The default rule AllowInternetOutBound allows any virtual machine to initiate outbound connections to internet destinations. In high-security environments, override this by creating an outbound custom rule (e.g., Priority 4000) that denies outbound access to Internet or forces egress through Azure Firewall.

---

Application Security Groups (ASGs) for Micro-segmentation

Managing NSG rules using explicit static IP addresses becomes unmanageable as infrastructure scales. Application Security Groups (ASGs) enable logical grouping of virtual machine NICs based on application workload identity (e.g., ASG-Web, ASG-App, ASG-Database).

Key Benefits of ASGs

• Zero-Trust Micro-segmentation: Define security policies based on application role rather than IP ranges.
• Dynamic Policy Application: When a new VM is provisioned and assigned to ASG-App, it automatically inherits all NSG rules specifying ASG-App as source or destination.
• Single NSG Management: A single NSG attached to a shared subnet can enforce strict isolation between Web, App, and DB tiers without maintaining complex IP lists.

NSG Rule Evaluation Matrix with ASGs

---

Azure Service Endpoints & Service Endpoint Policies

By default, Azure PaaS services (e.g., Azure Storage, Azure SQL Database) are exposed via public IP endpoints. Service Endpoints optimize PaaS connectivity by routing traffic directly over the Microsoft global backbone network.

Service Endpoint Mechanics

• When enabled on a subnet (e.g., Microsoft.Storage), the route for that service changes from public internet routing to direct private VNet backbone routing.
• PaaS firewalls can then be configured to accept traffic only from authorized VNet subnets, blocking all general public internet traffic.
• Traffic retains source private IP identity when accessing the PaaS resource.

Service Endpoint Policies (Exfiltration Prevention)

A critical security limitation of standard Service Endpoints is that VMs in the subnet can access any Azure Storage account in any subscription across Azure. This creates a data exfiltration vector where an attacker could copy sensitive internal data to an unauthorized external storage account.

Service Endpoint Policies restrict outbound Service Endpoint access to specific, approved Azure Storage accounts or specific Resource Groups/Subscriptions, effectively blocking unauthorized data transfer.

---

Forced Tunneling & User Defined Routes (UDRs)

Forced Tunneling ensures all internet-bound traffic originating from Azure subnets is redirected (tunneled) back to an inspection device—either an on-premises firewall via ExpressRoute/S2S VPN or an in-VNet Azure Firewall appliance—rather than exiting directly to the internet.

Implementation via Custom Route Tables (UDRs)

To enforce forced tunneling:

1. Create a custom Route Table and associate it with target workload subnets.
2. Define a route for prefix 0.0.0.0/0 with Next Hop Type set to:
   • VirtualAppliance (IP address of Azure Firewall or third-party NVA).
   • VirtualNetworkGateway (for routing via BGP to on-premises security stacks).

---

VNet Peering Security Configuration

Virtual Network Peering connects two Azure VNets with ultra-low latency over the Microsoft backbone. Peering is non-transitive by default (if VNet A is peered to VNet B, and VNet B is peered to VNet C, VNet A cannot communicate with VNet C without explicit peering or central routing).

Key Peering Security Flags

• Allow Virtual Network Access (AllowVNetAccess): Enables resources in peered VNets to communicate using the default AllowVNetInBound NSG rule. If disabled, traffic between peered VNets is blocked unless explicitly permitted.
• Allow Forwarded Traffic (AllowForwardedTraffic): Permits traffic not originating from within the peered VNet (e.g., traffic routed through a Network Virtual Appliance or gateway) to enter the VNet. Must be enabled on hub/spoke firewalls.
• Allow Gateway Transit & Use Remote Gateways: Allows spoke VNets to utilize a shared Virtual Network Gateway or Azure Bastion host located in a central Hub VNet, consolidating perimeter ingress/egress.