A Cloud Governance Model,
Providing governance for resources.
Cloud computing serviceS (e.g., Azure) is a versatile cloud platform. Customers can not only create and deploy their applications; they can also actively manage and govern their environments.
Clouds generally follow a pay-as-you-go paradigm, where a customer subscribes and can then deploy virtually anything to the cloud. It could be as small as a basic virtual machine, or it could be thousands of virtual machines with higher stock-keeping units (SKUs).
Cloud computing serviceS will not stop any customer from provisioning the resources they want to provision. Within an organization, there could be a large number of people with access to the organization's Azure subscription. There needs to be a governance model in place so that only necessary resources are provisioned by people who have the right to create them.
For managing and providing governance for resources, a Cloud computing service (e.g., Azure) provides resource management features, such as:
Azure management groups and subscriptions
Azure Role-Based Access Control (RBAC),
Azure Policy, and Blueprints
Resource locks,
Azure Resource
In Azure, the term resource refers to an entity managed by Azure
In Azure, the term resource refers to an entity managed by Azure. For example, virtual machines, virtual networks, and storage accounts are all referred to as Azure resources.
Azure resource group
A resource group is simply a logical construct that groups multiple resources together so they can be managed as a single entity.
Each resource in Azure must belong to a resource group. A resource group is simply a logical construct that groups multiple resources together so they can be managed as a single entity. For example, resources that share a similar lifecycle, such as the resources for an n-tier application may be created or deleted as a group..
Azure Resource Manager
Azure Resource Manager (ARM) is the deployment and management service for Azure.
Azure Resource Manager serves as an essential component of Azure deployment and provides a unified management layer regardless of the tool set used.
Whether we use the Azure Graph API (API REST Management), Azure CLI, Azure Powershell, or one of the many other methods for managing Azure resources, the commands all utilize Azure Resource Manager (ARM).
The following image shows the role Azure Resource Manager plays in handling Azure requests.
All capabilities that are available in the portal are also available through PowerShell, Azure CLI, REST APIs, and client SDKs.
Functionality initially released through APIs will be represented in the portal within 180 days of initial release.
Understanding the Resource Manager Hierarchy
The Azure Resource Manager model uses four levels, or “scopes.” The following diagram provides an example of each of these scopes.
We can apply management settings at any of these levels of scope. The level selected determines how widely the setting is applied.
Lower levels inherit settings from higher levels. For example, when a policy is applied to the subscription, the policy is also applied to all resource groups and resources in the subscription.
We can deploy templates to tenants, management groups, subscriptions, or resource groups.
Azure Blueprints
Easily create, deploy, and update compliant environments
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.
Streamline environment creation
Easily create 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.
Enable compliant development
Speed deployment of compliant applications to production through a self-service model, and easily deploy compliant environments matched to production standards. Use blank templates for custom blueprints or built-in blueprints for compliance with common internal scenarios and external regulations such as ISO 27001.
Lock foundational resources
Avoid unwanted changes and misconfigurations—even by subscription owners—that could affect multiple applications. With resource locking, you can limit access to key infrastructure that’s shared across subscriptions. Protect resources that the blueprint is governing and configure exceptions to match your specific needs.
Azure Resource Graph
Designed to extend Azure Resource Management by providing efficient and performant resource exploration
Azure Resource Graph is a service in Azure that is designed to extend Azure Resource Management by providing efficient and performant resource exploration
With the ability to query at scale across a given set of subscriptions so that you can effectively govern your environment. These queries provide the following features:
Ability to query resources with complex filtering, grouping, and sorting by resource properties.
Ability to iteratively explore resources based on governance requirements.
Ability to assess the impact of applying policies in a vast cloud environment.
Ability to detail changes made to resource properties.
Azure management groups
Management groups act as a placeholder for organizing subscriptions
Management groups act as a placeholder for organizing subscriptions. If we apply a policy, access control, and/or compliance at the management group level, it will be inherited by the underlying management groups and subscriptions.
From the subscription level, that policy or access will be inherited by resource groups and then finally by the resources.
Effective use of management groups
Among the multiple way’s management groups can be utilized, Azure Management Groups can mirror the billing hierarchy. Often enterprises begin utilizing management groups in this method.
However, the power of management groups is when we use them to model the organization. Azure Subscriptions can be grouped based on a need for common roles assigned along with Azure Policies and initiatives.
Organizing with management groups
Azure Management Groups provide a level of organization above Azure Subscriptions.
All subscription objects within a management group receives a copy of the role-based access control and policy settings applied to the management group.
Azure Subscriptions
Subscription refers to the logical entity that provides entitlement to deploy and consume Azure resources.
An Azure Subscription is :
A logical collection of Azure resources. Each asset in Azure is deployed to a single subscription.
A defined administrative security boundary that supports Role-Based Access Control.
A limiting factor to Azure scale (more on this below, see Subscription Limitations).
A deployment construct for the organization and consistency of Azure resources
Microsoft’s definition of a subscription is “an agreement with Microsoft to use one or more Microsoft cloud platforms or services, for which charges accrue based on either a per-user license fee or on cloud-based resource consumption.”
Usage and quotas
As mentioned in the previous section, capacity planning needs to be one of the first steps when we architect a solution. We need to verify whether the subscription has enough quota to accommodate the new resources we are architecting. If not, during the deployment, we may face issues.
Each subscription has a limited quota for each resource type. For example, there could be a maximum of 10 public IP addresses provisioned with an MSDN Microsoft account.
Similarly, all resources have a maximum default limit for each resource type. These resource type numbers for a subscription can be increased by contacting Azure Support or clicking on the Request Increase button in the Usage + Quota blade on the Subscription page.
Subscription design
In addition to Management Groups, subscriptions provide multiple layers to best organize Azure Resources to meet the needs of the enterprise. Ultimately, it is up to the business to determine how best to utilize Azure Subscriptions to organize Azure Resources.
Azure Role-Based Access Control (RBAC)
Azure provides authentication using Azure Active Directory for its resources. Once an identity has been authenticated, the resources the identity will be allowed to access should be decided.
This is known as authorization. Authorization evaluates the permissions that have been afforded to an identity. Anybody with access to an Azure subscription should be given just enough permissions so that their specific job can be performed, and nothing more.
Authorization is popularly also known as RBAC. RBAC in Azure refers to the assigning of permissions to identities within a scope. The scope could be a management group, a subscription, a resource group, or individual resources.
RBAC helps in the creation and assignment of different permissions to different identities. This helps in segregating duties within teams, rather than everyone having all permissions.
Security Principals: A security principal can be any one of the following; a user, a group, Service Principals, or a Managed Identity. Security Principals should be assigned privileges using Azure Active Directory Groups.
Role Definitions: A Role Definition, also referred to as a Role, is a collection of permissions. These permissions define the operations that can be performed by the Security Principals assigned to the Role Definition. This functionality is provided by Azure Resource Roles and Azure Active Directory Administrator Roles. Azure comes with a set of built-in roles (link) which can be augmented with custom roles.
Scope: The scope is the set of Azure resources that a Role Definition applies to. Azure Roles can be assigned to Azure Resources using Azure Management Groups.
Azure Policy
Azure Policy defines rules for resource creation.
For example, a resource policy can limit the SKU of a VM to a particular pre-appproved size.
Or, a resource policy can enforce the addition of a tag with a cost center when the request is made to create the resource.
Each policy can be built using multiple rules, and multiple policies can be applied within a scope. The scope could be a management group, a subscription, a resource group, or individual resources. Based on whether the rules are satisfied, policies can execute various actions.
Azure locks
Azure Locks are mechanisms for stopping certain activities on resources.
RBAC provides rights to users, groups, and applications within a certain scope. There are out-of-the-box RBAC roles, such as owner, contributor, and reader. With the contributor role, it is possible to delete or modify a resource.
How can such activities be prevented despite the user having a contributor role? Enter Azure locks.
Azure locks can help in two ways:
• They can lock resources such that they cannot be deleted, even if we have owner access.
• They can lock resources in such a way that they can neither be deleted nor have their configuration modified.
Locks are typically very helpful for resources in production environments that should not be modified or deleted accidentally.
Locks can be applied at the levels of subscription, resource group, management group, and individual resource. Locks can be inherited between subscriptions, resource groups, and resources.
Applying a lock at the parent level will ensure that those resources at the child level will also inherit it. Resources that are added later in the sub-scope also inherit the lock configuration by default. Applying a lock at the resource level will also prevent the deletion of the resource group containing the resource.
Azure Governance best practices related to Resource organization
This best practice serves as a foundation that an organization can use to quickly and consistently add governance guardrails across multiple Azure subscriptions.
Subscription Design Strategies
Microsoft recommend the following subscription design strategies to address the business priorities.
Workload Separation Strategy
As an organization adds new workloads to the cloud, different ownership of subscriptions or basic separation of responsibility may result in multiple subscriptions in both the production and nonproduction management groups.
While this approach does provide basic workload separation, it doesn't take significant advantage of the inheritance model to automatically apply policies across a subset of subscriptions.
The following diagram shows the governance hierarchy for organizing resources.
Microsoft recommends that we split production environments than those "DevTest", creating two tiers of management groups.
The management group root by default will have fundamental policies, such as those relating to security. On the remaining Management Groups are associated specific policies. The hierarchy of Management Groups provide a model for which the policies that are defined at higher levels in the hierarchy cannot be overwritten by lower levels.
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.
A management group for each type of environment (such as Production, Development, and Test).
A subscription for each "application categorization".
A separate resource group for each application.
Consistent nomenclature should be applied at each level of this grouping hierarchy.
Application Category Strategy
Each organization will categorize their applications differently, often separating subscriptions based on specific applications or services or along the lines of application archetypes.
This categorization is often designed to support workloads that are likely to consume most of the resource limits of a subscription, or separate mission-critical workloads to ensure they don't compete with other workloads under these limits.
Internal versus External services Separation Strategy
Another recommendation from Microsoft of using management groups to separate different services include:
Internal services versus external services: Enterprises often have different requirements, policies, and roles for internal services versus external customer-facing services.
Management Group & Subscription design strategy
Effective subscription design helps organizations establish a structure to organize and manage assets in Azure during cloud adoption.
Model the organization
Because every organization is different, Azure management groups are designed to be flexible. Modeling cloud estate to reflect organization's hierarchy helps us define and apply policies at higher levels of the hierarchy, and rely on inheritance to ensure that those policies are automatically applied to management groups lower in the hierarchy.
Although subscriptions can be moved between different management groups, it's helpful to design an initial management group hierarchy that reflects the anticipated organizational needs.
Azure Governance Model & Management Group
The following the diagram provides an Azure Governance Model & Management Group, it allow the “Azure COE” to organize the subscriptions and apply governance controls, such as Azure Policy and Role-Based Access Controls (RBAC), to the management groups.
All subscriptions within a management group automatically inherit the controls applied to the management group.
Subscription limitations
Azure has a large number of limitations per subscription, which are often referred to as “quotas”. Many (but not all) of the subscription limits can be raised by opening an online customer support request with Microsoft. Even so, all limits have a maximum value.
Once we reach a maximum value, the only way to overcome it is multiple subscriptions. Details on most of the limits can be found on Microsoft Documentation site Azure subscription and service limits, quotas, and constraints.
1. By creating a hierarchy like this “Azure COE” can apply a policy, for example, VM locations limited to Europe West Region on the group “Infrastructure Team management group” to enable internal compliance and security policies.
This policy will inherit onto both EA subscriptions under that management group and will apply to all VMs under those subscriptions. As this policy inherits from the management group to the subscriptions, this security policy cannot be altered by the resource or subscription owner allowing for improved governance.
2. By using management groups, “Azure COE” can reduce workload and reduce the risk of error by avoiding duplicate assignments. Instead of applying multiple assignments across numerous resources and subscriptions, we can apply the one assignment on the one management group that contains the target resources.
This will save time in the application of assignments, creates one point for maintenance, and allows for better controls on who can control the assignment.
3. Another scenario where “Azure COE” would use management groups is to provide user access to multiple subscriptions.
By moving multiple subscriptions under that management group, “Azure COE” have the ability to create one RBAC assignment on the management group which will inherit that access to all the subscriptions.
Without the need to script RBAC assignments over multiple subscriptions, one assignment on the management group can enable users to have access to everything they need.
Comentarios