Azure Security Fundamentals: Zero Trust for Cloud Workloads

Traditional perimeter-based security assumed that everything inside the corporate network was trustworthy. Build a strong wall, keep attackers out, and everything inside is safe. That model is dead. Cloud workloads span multiple regions, employees access systems from anywhere on any device, and modern attacks increasingly originate from inside the perimeter — through compromised credentials, phishing, or supply chain vulnerabilities.

Zero Trust replaces implicit trust with continuous verification. The principle is simple: never trust, always verify. Every access request — whether it comes from inside or outside the network — must be authenticated, authorised, and validated before access is granted. No exceptions.

The three Zero Trust principles

• Verify explicitly — always authenticate and authorise based on all available data points: identity, location, device health, service, workload, and data classification.
• Use least privilege access — limit user and workload access with just-in-time and just-enough-access policies. Minimise lateral movement if an account is compromised.
• Assume breach — design as if attackers are already inside. Segment access, encrypt everything in transit and at rest, use analytics to detect anomalies, and have an incident response plan ready.

On Azure, Zero Trust is implemented across three layers: identity and access (Microsoft Entra ID), network (Private Endpoints, NSGs, Azure Firewall), and workload visibility (Microsoft Defender for Cloud, Microsoft Sentinel). This article covers each layer with practical, implementable steps.

Identity is the new perimeter. In a Zero Trust architecture, strong identity controls are the most impactful single investment you can make. A compromised credential with no MFA and broad permissions is a complete breach. The same credential with MFA, Conditional Access, and least-privilege RBAC is a contained incident.

Multi-Factor Authentication and Conditional Access

Enable MFA for every user — no exceptions. In Microsoft Entra ID, use Security Defaults as a baseline or, for more control, Conditional Access policies. A strong baseline policy requires MFA when risk is detected and blocks legacy authentication protocols entirely.

• Require MFA for all users — prioritise admins and service accounts first.
• Block legacy authentication (SMTP, POP3, IMAP) — these protocols cannot enforce MFA and are a frequent attack vector.
• Require compliant or Entra ID-joined devices for access to sensitive applications.
• Use sign-in risk and user risk policies: automatically block or require step-up authentication when Entra ID detects suspicious behaviour.

Privileged Identity Management (PIM)

Permanent privileged access is one of the biggest risks in any Azure environment. A compromised Global Administrator account is a catastrophic breach. Privileged Identity Management (PIM) replaces permanent privileged roles with just-in-time access: users request elevation, provide a justification, and receive time-limited access that expires automatically.

// PIM role assignment settings (configured via Entra ID portal or ARM)
{
  "rules": [
    {
      "ruleType": "RoleManagementPolicyExpirationRule",
      "isExpirationRequired": true,
      "maximumDuration": "PT8H"   // max 8-hour activation
    },
    {
      "ruleType": "RoleManagementPolicyNotificationRule",
      "notificationType": "Email",
      "recipientType": "Approver",
      "isDefaultRecipientsEnabled": true
    },
    {
      "ruleType": "RoleManagementPolicyApprovalRule",
      "setting": {
        "isApprovalRequired": true,
        "approvalStages": [{
          "approvalStageTimeOutInDays": 1,
          "primaryApprovers": [{ "id": "<security-team-group-id>" }]
        }]
      }
    }
  ]
}

Least-privilege RBAC

Apply Azure RBAC at the narrowest scope possible. Assign roles at the resource group level rather than the subscription, and at the resource level when dealing with sensitive assets. Never use Owner or Contributor at subscription scope for day-to-day work. Use custom roles when built-in roles are too broad.

// Assign a custom least-privilege role at resource group scope
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(resourceGroup().id, principalId, roleDefinitionId)
  properties: {
    roleDefinitionId: roleDefinitionId  // custom or built-in role ID
    principalId: principalId             // managed identity or user object ID
    principalType: 'ServicePrincipal'
  }
}

Network controls in Azure have shifted from perimeter firewalls to micro-segmentation and private connectivity. The goal is to eliminate public exposure for every resource that does not need it, and to ensure that traffic between services never leaves the Microsoft backbone network.

Private Endpoints

By default, Azure services like Storage, SQL, Key Vault, and Cosmos DB have public endpoints — accessible from the internet with valid credentials. Private Endpoints replace the public endpoint with a private IP address in your Virtual Network. Traffic to the service stays within your VNet and the Microsoft backbone; it never traverses the public internet.

resource privateEndpoint 'Microsoft.Network/privateEndpoints@2023-04-01' = {
  name: 'pe-storage'
  location: location
  properties: {
    subnet: { id: subnetId }
    privateLinkServiceConnections: [{
      name: 'storage-connection'
      properties: {
        privateLinkServiceId: storageAccount.id
        groupIds: ['blob']
      }
    }]
  }
}

// Disable public network access on the storage account
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  properties: {
    publicNetworkAccess: 'Disabled'
    networkAcls: { defaultAction: 'Deny' }
  }
}

Just-in-Time VM Access

Virtual machines with open RDP (port 3389) or SSH (port 22) ports are constantly probed by automated scanners. Just-in-Time (JIT) VM access, provided by Microsoft Defender for Cloud, locks down management ports by default. When an administrator needs access, they request it through the portal or CLI — the port is opened for the specific source IP for a limited time window, then automatically closed.

1. Enable Microsoft Defender for Servers on the subscription.
2. In Defender for Cloud, go to Workload Protections → Just-in-time VM access.
3. Select the VMs to protect and configure allowed ports (RDP, SSH, WinRM) with maximum request times.
4. To request access: select the VM, click Request access, enter your source IP and duration.
5. Defender for Cloud creates an NSG rule for the duration, then removes it automatically.

Network Segmentation with NSGs and Azure Firewall

Use Network Security Groups (NSGs) to enforce micro-segmentation between subnets. Apply the principle of least privilege: deny all traffic by default and allow only what is explicitly required. For centralised, stateful filtering across the entire hub network, deploy Azure Firewall with IDPS (Intrusion Detection and Prevention System) enabled.

resource nsg 'Microsoft.Network/networkSecurityGroups@2023-04-01' = {
  name: 'nsg-app-tier'
  location: location
  properties: {
    securityRules: [
      {
        name: 'allow-https-inbound'
        properties: {
          priority: 100
          protocol: 'Tcp'
          access: 'Allow'
          direction: 'Inbound'
          sourceAddressPrefix: 'VirtualNetwork'
          sourcePortRange: '*'
          destinationAddressPrefix: '*'
          destinationPortRange: '443'
        }
      }
      {
        name: 'deny-all-inbound'
        properties: {
          priority: 4096
          protocol: '*'
          access: 'Deny'
          direction: 'Inbound'
          sourceAddressPrefix: '*'
          sourcePortRange: '*'
          destinationAddressPrefix: '*'
          destinationPortRange: '*'
        }
      }
    ]
  }
}

Assume breach means you must detect and respond to incidents quickly. Visibility across your entire Azure environment — who is doing what, which resources are misconfigured, and where anomalous activity is occurring — is not optional. It is the difference between a contained incident and a front-page breach.

Microsoft Defender for Cloud

Defender for Cloud provides a unified security posture score across your Azure subscriptions. It continuously assesses your resources against security benchmarks (CIS, NIST, Azure Security Benchmark) and surfaces recommendations ranked by impact. Enable the enhanced workload protections (Defender for Servers, Defender for Containers, Defender for SQL) to add threat detection on top of posture management.

• Start with the Secure Score in Defender for Cloud — anything below 70% has significant exposure.
• Address "High" severity recommendations first: exposed management ports, missing MFA, disabled disk encryption.
• Enable Defender for Servers to get JIT VM access, file integrity monitoring, and endpoint detection.
• Enable Defender for Containers to scan images in ACR for vulnerabilities and monitor AKS for runtime threats.
• Export recommendations to Azure Policy to enforce compliance automatically on new resources.

Microsoft Sentinel for SIEM and SOAR

Microsoft Sentinel is Azure's cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation and Response (SOAR) platform. It ingests logs from Entra ID, Azure resources, Microsoft 365, and third-party sources, applies machine learning to detect threats, and can trigger automated response playbooks.

// Example Sentinel analytics rule: detect impossible travel
{
  "displayName": "Impossible Travel Activity",
  "description": "Detects sign-ins from two geographically distant locations in a short time window",
  "severity": "High",
  "query": "SigninLogs | where ResultType == 0 | summarize Locations = make_set(Location), Times = make_list(TimeGenerated) by UserPrincipalName | where array_length(Locations) > 1",
  "queryFrequency": "PT1H",
  "queryPeriod": "PT1H",
  "triggerOperator": "gt",
  "triggerThreshold": 0,
  "tactics": ["InitialAccess"],
  "techniques": ["T1078"]
}

Connect Sentinel to your Entra ID sign-in logs, Azure Activity logs, and Defender for Cloud alerts as a minimum baseline. Use the built-in MITRE ATT&CK coverage workbook to understand which attack techniques you can detect and which are gaps.

Zero Trust is not a destination — it is a continuous improvement process. Start with the highest-impact controls: MFA for all users, PIM for privileged roles, Private Endpoints for sensitive services, and JIT VM access. These four changes alone will dramatically reduce your attack surface.

Then establish visibility: enable Defender for Cloud, connect Sentinel, and review your Secure Score monthly. Security is a culture, not a project. The organisations that treat it as ongoing practice — not a one-time audit — are the ones that catch incidents early and contain the blast radius when something does go wrong.