Azure Landing Zones Governance

Brewing the Latest Azure Landing Zone – Identity and Access Foundations

Designing for least privilege and conditional access within the new ALZ model.

A landing zone without a proper identity model is like a café without portion control—too much espresso and everything goes haywire, too little and nothing works with any punch. The latest Azure Landing Zone (ALZ) design has refined its approach to identity and access, ensuring your platform and workloads aren’t over‑caffeinated with excessive privilege.

In this post, we’ll look at how the ALZ identity layer is structured, how to align with least‑privilege principles, and how tools like Privileged Identity Management (PIM) and Conditional Access keep your digital baristas in check.

What is “Identity and Access Foundations” in ALZ?

In Microsoft’s Cloud Adoption Framework (CAF), Identity and Access Management is one of the core design areas underpinning governance, networking, and operations. It defines how Microsoft Entra ID (formerly Azure AD) authenticates and authorises users, applications, and services.

Within a landing zone, identity foundations mean:

  • Administrative layers are clearly divided using management groups and subscriptions.
  • Access follows least privilege and just‑in‑time principles.
  • Conditional Access (CA) policies and break‑glass accounts are defined from day one.
  • Platform and workload identities operate independently, reducing blast radius.

Deployed via the ALZ Bicep or Terraform accelerators, these principles become part of your control plane architecture—not an afterthought after workloads land.

How It Works

Identity in an ALZ spans three planes:

  1. Control Plane – Managed through Entra ID and management groups. This is where global policies and Conditional Access live. Only a small, well‑audited team should hold access here.
  2. Platform Layer – Covers shared services such as networking, monitoring, and security. Role assignments here are limited to platform engineers via RBAC.
  3. Workload Layer – Each workload subscription inherits a baseline identity policy while maintaining autonomy for its application teams.

A simple mapping looks like this:

flowchart TD A[Entra ID Tenant] --> B[Management Group Hierarchy] B --> C[Platform Subscription] B --> D[Connectivity Subscription] B --> E[Workload Subscriptions] A -->|PIM + Conditional Access| B C -->|RBAC Roles| F[Platform Team] E -->|Managed Identities + Custom Roles| G[Workload Teams]

Each layer integrates with Entra roles, Azure RBAC, and PIM to maintain separation between operational, security, and application functions.

Real‑World Impact

When identity is poorly structured, everyone ends up wearing too many aprons—network admins holding Owner rights on production subscriptions, or developers creating service principals with excessive permissions.

By enforcing tiered identity and PIM activation:

  • Privilege sprawl is drastically reduced.
  • Operational oversight improves with clear audit trails.
  • Security breaches are contained—access is temporary, traceable, and justified.
  • Cross‑team collaboration becomes safer with controlled Entra B2B roles.

It’s a design that scales with your tenancy, not against it.

Implementation Examples

1. Assign Role‑Based Access in Azure Portal

  1. Go to Management Groups → Access Control (IAM).
  2. Assign:
    • Owner or Contributor roles only at Platform or Connectivity tiers to core teams.
    • Reader or Monitoring Contributor roles for governance visibility.
    • Narrow roles (e.g. Network Contributor, Security Reader) for workload subscriptions.

2. Enable Privileged Identity Management (PIM)

  1. Open Entra ID → Privileged Identity Management.
  2. Onboard Azure resources.
  3. Define permanent eligible role assignments (not active).
  4. Require MFA, justification, and approval to activate roles.

3. Bicep Example – Controlled Role Assignment 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

param principalId string
param roleDefinitionId string
param scope string

// Assign Network Contributor at platform subscription level
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(scope, principalId, roleDefinitionId)
  scope: scope
  properties: {
    roleDefinitionId: roleDefinitionId
    principalId: principalId
    principalType: 'ServicePrincipal'
  }
}

Example values:

  • roleDefinitionId: b24988ac-6180-42a0-ab88-20f7382dd24c (Contributor)
  • scope: /subscriptions/{platformSubscriptionId}

4. Conditional Access + MFA Enforcement

Use Conditional Access in Entra ID → Security → Conditional Access to enforce MFA for administrative roles.
Common patterns:

  • Require compliant device or Azure AD‑joined machine.
  • Block access from legacy auth or anonymous IP ranges.
  • Apply strict policies to Global Administrator, Privileged Role Administrator, and PIM‑eligible roles.

Sovereign Landing Zones and Identity

While most ALZ identity designs target commercial Azure regions, the same principles extend to Microsoft Sovereign Landing Zones (SLZ). These environments service jurisdictions such as Azure Australia Central, Azure Government, and Azure for EU Data Boundary—offering additional isolation and compliance controls.

Key differences include:

  • Tenant separation – Sovereign or regulated environments may require a dedicated Entra ID tenant, isolated from corporate or commercial directories.
  • Conditional Access under local policy – CA rules may enforce sovereign network ranges, national ID providers, or hardware‑backed MFA.
  • PIM activation oversight – Privileged activations often require local approval aligned with regulatory standards (e.g. IRAP, FedRAMP, or EU GDPR).
  • Identity data residency – Authentication logs and audit data may be restricted to certified national datacentres.

For most enterprises, the identity design principles in this post serve as the baseline for sovereign expansion—the same brew, just filtered through a compliance‑grade portafilter.

Gotchas & Edge Cases

  • Global Admin concentration: Limit tenant‑wide roles. Use scoped Entra roles like Cloud App Administrator or Security Admin wherever possible.
  • Automation accounts: Managed identities don’t always bridge cross‑tenant scenarios; consider using app registrations secured with certificates.
  • PIM activation latency: Factor delays into incident response playbooks.
  • Break‑glass accounts: Maintain two emergency cloud‑only accounts with monitored sign‑in alerts—never MFA‑disabled by accident.

Best Practices

  • Model access around management group hierarchy, not ad‑hoc subscription roles.
  • Group RBAC assignments via Azure AD security groups to simplify lifecycle management.
  • Enforce Conditional Access with MFA for all administrators.
  • Separate platform and workload identities—no shared service principals.
  • Automate credential rotation through Key Vault and managed identity.
  • Review PIM usage quarterly; revoke stale eligible assignments.
  • Document ownership boundaries as part of your governance artefacts.
  • For sovereign deployments, confirm identity residency and tenant isolation requirements early in design.
🍺
Brewed Insight: Identity is the grind setting of your cloud security—too coarse and everything slips through, too fine and no one can do their job. Get it just right with structured access tiers and automation, and your landing zone will run as consistently as your first morning cuppa.

Learn More