State of Azure IAM 2022

Azure Identity and Access Management (IAM) is a critical component of any Azure security design. It is responsible for controlling access to resources and services within the Azure platform. This blog post is my independent analysis of some of the key developments in Azure IAM over the past year and what will be interesting to see next year.

1. Azure IAM growth continues and remains difficult to manage

• In the past year, 2710 new permissions have been added*, increasing the total number of permissions to 16,210. This can be helpful (in some cases) because it allows us to give more specific access instead of just giving broad roles like Contributor (E.g. Azure ADDS). However, it’s important to consider if organizations are using these new permissions to improve the way they assign permissions (more on this below).
• Of course there are also new permissions that could be abused by attackers if compromised. For example, the permission [Microsoft.ContainerService/fleets/listCredentials/action] was added for the new AKS Fleet Manager service but this could be abused by an attacker to steal credentials for multiple AKS clusters! OR the [Microsoft.Network/bastionHosts/createShareableLinks/action] permission that could be abused to create backdoor to virtual machines.

• Over the past year, 60 new built-in roles were added to Azure IAM*, which happens to be about 5 new roles per month. The total number of roles is now 377.

2. Rapid servicce evolution and innovation continues

• Overall, Microsoft annouced 389 updates on https://azure.microsoft.com/updates/ in the last 12 months. Out of these updates, 193 were preview announcements and 196 were GA announcements.
• Did security teams have the opportunity to look at the potential risks and effects of these new features? For example, among the GA announcements this year were two features for popular services that most organizations are probably using already: the ability to use SFTP with Azure Blob Storage and the ability to use role-based access control with Azure Cosmos DB (MongoDB API). Both of these features have the potential to be abused by an attacker for persistence! As they allow for the creation of service level local user accounts to the data plane!

This can be concerning for organizations especially as many cross-tenant vulnerability disclosures for the Azure Cloud platforms seem to orginiate from feature additions.

• Have security teams really had the chance to review the risk and impact of these features. A recent analysis that I did showed that many of the cross-tenant vulnerability disclosures for Azure were introduced in feature updates that became GA later but I’ll cover this in another post.
• Two of the features that became GA this year were SFTP support for Azure Blob Storage and RBAC for Azure Cosmos DB (MongoDB API).
• Both of these features carry a risk of being used for establishing persistence in an environment as they allow for the creation of service level local user accounts to the data plane!

3. Majority of organizations still rely on built-in roles for permission assignment

• Most permissions (87%) are assigned using the built-in roles that come with Azure**. These built-in roles usually have been found to contain almost twice more permissions than custom roles created by cloud professionals**.
• Built-in roles, like Owner, Contributor, or Reader, usually have a lot of permissions and can automatically get new permissions (like some of the 2710 added this year) without being checked by the security team first for risk and potential impact!
• With the growing cloud compute credential theft,

4. Overprivileged access is still a big issue for built-in role assignments.

• The five most commonly used built-in roles in Azure are Contributor, Owner, Storage Blob Data Contributor, Billing Reader and Virtual Machine Contributor**. Each of these roles has certain permissions that could be abused if compromised (see image below on some of the abuse options). And out of all the permissions included in the built-in role assignments, only a very small percentage (0.83%) were actually found to be used within the last 60 days**.
• I personally subscribe to avoiding built-in roles at all cost. Permission assignments should be customized for each function, but I know that this is not always possible or practical for organizations.

5. Custom role implementations are equally as overprivileged as the built-in ones.

• Custom roles are a way to assign specific permissions to users, but it was found that most of the permissions assigned to these custom roles (98%) were not used within the last 60 days**. This means that the custom roles we are creating often have more permissions than they actually need, just like built-in roles!
• This shows that cloud operators (cloud security and governance teams, cloud architects, cloud administrators) still struggle with defining the right set of permissions needed by cloud workload operators (development and devops teams, data teams).
• One reason for this is the difficulty that organizations are facing in defining a working “role and responsibilities” framework for teams in a cloud native world so it goes back to design and architecture!
• This shows that cloud operators (people who manage and secure the cloud) are still having trouble deciding what permissions should be given to cloud workload operators (like development and data teams) who use the cloud for their work. This is partly because it can be hard for organizations to create a clear framework for roles and responsibilities in a cloud-based environment. This issue relates to the design and architecture of the cloud system.

Fixing a lot of these issues means we have to go back to best practices in designing cloud governance at scale for continuously changing environments. I hope to put out more of my thoughts and perspectives around this in 2023! Ensure you follow my medium and social media pages — Twitter, LinkedIn.

REFERENCES:

• * I analyzed the commit history of Ian McKay’s github repository for the past 12 months — https://github.com/iann0036/iam-dataset/
• ** Unit42 CLOUD THREAT REPORT VOLUME 6 — https://www.paloaltonetworks.com/prisma/unit42-cloud-threat-research-volume-six