There are usually three common approaches when you need to provide access to your Azure environment to a third party, such as external contractors, vendors, partner organizations, or a managed service provider (MSP). There are many pros and cons to each of these, which will be described in this article from the perspective of identity and access management (IAM). As a bonus, this article will also touch on one overlooked approach, which can be especially beneficial for MSPs.
Let’s start from the worst case scenario and move towards better alternatives.
Shared account(s) for external users in your Entra ID tenant
That access scenario is common for small and medium organizations where a third party is provided with a few impersonalized accounts in a client’s Entra ID tenant. In other words, they are used by multiple people to manage the client’s environment in the Azure cloud. The usual reasoning for such an access design decision is that it’s simple, quick to set up, and minimizes license costs and the attack surface, as fewer accounts are handed over to an external organization or user(s).
Despite its simplicity, that approach to accessing client Azure environments has a few serious drawbacks:
- Using shared accounts is generally a bad security practice, as many people know the account credentials, and investigating user activity becomes a titan’s quest: you cannot be sure who exactly used a shared account at any given moment.
- Those few user accounts are often overprivileged, granting administrative permissions to many systems and applications, making them ideal for credential theft attacks.
- Securely handling those shared accounts by third parties requires additional effort from both sides.
Those security risks can be partially mitigated by enforcing a multitude of protocols including a strong password policy, regular password rotations, using a password manager with access control, and, most importantly, enforcing mandatory multi-factor authentication (MFA) for those accounts. Still, the shared account usage pattern creates more security threats than benefits, and it is something that is strongly not recommended.
The only probable exception from that recommendation is break-glass accounts, which are known/accessible by very few people. However, those accounts are not intended for regular use, should be used only in exceptional circumstances, and should be extensively monitored/alerted when used for authentication.
Regular user accounts for external users in your Entra ID tenant
Many enterprise-scale organizations prefer providing individual user accounts in their Entra ID tenants to external contractors, vendors, etc. The most obvious reason for that IAM practice is having complete control over the account security policies. In that scenario, an organization (client) can leverage all available identity protection capabilities in their user access management setup: password policies, conditional access, access restrictions, monitoring, logging, suspicious activity detection, etc.
In large companies, identity and access management are usually performed in-house for security reasons, and they dictate the rules for accessing the organization’s environment.
The first notable downside of this approach is that the client now needs to manage the entire user account lifecycle for external users, meaning it needs to provision new accounts for such users and decommission them when required. The last part is often overlooked and delayed as it requires an efficient notification process between the client and third parties when a third-party user account provided by the client should be deactivated. If there is no such process in place, a security gap will be created when a third-party user is no longer authorized to access the client environment, whereas their personalized account in the client tenant is still active and can be used to gain that access.
Secondly, in the MSP access scenario, when a single engineer can manage multiple client Azure environments, that creates an overhead of maintaining and securing many individual accounts for accessing different client environments. When the engineer parts ways with the MSP, the latter needs to reach out to all the clients the engineer had accounts with and ask them to revoke that access.
Thirdly, as those user identities are housed in the client tenant, the client needs to license them accordingly to comply with application license requirements.
What if you could eliminate clients’ need to manage user identities on their side while still giving clients enough access controls?
Guest user accounts in your Entra ID tenant
The concept of guest user accounts has existed in Entra ID for quite some time. In short, it allows you to invite a user into your organization using their external identity, e.g., their user account in another Entra ID tenant.
While providing you with all security controls you can enforce on user accounts in your (client) tenant, as in the previous scenario, that approach also simplifies access revocation for such identities: as soon as a guest account is deactivated in its home tenant, it cannot authenticate and access your (client) tenant, too. You can also disable (or modify) guest account access in your (client) tenant without affecting its state and permissions in its home and other tenants. Sounds like a perfect solution, or not?
One caveat with guest account access is that you must still onboard (invite) those accounts to your tenant and configure their access. With some effort and a well-designed access model, that process can be automated and monitored for proper access configuration.
Another point worth mentioning is that with guest user accounts, you have little to no control over their authentication process, which happens outside your (client) tenant. In other words, you might need to make an additional effort to configure some advanced authentication controls on your side, like requesting additional MFA enrollment and its usage by guest users in your tenant.
Overall, managing guest user access at scale requires careful planning and deploying services like Microsoft Entra External ID to handle advanced scenarios. If designed properly, that scenario can be a solid foundation for providing access to external identities in your tenant.
[Bonus part] Delegated access with Azure Lighthouse
Despite being introduced back in 2019, that solution for delegated access to Azure resources is often overlooked when designing third-party access to your Azure environment. The basic idea of that solution is simple: you can delegate access to your Azure subscriptions and/or resource groups with specific permissions to specific security principals in an external (e.g., MSP) tenant.
Apart from configuring delegated access in your tenant, MSPs can create service templates by packaging managed services they offer with required permissions to fulfill them into Azure Marketplace offers, simplifying the onboarding experience for new customers.
After the target Azure resources are onboarded for delegated access with Azure Lighthouse, those (guest) service principals can access and manage them. Plus, as those service principals can represent security groups (usually a preferred approach here) in another tenant, you can basically abstract yourself from managing access for individual user accounts.
In addition, MSP engineers can now access different client environments using their home (MSP) tenant user accounts without needing to remember and manage multiple access accounts. Because the delegated permissions in Azure Lighthouse can be different from client to client and from scope to scope, they also don’t need to worry about using correct access profiles, as they are already pre-configured for them.
Those benefits can also be seen as a disadvantage, as you have no explicit control over who can manage the Azure resources you delegated access to because it’s controlled on the MSP side by managing the membership of security groups referred by security principals in the Azure Lighthouse deployment template.
Another aspect of using Azure Lighthouse for delegated access to Azure resources is that you don’t have control over the authentication process for the security principals in the MSP tenant. So, the principle of least privileged access becomes even more critical in that access scenario, as you likely want to reduce the potential blast radius in case a service principal (user account) with delegated access is compromised in the MSP tenant.
Integrating Azure Lighthouse with Entra ID Privileged Identity Management (PIM) on the MSP side can strengthen the security of using delegated access. However, requiring such additional controls from the customer side requires auditing MSP processes and building trust relationships with your MSP. From the technical side, you, as a client, can only monitor MSP activity within the scope of delegated management.
Compared to the scenario with guest user accounts in your tenant, Azure Lighthouse removes the overhead of managing individual guest user identities in your tenant for the cost of less control of what specific users in the MSP tenant will have access to your Azure environment. As in the previous case, it can be a very efficient and secure access model with proper permissions, scopes and monitoring configurations.
As you might conclude after reading about the described access model, there is no one perfect design for access solutions. Each has some tradeoffs, which you can try to compensate with additional controls like automation, monitoring, regular auditing, etc. The most important thing is to know about those drawbacks and how to deal with them in your specific use case. Plus, you need to understand how your solution for delegated access to your Azure environment fits into the overall security design in your organization.
In the next part of this series, there will be some ideas presented on configuring delegated access to client Azure environments with Azure Lighthouse and integrating it with Entra ID PIM for better control access elevation.
About Atlas Technica
Atlas Technica was founded in 2016 with two main goals: to provide the best customer service experience possible for their clients, and to use best-in-class public cloud technology to do so. There is a clear need among hedge funds and other alternative investment firms for an IT provider that will put service first. Atlas Technica's mission is to shoulder the burden of IT management, user support, and cybersecurity compliance so you don't have to. Atlas Technica has offices located throughout New York, London, California and Florida. For more information, visit www.atlastechnica.com.
About the Author
Andrew Matveychuk is a Cloud Solution Architect with 20+ years of experience in the IT industry, focusing on cloud governance, security, cost management, automation, monitoring and other DevOps and SRE practices. He is also an author of one of the top Azure Policy repositories on GitHub and a recognized contributor in Azure Community. Andrew oversees the Cloud Solutions practice at Atlas Technica and helps our clients to design and deploy secure, scalable and efficient cloud solutions. For more details, please check his LinkedIn profile at: linkedin.com/in/andrewmatveychuk/
