Building Azure
Zero Trust.

The era of the "trusted internal network" is over. In modern cloud architecture, we must assume that breaches will happen. Zero Trust is not a product—it is a mindset: Verify Explicitly, Use Least Privilege, and Assume Breach.

In this guide, I will walk you through the exact architecture I built for the Azure Zero Trust Reference Implementation.

1. Identity as the Perimeter

In Zero Trust, identity is the new firewall. We control who can access resources before we even care about where they are connecting from.

Entra ID & Conditional Access

We start by enforcing strict verification policies. It's not enough to have a password; we need context.

• MFA for All: No exceptions. Using Conditional Access Policies to enforce phishing-resistant MFA.
• Device Compliance: Access is blocked if the device is not managed (Intune) or has a high risk score.
• Blocked Locations: Deny access from non-sanctioned geographies immediately.

# PowerShell: Create Conditional Access Policy
New-AzureADMSConditionalAccessPolicy `
    -DisplayName "Enforce MFA for Admins" `
    -State "Enabled" `
    -Conditions $conditions `
    -GrantControls $controls

Privileged Identity Management (PIM)

We remove permanent access ('Standing Access'). Admins must "activate" their roles just-in-time (JIT) for a limited duration (e.g., 2 hours).

2. Network Isolation (Hub & Spoke)

Even with strong identity, we need to contain the blast radius. We use a Hub-and-Spoke topology.

Azure Firewall Premium

The Hub contains the Azure Firewall. All traffic (North-South and East-West) is routed through it for inspection (IDPS/TLS Inspection).

Micro-segmentation with NSGs

In the Spoke VNets, we apply Network Security Groups (NSGs) to subnets. The default rule is Deny All. We explicitly allow only necessary traffic (e.g., Port 443 from the Hub).

3. Infrastructure as Code (Bicep)

Security cannot be manual. We define the entire environment using Azure Bicep. This ensures that our security baselines are version-controlled and repeatable.

// Bicep: Define NSG with Default Deny
resource nsg 'Microsoft.Network/networkSecurityGroups@2021-02-01' = {
  name: 'nsg-spoke-web'
  properties: {
    securityRules: [
      {
        name: 'DenyAllInbound'
        properties: {
          direction: 'Inbound'
          access: 'Deny'
          priority: 4096
          sourceAddressPrefix: '*'
          destinationAddressPrefix: '*'
        }
      }
    ]
  }
}

4. Continuous Monitoring (Sentinel)

"Assume Breach" means we must be looking for it. We stream logs from all resources (Firewall, Entra ID, NSG Flow Logs) to a Log Analytics Workspace connected to Microsoft Sentinel.

We use KQL (Kusto Query Language) to hunt for threats. For example, detecting failed SSH brute force attempts or impossible travel.

Conclusion

By combining Identity Governance, Network Micro-segmentation, and Automated Monitoring, we create a defense-in-depth posture that makes it incredibly difficult for attackers to move laterally.

<< Return to Project Overview