3.1 Azure RBAC, Custom Roles, and Governance

3.1 Azure RBAC, Custom Roles, and Governance

Securing identity in Microsoft Azure requires a clear distinction between resource access management and directory identity management. Azure Role-Based Access Control (RBAC) is the core Authorization framework used to manage access to Azure infrastructure resources, while Microsoft Entra ID roles govern directory-level objects and administrative functions. Mastering Azure RBAC architecture, custom role creation, scope inheritance, deny assignments, and Azure Policy enforcement is critical for passing the AZ-500 exam and architecting zero-trust Azure environments.

---

1. Azure RBAC Architecture vs. Microsoft Entra ID Roles

Azure security administrators must understand the functional boundary between the Azure Resource Manager (ARM) control plane and the Microsoft Entra ID directory control plane.

[!IMPORTANT] A user assigned the Global Administrator role in Microsoft Entra ID does NOT automatically have permissions to manage Azure resources (such as reading storage accounts or managing Virtual Machines). To manage Azure resources, a Global Administrator must explicitly enable the "Access management for Azure resources" toggle in Entra ID properties, which temporarily elevates their account to the User Access Administrator role at the Root Management Group (/) scope.

---

2. Built-in Azure RBAC Roles

Azure provides over 100 built-in roles. The AZ-500 exam heavily tests the operational boundaries of the primary fundamental roles:

1. Owner (/providers/Microsoft.Authorization/roleDefinitions/8e3af657-a8ff-443c-a75c-2fe8c4bcb635):
   • Grants full access to manage all resources, including the ability to assign roles in Azure RBAC (Microsoft.Authorization/*).
2. Contributor (/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c):
   • Grants full access to manage all resources (create, edit, delete ARM resources), but cannot grant access to others (NotActions: ["Microsoft.Authorization/*/Write", "Microsoft.Authorization/*/Delete"]).
3. Reader (/providers/Microsoft.Authorization/roleDefinitions/acdd72a7-3385-48ef-bd42-f606fba81ae7):
   • Grants read-only access to view ARM resources and configurations. Cannot make changes or read data plane content unless explicitly allowed.
4. User Access Administrator (/providers/Microsoft.Authorization/roleDefinitions/18d50206-a5e3-4b86-8234-45016c74990d):
   • Grants permissions to manage user access to Azure resources (assign and remove RBAC roles) without granting control over resource deployment or configuration.
5. Security Admin (/providers/Microsoft.Authorization/roleDefinitions/fb355c54-9285-4728-b570-1463945138f6):
   • Grants permissions to view security recommendations, security policies, alerts, and configure Microsoft Defender for Cloud, but cannot grant user permissions or delete resources.

---

3. Custom Role Creation Deep Dive

When built-in roles do not meet specific organizational least-privilege requirements, security engineers must construct custom Azure RBAC roles. Custom roles are defined using JSON structures containing five key properties:

{
  "Name": "Virtual Machine Operator and Security Auditor",
  "IsCustom": true,
  "Description": "Allows restarting VMs, inspecting network interfaces, and reading storage data.",
  "Actions": [
    "Microsoft.Compute/virtualMachines/read",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Network/networkInterfaces/read",
    "Microsoft.Insights/alertRules/*"
  ],
  "NotActions": [
    "Microsoft.Compute/virtualMachines/delete"
  ],
  "DataActions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d",
    "/providers/Microsoft.Management/managementGroups/mg-core-infrastructure"
  ]
}

Understanding Role JSON Elements:

• Actions: Operations allowed on ARM control plane resources. Supports wildcards (*).
• NotActions: Operation exclusions subtracted from the Actions set.

  [!WARNING] NotActions is NOT a Deny rule! It is simply a subtraction helper. If a user is assigned a role with NotActions: ["Microsoft.Compute/virtualMachines/delete"], but is also assigned the Contributor role elsewhere, the user CAN STILL DELETE the Virtual Machine because permissions in Azure RBAC are strictly additive across assignments.

• DataActions: Operations allowed on data plane resources (e.g., reading messages from Azure Storage Queues, blobs, or Key Vault secret values).
• NotDataActions: Exclusions subtracted from DataActions.
• AssignableScopes: Specifies the Management Groups, Subscriptions, or Resource Groups where the custom role can be assigned.
  • Custom roles can be assigned at Management Group scope (must be enabled for Management Groups).
  • You cannot set an individual Resource scope (e.g., specific VM path) directly as an AssignableScope in the JSON definition.

---

4. Scope Hierarchy and Permission Inheritance

Azure RBAC permissions follow a strict structural hierarchy:

$\text{Management Group} \longrightarrow \text{Subscription} \longrightarrow \text{Resource Group} \longrightarrow \text{Resource}$

Core Inheritance Rules:

1. Top-Down Inheritance: Role assignments created at higher scopes (e.g., Management Group) are automatically inherited by all child containers and resources (Subscriptions $\longrightarrow$ Resource Groups $\longrightarrow$ Resources).
2. Additive Permission Model: Total effective permission is the union of all explicit and inherited role assignments. You cannot revoke inherited permissions at a child scope via standard RBAC assignments.
3. Resource Limits: A single Azure subscription supports up to 4,000 role assignments.

---

5. Deny Assignments

Unlike normal RBAC assignments (which are strictly additive allow rules), Deny Assignments explicitly block specific actions from being performed by security principals, even if an allow role assignment grants access.

• System-Managed Only: Deny assignments cannot be created directly by tenant administrators via Portal or CLI.
• Created by Services: Applied automatically by Azure Blueprints or Azure Managed Applications to prevent users (including Subscription Owners) from altering managed infrastructure components.
• Deny Assignment Exclusions: Can exclude specific deployment service principals while blocking user accounts from modifying protected resources.

---

6. Azure Policy Security Baselines and Governance

Azure Policy enforces organizational security standards and assesses compliance at scale across management groups and subscriptions.

       Azure Policy Engine
                │
    ┌───────────┴───────────┐
    ▼                       ▼
Initiatives           Policy Definitions
(Policy Sets)         (Single Evaluation Rules)
    │                       │
    └───────────┬───────────┘
                ▼
      Policy Assignments
(Scope: MG / Sub / RG / Resource)

Policy Definitions vs. Initiatives

• Policy Definition: A single rule condition expressed in JSON that evaluates a specific resource property (e.g., requiring tag Environment, restricting allowed VM SKUs, or enforcing storage HTTPS).
• Initiative (Policy Set): A collection of related policy definitions grouped together to achieve a broader compliance goal (e.g., the Microsoft Cloud Security Benchmark or Regulatory Compliance initiatives like PCI-DSS).

Azure Policy Effects (Execution Order):

1. Disabled: Policy rule is not evaluated.
2. Audit: Evaluates resource compliance and logs a non-compliant event in Azure Policy reporting without blocking resource deployment.
3. Deny: Evaluates resource creation or update request in ARM; if non-compliant, ARM immediately rejects the API call with a 403 Forbidden error.
4. AuditIfNotExists: Checks if a related sub-resource or setting exists (e.g., verifying if diagnostic logs are configured for a Key Vault). If absent, logs an audit event.
5. DeployIfNotExists (DINE): Checks if a sub-resource or setting exists; if non-compliant, automatically triggers a remediation task via a Managed Identity to deploy the missing resource (e.g., deploying the Defender for Cloud agent).
6. Modify: Adds, alters, or removes specified tags or resource properties during creation or update (e.g., automatically appending default tags).