If you peek inside your Microsoft Azure environment, you’ll see two different kinds of roles – Azure roles and Azure AD roles. Lets see how Tailwind Traders matches these roles to maintain their “least privilege” security principle.
Understanding the Microsoft Azure environment
When Tailwind Traders creates their first Microsoft Azure account, they receive an environment (also known as a tenant or tenancy) which contains:
- One Azure Active Directory, with the user account for the owner of the environment.
- One subscription, which is the billing entity for the resources they will create. This could be a trial or free subscription, an offer subscription like the Azure benefit for Visual Studio, an organization’s Enterprise Agreement subscription or a Pay-as-you-go subscription with your nominated credit card.
From here, they will create other Azure users inside Azure Active Directory, as well as other types of identities such as service principals, and they’ll add their domain name to this directory. They might even use this directory to synchronize accounts from an existing on-premises Active Directory environment. And they’ll create Azure resources (virtual machines, storage and networking, functions, AI & machine learning applications etc.) inside their subscription.
They may also create other directories and other subscriptions, but for now we’ll keep it simple at just one of each.
Organizational decisions regarding roles and access
Tailwind Traders always works on a “least privilege” principle – that is, all users have the lowest access rights needed to do their jobs. If someone works in a Helpdesk, they should be able to check that Azure resources are functioning and healthy, to help them troubleshoot problem calls, but they shouldn’t be able to create new resources inside Azure. In addition, some people in the Helpdesk are allowed to reset user passwords. Mapping these job functions to access requirements may be something that Tailwind Traders has already completed for their existing non-Cloud systems, that needs extending into Microsoft Azure.
Exploring the roles and their functions
Azure roles
Starting with access to their Azure resources, Tailwind Traders reviews which of the built-in roles will give their Helpdesk staff the appropriate level of access. A role is made up of a name and a set of permissions. Each resource contains an Access Control (Identity and Access Management) blade which lists who (user or group, service principal or managed identity) has been assigned to which role for that resource. Resources can also inherit these role-based access control settings from their parent resource group, subscription, management group, Azure policy or blueprint.
The four fundamental roles are:
Owner – Full rights to change the resource and to change the access control to grant permissions to other users.
Contributor – Full rights to change the resource, but not able to change the access control.
Reader – Read-only access to the resource
User Access Administrator – No access to the resource except the ability to change the access control.
There’s also an extensive range of other, more detailed built-in roles that Tailwind Traders can use for specific resource types and work tasks. For example, the Virtual Machine Contributor can only manage Azure virtual machine resources and cannot change storage accounts. Tailwind Traders can also create their own custom roles.
For our Helpdesk scenario, Tailwind Traders will assign the Helpdesk Staff group to the Reader role.
For a full list of the built-in roles and their permissions, visit Azure built-in roles.
Learn more about custom roles.
Note: Role-based access control applies when someone tries to action a task against a resource using a method that hits the Azure Resource Manager. This does not apply to settings inside a virtual machine operating system or to application access.
Azure AD roles
Azure Active Directory has its own, unique set of roles, specific to identity and billing management. This means that Tailwind Traders can control who has permission to make changes to these tenant-wide components, without needed to grant them access to other Azure resources. There’s also a cross-over here with Microsoft 365, which uses Azure Active Directory as its Identity directory. These roles will be familiar to users of the Microsoft 365 Admin Center.
The Azure AD roles include:
Global administrator – the highest level of access, including the ability to grant administrator access to other users and to reset other administrator’s passwords.
User administrator – can create and manage users and groups, and can reset passwords for users, Helpdesk administrators and User administrators.
Helpdesk administrator – can change the password for users who don’t have an administrator role and they can invalidate refresh tokens, which forces users to sign back in again.
Billing Administrator – can make purchases and manage subscriptions.
For Tailwind Traders, the built-in Helpdesk administrator role is perfect. An advantage of using a built-in role is that it is maintained by Microsoft – if a detailed permission has a name change, for example, Microsoft will update all the built-in roles that have it listed, to match. In addition, users can have both Azure roles and Azure AD roles, giving them access to user administration and to Azure resources.
For a full list of Azure AD built-in roles visit Azure AD roles or learn how to create and assign a custom role in Azure Active Directory.
What about temporary elevated access?
Late one night, the helpdesk gets a call that a system is unavailable. On checking, there are some monitoring alerts that point to an Azure virtual machine that is currently stopped. A quick phone call to the sleepy Level 3 support tech and “try starting it” is the suggested approach. It would be great if the Helpdesk person could start the VM but that would require access that’s greater than their current Reader role, but only for the time needed to try starting this virtual machine.
This is possible, if Tailwind Traders uses a feature of Azure AD Privileged Identity Management (or PIM) known as Just in time administrator access (JIT). Learn about the license requirements to use Azure AD Privileged Identity Management. This process looks like:
- Determine which roles will be protected by PIM
- Assign users to those roles as "eligible" users
- The user can then activate the role and either provide Multi Factor Authentication, request manual approval or enter a business reason for the activation.
- The user is then granted the role assignment and its associated permissions for a pre-configured time period.
In this case, Tailwind Traders could protect the Virtual Machine Contributor role with PIM, enabling on-call Helpdesk staff to elevate their access so they can start the Virtual Machine. This needs to be configured in advanced, but can be activated when required by the Helpdesk staff entering a business reason to justify it (which could include an internal support ticket number, for example). Or, Tailwind Traders could create a custom role with a subset of the Virtual Machine Contributor permissions (for example, Microsoft.Compute/virtualMachines/start/action) and protect that role with PIM, further refining what the Helpdesk staff would have access to do in their elevated role.
To learn more about Privileged Identity Management, visit Examine Privileged Identity Management.
Summary:
Regardless of how your organization is structured, take a look at Azure roles, Azure AD roles and Privileged Identity Management to remove widespread, high levels of access to your cloud resources and identities.
Learn more:
Classic subscription administrator roles, Azure roles and Azure AD roles
What is Azure role-based access control?
Overview of role-based access control in Azure Active Directory
Administrator roles by admin task in Azure Active Directory