Use Azure RBAC to limit access by role

Azure role-based access control, or Azure RBAC, determines who can access Azure resources, which operations they can perform, and where those permissions apply.

It is an authorization system built on Azure Resource Manager. It should sit alongside identity protection, network controls, resource policy, logging, data-plane permissions, and operational review.

A role assignment has three parts

Security principal

A security principal is the identity receiving access. It can be a user, group, service principal, or managed identity.

Use groups and workload identities where practical. Direct user assignments are harder to review and remove at scale.

Role definition

A role definition lists allowed control-plane actions and, where supported, data actions. Azure includes built-in roles, and organisations can create custom roles when a built-in role grants too much or too little.

“Contributor” is not a harmless default. Select the narrowest role that supports the task and review privileged permissions separately.

Scope

Scope defines where the assignment applies:

1. management group
2. subscription
3. resource group
4. individual resource

Assignments at a higher level are inherited below that point. A broad scope increases the effect of a compromised account or mistaken change.

Microsoft’s scope guidance explains the hierarchy and inheritance behaviour.

Separate control-plane and data access

Permission to manage a resource does not always provide access to the data inside it. Azure role definitions distinguish management actions from data actions for services that support that model.

Check both planes. A person may need to configure a storage account without reading blobs, or read data without changing the resource.

Also review access paths that bypass Entra-based RBAC, such as account keys or service-specific credentials.

Apply least privilege to real tasks

Start with what the person or workload must do:

• which resource types
• which operations
• which environment
• for how long
• through which identity
• with which approval

Test the role in the intended scope. Do not add broad permissions to resolve an unexplained authorization error.

Govern privileged access over time

RBAC becomes an operating control when assignments have owners and review dates.

A practical review asks:

• Which assignments were added or removed?
• Which users receive access through nested groups?
• Which service principals or managed identities are inactive?
• Which custom roles changed?
• Which privileged assignments are permanent?
• Which resources still use keys or shared credentials?

Record emergency access separately and test how it is activated, monitored, and revoked.

Understand the compliance boundary

RBAC can support separation of duties and least privilege. It does not prove that an Azure environment meets a regulation or certification.

Compliance also depends on data handling, configuration, monitoring, incident response, evidence, and human process. State the control RBAC supplies rather than describing it as a complete compliance solution.

Microsoft’s Azure RBAC overview is the maintained source for principals, roles, scope, assignments, and licensing requirements.