After an introduction to Enterprise-Scale and further information about possible use cases, I would like to focus on one of the design principles: policy-driven governance.
Policy-driven governance means the usage of Azure Policy to build and provide guardrails, and to enable autonomy for the platform and application teams, regardless of their scale points. Those guardrails ensure that deployed workloads and applications are compliant with your organization’s security and compliance requirements, and therefore a secure path to the public cloud.
What is Azure Policy?
From the Azure Policy overview:[1]
Azure Policy evaluates resources in Azure by comparing the properties of those resources to business rules. These business rules, described in JSON format, are known as policy definitions. To simplify management, several business rules can be grouped together to form a policy initiative (sometimes called a policySet). Once your business rules have been formed, the policy definition or initiative is assigned to any scope of resources that Azure supports, such as management groups, subscriptions, resource groups, or individual resources. The assignment applies to all resources within the scope of that assignment. Subscopes can be excluded, if necessary.
Azure Policy uses a JSON format to form the logic the evaluation uses to determine if a resource is compliant or not. Definitions include metadata and the policy rule. The defined rule can use functions, parameters, logical operators, conditions, and property aliases to match exactly the scenario you want. The policy rule determines which resources in the scope of the assignment get evaluated.
In order to understand the behavior of policies in the context of Enterprise-Scale, some basic Policy characteristics must be known.
- Policy operates at a level above other Azure services by applying policy rules against PUT and PATCH requests and GET responses of resource types going between Azure Resource Manager (ARM) and the owning resource provider (RP).[2]
- A newly assigned policy or policySet, to any supported scope, takes around 30 mins for the assignment to be applied scope.[3]
- Compliance data is updated as follows:[3]
- New policy assignments: 30 mins
- Update existing policy definition: 30 mins
- Update existing policy assignment: 30 mins
- On-demand scan (REST API, PowerShell): 3 mins
- Standard compliance evaluation cycle: 24 hours
- Policy provides different effect types (what happens when the policy rule is evaluated), which do behave differently.[4] The effect types are also evaluated in a specific order, as shown below:[6]
- Disabled
- Append and Modify
- Deny
- Audit
- AuditIfNotExists and DeployIfNotExists
In order to understand how the compliance works and when a resource is marked as non-compliant, you need to understand the following:[5]
- For Audit and Deny: It requires IF statement to be TRUE then effect takes place.
- For Audit resource is marked as non-compliant.
- For Deny, new deployment (for new or update resource) is denied while existing resource is marked as non-complaint.
- For DeployIfNotExists and AuditIfNotExists: It requires IF statement to be TRUE and existence condition to be FALSE.
Azure Policy in the context of Enterprise-Scale
As outlined in the Enterprise-Scale design principles, Policy is used build and provide the required guardrails for all landing zones. For example, a policy ensures that all required activity logs for all subscriptions (selected categories in diagnostic settings) are sent to a central Azure Log Analytics workspace. Or all virtual machines are protected by Azure Backup, as another example. For this, Enterprise-Scale is primarily focusing on proactive and preventive policies (e.g. with DeployIfNotExists, or in short DINE) to enable autonomy for the platform, autonomy for the application teams, and ensures that resources are in their compliant goal state, no matter how those resources got created.
In order to simplify the adoption of those proactive and preventive policies, Enterprise-Scale includes three reference implementations for three different customer use cases, all with an extensive list of policy definitions and policy assignments.[7] For example:
- Enable Azure Security Center with Standard tier
- Deploy a virtual network including network peering
- Deploy and enable security features for Azure SQL Databases (Transparent Data Encryption, auditing, etc.)
The three included reference implementations are:[8]
- Contoso – a hybrid networking example using Azure Virtual WAN
- AdventureWorks – a hybrid networking example using the traditional hub and spoke network architecture
- WingTip – an Azure-only example
The provided user experience allows you to easily deploy (bootstrap) the selected reference implementation, with all included definitions and assignments. Furthermore, policy definitions and assignments can also be deploy out-of-band on targeted management groups and subscriptions. The user experience when deploying a reference implementation is shown in the figure below:
Finally, a big thank you to @KristianNese for reviewing and providing feedback.
[1] https://docs.microsoft.com/en-us/azure/governance/policy/overview
[2] https://github.com/Azure/azure-policy
[3] https://docs.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data
[4] https://docs.microsoft.com/en-us/azure/governance/policy/concepts/effects
[6] https://docs.microsoft.com/en-us/azure/governance/policy/concepts/effects#order-of-evaluation
[7] https://github.com/Azure/Enterprise-Scale/tree/main/azopsreference