Core Infrastructure Security: Network Segmentation and Virtual Networks in Azure

Introduction: The Foundation of Cloud Security

When we talk about cloud security, we often focus on identity management or threat detection. However, the most fundamental layer of defense remains the network. In an on-premises data center, you rely on physical firewalls, routers, and cabling to control traffic. In the cloud, this infrastructure is abstracted into software-defined networking (SDN). Microsoft Azure provides a powerful suite of tools to define, manage, and secure these virtualized networks.

Network segmentation is the practice of dividing a network into smaller, isolated sub-networks. The goal is simple: if a malicious actor gains access to one part of your environment, they should not be able to freely move to other, more sensitive areas. Think of it like a modern office building: you have a lobby, a public workspace, and a secure server room. You wouldn't give a visitor to the lobby the same access card as the system administrator, and you wouldn't allow them to walk directly into the server room.

In Azure, we implement this "Zero Trust" mentality through Virtual Networks (VNets), subnets, Network Security Groups (NSGs), and Application Security Groups (ASGs). This lesson explores how to architect these components to minimize your attack surface and protect your core infrastructure. Understanding these concepts is not just a technical requirement for certification; it is a critical skill for any cloud engineer responsible for protecting enterprise data.

Understanding the Azure Virtual Network (VNet)

A Virtual Network is the fundamental building block for your private network in Azure. It enables Azure resources, such as Virtual Machines (VMs), to securely communicate with each other, the internet, and on-premises networks. When you create a VNet, you are essentially creating a virtual version of a traditional network that you might have managed in a physical data center.

Core Components of a VNet

• Address Space: This is the range of private IP addresses you assign to your VNet, typically using CIDR notation (e.g., 10.0.0.0/16).
• Subnets: These are segments within your VNet that allow you to isolate resources into smaller groups. You can group resources by function, security requirements, or environment (e.g., web tier, application tier, database tier).
• Network Security Groups (NSGs): These act as virtual firewalls. They contain a list of security rules that allow or deny inbound and outbound network traffic based on IP address, port, and protocol.
• Route Tables: These define how traffic is routed within your VNet. By default, Azure handles routing, but you can override this to force traffic through a virtual appliance or a firewall.

Callout: VNet vs. Subnet While the VNet is the boundary for your private IP space, the subnet is the unit of segmentation. You can think of the VNet as the entire office building, and the subnets as the individual rooms. You can define security policies for the entire building, but you also need specific locks on the doors of the individual rooms to manage access effectively.

Designing for Segmentation: The Tiered Architecture

A common mistake in cloud deployments is creating a single, flat network where everything can talk to everything else. This creates a "flat network" vulnerability, where a compromised web server can easily scan and attack a database server. Instead, we use a tiered architecture.

The Three-Tier Model

1. Web Tier: This subnet contains resources that face the internet or a load balancer. These resources require the most restrictive inbound rules.
2. Application Tier: This subnet contains the business logic. It should only accept traffic from the Web Tier and should not have direct access to the internet.
3. Database Tier: This is the most sensitive area. It should only accept traffic from the Application Tier and should never have direct internet access or be reachable from the Web Tier.

Tip: Minimize Public Endpoints Always aim to keep your backend resources on private IP addresses. Use private endpoints or service endpoints to allow your resources to communicate with Azure PaaS services (like Azure SQL or Storage) without traversing the public internet.

Implementing Network Security Groups (NSGs)

Network Security Groups are the primary tool for traffic filtering. An NSG is a collection of security rules. Each rule specifies a source, a destination, a port, a protocol, and an action (allow or deny).

How NSGs Work

When you associate an NSG with a subnet, the rules apply to every resource within that subnet. When you associate it with a specific network interface (NIC) on a VM, the rules apply only to that VM. Best practice suggests applying NSGs at the subnet level for centralized management, while using NIC-level NSGs for specific, highly sensitive exceptions.

Example: Restricting Database Access

Let’s look at a scenario where we want to ensure only the Application Tier can access the Database Tier on port 1433 (SQL Server).

Step-by-step configuration:

1. Create an NSG named NSG-Database.
2. Add an inbound security rule:
   • Source: Application Subnet IP Range (e.g., 10.0.2.0/24)
   • Source Port Ranges: * (All)
   • Destination: Database Subnet IP Range (e.g., 10.0.3.0/24)
   • Destination Port Ranges: 1433
   • Protocol: TCP
   • Action: Allow
3. Add a deny rule (or rely on the default "DenyAllInbound" rule):
   • Source: Any
   • Destination: Any
   • Action: Deny

Warning: Default Rules Every NSG comes with default rules that allow communication within the VNet and deny all other inbound traffic. Be very careful when creating custom "Allow" rules; always follow the principle of least privilege. Never use "Any" as a source if you can define a specific IP range or service tag.

Advanced Segmentation: Application Security Groups (ASGs)

While NSGs use IP addresses, managing rules for hundreds of VMs based on IP addresses becomes a nightmare. This is where Application Security Groups (ASGs) come in. ASGs allow you to group VMs by their function (e.g., "WebServers," "DBServers") rather than their IP address.

Why use ASGs?

• Dynamic Membership: If you scale out your web tier, new VMs added to the "WebServers" ASG automatically inherit the security policies.
• Readability: It is much easier to read a rule that says "Allow traffic from WebServers to DBServers" than "Allow traffic from 10.0.1.5, 10.0.1.6, and 10.0.1.7 to 10.0.3.5."

Implementation Example

Instead of using IP ranges in the NSG rule, you use the ASG.

// Conceptual representation of an NSG rule using ASGs
{
  "name": "AllowWebToDB",
  "properties": {
    "sourceApplicationSecurityGroups": [
      { "id": "/subscriptions/.../resourceGroups/.../providers/Microsoft.Network/applicationSecurityGroups/WebServers" }
    ],
    "destinationApplicationSecurityGroups": [
      { "id": "/subscriptions/.../resourceGroups/.../providers/Microsoft.Network/applicationSecurityGroups/DBServers" }
    ],
    "destinationPortRange": "1433",
    "protocol": "Tcp",
    "access": "Allow",
    "priority": 100,
    "direction": "Inbound"
  }
}

Azure Firewall and Network Virtual Appliances (NVAs)

While NSGs provide excellent packet-level filtering, they are not a substitute for a full-featured firewall. For more advanced needs, such as Layer 7 inspection (application-level filtering), intrusion detection, and centralized management, you should use Azure Firewall.

Azure Firewall vs. NSGs

• NSGs: Best for basic traffic filtering between subnets and protecting individual VMs. They are free of charge.
• Azure Firewall: A managed, stateful firewall service. It provides FQDN filtering (e.g., allowing traffic only to *.microsoft.com), threat intelligence, and centralized logging.

Centralized Hub-and-Spoke Topology

In enterprise environments, it is common to use a "Hub-and-Spoke" network design. The "Hub" VNet contains shared services like the Azure Firewall, VPN gateways, and ExpressRoute circuits. The "Spoke" VNets contain the application workloads. All traffic between spokes or to the internet is forced through the Hub, where it is inspected by the Azure Firewall.

Callout: When to use what? Use NSGs for internal traffic control between application tiers. Use Azure Firewall for egress traffic (internet-bound) and for traffic between different spokes in a large network topology. This provides a "defense-in-depth" strategy where you have multiple layers of inspection.

Best Practices for Network Security

Security is an ongoing process, not a one-time setup. As your infrastructure evolves, your network configuration must evolve with it.

1. The Principle of Least Privilege

Always start with a "Deny All" posture. Only open the specific ports and protocols that are absolutely necessary for the application to function. If a server doesn't need to talk to the internet, ensure it doesn't have a public IP and that the routing table does not allow egress to the internet.

2. Use Infrastructure as Code (IaC)

Manual configuration is prone to human error. Use Bicep, ARM templates, or Terraform to define your network infrastructure. This ensures that your security rules are version-controlled, documented, and consistently applied across environments.

3. Implement Centralized Logging

Azure provides Network Watcher and NSG Flow Logs. These logs capture the IP traffic flowing through your NSGs. You should stream these logs to a Log Analytics workspace or Azure Sentinel. This allows you to audit traffic patterns and detect anomalies that might indicate a breach.

4. Regularly Audit Security Rules

It is easy for "temporary" rules to become permanent. Perform quarterly audits of your NSG rules to identify unused or overly permissive rules. Tools like Azure Policy can help enforce standards, such as preventing the creation of NSGs with rules that allow access from "Any" source to sensitive ports like SSH (22) or RDP (3389).

5. Use Service Tags

Whenever possible, use Azure Service Tags instead of hardcoded IP addresses for Microsoft services. For example, if you want to allow a VM to communicate with Azure Storage, use the Storage service tag. Microsoft automatically updates the IP addresses associated with this tag, saving you from having to manually update your firewall rules.

Common Pitfalls and How to Avoid Them

Even experienced engineers fall into common traps when designing network security. Here are the most frequent issues and how to avoid them.

Pitfall 1: Over-reliance on Default Rules

Many engineers assume that because they haven't added any rules, the network is secure. While the default "Deny All" inbound rule is helpful, the default "Allow VNet" rule allows any VM in your VNet to talk to any other VM. If you have different departments or environments (Prod vs. Dev) in the same VNet, you must explicitly add rules to block traffic between them.

Pitfall 2: Excessive Use of Public IPs

Assigning a public IP address to a VM is a major security risk. It exposes the VM directly to the internet, making it a target for brute-force attacks.

• The Fix: Use Azure Bastion for secure, RDP/SSH access to your VMs over SSL. Remove all public IPs from your VMs and rely on internal private IPs for all traffic.

Pitfall 3: Ignoring Egress Traffic

Security focus is often on what comes in. However, malware often communicates out to a Command-and-Control (C2) server. If you don't restrict outbound traffic, a compromised server can easily exfiltrate data or download further malicious payloads.

• The Fix: Use Azure Firewall or a similar NVA to restrict outbound traffic to only necessary FQDNs.

Pitfall 4: Misconfigured Route Tables

Sometimes, users create custom route tables to force traffic through a firewall but forget to include the default routes for Azure services. This can lead to connectivity issues where the VM cannot reach the Azure fabric, causing services like updates or monitoring agents to fail.

• The Fix: Always test your custom routes in a non-production environment first and ensure that routes for Azure service tags are correctly configured.

Step-by-Step: Securing a New VNet

Let’s walk through the process of setting up a secure network for a hypothetical web application.

1. Create the VNet: Define a non-overlapping address space (e.g., 10.10.0.0/16).
2. Define Subnets: Create three subnets: Subnet-Web (10.10.1.0/24), Subnet-App (10.10.2.0/24), and Subnet-Data (10.10.3.0/24).
3. Create NSGs: Create three separate NSGs, one for each subnet. This allows for granular control.
4. Configure Inbound Rules:
   • NSG-Web: Allow Port 80/443 from Internet (or a Load Balancer).
   • NSG-App: Allow Port 8080 from Subnet-Web.
   • NSG-Data: Allow Port 1433 from Subnet-App.
5. Assign NSGs: Associate each NSG with its respective subnet.
6. Verify: Use the "IP Flow Verify" tool in Azure Network Watcher to test connectivity between subnets. This tool tells you if a packet is allowed or denied based on your NSG rules.

Note: If you are using Azure Bastion, remember to create a specific subnet named AzureBastionSubnet with at least a /27 prefix. This is a requirement for the service to function.

Advanced Network Security: Private Link and Service Endpoints

As mentioned, exposing PaaS services to the internet is a risk. Azure provides two ways to secure this:

1. Service Endpoints

Service Endpoints provide a direct, secure connection to Azure services over the Azure backbone network. Your traffic never leaves the Azure network. However, the service still has a public IP address, and you rely on firewall rules at the service level to restrict access.

2. Private Link (Private Endpoints)

Private Link takes this a step further by assigning a private IP address from your VNet to an Azure service (like a SQL database or Storage account). The service effectively appears as if it is inside your VNet. This is the gold standard for security, as it completely removes the need for public IP addresses for your backend services.

Integrating with Azure Sentinel (SIEM)

A secure network is only as good as your ability to monitor it. Azure Sentinel is a cloud-native SIEM (Security Information and Event Management) that can ingest your NSG flow logs.

By analyzing these logs, Sentinel can identify:

• Reconnaissance: A single IP scanning multiple ports on your internal network.
• Data Exfiltration: A sudden spike in outbound traffic from a database server to an unknown external IP.
• Brute Force: Multiple failed login attempts from a specific external IP.

Setting up this integration involves enabling diagnostic settings on your NSGs to send logs to a Log Analytics Workspace, then connecting that workspace to Sentinel. This provides a single pane of glass for all your network security alerts.

Summary and Key Takeaways

Securing your infrastructure in Azure requires a shift in how you think about connectivity. By leveraging the tools provided in the Azure networking stack, you can create a robust, layered defense that protects your assets from both external and internal threats.

Key Takeaways for Cloud Engineers:

• Segmentation is Essential: Never deploy a flat network. Use subnets to group resources logically and enforce security boundaries between them.
• NSGs are your First Line of Defense: Apply NSGs at the subnet level to control traffic flow. Always follow the principle of least privilege, explicitly denying what you don't need to allow.
• ASGs Simplify Management: Use Application Security Groups to group VMs by function, making your NSG rules easier to read, maintain, and scale.
• Choose the Right Tool: Use NSGs for basic filtering, but look to Azure Firewall or NVAs for advanced Layer 7 inspection, centralized egress control, and threat intelligence.
• Prioritize Private Connectivity: Avoid public IP addresses for internal resources whenever possible. Use Private Link to keep your traffic on the private Azure backbone.
• Infrastructure as Code is Mandatory: Use templates to deploy your network. This eliminates configuration drift and ensures that your security standards are applied consistently across all environments.
• Monitor and Audit: Network security is not "set and forget." Enable flow logs, integrate with Sentinel, and conduct regular audits of your security rules to ensure they remain aligned with your business needs.

By following these principles, you move away from a reactive security stance and toward a proactive, "Zero Trust" architecture. Your networks will not only be more secure but also more manageable and resilient against the evolving threat landscape. Remember that in the cloud, you are responsible for the security of your network, and these tools are the primary instruments you have to fulfill that responsibility.