Align business needs to cloud technologies — with Azure governance

When an enterprise makes the prudent choice to upgrade and transition all or part of its on-premises workloads to the cloud, the move involves more than just picking up new technologies. Cloud success is based in part on the ability to properly align business strategy with the technology that supports those requirements.

 A formal approach to governance helps make this alignment possible. Designing a practical governance process should be one of the first milestones on an Azure project, because those rules will form the “guardrails” that serve as tangible boundaries around design and deployment choices.

The importance of governance is even more pronounced if this is your first move to the cloud, as so many unknowns exist at that point. We often see individuals take off on their own and start making key choices based solely upon past on-premises experience — choices that hamper future cloud success.

Just as shifting technologies to the cloud requires a new mindset, transitioning on-premises governance to a cloud governance model mandates an updated way of aligning the business needs to new cloud processes. In this paper we will visit some of the key governance points to consider when making this move to Azure.

By following a formal governance process, companies can make measurable progress toward their goals in their move to the cloud. Below, we list governance items in a recommended order based on common experiences in real-world deployments.

To understand the approach, it will help you to refer to the Microsoft Azure Scaffold Governance Model (Figure 1). This diagram shows the key foundation (subscriptions), pillars (policies and auditing, along with naming standards) and Azure features that form an environment with governance at its forefront. This ensures a secure, consistent and manageable Azure environment for deploying services in accordance with company governance.

Azure subscriptions and management groups

Nothing can be done in Azure without a subscription, as that is the way to get access to Azure services. In the Microsoft Azure Scaffold Governance Model, the foundation is a well-defined enrollment and subscription hierarchy model. Architecting the correct hierarchical subscription model that properly defines the relationship between consumers of Azure and their use of Azure is critical. This is the first step in the governance process because it lays a solid foundation of billing responsibilities, access control and proper service limits. 

Subscriptions are allocated by the enterprise agreement (EA) administrator. Some of the most popular ways of granting subscriptions are based on geography, business units and functional units. For example, a subscription can be given to development, quality assurance (QA)/test, preproduction and production. You could break it out by the North America business unit and the South America business unit or by marketing, research, sales, support, etc.

Microsoft has more information on subscription management.

The use of Azure management groups is a relatively new way to efficiently manage your Azure policies, control access and, most importantly, implement Azure governance requirements consistently across all subscriptions contained in a specific Azure management group. These management groups live logically above the subscription level and can contain more than one subscription. By applying governance controls to the management group, any constraints incorporated into the management group are inherited automatically by its contained subscriptions. This forces the application of consistent governance conditions across all subscriptions contained in that management group.

Role-based access control (RBAC) using only built-in roles (no custom roles at this point) is supported for all role definitions and resource access housed in a management group. That means if you assign a specific built-in role to a management group, it will flow downward and be active in any resource that it applies to within that group. For example, if you used the standard RBAC role Azure Service Bus Data Owner, any Azure Service Bus resources in that management group would contain that role. We will discuss RBAC more in a moment .

Microsoft has more information on Azure management groups.

Azure policies

While Azure management groups help to ensure consistency across subscriptions, Azure policies are a similar guardrail for the lower resource level. In the Microsoft Azure Scaffold Governance Model, this is one of the key pillars that applies to all the Azure services necessary for good governance.

To have a strong governance model, it is important to enforce rules that ensure your resources stay compliant with corporate policies. Used properly, Azure policies set rules to ensure the resources you allocate and use maintain compliance with your corporate requirements. Policies are one of the best recent additions to Azure in support of a consistent governance model. 

Like RBAC’s built-in roles, there are standard Azure policy definitions available by default for many Azure entities, although you can also create custom policy definitions. These standard definitions include allowed or prohibited resource types, required or default tagging values, stock-keeping units (SKUs) for storage accounts, virtual machines (VMs), etc. You can apply policy scopes in an inheritance model to an Azure subscription or a management group, or to an Azure resource group or to specific resources in a resource group. 

Policies are enforced upon policy assignment or policy update to a specific policy scope. Similar policies (for instance, those relating to identity and access management) can be further grouped into what are called policy initiatives to simplify policy management. 

Upon assignment, all resources within that policy scope are checked for compliance. If a resource is found to be noncompliant, it will be flagged on the compliance page under that policy in the Azure portal. New resources are simply not allocated if they are found to be noncompliant. Or you can set it up with a “deployIfNotExist” effect type, using a managed identity to handle the resource deployment if it is found not to exist. 

You can use many types of policies to ensure good governance conditions for everything from cost to types of resources allocated.

Good policy usage helps to manage geo-compliance, cost, types of resources and tagging. Here are just a few of the many standard policies from which you can choose:

• Require that tags be applied to resources when created. If none are provided, you can provide a default value 
• Restrict where resources can be deployed to a specific list of Azure locations (e.g., U.S. East or U.S. West) 
• Prevent different types of SKUs when provisioning an Azure VM, to save cost
• Require a network security group (NSG) on every subnet

Microsoft has more information on Azure policies.

Auditing

Auditing is one of the less exciting governance concepts, but one of the most critical when it comes to saving money. Logs play a key role in auditing. You can create an Azure Log Analytics (LA) workspace along with a linked Azure Automation account under that workspace. Azure LA is an Operations Management Suite (OMS) service where you can collect and analyze resource log data. Many Azure entities, such as Azure Monitor and VMs, log data into an LA workspace. 

Naming standards

Azure provides its own naming standard to enforce consistent naming across Azure resources. These can be a starting point for your organization when blended with your on-premises naming requirements. On Azure tagging, discussed below, it is a bit of an effort (and one prone to errors) to have to change resource names after deployment, especially around scripting and automation. A good naming convention can make searching for resources, and future script writing, much simpler. Using standard prefixes and suffixes to clearly identify the use of the resource is a common practice. 

Microsoft has more information on Microsoft-recommended Azure naming conventions.

Tagging 

Azure gives you the ability to associate multiple Name=Value “tagging” pairs with a resource. You can use Azure policies to enforce use of tagging (along with default values) when a resource is provisioned, or create a policy that automatically creates tags during deployment instead of manually applying tags. 

It is much better to do tagging when a resource is provisioned rather than to apply a tag or change it later. As with naming standards, this can break scripts and automation if the changed named is not fully replicated across your entire Azure environment.

Microsoft has more information on resource tagging.

Azure blueprints 

Whereas Azure management groups are a very nice piece of Azure governance around subscriptions and resource groups, Azure blueprints bump that encapsulation up one level. Azure entities such as Resource Groups and Resource Manager template file, role and policy assignments, can all be encapsulated and reused in an Azure blueprint. You can then apply a blueprint to your Azure subscription or management group.

Using an Azure blueprint saves time and reduces the chance of errors while increasing consistency of governance during deployments. A blueprint is a package or container for composing focus-specific sets of standards, patterns and requirements related to the implementation of Azure cloud services, security and design. 

Blueprints can be reused to maintain consistency and compliance. When blueprints are used, well-governed subscriptions are created quickly that comply with the organization’s best practices and governance regulations. You can specify Azure Resource Manager templates in a blueprint to govern setup of the environment.

You can easily create your cloud governance templates, access controls and policies as a single compliant package so environments are ready to be configured. Deploy blueprints to multiple subscriptions with a single click. Manage blueprints from a central location and track blueprint versions to push updates.

Microsoft has more information on Azure blueprints.

Role-based access control 

Azure policies allow you to manage the types and properties of resources, such as SKU or location. Role-based access control (RBAC) dictates which users can take which actions on those specific resources. One of the standard RBAC roles is that of Resource Policy Contributor, which includes most of the Azure policy actions.

RBAC allows you to break up security and limit secure access to individuals (via their roles) to control fine-grained access of Azure resources. RBAC can integrate with roles you have defined in your Azure Active Directory. This also allows you to grant minimal access to users or groups to perform their duties.

Note that RBAC roles can also be applied to an application to give it access to the resources (in a resource group) that it needs to access. Azure provides built-in roles to manage access for most common needs; however, you can also create custom roles.

Microsoft has more information on Azure RBAC.

Resource groups 

Resource groups (RGs) are logical containers around related resources. For example, you can group resources by life cycle, with all the resources in a product environment within one RG, and all those in a preproduction environment within another RG. That way you can manage their lifetime, security and usage, as well as better track their cost, broken down by each environment. Or you can group resources by workload; for example, all the accounting applications deployed to Azure. Either way, you can delete all the resources in an RG at one time simply by deleting the RG. 

Microsoft has more information on Azure resource groups.

Control with agility 

The conceptual diagram of Azure governance architecture shown in Figure 2 illustrates many of the governance elements we have just now discussed. We showed how concepts such as management groups and blueprints can encapsulate key governance concepts, such as resource groups and policies, to ensure consistent deployment across subscriptions. RBAC allows you to control who can do what to certain resources. Resource groups join resources from common logical entities, such as life cycle or workload. Tagging can be used to help with cost tracking and searching for resources. Using a common naming standard is just as important in that search/tracking process. 

In summary: Both the correct usage and application of these various governance entities are necessary to provide proper Azure governance in an agile environment.

About the author

Michael T. McKeown is senior Azure cloud solutions architect for DXC Technology.

Contact us to learn more about DXC Azure Services.