Let’s be honest, roles are a useful construct. Assigning users to roles and groups is a standard practice for virtually every organization. Unfortunately, roles have been hyped and oversold as the only way to govern access. In fact, many practitioners I speak with–and even some industry analysts!–believe that role-based access controls (RBAC) are as state-of-the-art as it gets.
In an RBAC model, the role assigned to an individual implicitly grants them the predetermined levels of access based on that role. If I am assigned to an HR role, then I will be allowed to perform certain operations within HR applications. I will be denied access to Finance apps (unless I’m also assigned to that role).
Change, however, is constant:
- Turnover rates and business reorganization are high;
- Workforce fluidity–especially in these uncertain times–can necessitate abrupt changes to roles, structures, and behaviors;
- M&A and deal room activities necessitate groups with bounded access around who can access what information for how long;
- Temporary projects require add/remove requests to be processed within a short period of time; and
- The movement of data and workloads to the cloud–predominantly to support digital transformation efforts–creates complex and siloed permissioning processes.
The shortcomings of RBAC models become crystal clear in the face of such change:
- Organizations begin drowning in more roles than actual employees, creating new ones to handle every edge case, remote access scenario, or special project;
- The time to process and implement role changes can’t keep up with the pace of business;
- Contextual access of an increasingly mobile and remote workforce represents increased risk that is not well-managed; and
- National security, privacy, and intellectual property concerns arise from exposing sensitive information like security clearance or special project access in identity systems.
Additionally, the use of role-based IAM systems as a proxy for protecting data and resources–the value of your organisation–conflates authentication with authorization. Authentication is the verification of a subject’s identity; authorization, or access control, is the decision to allow or deny that subject access to data or resources. Let me offer a quick example for clarity. As a member of the HR group, I am granted the ability to authenticate into an HR application, but in today’s world of privacy regulations, I may no longer be authorized to view personal data for EU employees.
New sets of roles could be created to address GDPR–and I’ve spoken to a practitioner who basically created multiple instances of his HR app with geographically partitioned datasets and matching roles–but that created a mess for appdev, identity, and IT teams. “I simply can’t keep doing the same thing to handle CCPA, or whatever else comes next,” he lamented. He was looking for a more sustainable way to handle authorization, like what you can see illustrated in this short video.
Part 2/7 ABAC Blog Series: Policy is the New Perimeter