Identity and Access Model

Access is the control plane for everything else. If access is assigned carelessly — Owner to individuals, broad scopes, no elevation path — then no amount of policy or network design will keep the platform safe. This page defines an access model that is least-privilege by default and auditable by design.

Purpose

This page defines the Azure control-plane identity and access model using Microsoft Entra ID and Azure RBAC, and the operational practices around them: group-based assignment, Privileged Identity Management, and emergency access.

Design Reasoning

Microsoft Entra ID and Azure RBAC are related but separate, and confusing them is a common source of over-permissioning:

Microsoft Entra roles manage tenant-wide identity and directory capabilities (for example, Global Administrator, User Administrator).
Azure RBAC roles manage access to Azure resources (for example, Reader, Contributor, Network Contributor) at management group, subscription, resource group, or resource scope.

The strongest default model is consistent and boring:

Assign roles to groups, never to individual users.
Use built-in, job-function roles where possible; reserve custom roles for genuine gaps.
Avoid Owner and broad Contributor as default roles.
Assign access at the narrowest practical scope.
Use Privileged Identity Management (PIM) for elevated privileges — eligible, not standing.
Keep emergency access accounts outside normal operating processes.

Architecture Decision Record

Decision	Choice	Rationale
Access model	Role-assigned security groups per scope and environment	More scalable, auditable, and maintainable than direct user assignments; survives joiners, movers, and leavers.
Privileged access	Eligible assignments activated through PIM	Lowers standing privilege and produces an audit trail for every elevation.

Tradeoff: Group-based, PIM-gated access adds a layer between a person and a permission. That friction is the point — it is what makes access reviewable and time-bound instead of permanent and invisible.

Recommended Configuration

A baseline group-to-role mapping. Group names are illustrative; the pattern is what matters.

Group	Role	Scope
`az-platform-admins`	Reader by default; elevated admin roles through PIM	Platform management group or platform subscriptions
`az-network-admins`	Network Contributor	Connectivity subscription
`az-security-readers`	Security Reader or Reader	Security and management scopes
`az-workload-owners-<app>-prod`	Owner or User Access Administrator, only when justified	Specific production workload subscription
`az-workload-contributors-<app>-nonprod`	Contributor	Non-production resource group or subscription
`az-breakglass-admins`	Global Administrator	Cloud-only emergency access accounts

Use Owner sparingly. Most teams never need permanent Owner; they need a least-privilege role plus a clear elevation path for the rare case.

Emergency access (break-glass) accounts

Microsoft recommends maintaining at least two cloud-only emergency access accounts with the Global Administrator role permanently assigned, used only when normal administrative access is unavailable.

Current break-glass guidance

Older guidance excluded break-glass accounts from all Conditional Access and MFA. Microsoft now enforces mandatory MFA for the Azure and Entra admin portals, so emergency accounts must be protected with phishing-resistant authentication (a FIDO2 passkey or certificate-based authentication), while still being excluded from Conditional Access policies that could cause a lockout. Monitor every sign-in, and validate the accounts on a schedule (around every 90 days).

Example Implementation

The same access model expressed as personas — default access plus the elevation path:

Persona	Default access	Elevation
Platform operations	Reader on workload subscriptions	Temporary troubleshooting role through PIM
Network team	Network Contributor on the connectivity subscription	No workload Contributor by default
Security team	Security Reader or Reader	Temporary investigation access through PIM
Workload production team	Least-privilege workload role	Owner or User Access Administrator only with justification
Workload non-production team	Contributor	Usually no elevation required

Assign a role to a group at a scope with the Azure CLI:

1
az role assignment create \
2
  --assignee-object-id <group-object-id> \
3
  --assignee-principal-type Group \
4
  --role "Network Contributor" \
5
  --scope /subscriptions/<connectivity-subscription-id>

Validation Steps

1
# Review role assignments at a scope
2
az role assignment list --scope /subscriptions/<subscription-id> --output table
3

4
# Inspect what a built-in role actually grants
5
az role definition list --name "Network Contributor"

Also validate that emergency access accounts are cloud-only, excluded from Conditional Access policies that could lock them out, protected with phishing-resistant MFA, closely monitored, used only for break-glass scenarios, and tested on a schedule.

Common Mistakes

Assigning Azure roles directly to users instead of to groups.
One shared Contributor group across multiple landing zones, which collapses isolation.
Granting Owner by default, or giving application teams management-group-scoped access.
Leaving service principals with broad, standing permissions.
Not using PIM for privileged roles, or never testing emergency access accounts.