As was previously discussed Roles are collections of permissions, while Groups are collections of users. So, we use Roles to grant access to Cloud resources and Services. While managing the membership of Azure resources through Group membership, and direct management of Azure AD Roles to individual users.
We will be focusing solely on the management and protection around Cloud based Roles. So to start, let’s review the segments of the Cloud, and which roles manage which segment.
Let’s identify what it means to protect and manage these roles. If any of the following happens, we would need to know:
- Someone is added to a role
- Someone is removed from a role
- When a someone in a role makes a change
For each of these actions we need the following information:
- Who authorized it
- Who did it
- Why was it done
Every company has their own audit and compliance requirements, this information is the boiled down aspects which it is important to identify the tools used to facilitate at least the basics.
The key component or service to use for Role management is Privileged Identity Management (PIM). This is the blade that will allow the creation and management of the polices around all roles in Azure.
Privileged Identity Management (PIM) – Azure AD Roles
Privileged Identity Management (PIM) is the service that Azure uses to manage the policies around Roles and is where an administrator would go to request activation for an elevated rights role. The previous posts in this series boil down to using this blade to implement the developed policies.
These are two types of Roles which can be managed from this segment on the PIM blade. To start we will look at the Azure AD roles.
Under the Azure AD Roles pane, all the roles associated with Azure AD (as well as Exchange and SharePoint) administration can have the users added to the role directly under Roles. This is whereas users are added, they can be identified as eligible or Permanent. It is recommended that except for a few administrators, all the members be added as eligible, which will require activation prior to allowing the account to have access.
While the actual policies are managed in the Settings Pane as Roles (see picture)
Within this, the Roles for Azure AD Administration can be protected by requiring the following before activating the role:
- Limit the maximum number of hours an account can have these rights.
- Notify the Global Administrators and Privileged Account Managers when the activation occurs
- Require an incident/request ticket to be entered at time of account activation
- Require Multi-Factor Authentication for activation.
This in turn will between making all role members eligible (except for a few for administrative coverage), any administrator that requires to make a change or do administrative work has a whole second set of approvals and a limited window of time to do this work. On top of e-mail notification and validation of why the work is needed to be done.
It is important to note that the alerts options are not for alerting on what the Administrator is doing, but rather are tracking the administrator roles, and comparing them to best practice standards such as if a role does not require MFA, of it there are any that are assigned outside of PIM. While not necessarily protecting access to the role itself, these do help ensure that the roles are being maintained.
Privileged Identity Management (PIM) – Azure Resources Roles
In addition to the Azure AD Roles, PIM also manages the Azure Resource roles. These are based on the Azure Resource Management (ARM) services to allow the management of them. In short, these are the Roles required to manage the Azure Resources as identified here:
Unlike Azure AD roles these can be associated with users or groups. Each role needs to be explicitly assigned to an azure resource and will also be inherited down to the resources within it.
Note* classic subscription admin roles are being phased out, all new deployments are through ARM
This is important to document out what the resource is that is to be managed. Granting someone full admin access over SQL databases at the Subscription level, will grant them admin access over all SQL databases in the entire subscription. Which in a shared services model can cause access beyond what is intended.
Resources are only visible when you have an active role assignment, and they are managed by PIM. Otherwise they will not be seen in the console. The roles for each resource are managed separately. This incudes custom Roles, which will need to be added to each resource that it supports. A custom role can be added to multiple resources, but the PIM management of the role will need to be handled uniquely for each resource, the same as the default roles.
To manage members, look under Roles for the specific role the member is to be added to. For each role, either Users or Groups can be added, so long as they exist in Azure AD. Once added to the role, the membership settings require the user to be assigned as either active (ready to go now) or eligible (able to request activation) and how long the assignment will last (default maximum of 3 months).
In order to configure the settings of a role, look at Role settings and select edit. Here are the options that can be configured on any role:
As can be seen, each role can be set to require approval, justification, and several other options. In conjunction with the Azure AD Roles these options will allow the secure management of elevated privileges within Azure. Again, as noted at the beginning of this series. This will help in securing the administrative roles throughout the Azure Cloud environment. The next step will be to secure the user base throughout the environment.