Enterprise Identity and Access Design

In enterprise Azure environments, identity and access management must scale to hundreds of subscriptions, thousands of users, and dozens of teams — all with different resource access needs. A well-designed identity model prevents both over-permissioning (users with too much access) and under-permissioning (users unable to do their jobs). The foundation is Microsoft Entra ID combined with Azure RBAC and governance tools like Privileged Identity Management (PIM).

Azure Role-Based Access Control (RBAC) grants access through three components:

• Security principal — who (user, group, service principal, or managed identity)
• Role definition — what (a set of allowed actions, e.g., 'Contributor')
• Scope — where (management group, subscription, resource group, or individual resource)

Combining these three elements creates a role assignment. Roles are inherited down the hierarchy — a role assigned at a management group applies to all subscriptions below it.

Azure provides over 100 built-in roles covering common scenarios (Owner, Contributor, Reader, and service-specific roles). For most enterprise use cases, built-in roles are sufficient. However, when you need permissions that do not match any built-in role — for example, a role that can read VMs but cannot delete them — you can create a custom role with precisely the permissions needed, following the principle of least privilege.

Assign roles to Entra ID groups rather than individual users wherever possible. When you assign a role to a group, all members inherit the role. Adding or removing access is then a matter of adding or removing a user from the group — not modifying role assignments across multiple scopes. This greatly reduces administrative overhead and ensures access is consistent across team members who perform the same function.

Privileged Identity Management (PIM) is an Entra ID service that provides just-in-time (JIT) privileged access to Azure resources and Entra ID roles. Instead of having permanent Owner or Global Administrator access, users are eligible for privileged roles and must request activation when they need elevated access. Activation can require MFA, a justification, and approval by a designated approver.

PIM provides several security benefits for enterprise environments:

• Reduced attack surface — no permanent admin accounts that could be compromised
• Audit trail — every activation is logged with timestamp, justification, and approver
• Access reviews — PIM supports periodic reviews where managers confirm which users should remain eligible
• Time-limited access — even approved access expires automatically, preventing forgotten elevated permissions

A well-designed enterprise RBAC model typically has these layers:

• Management group level — broad viewer access for governance teams; policy assignments
• Subscription level — team-level Contributor access for application teams who manage one subscription
• Resource group level — service-specific roles (e.g., Storage Blob Contributor for an app that only needs blob access)
• Resource level — only for exceptional cases where fine-grained control is needed

Applications and automated processes should not use user accounts to authenticate to Azure. Instead, use:

• Service principals — application registrations in Entra ID with a client ID and secret or certificate; used by CI/CD pipelines and on-premises automation
• Managed identities — automatically managed credentials for Azure-hosted resources (VMs, App Service, AKS); no secrets to manage or rotate

Assign the minimum required RBAC roles to service principals and managed identities.

Conditional Access policies in Entra ID add intelligence to authentication decisions. For Azure resource management, you can require that admin access (Azure portal, CLI) only be permitted from:

• Compliant devices (managed by Intune)
• Named locations (corporate network or VPN)
• After MFA (always enforced for privileged actions)

Combining Conditional Access with PIM creates a very strong security posture for Azure administrative access.

Entra ID Access Reviews allow administrators to periodically validate that users still need the access they have been granted. Reviews can be delegated to resource owners or managers, who answer 'Yes, this person still needs access' or 'No, remove this access' for each user. Access reviews can be scheduled quarterly and automate the removal of access that is no longer approved, preventing access creep over time.

Every enterprise should maintain at least two emergency access (break-glass) accounts — Global Administrator accounts that are not protected by Conditional Access or MFA requirements (they use hardware FIDO2 keys instead). These accounts are used only when Entra ID or MFA systems are unavailable and normal admin accounts cannot be accessed. Emergency access account usage should trigger immediate security alerts and be audited rigorously.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: enterprise RBAC uses group-based assignments at management group, subscription, and resource group scope; Privileged Identity Management provides just-in-time access to eliminate permanent admin roles; and managed identities and service principals should be used for application authentication instead of user accounts. Congratulations — you have completed the enterprise architecture and governance section of the AZ-900 track!