Role based access or RBAC, crested the identity wave a decade ago, only to crash ignominiously to the sand, in a very short time. The key reason for the failure was that people realized the idea was good, but it was no magic bullet; to be truly meaningful they had to define usable roles. Automation was minimal, most provisioning was ad hoc, based on phone calls, spreadsheets or in the simplest of cases a holler across cubicles. Trying to decipher consistent policies and roles for provisioning in such environments was challenging, with the probability of finding repeatable patterns too low to be viable.
Role based access has resurfaced now under the umbrella of a new acronym - IGA, or Identity Governance and Administration! The requirements around finding appropriate roles remains, but now the environment has changed and drivers for getting identity governance are far greater. In general:
Roles are no longer just an enabler for automated provisioning. Compliance mandates and industry regulations require organizations to report periodically on their identity and access controls and in the absence of policies that manage permissions via roles this can become an audit nightmare. So difficult or not, some level of role definition is a must.
Solution vendors have jumped on the governance bandwagon and offer functions and features that reduce (not remove) the complexity of role definition.
Typically, role definition includes two approaches. The top down approach where you use a combination of job titles, department, region or other attributes that help define responsibility and authority to identify what roles are to be assigned so users can do their jobs. And the bottom up approach where you look at identities and their current permissions, to identify possible patterns that can then be used to develop potential roles. The latter process is also called role mining.
Vendors like SailPoint have invested in AI based tools that do much of the heavy lifting when doing role mining. This takes away some of the burden that stymied role adoption in the past. For example, after crawling through all the users and permissions in a department X, the tool might find that all users have Permissions A, B and C. Therefore, it will suggest a possible role that contains Permissions A, B and C. This process merely offers up a list of potential roles, and it is still the job of reviewers such as application owners and IAM teams to refine and appropriately name these candidate roles. Such role combinations can then be aggregated into more business focused collections which can be mapped to roles identified through the top down approach. Remember the overall goal is to get a limited set of roles that users can intuitively request when requiring accesses to do their jobs.
Roles and role-based access models help organize identities and their accesses and this goes a long way when implementing governance controls such as annual certification of users’ access, segregation of duties policies and developing compliance reports. If role assignments are largely automated, then reviewers need to merely focus on exceptions rather than the entire user population they manage. It goes a long way in simplifying governance processes and we can all agree that complexity and lack of transparency have been key obstacles when it comes to the business adopting good security practices. Sounds like a winning proposition all around. But like all such propositions the devil is in the details and like I said at the start there is no magic bullet. It takes stakeholder vision and support, time from different resource teams, effort and planning, but then again which successful solution doesn’t?