Azure Landing Zone design: Azure Policy

Setting the stage

I believe that if You are working with Microsoft Azure, You must be familiar with the Azure Landing Zone construct, part of the Microsoft Cloud Adoption Framework for Azure. In case You are not, it represents a structured environment adhering to fundamental design principles across eight distinct areas:

1. Azure billing and Microsoft Entra tenant; (A)
2. Identity and access management; (B)
3. Resource organization; (C)
4. Network topology and connectivity; (E)
5. Security; (F)
6. Management; (D, G, H)
7. Governance; (C, D)
8. Platform automation and DevOps. (I)

Note:

We discussed the Cloud Adoption Framework several times. Refer to the links at the bottom of this article for more information.

Below is an illustration of the conceptual architecture for Azure landing zones, showcasing a scaled-out target structure aimed at assisting organizations in effectively managing cloud environments to propel their business forward while upholding optimal standards for security and governance. Every implementation option for Azure landing zones offers a deployment strategy and clear design principles.

These principles cater to diverse application portfolios, facilitating the seamless migration, modernization, and expansion of applications on a large scale. Utilizing subscriptions, an Azure landing zone segregates and amplifies both application and platform resources. Specifically, subscriptions designated for application resources are referred to as application landing zones, while those allocated for platform resources are known as platform landing zones.

Landing Zone Design area: Resource organization

As part of the Resource Organization (C), I want to focus on the Design Principles, more specifically on the policy-driven guardrails (Azure Policy). The Azure Policy is for governance, monitoring, security and compliance. If You need to prohibit specific named users and/or service principals from doing something, then You need Role-Based Access Control, or as it is mentioned above – Identity and access management (B).

This is covered in the policy-driven guardrails documentation, as referenced above. It provides an comprehensive coverage of DeployIfNotExists (DINE) or Modify policies from making changes within your Azure environment.

In this article I want to point out some design areas as well as recommendations to follow during implementation of Azure Policies in Your environments.

Landing Zone Design area: Management Group structure

Policy/Initiative Definitions and Policy Assignments need to be deployed at a scope. This is valid for both built-in and custom ones. The scope You should be looking at is the Management Group (MG) in each tenant.

That Management Group level should be the single group, underneath the “Tenant Root group” as recommended in the Design Areas (Cloud Adoption Framework) or at the actual “Tenant root group” if You have simple structure.

Best practice:

Keep the Management Group tree depth to maximum two levels.

Each new or de-allocated subscription must be placed in appropriate Management Group for such purpose (in the image above that Management Group is “Decommissioned”) or below the scope of specific security-driven policy assignment. With that, You will prevent those subscriptions from bypassing the established security controls relevant for the organization.

Note:

If You look at the image above, it implies that the policies are applied on the Subscription level. This actually is not true, the methodology references the Management Groups.

Landing Zone design area: Policy Assignments

Until You assign a Policy, it’s an inert element in Your Tenant. The assignment is on a scope (Tenant Root Group, Management Group, Subscription). When You create an assignment, mind the following:

• Use naming convention that makes sense to You: it is clear enough to understand what it is all about;
• Always add description, outlining at least what the policy is all about, some basic information and which department(s) own(s) it (can be up to 512 characters);
• You can use the metadata to store some additional information (up to 1024 characters);

Note:

A subset of metadata are reserved for common properties, such as createdBy, assignedBy, createdOn, parametersScope, updatedBy, updatedOn, evidenceStorages
More information can be found here.

You should also be aware, that with each subscription, Defended for Cloud, automatically assigns the “ASC Default (subscription: XYXYXY)” initiative (I know, this is an old name). It also contains the subscription ID in its name.

Each one of those contains 242 Policy definitions inside (at the moment). All policies inside are set to “Audit”. This is a great start, of you haven’t defined the policy settings by yourself.

It actually gives you a great security baseline, on which You can build up on. For small and mid-sized organizations this might be more than enough. But, once You consider following the framework recommendation and assign it on the Management Group level, be careful of overlapping.

Best practice:

In most scenarios, you will set some of the effects to “Deny”. Create a new Assignment at a Management Group level to change the effects accordingly (see Management Group structure). Once done you should remove the auto-assigned Policy Assignments to avoid difficulties on overlaps.

In some cases You will need to assign additional security and/or compliance related initiatives (i.e. ISO27001, NIST, etc). Just don’t over do it.

Best practice:

Don’t use more than three initiatives, including any custom policy initiatives. Maintenance, managing exemptions and troubleshooting is almost impossible for more than that.

Within the assignments, any policy that will perform modification or deployment of resource/component that does not exist, will require a Managed Identity (with specific role to perform this action).

Decision point:

System-assigned Managed Identity service principal is always bound to one assignment. This will eliminate malicious usage of that service principal, since Azure is going to “keep an eye” on it.
User-assigned Managed Identity service principal can reduce the number of Azure role assignments for service principal accounts. But, additional security measures and/or exemption from ones, need to be considered for that service principal.

These accounts will be important when You execute specific Policy remediation tasks. We use scripting to perform this operation, and not the CI/CD tools.

Landing Zone design area: Policy customization

Each time You decide to run a custom policy definition and/or imitative, this would be the a well considered in advanced option. When opting in for this model, there are couple of things to remember:

• The elements of a policy are unchanged in value, no matter how many times You assign that policy.
• Support Your organization operating model: depending on the structure, You might have different teams in charge of different Policy definitions/initiatives.
• Don’t repeat yourself: reduce repetition of information which is likely to change, replacing it with abstractions that are less likely to change, or using data normalization which avoids redundancy in the first place.

Now customization will create a different level of complexity – You need to manage these policies. As time progresses, Azure landing zone custom policies and policy initiatives evolve to newer iterations, offering enhancements that you can integrate into your Azure environment. This is where the problem lies – following the changes, testing and updating the policy assignments. Using CI/CD process (i.e Azure DevOps, GitHub, Jira, etc) helps maintain visibility and control.

The following diagram explains how the process goes, as per Cloud Adoption Framework guidance:

Decision point:

This is where You need to decide should the policy definitions/initiatives be customized, or should You opt-in for the built-in ones?

Although there are some constrains with the built-in policies, but still its far more easier for implementation. You don’t need to handle the naming conventions, description, versioning, assignments, testing, and troubleshooting. This becomes more evident in multi-tenant scenarios. There are couple of links at the end, with tools and sources that will help You in that case.

Landing Zone design area: Policy exemptions

The Azure Policy exemptions feature serves as a valuable tool for excluding either an entire resource hierarchy or individual resources from the evaluation process of initiatives or definitions. While exempted resources still contribute to the overall compliance status, they are temporarily exempted from evaluation.

It’s important to note that exemptions offer flexibility in compliance management, allowing organizations to tailor their policies according to specific needs and scenarios. Additionally, exemptions can be applied strategically to address temporary requirements or unique circumstances within the Azure environment.

There are two categories:

• Mitigated: This exemption is authorized when the policy’s objectives are fulfilled through alternative means.
• Waiver: This exemption is authorized when a resource’s non-compliance status is temporarily acknowledged.

Another scenario where Waiver category is applicable is for resources or resource hierarchies that require exclusion from specific definitions within an initiative, without necessitating exclusion from the entire initiative.

The policy exemption (JSON) contains elements for:

• Display name
• Description
• Metadata
• Policy assignment
• Policy definitions within an initiative
• Exemption category
• Expiration
• Resource selectors
• Assignment scope validation

Best practice:

The metadata property allows creating any child property needed for storing relevant information (string). Use it to store link with additional information, to keep information why and who granted the exemption.

Additional information

Cloud adoption in the era of accelerated Digital Transformation
Azure Policy assignment structure
Azure/azure-policy: Repository for Azure Resource Policy built-in definitions and samples (github.com)
Enterprise Azure Policy as Code (EPAC)
AzAdvertizer
Azure Policy – What’s new (GitHub)
Update Azure landing zone custom policies
Design Azure Policy as Code workflows
Useful links repository (GitHub)