RBAC vs ABAC: Make the Right Call
Role-based access control (RBAC) and attribute-based access control (ABAC) are the two most popular ways to implement access control. Knowing what separates the two methods can help you choose what’s right for your organization.
RBAC grants or rejects access based on the requesting user’s role within a company. ABAC takes into account various pre-configured attributes or characteristics, which can be related to the user, and/or the environment, and/or the accessed resource.
But First – What’s Access Control?
Think of a company’s network and resources as a secure building. The only entry point is protected by a security guard, who verifies the identity of anyone and everyone entering the building. If someone fails to prove their identity, or if they don’t have the necessary rights to enter the building, they are sent away. In this analogy, the security guard is like an access control mechanism, which lays the foundation of a company’s security infrastructure.
It’s hard to overstate the need for access control. Every year data breaches cost companies millions of dollars, and a lot of these can be avoided by implementing better access control. In the following sections, let’s explore what RBAC and ABAC bring to the table and how they fare against each other.
What is Role-Based Access Control (RBAC)?
In an RBAC system, people are assigned privileges and permissions based on their “roles.” These roles are defined by an administrator who categorizes people based on their departments, responsibilities, seniority levels, and/or geographical locations.
For example, a chief technology officer may have exclusive access to all the company’s servers. A software engineer may only have access to a small subset of application servers. Remote employees may get assigned a special role, which only lets them access the server they are actively working on.
The levels of access may also differ based on roles. For example, a junior resource is only allowed to read information from a database; they can’t add or alter anything. However, a senior database developer has maximum privileges on all the databases.
The duration of access might also be different for different roles. E.g., a third-party contractor is assigned the outsider role, which grants them access to a server for x hours. On the other hand, an internal software developer may be allowed indefinite access to the same server.
It’s also possible for one user to be assigned multiple roles. For example, a software architect oversees different teams that are building different projects. They need access to all the files related to all these projects. To this end, the administrator assigns them multiple roles with each giving them access to files from a particular project.
Types of RBAC
The NIST model for role-based access control defines the following RBAC categories:
Flat RBAC: Each employee is assigned at least one role, but some can have more than one. If someone wants access to a new file/resource/server, they need to first obtain a new role.
Hierarchical RBAC: Roles are defined based on seniority levels. In addition to their own privileges, senior employees also possess those of their subordinates.
Constrained RBAC: This model introduces separation of duties (SOD). SOD spreads the authority of performing a task, across multiple users, reducing the risk of fraudulent and/or risky activities. E.g., if a developer wants to decommission a server, they need approval from not only their direct manager, but also the head of infrastructure. This gives the infrastructure head a change to deny risky and/or unnecessary requests.
Symmetric RBAC: All organizational roles are reviewed regularly. As a result of these reviews, privileges may get assigned or revoked, and roles may get added or removed.
What is Attribute-based Access Control (ABAC)?
In an ABAC environment, when a user logs in, the system grants or rejects access based on different attributes. These attributes can be related to the:
- User. In ABAC terms, the requesting user is also known as the subject. User attributes can include designation, usual responsibilities, security clearance, department, and/or seniority levels.
For example, let’s say Bob, a payroll analyst, tries to access the HR portal. The system checks their “department,” “designation,” and “responsibilities” attributes to determine that they should be allowed access. However, if Alice from the IT team tries to access the same portal, she won’t be allowed, because she doesn’t have the required attributes.
Accessed resource. This can include name and type of the resource (which can be a file, server, or application), its creator and owner, and level of sensitivity.
For example, Alice tries to access a shared file which contains the best practices for software development. Since the “sensitivity level” attribute for the file is low, Alice is allowed access to it, even though she doesn’t own it. However, if she tries to access a file from a project she doesn’t work on, the “file owner” and “sensitivity level” attributes will prevent her from doing so.
Action. What is the user trying to do with the resource? Relevant attributes can include “write,” “read,” “copy,” “delete,” “update,” or “all.” For example, if Alice only has the “read” attribute set in her profile, for a particular file, she will not be allowed to update the source code written in that file. However, someone with the “all” attribute set can do whatever they want.
Environment. Some of the considered attributes are time of day, the location of the user and the resource, the user device and the device hosting the file.
For example, Alice may be allowed to access a file in a “local” environment, but not when it’s hosted in a “client” environment.
RBAC vs. ABAC: Pros and Cons
RBAC PROS
RBAC CONS
Defining and implementing roles is much simpler and faster than assigning attributes to individuals. This is especially helpful for small-to-medium sized organizations.
To establish granular policies, administrators need to keep adding more roles. This can very easily lead to “role explosion,” which requires administrators to manage thousands of organizational roles.
Allows you to create access hierarchies, where managers automatically get all the permissions of their direct reports.
In the event of a role explosion, translating user requirements to roles can be a complicated task.
If role explosions can be avoided, costs associated with RBAC implementations are usually low.
ABAC PROS
ABAC CONS
Define a granular access control policy. Administrators have the luxury of choosing from a large set of attributes, which helps them formulate highly specific rules.
Can be hard to implement, especially in time-constrained situations.
No need to modify existing rules to accommodate new users. All administrators need to do is assign relevant attributes to the new joiners.
Recovering from a bad ABAC implementation can be difficult and time-consuming.
When revoking or adding permissions, it’s much easier to modify attributes than to change or define new roles.
Implementing ABAC often requires more time, resources, and expensive tooling, which add to the overall cost. However, a successful ABAC implementation can be a future-proof, financially viable investment.
When to use RBAC or ABAC?
Even though ABAC is widely considered an evolved form of RBAC, it’s not always the right choice. Depending on your company’s size, budget, and security needs, you may choose one over the other.
Choose ABAC if you:
Have the time, resources, and budget for a proper ABAC implementation.
Are in a large organization, which is constantly growing. ABAC enables scalability.
Have a workforce that is geographically distributed. ABAC can help you add attributes based on location and time-zone.
Want as granular and flexible an access control policy as possible.
Want to future-proof your access control policy. The world is evolving, and RBAC is slowly becoming a dated approach. ABAC gives you more control and flexibility over your security controls.
Choose RBAC if you:
Are in a small-to-medium sized organization.
Have well-defined groups within your organization, and applying wide, role-based policies makes sense.
Have limited time, resources, and/or budget to implement an access control policy.
Don’t have too many external contributors and don’t expect to onboard a lot of new people.