By Richard Hawes
There are numerous benefits to implementing an Identity Governance program, and one of the primary tools in the Identity Governance toolbox is User Access Certifications. User entitlement creep and sprawling, unnecessary privileges are a well-known area of cybersecurity risk, and like many little problems that compound over time, become larger and difficult to untangle by the time enterprises seek to address them. Identity Governance suites provide the tools to review and address these, like Access Certification, but making sure that all of your certifiers have the knowledge and the data required to make the proper decisions is another matter. Reviewers can become overwhelmed if the volume of entitlements they’re tasked with certifying is overly large, and this is made worse if the entitlement metadata is insufficiently descriptive. In the worst case scenario, your Access Certification becomes a box-checking exercise and the benefits of removing that attack surface from your environment are diminished.
One of the ways to make the most of your Identity Governance program is to develop a Role Based Access Control (RBAC) framework to go with it. This is especially true of the User Access Certification process. Certifying many individual entitlements can be impractical, especially for business users in management whose time is at a premium. Certifying Roles, however, can make this easier. Proper Role definition allows for a two-tier certification process that enables the responsible party to certify the Role itself (the accounts and entitlements that comprise it), and it allows the individuals certifying user access to do so at the Role level. They may not be familiar with every individual entitlement of the user, but they do know that user’s role and what access they require to perform their job. Like many things, achieving this state of affairs often requires overcoming some challenges. In this series, I plan to outline some of these challenges and how they can be overcome.
Defining and implementing an RBAC framework is one thing–how that model aligns with the entitlements that users actually have assigned is another. At go-live, many enterprises find that their carefully designed roles don’t perfectly match with many users’ existing access. Users may have most, but not all, of the entitlements needed to be dynamically assigned to a role, causing expected role assignments to fail. This means access certifications, which were supposed to be streamlined and role-based, may instead become a confusing mix of incomplete role assignments and scattered entitlements. Addressing this challenge early is critical to ensuring that your RBAC framework and accompanying certification process work as intended.
Nobody likes tedious, manual work—but when it comes to aligning your RBAC model with real-world access, there’s no shortcut. The success of your Identity Governance program depends on refining roles and updating user entitlements, all the while making sure you address actual business needs. Without this effort, enterprises risk an RBAC framework that looks good on paper but fails to deliver the coverage and efficiency they expect. Addressing this early ensures that role-based certifications function as intended, reducing certifier fatigue and making access decisions easier and more effective.
A critical first step is refining your roles iteratively. Start by validating your most critical business roles against your user’s real-world access patterns. What are the outliers? What is missing? Use this to refine your role definitions before you begin to enforce them in IGA. Role design usually starts from a sound concept of access needs for a given role, but it’s important to compare this with actual entitlement assignments and adjust accordingly. Organizations that take the time to do this work, always serving their business’ requirements, can fine-tune their roles to better reflect how access is truly used. Overly rigid or incomplete role definitions that exclude necessary (though perhaps inconvenient) variations can prevent users from being dynamically assigned, leading to misalignment and unexpected certification complexity. If you find yourself granting too much unnecessary access, does your role need to be split into sub-roles to cater to distinct variations of what was previously considered the same job?
Assuming it is not too late, efforts to do this baselining against reality before go-live can significantly reduce these issues. Identifying users who are close to qualifying for a role but are missing a few entitlements allows the organization to remediate the gaps proactively. This may mean granting missing entitlements to bring users into alignment where appropriate or revisiting role criteria to accommodate necessary deviations. By performing this analysis and cleanup in advance, enterprises can increase their initial RBAC coverage, making the transition to role-based certifications smoother and more effective.
“Perfect RBAC Alignment” is an aspirational goal, so be prepared to make accommodations for users who do not immediately fit into predefined roles. Maybe some won’t, and you don’t want to create a bespoke role for an individual. Ultimately, it’s a judgment call on how much to stretch your role definitions to reach however many users. Develop exception-handling strategies to track outliers. Temporary entitlements may be necessary as a stopgap measure, and they should be monitored carefully to avoid creating a parallel access structure that undermines RBAC. Governance policies should be implemented to monitor and phase out these outlier entitlements as role definitions mature. Organizations that proactively manage this transition can minimize drift over time and ensure that their role-based certification process continually moves in a positive direction.
