What is Azure Policy: All You Need to Know

Originally published by Sonrai Security.

Written by Tally Shea.

What is Azure Policy? Azure Policy is a service within Microsoft Azure that allows organizations to create, assign, and manage policies. These policies define rules and effects over resources, identities, and groups, in an effort to ensure compliance and uphold security. Enforcement comes in two forms – flagging non compliance so your team can remediate the concern or simply blocking deployment.

Before delving deeper into Azure Policy, let’s narrow in on what a security policy is, especially in the context of the Cloud. A security policy in cloud computing is a set of rules and guidelines that control the protection of cloud-based systems and data.

Security policies are an important part of robust cloud identity and access management (IAM). IAM policies are crucial for safeguarding data by limiting the identities with access to critical applications and assets.

To drive this point home, IBM’s 2022 Cloud Threat Landscape Report noted that identities were excessively privileged in 99% of the cloud breach cases their teams analyzed.

Core Concepts of Azure Policy

Policies and Initiatives

At the heart of Azure Policy are two core components: policies and initiatives. Policies in Azure are the specific rules or guidelines, while initiatives are collections of policies that help achieve a broader compliance goal. Let’s break down the components of policies below.

Definitions, Parameters Assignments, and Azure Policy Effects

Policy Definitions: A policy definition expresses what to evaluate and what action to take. Each policy definition in Azure Policy has a set of conditions under which it’s enforced and an accompanying effect that takes place if the conditions are met.

Azure Policy Effects: What happens when the conditions are met. Some common effects include: Deny, Audit, Append, Disabled, and DeployIfNotExists

Policy Parameters: Parameters are used to provide flexibility and reduce policy definition redundancy. They allow you to reuse the policy definition for different scenarios. Think of them as fields on a form to fill out – name, city, birthdate, address, etc. They remain, but how you fill them out can change.

Policy Assignments: Assignments are the application of a policy or initiative to a specific scope (subscription, management group, etc.)

Why Use Azure Policy?

Resource Consistency

Azure Policy ensures consistent resource configuration across your environment, this is especially helpful in large scale enterprise environments with various tenants, subscriptions, and teams.

Regulatory Compliance

It helps in maintaining regulatory compliance by ensuring that resources and identity access adheres to corporate standards and legal regulations.

Security

Azure policy enhances security by enforcing restrictions on resource configurations and services. Control over developer testing and deployment and general employee or machine identity privilege is critical for safeguarding your business. Unauthorized access and excessive privilege is a frequent and serious concern leading to security breach and business disruption.

Hierarchy of different Azure scopes.

Types of Azure Policy Scopes

Management Groups

Management groups in Azure Policy provide a way to manage access, policy, and compliance across multiple Azure subscriptions. They act as overarching security guardrails.

Subscriptions

Policies can be applied to entire subscriptions, affecting all resources within.

Resource Groups

Resource groups are another level at which policies can be applied, affecting all resources within the group.

Individual Resources

Policies can also be targeted at specific resources, providing granular control.

The Power of Policy in Management Groups

As mentioned above, management groups are a mechanism to help group together Azure subscriptions. This can be a powerful tool when used correctly. Management groups allow you to manage multiple subscriptions alike, without having to implement controls at the individual subscriptions.

When building Azure policies, you can set the scope to “management group” to ensure security practices are enforced across subscriptions. For example, if you implemented role-based access control to better protect data and resources, all the subscriptions within that management group inherits the RBAC. This is a good way to build far-reaching security guardrails.

You can organize different management groups to reflect your business (regional units, teams, etc.) or deployment stages (e.g. development, testing, production.)

With many varying scopes of policy, differing inheritance processes and hierarchical structures, Azure governance can get complicated. Below, we’ll discuss challenges associated with it.

Azure Policy vs Azure Role-Based Access Control

Azure Policy and Azure Role-Based Access Control (RBAC) differ significantly. While Azure Policy focuses on resource properties, RBAC concentrates on user actions. Azure Policy enforces properties at the time of resource creation or update, whereas RBAC controls what users can do with existing resources.

According to Microsoft, Azure management groups support Azure RBAC. Any role can be assigned to a group and it will inherit down the hierarchy – for e.g. a role ‘vm contributor’ assigned to a resource group will lead all virtual machines in the group to inherit the role.

What Are Common Challenges for Azure Policies?

Policy Hierarchy Complexity

The hierarchy of Azure policies adds a layer of complexity, particularly in large organizations with multiple levels of management and resources. The challenges include:

1. Visibility and Traceability: With policies set at various levels – from the tenant level down to individual services – it becomes difficult to have clear visibility into how these policies interact and what their cumulative effect is. Policies set at high levels mean resources and identities down the hierarchy inherit those policies and permissions.

2. Consistency and Conflict Resolution: Ensuring consistency of policies across different levels and resolving conflicts when overlapping policies are applied can be a difficult task if done manually.

3. Complexity in Troubleshooting: When issues arise, diagnosing and troubleshooting become more complex due to the multiple layers of policies that might be affecting a resource or a service.

Policy Implementation

Implementing Azure policies, especially in complex environments, can be challenging. The key issues include:

1. Understanding the Scope and Impact: Administrators must thoroughly understand the scope and potential impact of a policy before implementation to avoid unintended service disruptions.

2. Aligning Policies with Business Objectives: Policies need to be aligned with business objectives and compliance requirements, which requires a deep understanding of both the organizational goals and the technical aspects of Azure services.

3. Continuous Monitoring and Adjustment: Policies are not set-and-forget. They require continuous monitoring and adjustments to adapt to changes in the cloud environment and organizational needs.

Compliance Standards

Adhering to compliance standards with Azure policies involves several challenges:

1. Keeping Up with Regulatory Changes: Compliance standards are not static. They evolve, and policies must be updated accordingly, which requires constant vigilance and adaptability, especially if done manually.

2. Mapping Compliance Requirements to Technical Controls: Translating compliance requirements into technical controls within Azure policies can be complex and requires a deep understanding of both the regulatory landscape and Azure services.

3. Proof of Compliance: Organizations often need to provide evidence of compliance, which means they must have mechanisms in place to document and report on policy adherence and effectiveness.

How to Use Azure Policies

• Create the Policy Definition: Start by creating a policy definition that outlines the specific rules and conditions. This is either a custom definition or one of Microsoft’s built-in definitions.
• Create an Initiative Definition: Group multiple policies into an initiative for broader governance goals. Again, this can be custom or built-in.
• Define Scope of the Initiative: Define the scope of your initiative, whether it’s a management group, subscription, or resource group. This defines how and where your policy is applied.
• Determine Compliance: Evaluate the compliance status of your resources against the defined policies and initiatives.

Azure Policy Best Practices

Some tips to keep in mind when building out policies:

• Start with an Audit or AuditIfNotExist Effect: Begin with policies that audit rather than enforce, to understand the impact without disrupting existing resources.Think of this as a trial run or test.
• Consider Organizational Hierarchies: Align your policies with your organizational structure for effective governance. This means first organizing your groups by roles or teams, and then applying policies to these different structures.
• Use Parameters: As we discussed above, the use of parameters makes policies more flexible and reusable, taking manual effort off your team.
• Create and Assign Initiative Definitions: Use initiative definitions to bundle related policies into groups for easier management.
• Regularly Review Policies: Regularly review and update your policies as teams, projects, priorities, and compliance regulations evolve.

Azure Policy Examples

Let’s consider some azure policy examples.

First, consider a policy set at the management group level only allowing specific resource types. This policy ensures that only approved types of Azure resources can be created within all the subscriptions under that management group.

For instance, an organization might want to restrict the creation of certain types of storage accounts that are not compliant with regulatory standards. By applying this policy at the management group level, the organization ensures a uniform compliance posture across all its Azure subscriptions.

Further, another azure policy example could be managing access to production vs non production workloads. You can use a management group policy to enforce that developer roles have contributor permissions in non-production environments, and read-only permissions for production environments.

Finally, let’s take a look at a specific policy set at the management group scope that is defining a custom role with the following permissions in JSON format:

{
  “Name”: “MG Test Custom Role”,
  “Id”: “id”,
  “IsCustom”: true,
  “Description”: “This role provides members with custom roles.”,
  “Actions”: [
    “Microsoft.Management/managementgroups/delete”,
    “Microsoft.Management/managementgroups/read”,
    “Microsoft.Management/managementgroup/write”,
    “Microsoft.Management/managementgroup/subscriptions/delete”,
    “Microsoft.Management/managementgroup/subscriptions/write”,
    “Microsoft.resources/subscriptions/read”,
    “Microsoft.Authorization/policyAssignments/*”,
    “Microsoft.Authorization/policyDefinitions/*”,
    “Microsoft.Authorization/policySetDefinitions/*”,
    “Microsoft.PolicyInsights/*”,
    “Microsoft.Authorization/roleAssignments/*”,
    “Microsoft.Authorization/roledefinitions/*”
  ],
  “NotActions”: [],
  “DataActions”: [],
  “NotDataActions”: [],
  “AssignableScopes”: [
        “/providers/microsoft.management/managementGroups/ContosoCorporate”
  ]
}

Security Visibility Challenge with Azure Policy

The complexity of managing multiple overlapping policies in Azure can lead to a lack of visibility and control. It’s crucial to have a comprehensive understanding of the cumulative effect of these policies on your Azure environment to avoid potential challenges.

Without proper visibility, your identities might end up with access that was never intended. In the cloud, privileges can be inherited in ways that are not immediately apparent, making it difficult to track them ‘on paper.’ This type of hidden privilege can create opportunities for lateral movement within your network, which malicious attackers could exploit.

Conversely, if you implement an overly conservative strategy with strict denial through Azure Policy, you may face development disruptions and inefficient request processes.