In the age of hybrid information systems, securing cloud resources is a cornerstone of enterprise security. Faced with constantly evolving threats and increasingly complex IT environments, companies are seeking more effective and scalable cloud information systems and access management solutions.
To meet this challenge, Microsoft has defined the Enterprise Access Model, offering a new approach to identity and access management adapted to the reality of the cloud. This model promises to redefine how companies manage access to digital resources, whether within cloud solutions like Azure, Office 365 applications, or other strategic services.
This article proposes a methodology and examples for implementing the Enterprise Access Model and defining criteria for assigning roles to the management plane or control plane. The article also aims to highlight the risks associated with poor implementation of the model, with concrete examples. Finally, it lists several best practices for configuring and managing the access model to help mitigate these risks.
Is the tiered model unsuitable for access management in the cloud?
(For more information on this subject, please consult wavestone’s white paper available here)
The tiering security model, applied to Active Directory, is based on the fundamental principle of segmenting privileged accounts into 3 different layers, known as tiers. The aim is to ensure that, if a resource or account in a tier is compromised, the higher-trusted tiers remain preserved, thus avoiding any potential propagation of the compromise to the entire system.
- Tier 0 is the most critical tier, covering all the infrastructure components managing the company’s AD Domain Controllers.
- Tier 1 typically comprises the company’s applications and the servers that host them.
- Tier 2 covers everything that revolves around the user environment.
While the tiering model can be used to secure the Active Directory infrastructure, it encounters significant challenges when applied in a cloud context. One of the major challenges lies in the very nature of the cloud, where access and administration are generally carried out via consoles exposed on the Internet, unlike in on-premises environments.
Microsoft has therefore defined a new model, the “Enterpise Access Model”, to take account of these new challenges. This article will look at how this model can be effectively implemented in a Microsoft cloud environment.
The Enterprise Access Model: a new model adapted to the needs of the cloud
One of the key features of the Enterprise Access Model is the implementation of a privileged access mode for certain critical tasks and the management of a multitude of critical resources, either on-premises or in the Cloud.
Source : https://learn.microsoft.com/en-us/security/privileged-access-workstations/privilegedaccess-access-model
Evolution of purpose and scope
Tier 0 -> control plane
- Control plane: includes management of all aspects of access control, identity management, and all elements that could jeopardize the tenant.
Tier 1 divided into 2 parts
- Management plane: management of the application infrastructure base, such as servers or configuration of PaaS (Platform as a Service) services.
- Data/Workload Plane: management and configuration of applications, resources, and APIs.
Tier 2 divided into 2 parts
- User access: includes B2B, B2C, and public access scenarios.
- App access: takes into account the attack surface of application-to-application exchanges via APIs.
Which accounts should be included in the control plane?
To define the accounts in the control plane, this article proposes an approach based on the criticality of the roles and the impact they can have on the cloud environment. If the role could have a systemic impact on the enterprise (destruction of a large part of the cloud and backups, for example), it should be managed in the control plane.
Make sure to carry out a complete analysis, as some common roles, such as helpdesk administrator, with no critical privileges on direct resources, can take control of accounts that do!
Strategy based on criticality
Optimizing security: applying the Enterprise Access Model to the Microsoft cloud
At the heart of Microsoft’s cloud ecosystem are roles, an essential component that governs how users and services interact with cloud resources.
This section takes a deep dive into this crucial aspect of identity and access management in the cloud. The section will explain what Azure roles are, how they work, and why good management is crucial to the security and performance of a company’s cloud infrastructure.
Organization of roles in Microsoft clouds:
Roles are a set of permissions that control who can access Azure resources and what actions they can perform.
Roles in Microsoft Cloud
It’s important to differentiate between three types of roles:
- Azure roles are dedicated to accessing and managing Azure resources.
- Microsoft Entra roles are used to manage resources in the Microsoft Entra ID directory.
- Microsoft Entra roles used to manage associated Office 365 resources.
It’s important to note that these roles can be interconnected.
Azure roles
Azure roles are organized according to the principle of Role-Based Access Control (RBAC), which is an integrated feature of Microsoft’s Azure cloud platform.
They are dedicated to the management and access of Azure resources, and encompass elements such as Azure virtual machines, SQL databases, services, as well as application services such as web apps.
Azure role assignment is a key step in implementing access management in a cloud environment. It determines who has access to which resources, and what privileges are granted.
‘Security Principals’, on Azure, refers to the entities, including users, groups, or services, to which permissions are assigned. There are several types of security principals on Azure, which may or may not be human.
Security Principal
Scope, when assigning roles in Azure, is crucial in determining where permissions apply. It can be specified at different levels, as shown in the diagram below:
The scope of RBAC
To better understand role assignment as well as the strategy based on the criticality of roles, and their impact on the cloud in terms of their placement in the control plane, this article proposes two concrete examples:
Strategy application example
In example 1, a user is assigned the owner role (allowing him to read, write, and assign roles to other users throughout the scope to which the role is assigned), on the scope of a management group. In this example, the owner role is critical because the scope is very high-level: it will therefore have full authority over all subscriptions, resource groups, and resources in its management group. This is why the owner role is in the control plane.
In example 2, a group is assigned the contributor role (allowing it to read and write to the entire scope to which the role is assigned), on the scope of a subscription. In this example, the impact is limited to one subscription, and therefore probably not systemic for the enterprise. This is why, in this case, the contributor role is in the management plane.
The key takeaway from these examples is that the criticality of a role is not only related to its permissions but also to the scope over which it is assigned.
Segmentation between Microsoft Entra ID and Azure? The case of global admin
Microsoft Entra ID and Azure roles are defined independently: in Microsoft Entra ID and Azure RBAC respectively. This means that authorizations assigned to Microsoft Entra ID roles do not provide access to Azure resources, and vice versa. However, as global admin within Microsoft Entra ID, they can grant themselves access to all associated Azure subscriptions and management groups.
When the global admin grants themselves access to Azure, they are assigned the role of user access administrator in the Azure management group root scope. This enables them to view all resources and grant themselves access to any subscription or management group in the directory.
It is therefore important to control who and how many people are assigned the global admin role, and to manage it in the Control Plane.
Global Admin Azure
Privilege escalation through password reset and MFA
This method relies on exploiting privileges that allow passwords to be reset for user accounts or systems. Attackers often target specific roles that have this privilege because, once compromised, they can reset the passwords of more sensitive accounts and thus gain access to take control of critical systems.
The table below highlights the Microsoft Entra ID roles that can reset the password of any subscription owner.
Note that security measures such as MFA (Multi-Factor Authentication) can reduce this risk, as detailed in the rest of this article.
Can a user with a role in column 1 reset the password of the user in row 1?
Attack scenario 1: Escalation of privilege to an Azure role from a Microsoft Entra ID role:
A helpdesk administrator, which is a very common role in the enterprise, can reset the password of a subscription owner and thus access Azure from within Microsoft Entra ID. As a result, segmentation between the two worlds is no longer guaranteed.
Attack scenario 2: Escalation of privilege to a Microsoft Entra ID role from a Microsoft Entra ID role:
Within Microsoft Entra ID, privilege escalation from a helpdesk administrator to an Authentication Administrator is possible.
These two scenarios are no longer possible if MFA is set up, as the password alone cannot be used to authenticate to the account. In most cases, this security measure covers this type of privilege escalation. However, certain roles have the upper hand on both parameters, i.e. password reset and MFA setting, and it is not uncommon for user support to have this ability.
Does a user with a role in column 1 have rights on the MFA?
Attack scenario 3: Privilege escalation from an authentication administrator to Azure or Microsoft Entra ID :
Here the authentication administrator is a role that can manage and reset the authentication methods of users who do not have an administrator role. In addition to being able to control the MFA, this role can also modify or reset the passwords of a large proportion of users. The tables above show that it can take on the role of a helpdesk administrator or a subscription owner.
These roles need to be managed in the control plane to avoid privilege escalation scenarios and maintain the watertight seal between Microsoft Entra ID and Azure.
Reinforce your security, some examples of additional security measures
Grant privileges to a managed identity rather than to a user
To limit the risks associated with assigning control plane roles, it is recommended to use Managed Identities as alternatives to user authorizations, or Privileged Identity Management (PIM) to better manage high-privileged users. This approach limits the risk of privilege escalation.
Managed Identities are authentication entities managed by Azure for applications and services. Rather than granting privileges to individual users, you can assign authorizations to the Managed Identities associated with these applications or services. This approach offers the following advantages:
- Reduced credential exposure: using Managed Identities reduces the potential attack surface, as credentials are not exposed or shared.
- Secure automation: applications and services using Managed Identities can automate tasks without the need for high-privileged user accounts.
- Centralized control: authorizations are managed centrally, facilitating privilege management across the entire cloud environment.
Limiting risks with Privileged Identity Management (PIM)
When assigning high-privilege roles or control plane roles, especially to users, it is very important to control and monitor the assignment of these roles. The use of PIM, a feature that enables precise management of administrative privileges, may prove useful. PIM is based on:
- Temporary elevation of privileges: users can be granted administrative privileges on a temporary basis to perform specific tasks, thus reducing the risks associated with permanent authorizations and errors.
- Mandatory justification for elevated privileges.
- Implementation of control and monitoring.
- Creation of a workflow to validate privilege elevations: /!\ requires a high level of maturity to manage reactivity and HNO (non-working hours) requirements.
Securing a cloud environment is an essential concern. Attacks using the concepts and intricacies of cloud management will increase in the near future, therefore; it would be a loss to wait until attackers start dealing with this subject before companies start dealing with it properly.
This article has explored various aspects of privilege management and security in the cloud, highlighting fundamental strategies and practices for effectively protecting the control plane, which brings together data and resources that are highly sensitive to the integrity of a company’s infrastructure.
The article explored Microsoft’s enterprise access model, based on the “Zero Trust” principle. This model offers a flexible and secure approach to access management in a cloud environment.
It was then presented that Microsoft Azure roles and some of the risks of privilege escalation, highlighting the importance of accurate authorization assignment and continuous monitoring to prevent abuse and potential threats.
Securing the control plane in a cloud environment is of paramount importance in protecting a company’s sensitive data and resources. Exploring the strategies and best practices discussed in this article, it’s clear that every organization needs to carefully define its role model, ensuring that accounts and permissions are appropriately assigned in the control plane or management plane. It is imperative that measures are put in place to ensure the isolation of each plane, while paying particular attention to precise authorization management and continuous monitoring to prevent abuse and potential threats (including privilege escalation).
Security in the cloud is no longer an option, but an absolute necessity!
