Using Identity Governance to govern privileged roles
How to levelrage Identity Governance to provide a request access system for privileged roles
Azure Identity Governance
Rebranded as Microsoft Entra Identity Governance , this solution provides a powerful way to manage privilege access lifecycle management. This helps overcome one of the shortcomings of Azure PIM which was that it has no in-built mechanism to request a privileged role. It only provides a mechanism to manage the roles and offloads the task of self-service to other solutions like Id Governance. Before we get in to using Identity Governance, it is important to understand the three liefcycle management concepts as shown below. Self-service for each of these lifecycles leverages automation and reduces IT workload by enabling users to request for access to an assignment, receive the appropriate approvals, and get the approved assignment as well as automatically remove their assignment as per required business logic.
For our usecase, we are interested in the Entitlement Management component of Identiy Governance, and specifically the Catalog and Access Package management functions.
Catalogs are container for access packages and allow for delegated administration of the access packages. This way, you may separate administration of different groups of access packages and enable scoped deployment and visibility to different groups of users.
Creating a governance model for PIM roles
Our governance model for entitlement management of PIM roles will look something like this:
As shown, the Access Package will be requested by users who want to use privileged roles in PIM. A naming convetion for access packages as well as associated resource makes it easy for administration as well as enables users to search for and identify these in the MyAccess Portal . It is also a good idea to add the contained roles in the access package description along with the approver emails since the requester will not have a way to view this information when making the request.
Access Package Naming Convention
Since there are multiple types of access packages possible to cater for each type of role, a suggested naming convention is provided below.
| Type | Naming Convention | Examples | Resources |
|---|---|---|---|
| AAD Role Access Package | Starts with “AAD Role - Role Name” | AAD Role - Global Admin | AAD Group assigned with AAD Role |
| Azure Role Access Package | Starts with “AzureRBAC - scope name - Role Name” | AzureRBAC - DevSub - Owner AzureRBAC - DevSub ResGrp1 - Contributor |
AAD Group assigned with Azure Role |
| Job role Access Package | “Org Name - Job Role” | Security - SOC Analyst Tier 1 | Can contain AAD Groups, Teams, Sites etc |
Instructions to create access packages can be found here .
AzureAD Group Naming Convention
In general, a good rule to follow is to name the AAD Groups as per the role assigned to it. Indicating the usage of these groups in PIM or Identity Governance is also a good idea. Eg: “IdGov - AAD Role - Global Admin” indicates this group is used in Identity Governance, is assigned the AAD role called Global Admin.
Instructions to create role-assignable AAD Groups can be found here .
Access Package Policy configurations - Request access
With each Access Package, you can define multiple policies that define how the access package will be used. However, for our usecase, it is recommended to keep on policy per access package. Since the userbase that requires privileged roles shopuld be small, it is also a good idea to use a single-stage approval process where the functional owner can be the approver. Considering the usecase, a suggested policy config guideline is provided below. Common or optional settings have not been mentioned.
| Configuration setting | Suggested setting | Comment |
|---|---|---|
| Users in Scope | For users in your directory, All members (excluding guests) |
Ideally privilged roles should be handed to users within your AAD tenant only. Unless there are well defined groups, opening the request to all users makes administration easier with the control placed at the approver level. |
| Approval - Require approval | Yes for privileged roles | There may be low risk roles that you may wish to provide automated approval, but for privileged roles, approval should be provided by a functional owner |
| Approval - Require justification | Yes | Always good for audit |
| Stages | 1 | Keeps approval steps simple and easy to trace |
| Approver | Functional leader | Although the approval by manager may seem like a less burdensome option, it does not prrovide for good controls for privileged roles |
| Requestor infromation | As required. Eg: Ask about which team requester is part of | This makes it easier for the approver to review and make a request. It also helps ensure the requester understand that they are requesting the right role for their function |
Instructions to change the request settings in a policy can be found here .
Access Package Policy configurations - Lifecycle
These settings enable governance of the access package by triggering expiry and ensuring privileged access is not assigned permanently. These only help in case you are not planning to use the Access Review functionality. Otherwise, setting the lifecylce to never expire will enable the governance via access reviews. Using this setting together with access reviews can cause a situation where the access package is removed in spite of an approval during access review as these settings deal strictly with the lifecycle time of the assignment. Some suggested config settings are given below for usecases where access reviews are not done.
| Configuration setting | Suggested setting | Comment |
|---|---|---|
| Access expires | 60 days for highly privileged roles. 180 days for lesser roles. 365 days for low risk roles. Never in case Access Reviews are configured. |
These settings reduce administrative burden while enabling good governance practices. If the rules are too stringent, they will add to administrative overhead of restoring access when users forget to extend. Setting this to never expire ensures that the only way access is revoked automatically is via the access review process. |
| Users can request specific timeline | Yes | Especially useful for contractors on projects with end-dates |
| Users can request extension | Yes | Under advanced expiration settings. Can be used in lieu of access reviews, allow users to extend their access |
| Require approval for extension | Yes | In lieu of access review, this acts as approval for extension of access |
Access Package - Access Review configuration
The access review is the secret sauce of Identity Governance since it enables the automated review of accesses. We can leverage these settings to ensure the right users have access to the privileged roles assigned via access packages.
Some suggested config settings are given below
| Configuration setting | Suggested setting | Comment |
|---|---|---|
| Require access review | Yes | This is recommended for aautomated governance |
| Starting on | Ideally beginning of a quarter | Access reviews have a static start date, and do not provide a “rolling” review window depending on when the user was assigned access. Having the reviews start at the beggining of a quarter makes the process predicatable |
| Review frequenct | High risk roles - Quarterly Medium risk roles - Bi-annually Low risk roles - Annually |
If the review cycle is too stringent, it will add adminsitrative overhead to the reviewers and to the admins if a review is missed and access is removed |
| Reviewers | High and Medium risk roles - select functional leaders Low-risk roles - self review |
These settings can help reduce the burden of access reviews |
| If reviewers don’t respond | Take recommended action | Caution should be used with this setting as the system looks at login pattern of the user. It may be prone to remove access for accounts that seldom use high-risk roles, and keep access for users who login to the portal frequently but dont use their roles |
| Show reviewer decision helpers | Yes | This is a good feature to provide reviewers with some decision making points. |
Instructions to create the access review settings in a policy can be found here .
With these configurations, our request and review process will follow model belowAt a high level, creating the following flow using an Accesss Package would enable self-service for privileged roles.
Thus, using Identity Governance and Privileged Identity Manager, we can ensure role assignment can be goverend while provided users a self-service capability to request the roles, and also maintain audit logs for the entire flow. There is a special usecase for enabling the assignment and activation of multiple AzueAD roles using a single access package. This will be covered in a follow up blog post under the same category.