Standard enterprise governance guide

This governance guide follows the experiences of a fictional company through various stages of their governance maturity. The guide is based on real customer experiences, and the suggested best practices are based on the constraints and needs of the fictional company.

Best practices overview

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.

Important

This MVP is a baseline starting point built on a set of assumptions. Even this minimal set of best practices is based on corporate policies driven by unique business risks and risk tolerances. Read the longer narrative that follows this article to check whether this set of assumptions apply to your situation.

Governance best practices

These best practices serve as a foundation for your organization to quickly and consistently add governance guardrails across your subscriptions.

Resource organization

The following diagram contains the governance MVP hierarchy for resource organization.

Diagram of resource organization.

Deploy every application in the appropriate area of your management group, subscription, and resource group hierarchy. During deployment planning, your cloud governance team needs to create the necessary nodes in this hierarchy to empower your cloud adoption teams.

  • Create one management group for each type of environment (such as production, development, and test).

  • Create two subscriptions: one for production workloads and one for nonproduction workloads.

  • Apply consistent nomenclature at each level of your grouping hierarchy.

  • Consider content lifecycle when you deploy resource groups: things that are developed together, managed together, and retire together go together. For more information on resource group best practices, see the resource consistency decision guide.

  • Consider region selection so you can ensure that networking, monitoring, and auditing are in place for failover/failback and confirmation that needed SKUs are available in the preferred regions.

The following diagram provides an example of this pattern in use.

Resource organization example for a mid-market company.

These patterns provide room for growth without unnecessarily complicating your hierarchy.

Note

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:

  1. 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.
  2. Create a blueprint definition using these built-in and custom policy and the role assignments required by the governance MVP.
  3. 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:

  1. 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.
  2. 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 tag built-in definition.
  3. Require that the Application tag 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:

  1. In the root management group, create a blueprint definition named governance-baseline.
  2. Add the following blueprint artifacts to the blueprint definition:
    1. Policy assignments for the custom Azure Policy definitions defined at the management group root.
    2. Resource group definitions for any groups required in subscriptions created or governed by the Governance MVP.
    3. Standard role assignments required in subscriptions created or governed by the Governance MVP.
  3. Publish the blueprint definition.
  4. Assign the governance-baseline blueprint 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:

  1. Establish a cloud secure hybrid VNet.
    1. The VPN reference architecture establishes a pattern and deployment model for creating a VPN Gateway in Azure.
    2. 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.
    3. 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.
    4. 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.
  2. In the root management group, create a second blueprint definition named secure-hybrid-vnet.
    1. Add the Resource Manager template for the VPN Gateway as an artifact to the blueprint definition.
    2. Add the Resource Manager template for the virtual network as an artifact to the blueprint definition.
    3. Publish the blueprint definition.
  3. Assign the secure-hybrid-vnet blueprint definition to any subscriptions requiring on-premises connectivity. This definition should be assigned in addition to the governance-baseline blueprint definition.

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.

Note

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.

Iterative governance improvements

Once you deploy the MVP, you can incorporate additional layers of governance into the environment quickly. Here are some ways you can improve the MVP to meet specific business needs:

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 Resource Manager templates and Azure policies to establish a small baseline for identity and security.

Diagram showing an example of an incremental governance MVP.

Incremental improvement of governance practices

Over time, you can use this governance MVP to improve governance practices. As adoption advances, business risk grows. Various disciplines within the Cloud Adoption Framework governance model will continue to change to manage those risks. Articles later in this series discuss how incremental improvements to corporate policy affect a fictional company. These improvements are made across three disciplines:

  • Cost Management discipline, as you scale your adoption.
  • Security Baseline discipline, as you deploy protected data.
  • Resource Consistency discipline, as your IT operations begin supporting mission-critical workloads.

Diagram showing an example of incremental improvements to governance practices.

Next steps

Now that you're familiar with the governance MVP and have some idea of governance improvements to follow, review this article's supporting narrative for additional context.