Azure Policies

Welcome back to Part Two of our four-part Blueprint Series. Today's post covers the use of Azure Policies within a Blueprint deployment, along with ARM templates and permissions management.

Azure Policies are the critical component of Azure Blueprints. Policies, like ARM Templates, are JSON documents that describe controls around Azure resources. As mentioned earlier, these can be as simple as identifying regions or resources allowed to be deployed. More in-depth capabilities include remediation of incorrect configuration issues and audit settings and configurations of Azure resources.

Policies have several effects that determine the actions the policy engine may (or may not) take when evaluating resources:

• Append
• Audit
• AuditIfNotExists
• Deny
• DeployIfNotExists
• Disabled
• EnforceOPAConstraint
• EnforceRegoPolicy
• Modify

If we think back to the "allowed regions" example, the Policy uses the 'Deny' effect if the deployment request's region did not match the policy definition.

When initially defining Blueprints, Policies with the 'Audit' and 'AuditIfNotExists' effects are the ones you're going to use the most, expanding to other resources as usage and skillsets become more advanced. The Microsoft FedRAMP sample Blueprints also use DeployIfNotExists as part of logging and audit requirements.

Policies and Initiatives

A policy is a single object to control settings in the environment, meaning one could have one for regions allowed or denied, and another Policy to enforce resource tags, and yet another to audit storage account encryption settings. Eventually, enough Policies exist that management of individual policies becomes cumbersome. Azure Initiatives solve this challenge by creating a collection of policies that can be managed and assigned as a group. You'll find built-in initiatives such as "Audit FedRAMP High controls" and "Audit FedRAMP Moderate controls" already in the portal, in addition to CIS benchmarks and others.

A user can also create their own initiatives that include a collection of requirements specific to organizational needs. Here are examples of initiative breakdowns I've seen that have worked well for customers:

• Compliance boundary - PCI, HIPAA, ISO.
• Internal alignments - Internal security or compliance project phases.
• Organization structure - Core Security, additional team initiatives.

There is no right or wrong way as long as there is a defined and followed internal practice.

Azure Security Center Policies

Azure Security Center (ASC) attempts to provide a single pane of glass for security teams and administrators to get quick, actionable data from the environments they manage. Much of what is within ASC is controlled by Policies and Initiatives and is an excellent place to explore when learning about Policies. Even better, this is part of the free tier, so it doesn't require upgrading to Security Center Standard.

Traversing through the Security Center under the Resource Security Hygiene section uncovers recommendations for security improvements driven by the default ASC Policies. Also, viewing the Policy resource finds assignments for each of the subscriptions called ASC Default. The portal provides charts and graphs on how many resources comply with the policies defined, providing both a breakdown and quick and easy remediation for resource issues that need attention.

The compliance reporting and drill down aspects of Policies are what make them so powerful. Policies, in part, are an excellent way to address compliance requirements and cloud governance structure. Adding them as part of a Blueprint configuration gives the ability to extend that power across the Azure Tenant consistently and repeatable.

ARM templates

ARM templates can also be defined within a Blueprint. There is the option of having ARM parameters defined when the Blueprint is assigned to a scope, and others that are static across all activations of that Blueprint.

One of the most common use cases for this is for deploying vNet. Typically, organizations with connectivity back on-prem leverage a hub-and-spoke network topology with Express Route or site-to-site VPN connections. Network connections drop into a central subscription, and spoke subscriptions get access back over those links when needed.

Consistent resource management is a crucial component of deployments, especially within core networking services, and it is one of the most common areas Coalfire sees organizations struggle.

Having the Azure networking building blocks defined, applied, and tracked within ARM templates and through the Blueprint provides peace of mind that the rest of the environment is being built on top of a solid networking foundation for security and compliance. Even a template as simple as defining a vNet with standard settings to bootstrap that process when the Blueprint is assigned to a new subscription provides consistent value.

When a blueprint is assigned with networking, the address space can be provided at assignment time.

Permissions

Managing permissions across resources is always a challenge for organizations from both a technical and operational perspective. Think about the permissions that are part of every configuration in an environment: Billing Admin, Security Admin, Security Reader, Contributors, etc. These roles are translated to permissions that can be enforced consistently across subscriptions or resource groups. The Blueprint can use a group or named principal to fulfill these roles for every item under the Blueprint. No longer will someone forget to give accounting rights and backtrack later to redefine permissions when it’s caught. Also, just like the ARM Templates, specific permissions may be assigned at deployment.

Conclusion

We’ve covered the basics of Blueprints and their ability to execute control over an Azure tenant. Part Three of this series covers Blueprint governance and lifecycle management. For more information and to get assistance with your cloud engineering and compliance challenges, please visit Coalfire Engineering.