Use Azure Policy to manage and enforce your standards for governance and compliance and to assess that compliance at scale. The idea is to set standards and to be able to demonstrated your organization is meeting your regularoty compliance goals.
In previous blog posts, you learned about setting up Management Groups and Security Center. For management groups, you learned that policies can be applied across multiple subscriptions. You noticed that Security Center provides a set of policies (an an policy initiative) for your subscription.
In this post, learn the basics of Azure Policy for you to manage resource consistency, regulatory compliance, security, and cost. And how Policies can be grouped together as initiatives, and how you can assign initiatives to specific regulatory compliance goals.
What is an Azure Policy?
You can think of an Azure Policy as a business rule that you want to apply to a resource. Policy definitions are defined in JSON. And rules that are grouped together is called a policy set.
Importantly, when you signed up for Azure Security Center standard, you added many out of the box policies to your subscription.
But first, let’s check the policies deployed as part of Security Center.
Explore Policies deployed by Security Center
When you installed Security Center, you installed the Security Center dashboard, andyou also added a set of Azure Policies. To view the policies, open your browser and log into Azure. Next, type Policy in the search bar.
The Policy dashboard appears. To view the list of policy initiatives that have been added to your subscription, click ASC Default (subscription: ).
Once you click on the ASC Default, view the list of policies that have been added for the ASC (Azure Security Center) initiative. Click View definition, as shown in the illustration.
You can view each of the policies defined in the ASC initiative, which consists of a the list of Policies. Click on one that you are interested in and you can see the policy as defined in JSON. The following illustration shows the policy titled Storage accounts should restrict network access.
Click Assign to see how you might assign the polilcy to a scope (subscription, resource group, or resource. Unter the tabs on the Assign policy page, you can also set whether the policy is to be enforced, which parameters to apply, and how to run a rediation step. The following illustration shows how to set Policy enforcement on the Basics tab.
In this section, you learned about policies set up by Security Center, how to view the policy, and where to find the definition of the policy in JSON. In the next section, you will learn the effects of policies.
Policy as rules
Business rules for handling non-compliant resources vary widely between organizations. Examples of how an organization wants the platform to respond to a non-complaint resource include:
- Deny the resource change
- Log the change to the resource
- Alter the resource before the change
- Alter the resource after the change
- Deploy related compliant resources
Kinds of policy definitions
As an administrator, you control and audit using policies that written using JSON, and are created from one of two kinds of definition:
- Built-in: A set of policies that are supplied automatically by Microsoft
- Custom: Policies that you can write and store in Azure
There are some interesting examples in the selection of built-in policies:
- Enforce tag and its value: Enforce a tag that might be used for cross-charging consumption of a single Azure subscription.
- Allowed regions. Enforce deployment of resources to particular regions, such as those in Europe, India, or United States.
- Not allowed resource types: Restrict access to certain kinds of Azure resources.
- Allowed virtual machine SKUs: Limit the series and size of virtual machines that delegated administrators can deploy.
The Azure Policy definition structure contains elements in JSON for:
- Display name
- Policy rule
- Logical evaluation
Apply a Policy effect
When you apply the policy, you apply the Policy effect. The effect determines what happens when the policy rule matches the resource. So, when you review an existing resource or create a resource or view, the policy is reviewed in the following order:
- Disabled. Should the policy even be evaluated (as shown in the previous section)?
- Append or Modify. Should the policy add something that you specify in or modify a resource? For example, specifying allowed IPs for a storage resource.
- Deny. Should the policy block the request? For example, a rule could be set to deny that storage resource that are not georedundant.
- Audit. Create a warning event in the activity log when evaluating a non-compliant resource
When you successfully deploy a resource, you can specify:
- AuditIfNotExists enables auditing of resources related to the resource. For example, it would evaluate a Virtual Machines to determine if the Antimalware extension exists then audits when missing.
- DeployIfNotExists evaluate to determine if additional compliance logging or action is required. For example, you might evaluates SQL Server databases to determine if transparentDataEncryption is enabled. If not, then a deployment to enable is executed.
For more information, see Understand Azure Policy effects.
Sample built-in policy
The following is an example of a policy provided by Microsoft, “Secure transfer to storage accounts should be enabled”.
policyRule element says that if the field in the resource
false, then apply the effect, which is provided as a parameter. The effect defaults to
/providers/Microsoft.Authorization/policyDefinitions/404c3081-a854-4457-ae30-26a93ef643f9, which you will use in the next section.
When you apply the policy, you provide it a scope (management group, subscription, or resource) and the effect.
For more information about this particular policy, see Require secure transfer to ensure secure connections.
The policy definitions can be grouped into an initiative. Security Center is an example of several policies tied togeather using an initiative.
Using JSON, you can group your own policies together using the Azure Policy initiative definition structure, which contains elements for:
- display name
- policy definitions
- policy groups (this property is part of Regulatory Compliance, explained in the next section.)
You can assign several of your own policies togeather as an initiative. In the following example, selected portions of the NIST SP 800-53 R4 initiative on GitHub includes the storage account rule used in the previous section.
policyDefinitionId refers to the resource id
/providers/Microsoft.Authorization/policyDefinitions/404c3081-a854-4457-ae30-26a93ef643f9 of the storage account policy. The initiative has
When you create initiatives, you are creating sets of policies that can be used to valiadate your regulatory compliance. But how can you track the policy initiative back to a specific regulation?
Use the policy groups element in the policy initiative JSON to define your own regulatory compliance. In the following example, the name
refers to a specific rule in NIST, but is also associated with other policies.
The schema makes is possible for you to define many policies to a particular regulatory compliance, but also for the regulator compliance to apply to multiple policies.
If using a built-in Regulatory Compliance initiative definition as a reference, it’s recommended to monitor the source of the Regulatory Compliance definitions in the Azure Policy GitHub repo.
You can even link your custom Regulatory Compliance initiative to your Azure Security Center dashboard, see Azure Security Center – Using custom security policies.
For more information, see Regulatory Compliance in Azure Policy.
Policy as Code
In the beginning, you will be using the portal to implement your policies. But as time goes on, you will want to lock down the workflow. You will want to demonstrate how and when your policies and how your code demonstrates regulatory compliance.
You will want to put your code into a DevOps workflow. When you make a change, check in the change into a code repository, then deploy it into your environments.
As provided in the guidance, it is best practice:
By making Azure Policy validation an early component of the build and deployment process the application and operations teams discover if their changes are non-compliant, long before it’s too late and they’re attempting to deploy in production.
For more information, see Design Policy as Code workflows.
Policy as Blueprints
Azure Policy and policy intiatives can be automated for deployment. For example, when you create a new subscription, you will want a set of policies in place when the subscription is created.
Blueprints are a declarative way to orchestrate the deployment of various resource templates and other artifacts such as:
- Role Assignments
- Policy Assignments
- Azure Resource Manager templates
- Resource Groups
Blueprints will give you a way to stand up a subscription that meets the compliance for policies and standard resource deployments.
The work you do in creating policies can be leveraged directly into Blueprints.
Learn more about the built in policy samples.
Set up an organizational policy and implementation. See Policy enforcement decision guide in the Cloud Adoption Framework.
And in next few posts, you will learn how to select and deploy Azure Blueprints. Use Azure Blueprints to deploy groups of policies (and resource templates) across your subscriptions, resource groups, or resources. The power of Azure Blueprints comes in at providing sets of policies that will demonstrate your regulatory compliance, such as
- Azure Security Benchmark
- CIS Microsoft Azure Foundations Benchmark v1.1.0
- NIST SP 800-53 R4
- NIST SP 800-171 R2
And then, you will be ready to to deploy resources.
- Azure Policy documentation
- Azure Policy Samples
- Aiden Finn’s Azure Policy for Governance Enforcement