Listen to this Post
Introduction:
In an era of sophisticated cyber threats and sprawling cloud environments, traditional flat network designs are a critical liability. The Hub-Spoke architecture emerges as the definitive model for achieving scalable, secure, and governable cloud infrastructure. By centralizing critical security services and strictly isolating workloads, this design enforces a Zero Trust posture, ensuring that even if a spoke is compromised, lateral movement is contained and every action is logged.
Learning Objectives:
- Understand the core components and traffic flow of a security-first Azure Hub-Spoke architecture.
- Implement key security controls like Azure Firewall, Private Endpoints, and centralized logging using verified commands.
- Deploy Infrastructure as Code (Terraform) to automate and enforce this secure design pattern, enabling drift detection.
You Should Know:
- Deploying the Secure Hub VNet: Your Centralized Cyber Fortress
The Hub Virtual Network is the cornerstone of control, hosting shared security and governance services. This is not merely a connectivity point but an active inspection and enforcement layer.
Step‑by‑step guide explaining what this does and how to use it.
First, provision the foundational Hub VNet and the Azure Firewall, which will enforce network-level Least Privilege policies.
Azure CLI: Create the Hub Resource Group and VNet az group create --name rg-hub-prod --location eastus az network vnet create \ --resource-group rg-hub-prod \ --name vnet-hub \ --address-prefix 10.0.0.0/22 \ --subnet-name AzureFirewallSubnet \ --subnet-prefix 10.0.0.0/26 Deploy Azure Firewall with a public IP for forced tunneling/inspection az network firewall create \ -g rg-hub-prod \ -n fw-hub-central \ --vnet-name vnet-hub \ --sku-name AZFW_VNet az network public-ip create \ -g rg-hub-prod \ -n pip-fw-hub \ --sku Standard az network firewall ip-config create \ -g rg-hub-prod \ -f fw-hub-central \ -n fw-config \ --public-ip-address pip-fw-hub \ --vnet-name vnet-hub
Next, deploy the centralized observability backbone: a Log Analytics workspace. All spoke logs will be sent here for correlation and threat hunting.
Create Log Analytics workspace for aggregated security logs az monitor log-analytics workspace create \ -g rg-hub-prod \ -n law-hub-central \ --location eastus \ --sku PerGB2018
- Isolating Workloads in Spoke VNets with Strict Access Controls
Each environment (Prod, Non-Prod) resides in its own isolated Spoke VNet, connected via VNet Peering only to the Hub. This segmentation contains potential breaches.
Step‑by‑step guide explaining what this does and how to use it.
Create the Production Spoke VNet and peer it to the Hub. Notice the peering is configured to use the Hub’s firewall (allowGatewayTransit and useRemoteGateways).
Create the Production Spoke Resource Group and VNet az group create --name rg-spoke-prod --location eastus az network vnet create \ --resource-group rg-spoke-prod \ --name vnet-spoke-prod \ --address-prefix 10.1.0.0/24 Peer the Spoke to the Hub (Initiate from Spoke) az network vnet peering create \ -g rg-spoke-prod \ -n peer-spokeprod-to-hub \ --vnet-name vnet-spoke-prod \ --remote-vnet $(az network vnet show -g rg-hub-prod -n vnet-hub --query id -o tsv) \ --allow-vnet-access \ --allow-forwarded-traffic \ --use-remote-gateways Configure the Hub peering back to the Spoke (Initiate from Hub) az network vnet peering create \ -g rg-hub-prod \ -n peer-hub-to-spokeprod \ --vnet-name vnet-hub \ --remote-vnet $(az network vnet show -g rg-spoke-prod -n vnet-spoke-prod --query id -o tsv) \ --allow-vnet-access \ --allow-forwarded-traffic \ --allow-gateway-transit
Implement a Network Security Group (NSG) for a subnet hosting backend VMs, denying all direct internet egress.
PowerShell: Create an NSG with a strict inbound rule and deny all outbound to internet $rule1 = New-AzNetworkSecurityRuleConfig ` -Name "Allow-Inbound-HTTPS-From-AppGw" ` -Protocol Tcp ` -Direction Inbound ` -Priority 100 ` -SourceAddressPrefix "10.0.1.0/24" ` App Gateway Subnet -SourcePortRange ` -DestinationAddressPrefix ` -DestinationPortRange 443 ` -Access Allow $rule2 = New-AzNetworkSecurityRuleConfig ` -Name "Deny-All-Outbound-Internet" ` -Protocol ` -Direction Outbound ` -Priority 4000 ` -SourceAddressPrefix ` -SourcePortRange ` -DestinationAddressPrefix "Internet" ` -DestinationPortRange ` -Access Deny New-AzNetworkSecurityGroup ` -ResourceGroupName rg-spoke-prod ` -Location eastus ` -Name nsg-backend-tier ` -SecurityRules $rule1, $rule2
- Enforcing Zero Trust Traffic Flow with Azure Firewall Policies
All traffic between spokes, and from spokes to the internet, must be forced through the Hub’s Azure Firewall (a technique called forced tunneling). This enables unified policy enforcement and logging.
Step‑by‑step guide explaining what this does and how to use it.
Create a User-Defined Route (UDR) table in the Spoke’s subnet to send all traffic (0.0.0.0/0) to the Azure Firewall’s private IP.
Get the private IP of the Azure Firewall FW_PRIVATE_IP=$(az network firewall show -g rg-hub-prod -n fw-hub-central --query "ipConfigurations[bash].privateIpAddress" -o tsv) Create a UDR in the Spoke resource group az network route-table create \ -g rg-spoke-prod \ -n rt-spoke-prod-default Add a default route to the Firewall az network route-table route create \ -g rg-spoke-prod \ --route-table-name rt-spoke-prod-default \ -n default-to-firewall \ --address-prefix 0.0.0.0/0 \ --next-hop-type VirtualAppliance \ --next-hop-ip-address $FW_PRIVATE_IP Associate the UDR with a Spoke subnet (e.g., a backend subnet) az network vnet subnet update \ -g rg-spoke-prod \ --vnet-name vnet-spoke-prod \ -n backend-subnet \ --route-table rt-spoke-prod-default
Now, configure an Azure Firewall Application Rule to allow specific, needed outbound traffic (e.g., to Windows Update, a trusted API).
Create a Firewall Policy and an Application Rule Collection az network firewall policy create \ -g rg-hub-prod \ -n fw-policy-core az network firewall policy rule-collection-group create \ -g rg-hub-prod \ --policy-name fw-policy-core \ --name DefaultAppRules \ --priority 200 az network firewall policy rule-collection-group collection add-filter-collection \ -g rg-hub-prod \ --policy-name fw-policy-core \ --rule-collection-group-name DefaultAppRules \ --name "Allow-Trusted-FQDNs" \ --collection-priority 300 \ --action Allow \ --rule-name "Allow-Windows-Update" \ --rule-type ApplicationRule \ --source-addresses 10.1.0.0/16 \ --protocols Http=80 Https=443 \ --target-fqdns ".windowsupdate.com"
- Securing PaaS Services with Private Endpoints and DNS Resolution
Exposing databases or storage accounts to public endpoints is a leading cause of data breaches. Private Endpoints bring PaaS services into your private VNet address space.
Step‑by‑step guide explaining what this does and how to use it.
Create an Azure SQL Database and then a Private Endpoint for it within the Production Spoke VNet. This ensures the database is only accessible via private IP.
Create a SQL Server and Database (disabled public access) az sql server create \ -g rg-spoke-prod \ -n sqlserver-prod-unique \ --location eastus \ --admin-user sqladmin \ --admin-password <strong_password> az sql db create \ -g rg-spoke-prod \ -s sqlserver-prod-unique \ -n appdb-prod Disable public network access at the server level az sql server update \ --resource-group rg-spoke-prod \ --name sqlserver-prod-unique \ --public-network-access Disabled Create a Private Endpoint in the Spoke's subnet az network private-endpoint create \ --connection-name sql-private-conn \ --name pe-sql-prod \ --resource-group rg-spoke-prod \ --subnet $(az network vnet subnet show -g rg-spoke-prod --vnet-name vnet-spoke-prod -n backend-subnet --query id -o tsv) \ --private-connection-resource-id $(az sql server show -g rg-spoke-prod -n sqlserver-prod-unique --query id -o tsv) \ --group-ids sqlServer
Integrate this with Azure Private DNS Zones in the Hub for secure, internal name resolution across all spokes.
Create a Private DNS Zone for database services in the Hub az network private-dns zone create \ -g rg-hub-prod \ -n privatelink.database.windows.net Link the zone to the Spoke VNet so VMs there can resolve the private DNS name az network private-dns link vnet create \ -g rg-hub-prod \ -n link-to-spokeprod \ --zone-name privatelink.database.windows.net \ --virtual-network $(az network vnet show -g rg-spoke-prod -n vnet-spoke-prod --query id -o tsv) \ --registration-enabled false
- Implementing Infrastructure as Code for Governance and Drift Detection
Manual configuration drifts over time, creating security gaps. Terraform enforces the declared secure state and provides a clear audit trail.
Step‑by‑step guide explaining what this does and how to use it.
Below is a foundational Terraform (main.tf) snippet for the Hub VNet and Firewall, demonstrating how code locks in the architecture.
main.tf - Hub VNet and Firewall Module
provider "azurerm" {
features {}
}
resource "azurerm_resource_group" "hub" {
name = "rg-hub-tf"
location = "East US"
}
resource "azurerm_virtual_network" "hub" {
name = "vnet-hub-tf"
address_space = ["10.0.0.0/22"]
location = azurerm_resource_group.hub.location
resource_group_name = azurerm_resource_group.hub.name
}
resource "azurerm_subnet" "firewall" {
name = "AzureFirewallSubnet"
resource_group_name = azurerm_resource_group.hub.name
virtual_network_name = azurerm_virtual_network.hub.name
address_prefixes = ["10.0.0.0/26"]
}
resource "azurerm_public_ip" "fw_pip" {
name = "pip-fw-hub-tf"
location = azurerm_resource_group.hub.location
resource_group_name = azurerm_resource_group.hub.name
allocation_method = "Static"
sku = "Standard"
}
resource "azurerm_firewall" "hub" {
name = "fw-hub-central-tf"
location = azurerm_resource_group.hub.location
resource_group_name = azurerm_resource_group.hub.name
sku_name = "AZFW_VNet"
sku_tier = "Standard"
ip_configuration {
name = "configuration"
subnet_id = azurerm_subnet.firewall.id
public_ip_address_id = azurerm_public_ip.fw_pip.id
}
}
Run `terraform plan` to preview changes and `terraform apply` to deploy. Any unapproved manual change to these resources will be flagged in the next plan, enabling proactive drift detection.
What Undercode Say:
- Centralized Control is Non-Negotiable: The Hub’s security services (Firewall, Logging) act as a single, auditable choke point. This dramatically reduces the attack surface and simplifies compliance evidence collection.
- Isolation Trumps Flat Connectivity: Environment parity does not mean network parity. Strict VNet isolation for Prod/Non-Prod is the primary control that prevents a dev-test misconfiguration from escalating into a production breach.
- Future-Proof with Automation: The true value of this architecture is realized when it is codified. Infrastructure as Code (Terraform) transforms a static diagram into a dynamic, enforceable, and repeatable security policy, making scaling secure by default.
Prediction:
This architectural pattern will evolve from being a best practice to a mandated compliance requirement for cloud deployments within regulated industries. The next iteration will see AI-powered security services (like Microsoft Sentinel) deeply integrated into the Hub, analyzing the centralized telemetry to autonomously detect anomalies and dynamically update firewall policies or NSG rules in real-time to counter zero-day threats. Furthermore, as quantum computing advances loom, the Hub will become the logical control plane for implementing and managing post-quantum cryptography across all spoke workloads, making this design critical for long-term cyber resilience.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Bhabya Bharti – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
