Governance guide for complex enterprises
Overview of best practices
This governance guide follows the experiences of a fictional company through various stages of governance maturity. It's based on real customer experiences. The suggested best practices are based on the constraints and needs of the fictional company.
As a quick starting point, this overview defines a minimum viable product (MVP) for governance based on best practices. It also provides links to some governance improvements that add further best practices as new business or technical risks emerge.
This MVP is a baseline starting point, based on a set of assumptions. Even this minimal set of best practices is based on corporate policies that are driven by unique business risks and risk tolerances. To see whether these assumptions apply to you, read the longer narrative that follows this article.
Governance best practices
These best practices serve as a foundation for an organization to quickly and consistently add governance guardrails across multiple Azure subscriptions.
The following diagram shows the governance MVP hierarchy for organizing resources.
Every application should be deployed in the proper area of the management group, subscription, and resource group hierarchy. During deployment planning, the cloud governance team will create the necessary nodes in the hierarchy to empower the cloud adoption teams.
Define a management group for each business unit with a detailed hierarchy that reflects geography first, then environment type (for example, production or nonproduction environments).
Create a production subscription and a nonproduction subscription for each unique combination of discrete business unit or geography. Creating multiple subscriptions requires careful consideration. For more information, see the subscription decision guide.
Apply consistent nomenclature at each level of this grouping hierarchy.
Resource groups should be deployed in a manner that considers its contents lifecycle. Resources that are developed together, managed together, and retired together belong in the same resource group. For more information about best practices for using resource groups, see the resource consistency decision guide.
Region selection is incredibly important and must be considered so that networking, monitoring, auditing can be in place for failover/failback as well as confirmation that needed SKUs are available in the preferred regions.
These patterns provide room for growth without making the hierarchy needlessly complicated.
In the event of changes to your business requirements, Azure management groups allow you to easily reorganize your management hierarchy and subscription group assignments. However, keep in mind that policy and role assignments applied to a management group are inherited by all subscriptions underneath that group in the hierarchy. If you plan to reassign subscriptions between management groups, make sure that you are aware of any policy and role assignment changes that may result. See the Azure management groups documentation for more information.
Governance of resources
A set of global policies and RBAC roles will provide a baseline level of governance enforcement. To meet the cloud governance team's policy requirements, implementing the governance MVP requires completing the following tasks:
- Identify the Azure Policy definitions needed to enforce business requirements. This might include using built-in definitions and creating new custom definitions. To keep up with the pace of newly released built-in definitions, there's an atom feed of all the commits for built-in policies, which you can use for an RSS feed. Alternatively, you can check AzAdvertizer.
- Create a blueprint definition using these built-in and custom policy and the role assignments required by the governance MVP.
- Apply policies and configuration globally by assigning the blueprint definition to all subscriptions.
Identify policy definitions
Azure provides several built-in policies and role definitions that you can assign to any management group, subscription, or resource group. Many common governance requirements can be handled using built-in definitions. However, it's likely that you will also need to create custom policy definitions to handle your specific requirements.
Custom policy definitions are saved to either a management group or a subscription and are inherited through the management group hierarchy. If a policy definition's save location is a management group, that policy definition is available to assign to any of that group's child management groups or subscriptions.
Since the policies required to support the governance MVP are meant to apply to all current subscriptions, the following business requirements will be implemented using a combination of built-in definitions and custom definitions created in the root management group:
- Restrict the list of available role assignments to a set of built-in Azure roles authorized by your cloud governance team. This requires a custom policy definition.
- Require the following tags on all resources: Department/Billing Unit, Geography, Data Classification, Criticality, SLA, Environment, Application Archetype, Application, and Application Owner. This can be handled using the
Require specified tagbuilt-in definition.
- Require that the
Applicationtag for resources should match the name of the relevant resource group. This can be handled using the "Require tag and its value" built-in definition.
For information on defining custom policies see the Azure Policy documentation. For guidance and examples of custom policies, consult the Azure Policy samples site and the associated GitHub repository.
Assign Azure Policy and RBAC roles using Azure Blueprints
Azure policies can be assigned at the resource group, subscription, and management group level, and can be included in Azure Blueprints definitions. Although the policy requirements defined in this governance MVP apply to all current subscriptions, it's very likely that future deployments will require exceptions or alternative policies. As a result, assigning policy using management groups, with all child subscriptions inheriting these assignments, may not be flexible enough to support these scenarios.
Azure Blueprints allows consistent assignment of policy and roles, application of Resource Manager templates, and deployment of resource groups across multiple subscriptions. Like policy definitions, blueprint definitions are saved to management groups or subscriptions. The policy definitions are available through inheritance to any children in the management group hierarchy.
The cloud governance team has decided that enforcement of required Azure Policy and RBAC assignments across subscriptions will be implemented through Azure Blueprints and associated artifacts:
- In the root management group, create a blueprint definition named
- Add the following blueprint artifacts to the blueprint definition:
- Policy assignments for the custom Azure Policy definitions defined at the management group root.
- Resource group definitions for any groups required in subscriptions created or governed by the Governance MVP.
- Standard role assignments required in subscriptions created or governed by the Governance MVP.
- Publish the blueprint definition.
- Assign the
governance-baselineblueprint definition to all subscriptions.
See the Azure Blueprints documentation for more information on creating and using blueprint definitions.
Secure hybrid VNet
Specific subscriptions often require some level of access to on-premises resources. This is common in migration scenarios or dev scenarios where dependent resources reside in the on-premises datacenter.
Until trust in the cloud environment is fully established it's important to tightly control and monitor any allowed communication between the on-premises environment and cloud workloads, and that the on-premises network is secured against potential unauthorized access from cloud-based resources. To support these scenarios, the governance MVP adds the following best practices:
- Establish a cloud secure hybrid VNet.
- The VPN reference architecture establishes a pattern and deployment model for creating a VPN Gateway in Azure.
- Validate that on-premises security and traffic management mechanisms treat connected cloud networks as untrusted. Resources and services hosted in the cloud should only have access to authorized on-premises services.
- Validate that the local edge device in the on-premises datacenter is compatible with Azure VPN Gateway requirements and is configured to access the public internet.
- Note that VPN tunnels should not be considered production ready circuits for anything but the most simple workloads. Anything beyond a few simple workloads requiring on-premises connectivity should use Azure ExpressRoute.
- In the root management group, create a second blueprint definition named
- Add the Resource Manager template for the VPN Gateway as an artifact to the blueprint definition.
- Add the Resource Manager template for the virtual network as an artifact to the blueprint definition.
- Publish the blueprint definition.
- Assign the
secure-hybrid-vnetblueprint definition to any subscriptions requiring on-premises connectivity. This definition should be assigned in addition to the
One of the biggest concerns raised by IT security and traditional governance teams is the risk that early stage cloud adoption will compromise existing assets. The above approach allows cloud adoption teams to build and migrate hybrid solutions, with reduced risk to on-premises assets. As trust in the cloud environment increases, later evolutions may remove this temporary solution.
The above is a starting point to quickly create a baseline governance MVP. This is only the beginning of the governance journey. Further evolution will be needed as the company continues to adopt the cloud and takes on more risk in the following areas:
- Mission-critical workloads
- Protected data
- Cost management
- Multicloud scenarios
Moreover, the specific details of this MVP are based on the example journey of a fictional company, described in the articles that follow. We highly recommend becoming familiar with the other articles in this series before implementing this best practice.
Incremental governance improvements
Once this MVP has been deployed, additional layers of governance can be quickly incorporated into the environment. Here are some ways to improve the MVP to meet specific business needs:
- Security baseline for protected data
- Resource configurations for mission-critical applications
- Controls for cost management
- Controls for incremental multicloud improvement
What does this guidance provide?
In the MVP, practices and tools from the Deployment Acceleration discipline are established to quickly apply corporate policy. In particular, the MVP uses Azure Blueprints, Azure Policy, and Azure management groups to apply a few basic corporate policies, as defined in the narrative for this fictional company. Those corporate policies are applied using Azure Resource Manager templates and Azure policies to establish a small baseline for identity and security.
Incremental improvements to governance practices
Over time, this governance MVP will be used to incrementally improve governance practices. As adoption advances, business risk grows. Various disciplines within the Cloud Adoption Framework governance model will adapt to manage those risks. Later articles in this series discuss the changes in corporate policy affecting the fictional company. These changes happen across four disciplines:
- The Identity Baseline discipline, as migration dependencies change in the narrative.
- The Cost Management discipline, as adoption scales.
- The Security Baseline discipline, as protected data is deployed.
- The Resource Consistency discipline, as IT operations begins supporting mission-critical workloads.
Now that you're familiar with the governance MVP and the forthcoming governance changes, read the supporting narrative for additional context.