Identity and Access Management for Azure Landing Zones

 

Today, we launched our refreshed guidance for identity and access management (IAM) in Azure Landing Zones. ALZ is a core part of the Cloud Adoption Framework for Azure. It is aligned to the eight CAF design areas, Identity and Access Management being one of them. You can check out the refreshed guidance over at: aka.ms/ALZ/IAM

 

The updated guidance brings IAM to the heart of a robust Azure Landing Zones implementation. ALZ is built to support a Zero Trust strategy, and the guidance is centred around the principle of least privilege to ensure that every administrator and user has the access they need, when they need it, to the right resources, and nothing more. No single administrator or team should have superpowers over everything. The principle of least privilege protects individuals and workloads, and is a key factor in limiting the damage that can be done by an attacker or a failed change.

 

IAM supports the ALZ design principle of subscription democratization: we trust application owners to know what’s best for their apps, and platform owners to provide services to those apps in a secure and scalable way. Fundamentally, we separate the identity and access management of every environment and every workload and avoid global permissions or reused credentials.

 

The updated guidance includes three sections/documents:

 

• Hybrid identity with Active Directory and Microsoft Entra ID is about understanding different identity options, how to integrate on-premises directory services with Microsoft Entra ID and selecting the right protocols and services for your authentication and authorization requirements.

 

• Landing zone identity and access explains on how to use RBAC for platform and application landing zones. We should automate as much as possible, and separate roles and responsibilities between workloads. We use role-based access control to ensure that application owners and administrators can manage their workloads with minimal intervention from the platform team, delegating as much responsibility as possible without introducing additional risk.

 

• Application identity and access controls how application components authenticate to one another. We avoid storing credentials where they could be discovered and minimise the lateral movement possible in the event that one resource is compromised.

 

Overview

 

First, where does identity and access management fit into ALZ?

 

 

There are two core components:

 

• Microsoft Entra ID (formerly Azure Active Directory). This is the central, cloud-hosted directory service providing the authentication and authorization for Azure services, whether at the control plane or within applications. It includes tenant-wide administrative roles such as Global Administrator, as well as services such as Privileged Identity Management (PIM), Identity Protection, and Conditional Access.

 

• The platform Identity subscription hosts identity services such as Active Directory domain controllers, or Microsoft Entra Domain Services managed domains. Not all organizations deploy services into here; if you are operating fully in the cloud, you may not have a need for hybrid or legacy IAM services.

 

In both cases, administrative control over an identity service is considered a privileged role that should be closely guarded.

 

It’s also important to understand the difference between Microsoft Entra ID roles, and Azure RBAC roles. If you’ve ever been given a Global Administrator Entra ID role and been surprised that you still can’t see or manage Azure resources, it’s because they are two separate access control scopes, with separate RBAC roles. A Global Administrator can acquire Azure resource permissions, but they don’t have them automatically.

 

 

 

Entra ID roles grant permissions to manage resources across the entire tenant, such as users, groups, and applications. Azure RBAC roles grant permissions to perform actions on resources within a specific scope, like a subscription, management group, resource group, or resource.

 

Both roles are relevant for Azure landing zones and application administrators, but in different ways. Application owners need the ability to manage groups and application identity principals, as well as managing Azure RBAC roles on resources within their landing zone. This creates a dilemma, as the giving individual application owners permissions over the whole Entra ID tenant clashes with the principle of least privileged access. The updated guidance has recommendations for how to manage that, like reducing the need for service principals, and using Entra ID administrative units and access packages to delegate group administration.

 

Hybrid identity with Active Directory and Microsoft Entra ID

 

Many organizations still use Active Directory as their primary identity service and synchronize it with Microsoft Entra ID. For these organizations, deploying domain services into a separate, secure platform subscription means that application owners can consume the required identity services – for example, domain-joined virtual machines – without being responsible for administering them.

 

Where possible, we recommend using Microsoft Entra ID to provide identity and access management for applications. Entra ID supports newer, more secure protocols, as well as security features such as multi-factor authentication (MFA) and Conditional Access to continuously validate the security posture of users and administrators. If you still need protocols such as Kerberos, LDAP, and NTLMv2, consider whether you should extend an existing domain into Azure, or start fresh with a managed domain using Microsoft Entra Domain Services.

 

Continuously review your application estate; over time, you may be able to migrate more applications onto Microsoft Entra ID, and deprecate services such as Active Directory Federation Services (AD FS), or use Azure Application Proxy and Global Secure Access to overlay legacy applications with modern security controls.

 

Landing zone identity and access

 

Subscription Democratization allows application teams to manage their own workloads within the policy guardrails set by the platform teams. Identity and access management underpins the separation of one landing zone from another, and the isolation of workloads within an organization. As such, it’s an enabler for the scale and security that the cloud can provide.

 

One common way to create application landing zones is to use a subscription vending model. This lets application owners create new environments when they need them, with the services, connectivity, and policy controls that the platform team sets up. Some settings should be automatically provisioned, such as a basic set of security groups and role assignments that the application owners can use to deploy and manage their workloads. Others may be done on demand, like network connectivity to the Identity virtual network that hosts the domain controllers, which shouldn’t be configured if the workload doesn’t need Active Directory services.

 

There should be no shared identities across environments. If an application has development, test, and production subscriptions, each should have their own security groups, role assignments, and managed identities or service principals. This prevents sideways movement from a less secure development environment to a production environment, as well as avoiding service interruption if a change in a dev environment removes an identity principal that was being used somewhere else. Always assign roles to groups rather than individuals, and use entitlement management to manage group membership. If one individual needs access to multiple environments, add them to multiple groups instead of using a single user or group role assignment.

 

In some cases, the built-in roles aren’t sufficiently restricted to adhere to the principle of least privilege. For example, the Contributor role can modify anything apart from role assignments, which might be excessive. Some restrictions can be put in place using Azure Policy, but sometimes a custom role definition is the best option for giving users the access they need. The Azure Landing Zones accelerator includes a set of custom roles, and the updated guidance gives examples of when they can be used and when new ones might be required. This will vary from one organization to another, as the separation of roles and responsibilities is very dependent on the organizational structure and the teams involved.

 

Wherever there is a need to assign access or administrative privileges, always think, ‘is there a more restrictive way we could do this and still let people do what they need to?’ For example, where application owners need access to manage users within Microsoft Entra ID, you can use Administrative Units to help make sure they have the rights to manage security principals related to their workload, without providing blanket Entra ID administration rights.

 

Application identity and access

 

This new section is about how to manage access between application components, such as a web front end accessing storage or a back-end SQL database. It briefly mentions authenticating users to applications, but that’s more comprehensively documented elsewhere.

 

We recommend using managed identities wherever possible. Managed identities avoid storing credentials in applications. You can use MIs with most Azure services that support Microsoft Entra ID authentication, and the list is always growing. If you’re using CI/CD pipelines, you can also use workload identity federation and OIDC to give your pipelines the required access to provision and configure resources, without storing SPN credentials that could expire or become compromised.

 

As with landing zone access controls, managed identities shouldn’t be shared across environments. For example, a development application server shouldn’t have any ability to access a production SQL database. Managed identities should be created and destroyed programmatically as part of your environment lifecycle, which reduces risk and complexity in the long term, as you don’t have to make changes or troubleshoot access when deploying from one environment to another.

 

Summary

 

The refreshed ALZ Identity and Access Management section of the CAF brings the design area closer to the Azure Landing Zones concept and offers some updated and clarified guidance based on our real-life experience talking to customers about their landing zone deployments; a process the team goes through on a regular basis to ensure ALZ remains evergreen. We’ve tried to address common questions and scenarios and looked at how ALZ has evolved over time. Ultimately, our aim is to enable Azure customers to build more secure environments with less friction between teams and processes, and we’ll be continuously reviewing the rest of the CAF design areas as both our own and our customers’ experience with landing zones becomes more mature.

 

See the updated documentation here: aka.ms/ALZ/IAM

 

Next Steps

 

• Sign up for Azure Landing Zones community call and sign up to ALZ notifications to hear the latest developments from the worldwide ALZ team
• Use the Azure ALZ Review Checklist to assess your own environment