Cloud
Using Azure Blueprints to Control Azure Compliance
This content is provided "as is" and is more than a year old. No representations are made that the content is up-to date or error-free.
As Peter Parker says, with great power comes great responsibility. And so it goes with public cloud: With cloud scale and agility come cloud-scale problems and compliance nightmares. Every day, IT professionals balance the need to act quickly—often leveraging cloud speed of execution to implement resources—with the need to control resource deployments in their efforts to maintain proper organizational compliance and security posture.
In this four-part series, we break down what Azure Blueprints are and how they can help govern your Azure tenant. Part One introduces Blueprints' terms and usage, and Part Two covers Policies, Initiatives, and Permissions. Part Three discusses Blueprint governance, and finally, in Part Four, we walk through the FedRAMP Moderate Blueprint deployment.
Enter Azure Blueprints
Blueprints allow organizations to define rules and requirements that fit their organization's needs and then assign those requirements to policies and guardrails across Azure. This handy tool eliminates the toil of fixing infrastructure that should have been correct in the first place and ensures environments are kept within the desired state after initial configuration.
In this first post, we look deeper at the following areas of Blueprints:
- Defining Blueprints
- Azure Policies
- Initiatives
- Security Center
- ARM templates
- Permissions
- Blueprint scoping
- Managing assignments
- Getting started with templates
- FedRAMP specifics
- Microsoft provided
- Custom Templates
- FedRAMP specifics
What are Azure Blueprints?
Blueprints are part of the solution to foundational compliance and security challenges that many organizations experience while operating in public clouds like Azure. While it would be ideal if all parties fully understood the security and compliance operating requirements of their organization, the reality is that few have that understanding. The result is persistent and ongoing challenges within most organizations.
On one hand, product and operations teams attempt to consume cloud resources to achieve their goals and business directives. On the other hand, security, compliance, and cloud architects are trying to control the chaos while allowing the organization to leverage cloud-scale and flexibility.
Blueprints allow the few who understand the security and compliance posture of an organization to quantify their knowledge into infrastructure rules that Azure Resource Manager (ARM) applies when anyone tries to make changes or deploy resources in Azure, providing organizations the best of both worlds. Consumers get to build quickly and make their own progress, while security and compliance are codified and reported on through Blueprints, keeping consumers' actions maintained within organization guidelines.
Blueprints consist of three artifacts:
- Azure Policies
- ARM templates
- IAM permissions management
These components allow governance and control to be built on a wide scale across multiple subscriptions and resources.
One of the most common restrictions limits into which Azure regions users can deploy resources. Suppose the organization needs to restrict resource deployments to regions with ExpressRoute or VPN connectivity within a specific country. In that case, a Policy can be defined within a Blueprint that only allows deployments to those regions defined therein. With that Policy in place, it doesn't matter if someone uses the Azure portal, PowerShell, AZ CLI, or a third-party management tool; the policy engine parses every request before going to ARM.
Note: Blueprints only work on ARM resources, so if the subscription still has Azure Service Manager (Classic) resources, Blueprints will not apply.
Another typical example of a restriction is the "allowed resource" type. This is especially useful while maintaining a prescriptive compliance framework like FedRAMP in Azure Commercial Cloud instead of Azure Government Cloud. Policies within the Blueprint can whitelist the Azure resource types to be deployed. This ensures that someone doesn't leverage a service in "preview" or without proper FedRAMP authorization.
Microsoft has sample Blueprints available in the Azure Portal and on GitHub that provide examples and base starting points for various levels of security and compliance postures, including ISO, SOC, and FedRAMP Moderate/High samples, among others.
In addition, the Azure community has created further samples, making it easy for organizations to jumpstart this process.
Conclusion
At this point, we’ve covered the foundational concepts of Blueprints. In Part Two of this series, we will go over using Policies, ARM templates, and permissions within a Blueprint.
More from this blog series:
Part 2:Azure Policies
Part 3:Blueprints scopes and assignments