Why Role-Based and Attribute-Based Access Controls Alone Aren't Enough

     

Businessman hand selecting different arrows as leadership concept.jpeg

Identity and Access Management (IAM) systems provide organizations with dynamic, wide-ranging methods for controlling access to their applications, systems, and proprietary resources. Role-Based and Attribute-Based Access Controls (RBAC and ABAC) are two of the most widely known and used methods.

RBAC and ABAC let organizations quickly define filters or rules that determine access based on a user’s roles or attributes, respectively, and both methods fill unique and important needs for granting access in many situations.

However, neither RBAC or ABAC is the complete, or even the most ideal solution in every case—particularly when it comes to exception or edge use cases.

FREE EBOOK: Just in Time Access, a More Secure Approach to Special-Case Access  Needs that Fall Outside of RBAC & ABAC Policies >>

RBAC and ABAC – What They Do & When They’re Needed

We’ve previously discussed RBAC and ABAC in-depth, but here’s a little refresher on the two access control methods.

RBAC controls access based on 1) the roles that users have within the system, and 2) rules stating what access is allowed for users in a given role. Most IAM solutions define a role as a local grouping of one or more users in the directory system that share common affiliations, such as the same department, physical location, or user type.

ABAC, by contrast, enables fine-grained access control, which allows for more input variables into an access control decision. Any available attribute in the directory can be used by itself or in combination with others to define the right filter for controlling resource access. ABAC can control access based on three different attribute types: user attributes, attributes associated with the application or system to be accessed, and current environmental conditions.

RBAC and ABAC are dynamic control tools for user access requirements on a large scale. For example, a new employee joining the IT department in a company’s Houston office would be assigned the “Houston office” role and the “IT” role, which grants them access to specific systems and applications when their account is first created. 

This role assignment and access is done dynamically, based on the RBAC and ABAC configurations set up in the company’s IAM system. And if the user should change office locations or move into a new role or department, the RBAC and ABAC controls would automatically update the roles and access accordingly.

The Exception to the Role

So, if RBAC and ABAC are such powerful tools, why does an organization need to use anything else? While it’s true that RBAC and ABAC cover the majority of a given user’s access needs, neither method is ideally suited for every use case.

All organizations have exception or edge use cases arise—more often than you might think—in which access to an application or system cannot be determined solely from the user’s standard attributes. This is especially true for smaller organizations that may not have as many formalized processes and large enterprises who tend to have a lot of unique business use cases.

 

In these situations, first instinct might be to create additional roles to manage these exceptions and edge use cases. However, this can quickly become an unmanageable situation in which new roles are created inside of existing roles. Such a complex role structure makes it difficult to support and identify role properties, and the task of keeping track of additional roles-within-roles for each user becomes a significant support effort for both IT and the individual business owners.

Consider a common scenario in which an IAM system is configured to grant employees access based on the departments to which they belong. If access is managed through predefined RBAC/ABAC dynamic filters, then users in the IT department are assigned an IT role and given access to IT department applications and systems.

Similarly, users in the Finance department are assigned a Finance role and granted access to business department systems and applications. However, neither would have routine access to the other department’s systems, because their positions do not require it.

But what if the IT director needed periodic access to a business system, such as when he or she is planning the department’s annual budget? The common access-granting solution calls for creating a new Finance role for the IT director using RBAC and ABAC static membership tools.

This process is usually not the most efficient, as it requires manual monitoring and management. It also calls for coordination between the requestor and access granter, typically including several out-of-band communications, before access is finally granted.

Managing RBAC and ABAC Edge Use Cases

For the majority of use cases, traditional RBAC and ABAC can be leveraged to dynamically assign roles and other access. However, no single access methodology can effectively manage every access use case across an organization.

The remaining use cases, encompass one-off exceptions or fringe cases that require special steps to grant access. While organizations commonly manage these situations by preemptively creating more roles for exceptions and edge use cases, this can quickly become overly complex and is not the most efficient, cost-effective, or secure way to address special-case access needs.

Download our new ebook, Just in Time Access (JIT): A More Secure Approach to Special-Case Access Needs that Fall Outside of RBAC & ABAC Policies to learn how a JIT access approach can improve access management for users, as well as administrative and support teams—with less dedicated administrative and maintenance time, automated deprovisioning, and more robust system security.

just-in-time-access

Comments

Subscribe Here!