Link Search Menu Expand Document
×
Topics

Broken Authorization in Azure

Play SecureFlag Play Azure Labs on this vulnerability with SecureFlag!

Azure Identity and Access Management (IAM) is a crucial component of Azure’s security model. It provides the tools and features necessary to ensure that the right people have the right access to the right resources.

Role-Based Access Control (RBAC) is an authorization system that provides fine-grained access management of resources in Azure. Azure has two different RBAC systems, named “Azure RBAC” and “Microsoft Entra RBAC”, which govern different resource types.

Microsoft Entra RBAC

Entra ID (previously known as Azure Active Directory) is Microsoft’s multi-tenant, cloud-based directory and identity management service. It allows employees to access external and internal resources, like Microsoft 365, the Azure portal, or corporate intranet apps.

Entra RBAC differs from Azure RBAC in the resources they govern; Entra RBAC manages access to Entra resources like users or groups, while Azure RBAC governs access to Azure resources storage, functions, and virtual machines. Although both have similar role definitions and assignments, their permissions can’t be interchanged.

Azure RBAC

Azure RBAC is a system that provides fine-grained access management to Azure resources, allowing administrators to grant specific permissions to users, groups, or applications. It operates on the principle of least privilege, ensuring individuals have only the necessary access to perform their tasks, thus enhancing security and compliance within Azure environments.

Assigning roles involves the following key concepts:

  • Security principals These are the Microsoft Entra ID identities (user, group, or service principal) who receive the role assignments.
  • Roles: A role is a collection of permissions necessary for a particular job. Both predefined and custom roles exist.
  • Scope: The scope defines the boundary of the role assignment. A role can be limited to a certain resource or target a whole resource group, subscription, or even a management group.
  • Role Assignment: It’s the act of linking a role to an identity, be it a user, a group of users, or service principals.

In summary, roles define “what can be done”, scopes determine “where it can be done,” and role assignments bridge roles and scopes to dictate “which identities can do what and where.”

Scope

RBAC uses “scopes” to determine the access boundaries for each role.

Scopes in Azure are hierarchical, meaning one can get as broad or granular as needed with permissions. It is represented as a path which typically follows the structure:

/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/{resource-provider-namespace}/{resource-type}/{resource-name}

Predefined Roles

Here are some of the primary predefined roles available in Azure:

  • Reader: Users with this role can view existing Azure resources.
  • Contributor: Beyond just viewing, these users can create and manage resources, although they can’t change access to them.
  • Owner: Owners can manage resources, grant access, and essentially have a carte blanche over resources.
  • User Access Administrator: Tailored specifically for access management, these users manage access permissions.

Many other predefined roles exist, each tailored to specific operational needs within Azure, and understanding their interrelation with scopes, role assignments, and users is crucial for maintaining a secure and efficient cloud environment.

Here’s an example of the “Reader” role to a user using Terraform:

resource "azurerm_role_assignment" "example_reader" {
  principal_id         = azuread_user.example.object_id
  role_definition_name = "Reader"
  scope                = "/subscriptions/${var.subscription_id}"
}

Custom Roles

Apart from predefined roles, it is possible to define custom role definitions with only the desired allowed or disallowed operations on resources or data within those resources. By creating custom roles, administrators can effectively provide only the required permissions to users, groups, or service principals.

Permissions

Permissions contain different types of actions, such as “Actions”, “NotActions”, “DataActions”, and “NotDataActions”.

“Actions” is a list that specifies allowed operations on resources. Conversely, “NotActions” is a list that specifies which operations are not allowed, serving as overrides to the permissions granted by “Actions”. “DataActions” and “NotDataActions” have the same characteristics but refer to operations on the data within those resources.

They correspond to a specific action and are formatted as {Company}.{ProviderName}/{resourceType}/{action}. The {action} segment specifies the operation type on a resource, e.g., read for reading, write for resource-changing and state-changing actions such as configuring or starting services, and delete for destructive actions. For example, Microsoft.Compute/virtualMachines/delete represents the action of removing virtual machines in the Compute service.

Wildcards (*) can be used to represent a broad set of actions when writing permissions. For instance, Microsoft.Compute/* would encapsulate all operations under the Compute service. When used at the start of the permission, wildcards signify that the particular action is applicable across a broad range of resource providers. For example, the */write permission permits the ability to perform write operations across all Azure resources. Such broad permissions can easily expose an organization to risks, as they grant expansive control across the Azure environment.

Here’s an example of a storage account operator who can perform every action on every storage account in a given subscription except deletion.

resource "azurerm_role_definition" "example" {

  name  = "Limited Storage Account Operator"
  scope =  data.azurerm_subscription.primary.id

  assignable_scopes = [
    data.azurerm_subscription.primary.id
  ]

  permissions {
    actions = [
      "Microsoft.Storage/storageAccounts/*"
    ]
    not_actions = [
      "Microsoft.Storage/storageAccounts/delete"
    ]
  }
}

resource "azurerm_role_assignment" "example" {
  scope              = data.azurerm_subscription.primary.id
  role_definition_id = azurerm_role_definition.example.role_definition_resource_id
  principal_id       = var.service_principal_id
}

References

Microsoft - What is identity and access management (IAM)?

Microsoft - What is Azure role-based access control (Azure RBAC)?

Microsoft - Understand Azure role definitions

Microsoft - Role-based access control for application developers

Microsoft - Azure built-in roles