Businesses adopt the public cloud for agility, scalability, and the “pay for what you use” cost model. This allows for an increase in revenue and savings while optimizing resource utilization.
Many clients of Microsoft public cloud services, like Office 365 (O365), get their initial Azure tenant created as part of an O365 deployment with little planning for the long term. Later, when they start to utilize Azure for services beyond Azure Active Directory for O365 authentication and access control, they have almost no guidance or resources for governance and delegation of administrative access.
With Azure management groups, policies, and role-based access control (RBAC), clients get a full suite of tools for governance and delegation of administrative access. These tools, together with Microsoft documentation and prescriptive guidance from partner organizations like Sirius, enable organizations to address the following concerns:
- Data sovereignty and other regulatory requirements
- Resource usage and cost accounting to support internal billing and charge-back processes
- Enforce organizational policies to provide guard rails for controlling resource deployment and administration
- Delegate administrative access through RBAC, with an audit trail for external verification
This blog introduces the core concepts of Azure tenant structure, and best practices related to governance and administration. Let’s start by getting our heads around the different ways Azure services can be purchased.
Purchasing options for Azure
Azure services can be purchased directly from Microsoft, or from a Microsoft partner.
- Purchase Azure directly from Microsoft
You will get the same Azure pricing whether you create an account through the Azure website or add Azure to a Microsoft Enterprise Agreement. When purchasing Azure directly, you have the following features and options:
- A monthly bill from Microsoft for the Azure services you consume
- The option to purchase a support plan for Azure from Microsoft
- The option to manage your Azure configuration and resource usage directly, or work with a Microsoft partner
There are two ways to pay for Azure services when purchased directly from Microsoft:
- Purchase a pay-as-you-go subscription through the Azure website
- Add Azure services to a new or existing Microsoft Enterprise Agreement (EA)
- Use Azure as part of a managed service from a Microsoft partner Microsoft Cloud Solution Provider (CSP) partners like Sirius offer a range of complete managed cloud solutions for Azure, and offer the following:
- A monthly bill from your CSP for the Azure services you consume
- The option to purchase a support plan for Azure from your CSP
- The option to work with your CSP for Azure configuration and resource usage management
Hierarchy of Enterprise Agreement based vs. Pay-As-You-Go based tenants
Microsoft Enterprise Agreement (EA) and pay-as-you-go tenants provide slightly different hierarchical options for organizing resources and delegating administrative access to those resources.
1) Enterprise Agreement hierarchy
2) Pay-as-you-go hierarchy
Enterprise Enrollment
The top level of the EA hierarchy is the Azure Enterprise Enrollment (AEE). Administration of the AEE is done using Azure Enterprise Portal, and initial login credentials for this portal are configured/provided when your EA is setup. Your login can be associated with multiple AEEs, and this portal can be used to assign an unlimited number of additional Enterprise Administrators.
Department
The second tier of EA hierarchy is the department. Departments allow for segmentation of an AEE, as well as the assignment of administrative roles for delegated administration. Departments are also managed using Azure Enterprise Portal. Using this portal, you can create additional departments, and assign administrative roles,
Account
While AEEs and departments act as containers and security boundaries, accounts represent actual individuals who will become Azure Account Administrators (AA) capable of creating and managing Azure subscriptions. For each Azure subscription an AA creates, they will be assigned as the Service Administrator (SA) for that subscription. Accounts can also be assigned as the AA and/or SA for existing Azure subscriptions. Accounts are created and managed using two different portals. The first portal is the Azure Enterprise Portal, used to define the accounts (in departments). Accounts can be either Microsoft accounts or work/school (organizational) accounts. This process can take up to a day to complete before you can use the account. Once complete, the user will receive an email notifying them of their assignment as an Azure Account Administrator. Note that when the new AA logs into the Azure Enterprise Portal for the first time, any existing Azure subscriptions they are an AA for, including Pay-As-You-Go subscriptions, will be transferred to the associated EA. This is difficult to undo, so consider having a user that will be assigned as an AA under an Enterprise Agreement log into the Azure Administration Portal beforehand, to see if there are existing subscriptions. Take appropriate action before making them an AA under the EA.
Subscription
Subscriptions, like AEEs and departments, act as containers and security boundaries but are primarily an entity for billing. Subscriptions can be created and managed in the Azure Account Portal, which can also be used to change the Service Administrator for a subscription.
Directory
Azure Active Directory (AAD) is a cloud-based identity and access management service that enables authentication and access control for resources in Microsoft Office 365, the Azure portal, Microsoft and third-party SaaS applications, apps on a corporate network, and cloud apps developed by your organization. Every Azure subscription has a trust relationship with an AAD instance to authenticate users, services, and devices. Multiple subscriptions can trust the same Azure AD directory, but each subscription can only trust a single directory. Each user will have a “home” directory for authentication but can also be guests in other directories. Users and groups defined in AAD can be granted RBAC assignments for access to resources in the associated Azure subscriptions. AAD directories can be created and managed in the Azure Administration Portal.
Resource group
Resource groups are containers that hold related Azure resources to be managed as a group. All resources in a group should share the same lifecycle and are deployed, updated and deleted together. A resource group can be used to scope access control for administrative actions through RBAC role assignments. Resource groups can be created and managed in the Azure Administration Portal.
Subscription tools
Both EA and pay-as-you-go Azure subscriptions provide tools like management groups, policies, and RBAC that allow clients to implement governance and delegate administrative access. Here is a breakdown of the capabilities and related recommended practices for each tool:
Management group
Management groups provide a level of scope above subscriptions, allowing you to organize subscriptions into containers and apply governance conditions and RBAC assignments to the management groups. Policies will inherit down to all subscriptions under that management group and will apply to all resources under those subscriptions.
Using management groups, you can create a hierarchy and apply policies. One example might be to create a policy that limits the creation of resources to the East US Azure Region and apply it to the dev/test management group. Management groups can also be used to assign administrative access to multiple subscriptions. With multiple subscriptions under a management group, a single RBAC assignment can be made on the management group, which will inherit to all the subscriptions below it. Each tenant/directory gets a single top-level management group called the “root” management group. Root management groups contain all other management groups and subscriptions in the hierarchy and allow for global policies and RBAC assignments to be applied at the directory level.
Recommended practices for management groups:
- All subscriptions and management groups within a hierarchy share a common directory
- A single directory can have up to 10,000 management groups
- Management group trees can support up to six levels below the root
- Each management group and subscription can have only one parent
- Each management group can have multiple children
- Management group activities are recorded in the Azure Activity Log
- An AAD Global Administrator will need to elevate their assignment to the User Access Administrator role of the root management group manually to be able to assign RBAC roles to other directory users or groups in order to manage the hierarchy
Policy
Azure policy allows administrators to create, assign and manage policies that enforce rules and perform automated actions on Azure resources to keep them compliant with corporate standards. One example would be a policy that controls the regions in which Azure resources can be created. When a new policy is applied, new and existing resources will be evaluated for compliance. Creating and implementing a policy is accomplished using a policy definition. Every policy definition has conditions under which it’s enforced, and a specific effect that takes place when those conditions are met. Some examples of built-in policies available by default are “allowed resource types,” “allowed locations,” and “apply tag and its default value.”
Recommended practices for policy:
- Start with an audit effect instead of a deny effect and track the impact of your policy definition on the resources to validate the configuration before implementing a deny, as a deny may break existing automation (like scripts)
- Leverage the organizational hierarchy when creating policy definitions and assignments, as policies inherit down the tree
- Use Azure audit logging to review the effects of applied policies
Role-based access control (RBAC)
Azure RBAC enables access to Azure resources and controls what can be done to them. The RBAC system is built on the Azure Resource Manager service and provides fine-grained access management for Azure resources.
Here are some examples of what an RBAC assignment allows:
- Assign a user to manage all virtual networks in a subscription
- Assign a user or group to manage all resources in a resource group
- Allow an application to access all resources in a resource group
- Assign a group of DBAs to manage SQL databases in a subscription
If a default RBAC role doesn’t meet the needs of your organization, you can create a custom role. Custom RBAC roles are stored in an AAD directory, can be shared across subscriptions, and can be assigned to users, groups, and service principals at subscription, resource group, and resource levels.
Recommended practices for RBAC:
- Grant only the amount of access to a role that users in that role need to perform their jobs
- Use groups instead of users whenever possible for making RBAC assignments
- Make RBAC assignments at the resource group level instead of on the individual resources
- Avoid making a custom RBAC role unless none of the default roles meets your needs
- Fully test custom RBAC roles before applying them to production to validate that users in the role can perform their jobs
Understanding the structure of an Azure tenant, and the tools provided by Microsoft to facilitate governance and delegation of administrative access, are the first steps to planning and implementing a secure and well-managed Azure estate.
Stay tuned for our next blog on this subject, where we will explore additional tools Azure provides for governance and administration, including privileged account management (PIM), multi-factor authentication (MFA), conditional access, and Azure audit logs, as well as additional recommended practices for these technologies.
Additional related blogs from Sirius:
The Azure Stack: A Primer for Putting Cloud in Your Data Center
Your Azure Cloud Questions Answered
Sirius is a Microsoft Gold Cloud Productivity and a Gold Cloud Platform Partner providing clients a full-service life cycle of cloud offerings from plan and design to operational transition, making us the ideal partner to guide you through your Azure cloud journey. Contact your local Sirius team and soar to the cloud with confidence!
