Is the tiering principle promoted for on-premise infrastructure applicable to the cloud?

Evolution of the Security Model

In on-premises Active Directory environments, infrastructure security generally relies on strict segmentation into three tiers (T0, T1, and T2). This allows for the isolation of critical administration systems (T0), servers (T1), and user workstations (T2) in order to limit propagation risks.

This hierarchical and perimeter-based organization is inherent to the AD world and cannot be directly applied to the cloud for the following two main reasons:

• Portals are centralized: A wide variety of administrators with different rights.
• The boundary between administration levels is more complex: The principle of granular permissions, whether Role-Based (RBAC), Attribute-Based (ABAC), or conditional (location, risk, compliance, authentication methods, etc.) allows for very precise access configuration, but it complicates and obscures the global view of permissions.

To address this new paradigm, Microsoft published its Enterprise Access Model (described here), highlighting three main planes: the Control Plane, Management Plane, and Data Plane.

This model retains “cascading” criticality but simplifies it with:

• the 3 tiers into 2 access types: administrator vs. user;
• the administration flows into portal access;
• the server’s criticality is centralized within the Data plane.

Below is a comparative illustration between the old and the new model:

This new model particularly highlights 3 elements:

• User identity: privileged access vs. user access;
• Data and services: at the expense of servers;
• The method of access to web administration portals.

The inversion of importance between “servers” and “web portals” abstracting Active Directory is a radical change.

However, very few (if any) large organizations are at this stage of abandoning their “legacy” IS; a large part will be in a transitional state where the information system has been virtualized on a cloud in order to move away from its datacenters, but whose administration methods have remained the same.

These companies must deal with an obsolete tiering model and an Enterprise Access Model disconnected from current security risks and needs.

For the remainder of this article, we will take as an example the Tartampion company, which has just completed a 3-year Move-to-Cloud program on AWS. The outcome is as follows:

• A Landing Zone was created, applications already on AWS were integrated into it
• Given the lack of time and resources, a major part of the IS was incorporated via lift and shift, including business, network, bastion, and AD solutions.
• The Data Centers were closed

A problematic hybrid and virtualized IS

According to the EAM, Azure and AWS portals are displayed at the same level (the management plane) at the T1 tier, without any other form of distinction. However, these 2 cloud environments are in themselves the support for numerous IS, used by multiple collaborators with very varied levels of rights and impacts.

To illustrate the previous points, let us set aside the Digital Workplace aspect (O365 suite) and take 3 AWS accounts from a Tartampion Landing Zone, supporting different infrastructure services:

Based on the framework proposed by Microsoft, these three AWS accounts should belong to the Management plane with a T1 security level. However, in the event of a compromise of one of the 3 accounts by an attacker, the impacts would be very different.

If the Landing Zone is correctly implemented, the compromise of a Sandbox account would have very little impact, whereas that of the Master Account would lead to the compromise of all underlying accounts and resources.

A more adequate example of segmentation would be the following:

Microsoft’s Enterprise Access Model is a macroscopic framework that allows for initiating a baseline for cloud service segmentation, but which remains to be adapted according to the criticality of the concerned IS.

How can it be made relevant? To answer this, it is necessary to understand the attack scenarios exploiting cloud services.

The cloud from an attacker’s perspective

5 cloud principles facilitating attacks

Firstly, public cloud administration panels are exposed to the Internet by default, unlike sensitive IS resources. Thus, successful phishing very likely leads to access to the cloud.

Secondly, companies today have hybrid organizations (on-premise and cloud):

• Cloud infrastructures are connected to the rest of the on-premises IS;
• Workstations can also be hybrid and managed by a cloud service like Intune. Permissions to use this service are managed in Entra ID;
• Identities are often synchronized accounts, this also applies to administration accounts.

Hybrid organizations can facilitate lateral movement between the cloud and on-premise environments.

Thirdly, identity management is very complex with different scopes. For example, Entra ID allows managing access to Azure and M365 for users, as well as for applications and service accounts.

In addition, cybersecurity concepts related to the cloud are still relatively new and unfamiliar to certain “legacy” teams, such as the SOC/CERT, network, etc. The most sensitive cloud resources are not systematically identified, protected, and monitored.

Finally, even if native detection mechanisms are present, they are not always interconnected with SIEM/SOAR, which slows down response capabilities. Moreover, a recent Purple Team operation conducted on Azure and AWS infrastructure confirmed that native detection tools have limited detection capacity. This is an observation also found in Red Teams since, with an “OpSec” approach, cloud detection tools are rarely able to identify an ongoing attack.

Feedback from our penetration tests & Red Team

Derived from recent Red Team operations, these cloud-specific attack paths demonstrate the impact and the ease with which it is possible to escalate privileges to obtain highly permissive access:

The first scenario, carried out on AWS, is described below; the other two were analyzed in a series of Risk Insight articles available here.

Reconnaissance and Initial Access

Categories of employees are generally targeted in order to compromise a person with interesting rights in the IS (Developer, Support, OPS…). A frequently used method is phishing. Current phishing mechanisms can bypass the use of complex passwords and most MFA (Multi-Factor Authentication) methods.

Privilege Escalation and Lateral Movements

In the first scenario, a compromised developer possessed access to a Citrix farm. Citrix environments are not simple to completely harden, and a few breakout vulnerabilities allowed the Red Team to gain access to the underlying server.

Information gathered on the machine indicated that the server could be hosted on AWS. This was verified by trying to access the server’s AWS metadata: the instance had rights on the client’s AWS account. The Citrix virtual machine possessed the “AmazonEC2FullAccess” role allowing it management actions on EC2s in the same AWS account.

Using the AWS CLI, the other EC2s were listed. A Domain Controller was present in this AWS account. It is a common practice to regroup services intended to be used by several projects into a single account, generally called “Shared Services”. It is nevertheless recommended to verify that the criticality of shared services is homogeneous to be able to apply adequate hardening on the account or separate them into several environments.

Actions on trophies

From the Citrix server AWS role, a snapshot of the domain controller was taken and then downloaded. Domain controller backups contain all the machine’s files, including the most sensitive files like the ntds.dit database, which contains the information and secrets of all domain users. The exfiltration of this database translates to the total compromise of the concerned AD domain.

This scenario illustrates one of the attack paths that were exploited during Red Team operations, facilitated by the lack of visibility regarding the impacts that a compromised resource hosted on the cloud can have.

Faster and stronger impacts

Attacks already possible on an on-premises IS can be reproduced and even accelerated thanks to cloud features. For example, the encryption of S3 buckets (file storage service) using a KMS (encryption) key from another AWS account mimics massive data encryption, or the use of the “lifecycle” feature allows for the deletion of all objects in less than 24 hours, regardless of the amount of data.

New attacks have also appeared, such as “Subscription Hijacking” which allows transferring an Azure organization’s subscription to another and thus stealing all the data it contains while preventing remediation actions. This attack is achievable in a few clicks from the Azure web interface.

Identification and protection of the cloud trust core

Identification

The trust core adopts an approach focused on asset prioritization, which differs from the tiering model or Microsoft’s Enterprise Access Model. Unlike these models which offer a predefined segmentation, there is no universal grid: each organization must identify for itself which resources deserve the highest level of protection. The idea is to establish a restricted circle of critical resources (whether cloud or on premises) and then deploy decreasing levels of protection as one moves away from this core.

The identification of the trust core relies on two main criteria:

• Business Criticality: these are the resources that concentrate the value and business continuity of the company. If they were to be lost or compromised, the consequences would be immediate for daily operations and financially. A SharePoint environment containing intellectual property / patents is a common example;
• IS Criticality: these are the resources that ensure the administration of the information system and which possess a high level of access. Their compromise would have a major impact on the entire IS and would allow for the business impact previously mentioned. Here we find domain controllers or cloud IAM services like Entra ID and AWS Identity Center.

This mapping is never totally clear-cut. For certain elements, the posture to adopt remains vague; two examples illustrate this well:

• EDR: an obvious security element of an IS, systematically deployed on both workstations and cloud and on-premises servers, its administration console is increasingly exposed to the internet, and allows executing arbitrary commands on the devices equipped with it.
• CI/CD pipelines: a clever but complex agglomeration of applications calling each other, whose access (the code repository: GitLab, GitHub…) is accessible by all collaborators and the runner permissions are very often administrator over the entire cloud infrastructure. Out of all Red Teams conducted in 2024 & 2025, 80% exploited vulnerabilities associated with these solutions to progress in their operation or even obtain compromise trophies through these means.

In order to identify the center of the trust core, which we will call the security foundation, we can revisit the precepts of the old T0: the compromise of one of its elements would probably lead to that of the others, and by cascade, of the major part of the IS.

Assuming that your applications apply correct inter-user segregation (all of your SharePoint sites are not accessible by everyone, are they?), references to the next applications should be understood as administrator / super-user access to them, and not simple user.

Here is one possible representation of a hybrid trust core:

In this representation, on the on-premise side, we can observe:

• The T0, with its domain controllers, ADCS, and potentially the PKI, the bastion, the EDR console…
• The T1, integrating additionally high-impact business applications.

And on the cloud side, we find:

• At the core, the Control Plane (AWS Orga & Identity Center, Entra ID) as well as the Landing Zone modules supporting T0 (if part of T0 is hosted in the cloud);
• Moving outward, the various administration consoles for productivity suites, and for infrastructure or application management.

When establishing this diagram, it is important to keep in mind that:

• IT serves the business, and even though the central zone of the trust core is mainly occupied by technical components, critical solutions should be included;
• Dependency/compromise chains have a significant impact on architectural choices: positioning an AD on AWS, or deploying an EDR on an AD can suddenly create numerous paths for compromise and pivoting between the 2 worlds.

Finally, building a trust core cannot be limited to a static classification logic. It must rely on an approach that evaluates the criticality of each asset and the risk it introduces (a software development company will surely not position its Git at the same level as a civil engineering company).

Protection of the cloud trust core

The security of the trust core will rely on the two traditional risk factors:

• Reduce impact: How to prevent a compromised or malicious user from connecting to cloud portals via a browser and performing sensitive actions in a few clicks, such as backing up a domain controller hosted on a VM or deleting production data backups?
• Reduce probability: How to reduce the risks of illegitimate access from a session cookie stolen via phishing, workstation compromising, or user password reuse?

Protection of the cloud security foundation

Regarding the cloud “security foundation,” it is possible to prioritize environments by criticality according to this macroscopic scale:

Depending on the teams involved and the complexity of including them in a particularly high protection level, some organizations choose to exclude environments whose compromise would not allow for dangerous lateral movement, such as those for FinOps, detection, the Digital Workplace…

Securing the cloud security foundation relies on 2 main points:

• Impeccable hygiene: streamlined IAM configuration, least privilege strategy, deployment procedures, limitation of resources to the strict minimum…
• A passive / active security layer: deployment of policies (SCP on AWS, Policy on Azure) explicitly forbidding certain actions, or the manipulation of certain resources, and detection rules to trigger an alert in the event of a policy modification or the occurrence of one of its protected events.

These policies can be effectively associated with a tagging strategy to apply, in addition to the RBAC (Role Based Access Control) model, an ABAC (Attribute Based Access Control) model.

For example, it is possible to tag different resources with a “tiering” key and a value between “T0”, “T1”, “T2” and then deploy this set of strategies:

• Prohibit any action targeting a resource tagged “tiering” by an identity whose own tiering tag value is not equivalent;
• Prohibit the manipulation of tiering tags, except for a specific role.

And that is how, with a few tags and 2 SCPs, it is possible to replicate the Microsoft tiering model (some exceptions may occur).

Protection of identities and access

To protect users, 3 hardening themes can be implemented:

• Identity: With which account does the user connect to cloud administration interfaces? How are rights obtained?
• MFA: Is the identity protected with multi-factor authentication resistant to phishing attacks?
• Origin: From which platform does the user connect to cloud administration interfaces? Is the platform managed, and healthy?

Several levels of protection are conceivable in order to protect cloud administrators:

To protect the restricted trust core, represented by the triple padlocks, it is recommended to implement the most robust authentication factors. This includes the use of a dedicated account for cloud administration, the activation of physical multi-factor authentication (example: FIDO2 security key), and the use of a workstation specifically reserved for operations on this trust core (this last one is not often implemented).

For resources further from the center of the core of trust, symbolized by the double padlocks, a hardened but proportionate security level can be applied, in order to strengthen protection to control costs and reduce excessive constraints on the users concerned.

Ultimately, the most secure methods are also those that imply the most constraints for the people concerned, usage must be controlled (limiting day-to-day operations) and emergency situations considered.

Repeat Operations

At the end of the identification and protection phases, resources will be distributed across the different layers of the core of trust.

To verify the proper implementation of the core of trust, an audit can be conducted to verify the proper protection of the critical resources that compose it.

An information system is always evolving, but the first two phases will have been performed at a given moment. New critical resources may be added, others modified or even deleted. It is essential to regularly re-evaluate the IS and update the distribution of resources within the core of trust.

In conclusion, information system security now operates within a context of increasing complexity and strong diversification of infrastructure components and services.

In this context, it appears increasingly complex to define a universal security model. Certain frameworks retain all their relevance within well-identified perimeters: tiering remains a reference for securing Active Directory, just like the EAM for cloud environments strongly centered on the Microsoft ecosystem. Nevertheless, these models quickly reach their limits as soon as one moves away from these specific use cases.

For the majority of information systems, an approach based on risk analysis therefore stands out as the most relevant. Identifying a core of trust, clearly defining critical assets – the crown jewels – and deriving security measures from these elements allow for building a more pragmatic security posture, adapted to the reality of the IS and capable of evolving with it. This logic, less normative but more contextualized, undoubtedly constitutes one of the major levers for reconciling security, agility, and sustainability of information systems.

Cet article Cloud Security: Adapting to a new reality est apparu en premier sur RiskInsight.

This article is the first of a series of 2, tackling the implementation of the Enterprise Access Model, an administration model proposed by Microsoft to secure the administration of Cloud environments.  

Today, most companies use public cloud to host numerous workloads from business to functional services. Although this brings benefits, the Cloud also introduces new paradigms, which need to be understood clearly in order to be secured. 

Historically, enterprises have relied on a 3-tier model for securing Active Directory environments. This model segments the network into three distinct tiers: Tier 0 for highly sensitive systems and data, Tier 1 for server administration, and Tier 2 for end-user workstations and devices. While this model has proven effective in on-premises environments, the shift to cloud-based infrastructures requires a reevaluation of its applicability. 

This article delves into a recent, concerning trend: the global compromise of Entra ID, originating from the compromise of a helpdesk account. Such an attack can have severe repercussions, even more so than an AD Domain Administrator compromise. We will explore the mechanisms behind these attacks, their implications, and, most importantly, how we should protect against this kind of privilege escalation and implement an adapted and secured administration model. 

Understanding Entra ID, Active Directory, and Azure Permissions 

As shown in Figure 1, Active Directory and Entra ID (formerly Azure Active Directory) are two Identity services with different structural properties and IAM protocols. While Entra ID focuses on identity and access management across both cloud and on-premises environments, providing authentication and user management, Azure permissions extend to the broader management of cloud infrastructure and services. Understanding the distinctions and interconnections between these tools is essential for maintaining robust security and effective access control in modern enterprise environments. 

Figure 1: Active Directory and Entra ID key differences

Between Active Directory, Entra ID, and Azure- each manages its own permission model: 

• Active Directory uses a unified permission model for all its objects, from users to servers. 
• Entra ID uses Role-Based Access Control (RBAC) to manage its tenant’s objects (e.g., users, devices, applications). 
• Azure Resource Manager (RM) uses RBAC to manage Azure resources 

However, there is a bridge between Entra ID and Azure RM thanks to the single tenant’s relationship to an Azure organization: the Entra ID’s Global Admin role is assigned by default the User Access Administrator role in the Azure RM service. As a result, it can grant itself full permissions in Azure.  

Although there is a link between Azure and Entra ID, it’s important to remember that the roles in Entra ID and Azure RM can be assigned independently. For example, a standard Entra ID user with very limited permissions on Entra ID can hold the highest privileges in Azure RM, which is a critical point of vulnerability exploited in attacks. 

Privilege escalation in Entra ID can lead to an extensive compromise of Azure RM (including all resources and infrastructures), Microsoft 365, workstations, Windows servers, cloud networks, and more. 

The most privileged roles in both systems are: 

• Entra ID: Global Administrator 
• Azure RM: Owner (which can be scoped from Management Groups down to resources) 

These significant differences mean that the concepts from the traditional AD 3-tier model cannot be directly applied to cloud environments. We must rethink and adapt these concepts to ensure they are relevant and effective in cloud-based contexts, particularly by adequately addressing the specific requirements and risks associated with cloud environments. 

A real-life global Entra ID compromise 

To focus on Cloud Administration compromise and privilege escalation, a small number of hypotheses will be taken: 

• The victim has an Entra ID tenant as Identity Provider. 
• The victim uses Intune to manage its entire workstation fleet. 
• The victim has an Azure subscription for its Virtual Desktop Infrastructure activities. 
• A helpdesk account is compromised (the source of the attack is not relevant, but it is important to note that this is a likely scenario that could have been the result of several different compromise like phishing, credential theft, workstation compromise, social engineering, etc.). 

1 Compromising a helpdesk account 

• Following our last hypothesis, the attacker has gained control of a helpdesk account, that can reset passwords and MFA.  

2 Initial Attempt to Reset Global Administrator Account

• The attacker initially attempts to reset the Global Administrator account, seeking the quickest path to becoming the Global Administrator of Entra ID.
• This action is blocked by default by Microsoft. The Global Administrator role is a “privileged role”, and only specific privileged roles are authorized to reset its password or modify its attributes. Microsoft updates here its list of privileged built-in Entra ID roles. 

3 Targeting a High-Value Standard User Account

• Restricted to resetting standard Entra ID user passwords, the attacker identifies a user with the username “VDI Admin”, who is the Owner of an Azure RM subscription used for workstation administration services. 
• Despite MFA being enabled on the account, the attacker successfully resets both the password and MFA mechanisms, gaining access to the account. 

4 Searching the available subscription 

• With the VDI Admin password reset, the attacker logs in and accesses the subscription. Through reconnaissance, they discover access to a key vault containing credentials for a service account. 
• The service account is identified as having the “Intune Administrator” role in Entra ID. 

5 Utilizing Intune Administrator Privileges 

• The attacker logs in as the Intune Administrator, gaining permissions related to workstation administration, including the ability to run scripts on any workstation. 
• They deploy a script on the Global Administrator’s workstation to extract authentication cookies from the Global Administrator’s browser. 

6 Compromising the Global Administrator Account

• The attacker obtains the Global Administrator’s authentication cookies and uses them on their own workstation to impersonate the Global Administrator. 
• This grants the attacker control over the entire Microsoft Entra ID tenant, which includes compromising the Microsoft365 tenant, the Azure RM environments, and all other Microsoft cloud-based tools relying on Entra ID. 

Figure 2: A global Cloud compromise path 

By following these steps, the attacker, beyond being able to compromise the entire cloud infrastructure, can deeply affect a company’s business through unauthorized access to emails & documents, backups, endpoints and corporate network. This attack demonstrates the critical importance of securing high privilege accounts that have permissions that could lead to a global compromise.  

Figure 3: Impact of a compromise at the Control Plane level 

How to ensure this does not happen: Implement the Enterprise Access Model and scope your Control Plane 

As discussed in the first part, cloud directories, particularly Entra ID, exhibit key differences from Active Directory. Consequently, the traditional three-tier model requires adaptation to be fully effective in cloud environments. To address these challenges, Microsoft has introduced a new administration framework specifically designed for cloud environments: the Enterprise Access Model. 

Figure 4: The Enterprise Access Model 

While there are some modifications, the core concept remains the same: sensitive resources must be isolated to ensure that a compromise in one plane (formerly tier) does not lead to a compromise in another. This leads us to a crucial question: how should we scope our Control Plane within our Information System to effectively isolate it and mitigate the risks of a global compromise? 

The answer lies in identifying the systemic components within our Information System — those whose compromise could lead to a widespread breach. Losing one project is far less critical than a global compromise of the entire Information System. 

In our cloud environment, numerous components interact to support projects, from CI/CD infrastructure and deployment pipelines to various IAM tools (such as Identity Providers like AD, Entra ID or Okta, IGA, etc.), along with cross-functional security tools (like EDR, Bastion, and MDM for example). While these are generic components likely present in many systems, there are also numerous environment-specific ones to consider. 

We must assess the impact of compromising high-privilege accounts within these components. For instance, if an attacker gains control of a high-privilege account for the CI/CD infrastructure, they could potentially alter the CI/CD processes and/or run a specific pipeline to deploy unauthorized changes in the cloud, which would allow them to gain global access. Thus, these high-privilege CI/CD accounts should be part of the Control Plane. Similarly, consider the EDR solution: if a high-privilege administrator can execute scripts across all workstations, potentially stealing authentication cookies, accessing critical data, or rendering all workstations inoperable, then this high-privilege account must also be included in the Control Plane. 

By carefully scoping and securing our Control Plane, we can significantly reduce the risk of a global compromise within our Information System. 

Synthesis 

As we have seen, the risk of global compromise in a Cloud environment is significant. While cloud computing offers enhanced flexibility, resilience, and cost optimization, it also introduces new paradigms and operational methodologies that must be mastered to ensure security. 

The traditional 3-tier model from the on-premises world, particularly from Active Directory, is not suited for organizing administration in the cloud. To address this, Microsoft has introduced the Enterprise Access Model (EAM). This model expands the 3 tiers into five distinct planes, with the most critical being the Control Plane. However, just as with the 3-tier model, isolation measures are crucial in the EAM, requiring the identification of critical components and high-privilege accounts within your Information System as a top priority for cloud security. 

The next article in this series will provide concrete examples of attack scenarios that can lead to a global compromise of cloud environments. It will also include security recommendations to enhance cloud administration and prevent such risks from becoming security incidents. 

 Thank you to Louis CLAVERO for contributing to this article.

Cet article Enterprise Access Model (1/2): How to scope your Control Plane to secure your Cloud Administration and prevent a global Cloud compromise est apparu en premier sur RiskInsight.

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:  

1. Reduced credential exposure: using Managed Identities reduces the potential attack surface, as credentials are not exposed or shared.  
2. Secure automation: applications and services using Managed Identities can automate tasks without the need for high-privileged user accounts.  
3. 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:  

1. 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.  
2. Mandatory justification for elevated privileges.  
3. Implementation of control and monitoring.  
4. 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! 

Cet article Protecting the Control Plane: Critical Stakes in Cloud Security  est apparu en premier sur RiskInsight.