Exploring the Azure Cloud Adoption Framework Blueprint

From an IT evolutionary standpoint, we are multiple years into the cloud age. It is no secret that the cloud has helped business of all sizes achieve their desired outcomes. The cloud, however, comes with it’s own set of challenges. Being effectively a toolbox of services, cloud providers have gone for breadth by making their offerings widely usable across vastly different use cases. In order to accomplish this, cloud providers have pushed bits of complexity on to the user. This manifests as the sets of options that a user must pick from when provisioning any given service. One only needs to try and deploy an Azure virtual machine to realize the extent to which this has proliferated.

As cloud providers look to grow and increase adoption of their services, the problem ultimately turns to how to assist novice users in getting up to speed quickly, with services that can be used safely and securely. I think it’s important to note here that novices are not just people “new to the cloud”, but also encompasses existing cloud users trying new services for the first time. When cloud services number in the 100’s, it is virtually impossible to be an “expert” in all of them. Further, as these services build on-top of one another, the amount of base knowledge required to competently administer composite services can become staggering.

So, the problem boils down to how do we help novice users:

• Understand the minimum set of services required to ensure safe and secure operations of cloud services
• Deploy those services with safe, secure, and appropriate defaults
• Grow deployments in a structured way, minimizing the overheads both in knowledge and time
• Make appropriate architectural decisions that may be hard to change later

The Azure solution to this is captured in the Cloud Adoption Framework and specifically in the concept of Landing Zones. Landing zones are implemented via a service called Azure Blueprints.

From the documentation:

Landing zone definition

A landing zone is the basic building block of any cloud adoption environment. The term landing zone refers to a logical construct capturing everything that must be true to enable the desired cloud adoption.

Scope: A fully functional landing zone considers all platform resources that are required to support the customer’s adoption needs.

Refactoring: A fully functional landing zone is the final deliverable of any iteration of the Cloud Adoption Framework’s Ready methodology. During each iteration, the code base that defines the landing zone will be refactored or expanded. After refactoring, the landing zone may be modified or redeployed to allow for new cloud adoption needs.

Goal: The goal of the landing zone approach is to create a common set of consistent platform implementations. Those consistent implementations must be in place to ensure that your applications have access to requisite components when deployed. Each landing zone iteration must consequently be designed and deployed in accordance with the requirements of the cloud adoption plan and the subscription design strategy.

Principle purpose: The principle purpose of the landing zone is to ensure that when an application lands on Azure, the required “plumbing” is already in place.

One of the first landing zones that Microsoft introduced is the CAF Foundations. The goal of this is to deploy a core set of infrastructure resources and policy controls “required for your first production grade Azure application”. So lets explore what is in it.

Azure Security Center

Azure Security Center has become the centralized place to manage the security of your Azure environment. Generalizing a ton, you can do the following high-level activities in security center:

• Configure an appropriate security posture for your subscription (or organization)
• Report on compliance against that security posture
• Perform various service specific assessments against recommended best practices
• Enable advanced security features such as “threat protection”
• Apply these capabilities to services both inside and outside of Azure

You can read more about it here.

What’s Included?

When you run the blueprint, you get Azure Security Center setup in “standard” mode. Standard gives you access to a bunch of the cool features in security center, but it comes at a cost per connected service.

You also get a pre-defined configuration of Azure security center which configures a base set of audit options for the various configuration items inside of security center.

Azure Policy

Part of the suite of tools that assists with governance of your Azure assets, Azure Policy allows you to set rules for how you want your azure resources to be deployed. These rules can be enforced on deployment, or they can be set in audit mode for a detect and respond approach. Azure Policy is a good way to set corporate guidelines on what services should be in use and how those services should be configured. It provides necessary reporting for organizations to meet their compliance requirements.

You can read more about Azure Policy [here]((https://docs.microsoft.com/en-us/azure/governance/policy/overview).

What’s Included?

You get a couple of configured policies such as:

• Ensuring certain tags are applied to all resources
• Ensuring that only certain azure resources and locations can be used
• Auditing that network watcher must be turned on
• Ensuring certain settings on storage accounts
• Ensuring monitoring is done in Azure Security Center

While the policy engine can be flexed much more than what is provided as part of this blueprint it is an okay start to some of the basics required for proper Azure governance.

Azure Resource Groups

Azure resource groups are logical groupings of Azure resources. Typically, groups are created to host similar component types, components that make up a single application/function, or components that have similar lifecycle and security rules.

You can read more about Azure Resource groups here.

What’s Included?

The blueprint makes 4 resource groups for you.

• Shared Services
• Network
• Identity Services
• First Application

It is pretty typical in Azure deployments to break out shared or corporate components from those relating to specific applications.

Azure Key Vault

Azure key vault is how Microsoft recommends companies deal with secrets in the Azure environment. You can read more about it here. Many services that offer encryption by default tie in to Azure Key Vault so that customers can manage the encryption keys as per their own policies. Further, Azure Key Vault is an effective IT admin tool for storing secret materials and controlling/auditing access.

What’s Included?

As part of the blueprint, you get a single deployed Azure Key Vault in the Shared Services resource group. Interestingly, the firewall is enabled but the default action is set to “Allow”. While this makes the key vault immediately usable, it doesn’t make use of network security controls to protect the key vault.

Azure Log Analytics

Azure Log Analytics is a core part of Azure monitor. It provides a centralized location for log storage and retention. Further, it allows for additional capability around querying logs, and build reports/dashboards/alerts as required by your organization. You can read more here.

What’s Included?

You get a singled deployed workspace configured for log retention along with a diagnostics storage account. You are basically set up to start centralizing your logs from any deployed Azure component.

Blueprint Review

Personally, I find the blueprint too basic. While it covers some foundational components, there is a bunch missing to make this enterprise ready. Some thoughts/notes:

• Resource groups are missing role assignments

Ideally the blueprint instructions would come with details on creating appropriate Azure Active Directory groups to delegate roles to from an administrative perspective.

• Incomplete network firewall implementations

While Microsoft is taking the stance that identity is the new boundary, many regulatory frameworks have not caught up with this guidance. It is still important to implement firewall rules (wherever possible) and restrict network access. I would have created a VNET as part of this deployment, employed service endpoints, prompted the user for their external IP addresses, and configured the firewalls on key vaults, storage accounts, etc.

• Expanded Azure Policy implementation

While some Azure policy is in use, it is mostly tied to Azure Security Center. I would expand the policy implementation to include best practices for deployed resources such as Key Vault and Log Analytics.

Most of the suggestions presented above are more advanced, and has a change of failure in both deployment and usage, if not implemented correctly. This could lead new users to a ton of confusion, so I can understand why Microsoft has chosen not to implement them.

Conclusion

In conclusion, this is a good “base framework” to look at and build upon. There are several other templates you can chose from, and you can find more information here. By providing lots of options, Azure allows companies to select blueprints that meet their compliance and complexity requirements.

 

About Shamir Charania

Share This Article

Comments