As an Azure Solution Architect for Ensono, I am constantly looking to ensure that our customers have the most robust security posture possible in their estate by leveraging native functionality found on the platform.
Most customers that have a presence in, or do business with, regulated industries are looking towards adopting a Zero Trust architecture; thereby aligning their security posture to adapt to the intricacies and complexity that come with modern cloud-based environments. Zero Trust is a security model based on the principle of maintaining strict access controls and not trusting anyone by default, even those already inside the network perimeter.
Today more than ever, this enables and empowers their workforce - now primarily remote due to the pandemic- to work with fewer interruptions by overbearing security policies. The Zero Trust model protects personnel, the devices, applications, and data accessed from wherever in the world an employee finds themself.
Zero Trust security models instruct us to “never trust, always verify.” With the Zero Trust security model, all access requests are stringently vetted within corporate policy constraints and inspected for irregularities before access is granted. This approach aids the process of satisfying compliance requirements for industries that must use NIST-based controls from the public sector, federal government, defense industry base, and the financial services sector.
To adhere to such requirements, the Zero Trust stance must extend through your entire Azure estate. Serving as the central integrated security standard and end-to-end strategy across the three Zero Trust principles of:
- Verify explicitly
- Use least privileged access
- Assume breach
Below is a diagram depicting Zero Trust architecture integrated with Microsoft Services
In Azure, this is achieved quickly with Azure Blueprints, templates providing quick, repeatable, auditable creation of fully governed cloud subscriptions.
What is an Azure Blueprint?
An Azure Blueprint is a set of pre-configured compliance settings for creating a specific set of standards and requirements that govern the implementation of Azure services, security, and design. Such packages are reusable so that consistency and compliance among resources can be maintained and audited.
Now this might lead you to ask, “why not just use Resource Manager templates and/or Azure Policy instead of blueprints?” It is a fair question since Azure Blueprints appear to overlap the functionality that Resource Manager templates and Azure Policy provide. Understanding the differences between Azure Blueprints, Resource Manager templates and Azure Policy is key to understanding which to use and when.
Azure Blueprints are intended to assist with environment setup. Such environments often include Azure resource groups, role assignments, different policies, and Resource Manager template deployments. Blueprints are essentially packages that pull these types of resources and artifacts together. These packages can then be composed, versioned, and assigned to a subscription. Such blueprint packages can also be audited and tracked.
So, What’s the Big Deal?
You may still be asking yourself “What’s the difference?”. Well, Resource Manager templates are documents that do not natively exist in Azure. Those templates are usually stored locally or in a source control tool. When a Resource Manager template has been used to deploy Azure resources, there are no longer any active connections or relationships between the template and the resources it deployed.
Azure Blueprints differ from Resource Manager templates because even post-deployment of a blueprint, the relationship between the blueprint definition and blueprint assignment (i.e. what the blueprint deployed) remains intact. Maintaining and preserving this connection allows for tracking and auditing of deployments, a key differentiator of Azure Blueprints. Another key benefit is that a single blueprint can be used to upgrade multiple subscriptions at once. Blueprints can consist of Resource manager template artifacts. Existing Resource Manager templates are reusable with Blueprints.
Switching over to the comparison with Azure policy, an Azure policy is an access control system providing default allow/explicit deny on new and existing resources to which the policy is applied. Azure Blueprints are packages for creating specific sets of requirements and standards to govern the implementation of Azure services. Azure policies included in a blueprint offer the ability to create accurate design patterns when the blueprint is assigned. Policy inclusion insures only approved changes are made to the resources or environment the blueprint is assigned. This subsequently ensures ongoing compliance with the blueprint.
What’s in a Blueprint?
In summary, the architecture of a blueprint is based on two main components: a blueprint-file and artifacts. This can include all, or some of the following artifacts:
- Resource Groups allow an administrator to organize resources and to structure them as needed. They also serve as scope limiters for policy assignment artifacts, role assignment artifacts, and Azure Resource Manager templates.
- Resource Group Templates are useful when designing complex environments, such as those managed with Azure Automation State Configuration. Leveraging templates makes standardization of such environments far easier than building them individually.
- Policy Assignments provide a means for applying policy to a subscription to which a blueprint is assigned. That said, the policy must be within the scope of the blueprint containing the policy. Parameters defined with a policy are assigned during blueprint creation or during blueprint assignment.
- Role Assignments provide a means for adding existing users or groups to a built-in role. This is done to ensure the correct people have the proper access to Azure resources. Role assignments are often defined for an entire subscription, but they can also be scoped to a specific resource group that’s included in the blueprint.
All these files are written in the json format. In general, the files are structured as follows: the “blueprint.json” file is located in the root directory and the artifacts in the artifacts folder. The following directory tree illustrates this.
The blueprint.json file describes all the resource group to be created and the parameters at blueprint level as shown below.
Azure Blueprints pass parameter values to these artifacts. When the blueprint author adds an artifact to a blueprint, they must decide on a value to define for each blueprint assignment or they must allow the blueprint assignment to provide a value at assignment time. With this flexibility, the author has the option to either define a pre-set value for all uses of the blueprint or to allow that decision to occur at assignment time.
Although a blueprint can have its own parameters, these parameters can only be created when the blueprint is generated from the REST API and cannot be created when generating the blueprint via the Portal. All new blueprints, when created are in “draft mode”. To assign the blueprints they must be published which requires versioning and a string to be defined as such. The version string has a limit of 20 alphanumeric characters, it can also include hyphens. This differentiates the blueprints from future changes to it and allows each version to be assigned separately.
As changes are made to a blueprint, the published version, along with unpublished changes, continue to coexist. After all changes to the blueprint are completed, the updated blueprint is published with a new version. Each separate (published) version of a blueprint can then be assigned to a subscription. When assigning blueprints via the portal, the blueprint defaults to the version most recently published. If there are any parameters, those are defined during the assignment process.
While Azure Blueprints are like Resource Manager Templates and Azure Policies, the blueprints differ because they are “living and breathing”, in a sense. As such, they retain their relationships to the resources they have been assigned to and can be tracked and audited. This is not possible with templates and policies.
With its versioning capabilities, Azure Blueprints offers the ability to create newer “versions” of specific blueprints, and to leverage those versions independently from the original blueprint from which the new versions were created. This further streamlines the configuration and architecting process of Azure environments since it does not require the reinvention of the wheel each time a new change is needed.
When all is said and done, Azure Blueprints is a service that empowers cloud architects with the ability to define an easily repeatable set of Azure resources that conforms to the organization’s standards and requirements.
Getting Started with Azure Blueprints
To get started using Azure Blueprints,
- From the Azure Portal, select All services in the left pane. Search for and select Blueprints.
- Select Blueprint definitions from the page on the left and select the + Create blueprint button at the top of the page.
Or, select Create from the Getting started page to go straight to creating a blueprint.
Azure Blueprints for Zero Trust
The Azure blueprint for Zero Trust enables IT professionals to create hardened, secure environments more easily for their application workloads. The blueprint enables seamless Zero Trust controls implementation across six foundational elements: identities, devices, applications, data, infrastructure, and networks.
The Zero Trust blueprint includes Azure Resource Manager templates to deploy and configure Azure resources such as Azure Key Vault, Azure Security Center, Azure Monitor, Virtual Networks, Network Security Groups, and more. If you’re working with applications that need to comply with NIST Risk Management Framework(RMF), FedRAMP High, or DoD Impact Level 4 requirements, or just want to improve the security posture of your cloud deployment, the blueprint for Zero Trust is designed to help you get there faster.
The Azure Blueprints for Zero Trust is currently in preview with limited support. To learn more and find instructions to deploy the Zero Trust blueprint in Azure, see Azure Blueprint for Zero Trust