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.

Identity and Access Lifecycles

For our usecase, we are interested in the Entitlement Management component of Identiy Governance, and specifically the Catalog and Access Package management functions.

Access Packages are objects that can be requested by users. These object contain resources such as Groups, Sites and Apps and have asssociated policies that govern the request process, access review process, assignments etc.
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.
Click here to learn more about Entitlement Management concepts

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.

Note that though there are equivalent access review settings available within PIM, PIM does not provide a request access process. Since the access review is configured in Identity Governance as part of the access package, you should not have overlapping or competing access review policies within PIM for these roles. Otherwise the role may get removed from the AAD group, this can make it seem like the Access Package is broken though the issue is within PIM.

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.