Apr 10, 2020

Enterprise Governance in Azure Part 3: Identity & Access in Azure

Adrian Romo
Bryan Sakowski
Brittany Wadsworth
Jim Jimenez

Adrian Romo, Bryan Sakowski, Brittany Wadsworth, and Jim Jimenez

Default image background

This is the third of a five-part series focused on enterprise governance in Microsoft Azure.

In part one, we discussed the four levels of management in the Azure Enterprise Portal: the Enterprise Agreement, departments, accounts, and subscriptions. In part two, we talked about the guiding principles behind dividing resources into resource groups and/or subscriptions as well as cloud cost management. This blog post will explore how Azure Active Directory, role-based access control, and privileged identity management (PIM) work together to enforce organizational standards for identity management within your Azure environment.

Azure AD and RBAC: Better Together

The goal of security-minded organizations should be to give employees the precise permissions they need to do their jobs. Excessive permissions expose your cloud environment to risk from without and within. However, too few permissions mean that employees can’t get their work done efficiently. Properly utilizing Azure Active Directory (AD) and role-based access control (RBAC) within the Azure hierarchy facilitates segregation of duties and least privilege.

Each Azure subscription is associated with a single Azure AD instance. Administrators can assign access rights using the Azure portal, Azure command line tools, and Azure management APIs to allow users and groups from that directory to manage resources in the Azure subscription. Leveraging Azure AD user accounts instead of Microsoft IDs is crucial because Microsoft IDs are privately owned by individuals and not managed by the organization. Therefore, they are not subject to password policies and cannot be quickly disabled in the event they are compromised.

If your organization uses traditional on-premises Active Directory, Azure AD allows you to synchronize your on-premises identities, using Azure AD Connect. It synchronizes on-premises Active Directory users, groups, and other objects into an Azure AD instance. This process opens the doors for centralized identity management, federation, and single sign-on, which reduces administrative overhead and improves the user experience.

It is important to understand how Azure AD fits into the Azure hierarchy. Each subscription in Azure trusts only one Azure Active Directory. However, within an Enterprise Agreement, multiple subscriptions can be associated with the same Azure Active Directory. This is important because it allows an organization to use a uniform set of users and groups across the enterprise. As you move down the hierarchy a resource group can belong to only one subscription, and each resource belongs to only one resource group. Administrators grant access by assigning the appropriate role to users and groups at a specified scope. The scope of a role assignment can be anywhere in this hierarchy: a subscription, a resource group, or a single resource. Bear in mind that access granted at a parent scope is inherited by its child scopes. For example, a user with access to a resource group can manage all the resources it contains, like websites, virtual machines, and subnets.

centered image
centered image

Figure 1. Azure AD functioning as a shared service

Leveraging RBAC empowers administrators to segregate duties within the organization and grant users only the amount of access they need to do their jobs. For example, RBAC can allow one employee to manage virtual machines in a subscription, while another can only manage SQL databases within the same subscription.

Azure RBAC comes in four fundamental flavors:

  1. Owner – Has full access to all resources including the right to delegate access to others.

  2. Contributor – Can create and manage all types of Azure resources but can’t grant access to others.

  3. Reader – Can view existing Azure resources.

  4. User Access Administrator – Can manage user access to Azure resources.

Each subscription has approximately 130 built-in roles with granular resource-based permissions. Some examples of these are network contributor, SQL DB contributor, and virtual machine contributor. It is recommended that these roles be utilized as much as possible, granting multiple roles to a specific duty/job role; however, if these roles do not meet your needs, custom roles can be created.

Highlighted Image

Figure 2. Applying RBAC roles

Basic Roles

The following roles are explanatory and are a small subset of the roles available in Azure. They should be customized to reflect the needs of the organization.

table, th, td { border: 2px solid black; border-collapse: collapse; padding: 6px; padding-left: 10px; color:black; font-size:12px; align:center }



Azure Roles

Cloud Operations Owner

This role is designed for the user(s) who is responsible for the Azure environment and overall cloud spend but does not interact with the day-to-day maintenance of the Azure workloads and resource.

  • Azure Reader

  • Cost Management Contributor

  • Security Reader

Subscription Admin

This role provides full access and the ability to modify all resources in the subscription and should be granted sparingly.

  • Owner applied at subscription level

Infrastructure Contributor

These roles provide the ability to manage IaaS workloads, DNS, storage accounts, and Azure Key Vault while having read-only access to all Azure and network resources.

  • Reader

  • Virtual Machine Contributor

  • DNS Zone Contributor

  • Storage Account Contributor

  • Key Vault Contributor

  • Network Reader

Network Contributor

These roles provide the ability to modify, add, or delete Azure network resources as well as read-only access to view the resources deployed in Azure. This role should also be granted permissions on the Palo Alto devices deployed in Azure.

  • Reader

  • Network Contributor

  • Classic Network Contributor

  • Traffic Manager Contributor

Security Contributor

These roles provide the ability to change settings in Azure Security Center, Azure Monitor, and log analytics.

  • Reader

  • Security Admin

  • Monitoring Contributor

  • Log Analytics Contributor

  • Application Insights Component Contributor

Database Contributor

These roles provide the ability to manage all types of SQL instances from the server to instance, and even at the database level. This role also has the ability to store SQL backup data onto an Azure storage account.

  • Storage Account Contributor

  • SQL Db Contributor

  • SQL Managed Instance Contributor

  • SQL Server Contributor

Financial Management

These roles allow for the viewing of Azure billing information and cost management mechanisms such as billing alerts and budgets; it is designed for financial teams who need insight into cloud spend but do not need to modify any billing or alerting information.

  • Billing Reader

  • Cost Management Reader

Custom RBAC Roles

Custom roles can be created when the built-in Azure roles are not sufficient or need to be combined to meet an organization’s needs. They are stored in Azure AD and can therefore be shared across all subscriptions within an Enterprise Agreement. Just like built-in roles, custom roles can be assigned to users, groups, and applications at the subscription, resource group, and resource level. Custom roles can be created using Azure PowerShell, the Azure command line interface (CLI), or via the REST API.

Privileged Identity Management (PIM)

Azure Active Directory privileged identity management (PIM) is a service that enables you to manage, control, and monitor access to important resources in your organization. PIM assists with managing the who, what, when, where, and why for access to resources. Utilizing PIM, you can provide just-in-time privileged access to Azure resources, build workflows for accessing privileged accounts, and enforce policies on administrator access. Workflows integrated with PIM can set time limits for administrator access, require approvals prior to access of these accounts, and enable notifications for when administrators are given access to a privileged account. Policies enforced on PIM can enforce Multi-Factor Authentication (MFA) to utilize the account or require a justification prior to access. All actions taken with PIM are audited and logged and can be used for internal or external audit purposes, to ensure users still need the roles they have access to request, and to conduct review of privileged accounts to report on metrics such as how often a certain role is needed, average length of use, purpose for use, etc.

PIM relies on a workflow approach for approvals and granting of access such as the one below:

Highlighted Image

Figure 3. Privileged identity management workflow

  1. An administrator requests access to something their job role has been pre-approved to access.

  2. An email is sent to the approver for this access to allow or deny the request.

  3. If approved, the administrator is granted access for the specified time.

  4. The administrator is able to complete their work with the necessary access.

  5. When the time limit expires, the administrator access is removed.

  6. Should the administrator need additional time, they can request an extension and the process restarts at step two.

Just-In-Time Access to Azure Virtual Machines

Just-In-Time (JIT) locks down inbound traffic to Azure virtual machines (VMs) by providing access to these VMs only when required and automatically removing access when not needed using a network security group (NSG). The NSG defines select ports to which inbound traffic will be locked down. By combining submitted requests and RBAC for the VM, Azure Security Center automatically configures the NSG and Azure firewall to allow inbound traffic over the specific ports and the amount of time that was specified. At the time of expiration, Security Center restores the NSG, blocking access without interrupting the connections currently established.

In summary, we recommend employing Azure Active Directory, role-based access control, and privileged identity management within the Azure hierarchy to enforce organizational standards across identity and access to all cloud resources and facilitate sound security practices such as segregation of duties and least privilege.

In part four of our series we will discuss Azure Policy, Azure Automation, Azure Blueprints, and Azure Security Center.

Want to Learn More?

Are you interested in exploring Microsoft Azure but concerned about governance and how to make public cloud fit within your IT model? Credera has extensive experience in cloud infrastructure design and implementation. If you have questions or would like to discuss cloud and infrastructure solutions, contact us at

Conversation Icon

Contact Us

Ready to achieve your vision? We're here to help.

We'd love to start a conversation. Fill out the form and we'll connect you with the right person.

Searching for a new career?

View job openings