Azure IAM Deep Dive: Enhancing Access Supervision with CNAPP Solutions

Have you ever experienced any of the following scenarios?

Have you ever given a friend, supplier, or someone outside of your family your Wi-Fi password and forgotten to change it afterwards? Have you ever given someone the password to your computer but forgotten to keep track of who had this information? Maybe you’ve logged into a service or platform using someone else’s device but then forgotten to log out? Well, you aren’t alone. Just as these small lapses in security judgement can lead to unintended access and potential risks in your personal life and data, the stakes are even higher for companies managing access to sensitive information on a much larger scale.
Let’s take for instance a big company that has many employees giving permissions to other employees or clients. Without proper tracking on who has which permissions, or without ensuring that permissions are revoked after they complete tasks, their company is at risk for potential attacks resulting from data leakage or manipulation and privilege escalation. Privilege escalation is when a user can obtain additional permissions beyond what they began with, including unsupervised access and much more. In this blog, we will explain the importance of awareness of supervising access and using IAM (identity and access management). Then, we will deep dive into how it's being handled in Azure, and explore how Panoptica, Cisco’s Cloud Application Security platform can help identify and detect these issues.

What is IAM?

IAM, or Identity and Access Management, is a collection of policies and technologies for ensuring the right individuals have the appropriate access to specific resources, in our case, Azure resources. IAM systems provide administrators with the tools and processes to assign and manage user identities, roles, and permissions, ensuring secure access to networks, systems, and data. These systems are crucial for maintaining security and compliance, as they help prevent unauthorized access and mitigate risks associated with threats and data breaches.

IAM can be split into two main categories:

1. Identity Management: The identity, whether a person, machine, or software component, verifies its claimed identity. This involves the creation, maintenance, and deletion of user identities and profiles.
2. Access Management: The person, machine, or software component is either granted or denied permission to access specific resources. This emphasizes controlling what entities can perform within a system . It involves setting up and managing roles and permissions to ensure that entities have the appropriate level of access to perform their job functions, while minimizing the risk of unauthorized access to sensitive information.

How IAM Works in Azure

To understand access management in Azure, we first need to explore how Azure handles identities through Microsoft Entra ID.

Entra ID

Entra ID is a cloud-based identity and access management service for services offered by Microsoft, including Azure (and other services like Teams, 365, and more). When registering to Microsoft Entra ID, the instance created is called a tenant. When configuring a tenant, the user will enter an initial domain name - usually the name of the company [. onmicrosoft.com].

In a tenant there can be one or more directories. A directory is a container for identities such as users, groups, and applications. The identities created in Entra ID are brought to the Microsoft services, in our case Azure, at the Root Management Group level (which will be explained later).

Scopes in Azure

As mentioned above, in Azure there is a hierarchy between different scopes. We have management groups, with the highest management group in the hierarchy called ‘Tenant Root group’, then we have subscriptions, resource-groups, and resources.

• Management Groups: The highest level of scope within Azure, is used to manage access, policies, and compliance across multiple subscriptions. These groups serve as containers that can include several management groups or subscriptions. Each Entra ID tenant is provided with a single top-level management group called the ‘Tenant root group’. This root management group is the parent of all other management groups and subscriptions within the tenant's hierarchy. New subscriptions are automatically defaulted on to the root management group when created.
• Subscriptions: A billing container that is used to provision and manage resources such as virtual machines, databases, and storage accounts. Within a subscription, resource groups organize these resources. Each subscription is linked to a directory within an Azure Entra ID tenant.
• Resource Groups: Used as containers that hold related resources. They help manage and organize resources by grouping them together, allowing for easier deployment, monitoring, and access management.
• Resources: Resources are individual services or components in Azure, such as virtual machines, databases, storage accounts, and networking components, that are used to build and run applications. Each resource is created within a resource group and is managed as part of that group or individually.

In the diagram above, we can see an example of a hierarchy in Azure. Under the default management group “Tenant Root Group” there is:

one management group called “Contoso” and one subscription called “Landing Zone B”.

Under the management group called “Contoso” lies a subscription called “Landing Zone A”.
Under each subscription there is a resource group, with resources within it. For example, “VMforA” is a virtual machine instance, within “MyResourceGroupA” resource group, within “Landing Zone A” subscription, within “Contoso” management group, within “Tenant Root Group”.

The red marked boxes are a hierarchy where the subscription is under a management group different than the default “Tenant Root Group”, and the latter is a subscription that is within the default management group.

Identities in Azure

Identities in Azure originate from Entra ID, from the same directory as your tenant’s. There are a few types of identities in Entra ID:

• Users
• Groups
• Service Principals
  • Applications
  • Managed Identities

Users

User identities consist of individuals such as employees or external users, with distinctions based on authentication method and user type properties. Users can be split by User Type and Authentication Method.

• User Type characterizes the user's association with the host organization's tenant. The options are Member or Guest.

• Authentication Method may occur internally. These can be accounts within the organization, or externally including accounts from other Microsoft Entra instances, social networks, or external identity providers.

This is what a user page looks like in Entra ID.

Groups

There are two types of groups:

1. 365 Group: Microsoft 365 Groups simplify working with Microsoft 365 tools so you can collaborate with your teammates when writing documents, creating spreadsheets, working on project plans, scheduling meetings, or sending emails. Note that in 365 groups there can only be users.

• Security Group: Security groups simplify access management for users, service principals, or other groups through role-based access control (RBAC). Granting access to a group rather than individuals is simpler and safer. In security groups there can be all types of identities, including more security groups.

This is what a group page looks like in Entra ID.

Service Principal

An Azure service principle is an identity created for use with applications, hosted services (like virtual machine), and automated tools to access Azure resources. This access is restricted by the roles assigned to the service principal, giving more control over which resources can be accessed and at which level.

There are two types of service principal: 

1.        Application

When creating an application, both an app object and a service principal are created. These two components work together to enable the application to authenticate and access resources within Entra ID and other Azure services. Let’s take a closer look and see the differences and the similarities of App Object and Service Principal below.

2.        Managed Identity

Managed identities provide an identity for some Azure resources such as virtual machines. They eliminate the need for developers to manage credentials, unlike applications, and simplify access management by seamlessly integrating with Azure services. To use a managed identity, it needs to be enabled. When a managed identity is enabled, a service principal representing that managed identity is created in your tenant. To oversee all managed identities, go to ‘Enterprise Applications’ in Entra ID and filter to see Managed identities.

There are 2 types of managed identities:

1. System-assigned
2. User-assigned

Let’s take a closer look and see the differences and the similarities of User Assigned and System Assigned Managed identities below.

Access Management in Azure - Meet ‘RBAC’

We talked before about the two parts of IAM: Identity Management and Access Management. We will focus on Access Management. We covered the type of identities in Azure that come from the directory. Those identities want to execute an action, and they will either be allowed to do so or denied. This is called RBAC - Role Based Access Control, an authorization system built on Azure Resource Manager that provides fine-grained access management to Azure resources. Identities are assigned roles that grant them the ability to execute an action (like read, write, delete) within a scope. A role assignment consists of three elements: security principal, role definition, and scope. Now let's break down these components to get a better understanding of how Azure RBAC works.

Security Principal

The security principal can be any type of the identities in Entra ID. It is an object that represents a user, group, or a service principal that requests access to Azure resources. You can assign a role to any of these security principals.

Permissions

The format of a permission is:

{company}.{providerName}/{resourceType}/{action}

An example of a permission using the format:

Microsoft.Compute/virtualMachines/delete

{action} can be one of the following:

Control Plane Operations

Control plane operations are permissions for management actions such as creating a resource, deleting a resource, editing permissions, etc. It is specified in the Actions and NotActions properties of a role definition.

For example:

Permission	Description
Microsoft.Storage/storageAccounts/blobServices/containers/read	Returns container or a list of containers

Data Plane Operations

Data plane operations are permissions that specify what actions are allowed to be performed to your data within that resource, such as uploading data, reading data, downloading data, etc. It is specified in the DataActions and NotDataActions.

For example:

Permission	Description
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read	Returns a blob or a list of blobs

Role Definitions

A role definition is a set of permissions, mostly referred to as a role. It contains the actions that can be performed. Roles can be high-level, like "Owner”, or specific, like virtual machine contributor . There are built-in roles and custom roles.

A Role definition consists of actions, notActions , dataActions, notDataActions, and assignableScope:

• Actions - NotActions = Effective control plane permissions (taking all permissions under Action and putting them on a list; then removing all permissions under NotActions from that list; finally to give you the effective control plane permissions).
• DataActions - NotDataActions = Effective data plane permissions. (Same calculations but subtracting the NotDataActions from DataActions).
• AssignableScope is the scope.

The permissions for control plane operations and data plane operations are distinct and you cannot mix them. Specifically, a data plane permission cannot be used in the ‘Action’ section of a role definition, and vice versa. Although Actions and NotActions, as well as DataActions and NotDataActions, can share the same strings, their purposes are different: Actions and DataActions define allowed operations, while NotActions and NotDataActions define excluded operations.

Having the same action appear both in Action and in notAction will not give permissions to execute the action.

Assignable Scope

This property specifies the scopes where a role definition can be assigned. The options are:

• Root “/” - available for assignment in all scopes. You cannot assign roles at this scope or create custom roles with this scope.
• Management Group
• Subscription
• Resource-group

When creating a custom role, the options of scope are only between management group, subscription, or resource groups.

For example, when the AssignableScopes is set to a specific subscription, the role will be available in all resource groups and resources under that subscription but will not be available in management groups or in a different subscription. Built-in roles have AssignableScopes set to the root scope ("/").

See below an example of Role Definition.

{
   "assignableScopes":     [         "/"     ],
   "description": "Grants full access to manage all resources but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.",
   "id": "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
   "name": "b24988ac-6180-42a0-ab88-20f7382dd24c",
   "permissions":     [
       {
           "actions":             [                 "*"             ],
           "notActions":             [
              "Microsoft.Authorization/*/Delete",
              "Microsoft.Authorization/*/Write",
              "Microsoft.Authorization/elevateAccess/Action",
              "Microsoft.Blueprint/blueprintAssignments/write",
              "Microsoft.Blueprint/blueprintAssignments/delete",
              "Microsoft.Compute/galleries/share/action",
              "Microsoft.Purview/consents/write",
              "Microsoft.Purview/consents/delete"
            ],
           "dataActions":             [],
           "notDataActions":             []
       }
   ],
   "roleName": "Contributor",
   "roleType": "BuiltInRole",
   "type": "Microsoft.Authorization/roleDefinitions"
}

If you desire to use all actions, or all actions under a provider, instead of making an extensive list, use the wildcard '*'. It lists all actions under the scope. In the example above, we can see that in Actions we have '*', a wildcard. This means all Actions. But we see there are 8 actions under NotActions, so the effective control plane operations consist of all Actions except for the 8 listed under NotActions. The wildcard can be put throughout the permission format. Some examples are:

• Microsoft.Compute/* - all permissions that begin with Microsoft.Compute 
• Microsoft.Compute/virtualMachines/* - All permissions that begin with Microsoft.Compute/virtualMachines
• Microsoft. Compute/virtualMachines/*/read - All permissions of Microsoft. Compute/virtualMachines/ with the action ‘read’.
• */read - All permissions that end with read

While the wildcard '*' can simplify permissions management, it is important to remember that using it may lead to overly broad permissions. It’s always best to adhere to the principle of least privilege  by granting only the specific permissions required for a given role or task and avoiding the ‘*’.

Role Assignments

Access to Azure resources is granted by creating a role assignment, and access is revoked by removing a role assignment.

A role assignment has several components, including:

• The security principal who is assigned the role
• The specific role granted to the security principal
• The scope of which the role is assigned
• The name of the role assignment, along with a description that clarifies the rationale for the assignment
• Conditions - an additional check that you can add to provide more fine-grained control

A role assignment is an extension resource. An extension resource is a resource that adds to another resource's capabilities. They always exist as an extension of another resource. For example, a role assignment at subscription scope is an extension resource of the subscription. The name of a role assignment is always the name of the resource you are extending plus /Microsoft.Authorization/roleAssignments/{roleAssignmentId}.

For example: role assignment at scope:

"Scope": "/subscriptions/11111111-1111-1111-1111-111111111111"

Will have this id:

 "RoleAssignmentId": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/00000000-0000-0000-0000-000000000000"

See below an example of a Role Assignment.

{
   "canDelegate": null,
   "condition": null,
   "conditionVersion": null,
   "description": null,
   "id": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/00000000-0000-0000-0000-000000000000",
   "name": "00000000-0000-0000-0000-000000000000",
   "principalId": "22222222-2222-2222-2222-222222222222",
   "principalName": "user@contoso.com",
   "principalType": "User",
   "roleDefinitionId": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
   "roleDefinitionName": "Contributor",
   "scope": "/subscriptions/11111111-1111-1111-1111-111111111111",
   "type": "Microsoft.Authorization/roleAssignments"
}

Multiple Role Assignments

What happens if you have multiple overlapping role assignments? Azure RBAC is an additive model, so your effective permissions are the sum of your role assignments in a scope. Meaning between two or more role assignments under the same scope for the same identity with different permissions, the identity will receive the permissions from all role assignments. This is called the Effective Permission.

Consider the following example where a user is granted the Contributor role at the subscription scope and the Reader role on a resource group. The sum of the Contributor permissions and the Reader permissions is effectively the Contributor role. Therefore, in this case, the Reader role assignment has no impact on the resource and resource group scope.

The diagram below shows the effective permission process:

The effective permission for both roles is the union of each role’s effective permissions. Since all the actions in both control and data plane for the reader role are in the contributor role, their effective permission includes all permissions from the contributor role.

The diagram below shows the example effective permission for each scope:

To understand the diagram, the right arrows indicate a role assignment at the current scope, whereas the down arrows indicate the role assignment inherited from the scope above. In the example we see the calculation of the effective permission in each scope after understanding how the calculation works.

AssignableScope differences

It is important to talk about the difference between the scope of role definition and role assignments. The scope in the role definition specifies the context in which the role will be visible and available for assignment to an identity. The scope of role assignment is the scope where the permissions from the role definitions are given.

For example, a role definition with a scope at a subscription level that is assigned at the resource group level will allow the identity being assigned the permissions only at the resource group level and not at the subscriptions level itself. 

Role definition

Role Assignment

{ "assignableScopes":     [ /subscriptions/11111111-1111-1111-1111-111111111111 ], "description": "Grants full access to manage all resources but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.", "id": "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c", "name": "b24988ac-6180-42a0-ab88-20f7382dd24c", "permissions":     [ { "actions":             [                 "*"             ], "notActions":             [ "Microsoft.Authorization/*/Delete", "Microsoft.Authorization/*/Write", "Microsoft.Authorization/elevateAccess/Action", "Microsoft.Blueprint/blueprintAssignments/write", "Microsoft.Blueprint/blueprintAssignments/delete", "Microsoft.Compute/galleries/share/action", "Microsoft.Purview/consents/write", "Microsoft.Purview/consents/delete" ], "dataActions":             [], "notDataActions":             [] } ], "roleName": "Contributor", "roleType": "BuiltInRole", "type": "Microsoft.Authorization/roleDefinitions" }

{ "canDelegate": null, "condition": null, "conditionVersion": null, "description": null, "id": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/00000000-0000-0000-0000-000000000000", "name": "00000000-0000-0000-0000-000000000000", "principalId": "22222222-2222-2222-2222-222222222222", "principalName": "user@contoso.com", "principalType": "User", "roleDefinitionId": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c", "roleDefinitionName": "Contributor", "scope": "/subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/Example-Storage-rg", "type": "Microsoft.Authorization/roleAssignments" }

Deny Assignments

Like a role assignment, a deny assignment links a set of deny actions to a specific user, group, or service principal at a defined scope. This is done to deny access, either to the specified identity or to all identities except those explicitly excluded in the deny assignment. Just as Actions and DataActions in the 'allow' policy specify permitted operations, in deny assignments, the Actions and DataActions represent the denied control plane and data plane actions, and the NotActions and NotDataActions represent the excluded actions from the denied actions.

Deny assignments block users from performing actions even if a role assignment grants them access.

Note that you cannot directly create a deny assignment; they are created and managed by Azure. However, you can specify deny settings when creating a deployment stack, which creates a deny assignment that is owned by the deployment stack resources.

An example of a deny assignment:

In the example above, we can see the deny assignment blocks all delete actions (“*/delete) except for these two delete actions: Microsoft.Authorization/locks/delete and Microsoft.Storage/storageAccounts/delete.

Differences Between NotActions and NotDataActions and Deny Assignments

NotActions and Deny assignments are not the same and serve different purposes.

NotActions and NotDataActions are a convenient way to subtract specific actions from a wildcard (*) action and Deny assignments block users from performing specific actions even if a role assignment grants them access.

Azure Resource Manager

Azure Resource Manager (ARM) is the service that manages Azure resources. To interact with ARM, an identity first acquires a token from Entra ID. This token is then used to make API calls to ARM. When ARM receives a request, it checks the token’s claims against the resource's deny assignments and role assignments to determine access. ARM effectively controls and authorizes access to resources based on these role assignments and the identity’s permissions.

Flow of IAM

Suppose a user with id: ‘1111’ gets assigned with the built in role ‘Reader’ on a subscription with id ‘0000’. The reader-built in role is as follows:

{
   "assignableScopes":     [         "/"     ],
   "description": "View all resources, but does not allow you to make any changes.",
   "id": "/providers/Microsoft.Authorization/roleDefinitions/acdd72a7-3385-48ef-bd42-f606fba81ae7",
   "name": "acdd72a7-3385-48ef-bd42-f606fba81ae7",
   "permissions":     [
      {
         "actions":             [                 "*/read"             ],
         "notActions":             [],
         "dataActions":             [],
         "notDataActions":             []
      }
   ],
   "roleName": "Reader",
   "roleType": "BuiltInRole",
   "type": "Microsoft.Authorization/roleDefinitions"
}

Suppose this user wants to read a blob in a storage account called ‘demostorage’ in subscription ‘0000’. Let’s see how Azure determines if the user will be granted access or not. Follow the diagram below to see how Azure determines if an identity can execute the action on a scope.

As you can see, because the identity did not have any role assignments with the  DataAction permission ״Microsoft.Storage/storageAccounts/blobServices/containers/read” necessary for reading the blob, the identity was not able to get access to read the blob in the scope subscription ‘0000’.

High-level Roles in IAM

High privileged roles in Azure, such as "Owner," "Contributor," and "User Access Administrator," grant extensive permissions across resources. The "Owner" role provides full access to all resources, including the ability to delegate access to others. The "Contributor" role allows users to create and manage all types of resources but does not permit them to grant access to others. The "User Access Administrator" role enables users to manage user access to resources. These are some examples of built-in Azure roles that grant high access for management, but identities can also create custom roles with high data privileges using dataActions or high management privileges using actions, which can lead to many attacks. This is called over-permissive access.

Over-permissive access can pose significant security risks. For instance, assigning the "Owner" role to users who only need read access, granting "Contributor" access to developers who should only manage specific resources, or giving "User Access Administrator" rights to individuals who do not require the ability to manage user access, can lead to unauthorized changes, data breaches, or accidental deletions.

These are the risks that we aim to address at Cisco and in particular through our Cloud Application Security product, Panoptica. We provide analysis and insights to companies to ensure they do not have unsupervised identities with over-permissive access.

IAM in Panoptica

Azure IAM Analyzer in Panoptica ensures secure and efficient management of identities and access through key components like Role-Based Access Control (RBAC) and Microsoft Entra ID. Similar to how Azure analyzes access, we at Panoptica have our own analyzer that calculates effective permissions for all our clients’ identities. We provide analysis and insights into identities so that our clients are aware of over permissive roles at a broader scale including subscription or management groups. Our goal is to help them adhere to the principle of least privilege so that identities are given the minimum access needed within the smallest scope possible.

Conclusion

In many cases, we overlook the assignment of high-privilege roles to identities, forget to remove roles from identities who no longer need them, or opt for the 'easy' solution of granting all privileges instead of applying the practices of least necessary privileges. This approach can be very dangerous for an enterprise with vast amounts of data at its disposal. Unsupervised identities with excessive access can lead to security breaches and attacks.

Our analyzer addresses this critical issue by helping clients become more aware of their identities' access levels and ensuring that privileges are kept to a minimum necessary for their roles.

Now more than ever, having IAM awareness is crucial. Azure is not an easy cloud platform to understand, and it is essential that our team shares our extensive findings and research on Azure identity models and the implementation of the Azure Analyzer into Panoptica. If you have any questions, please feel free to reach out directly to our team, and we hope you take care of your IAM ASAP!