When it comes to access control, role-based access control (RBAC) and attribute-based access control (ABAC) are the two most common systems deployed by organizations—how do you know which is right for you? RBAC authenticates users based on their role, while ABAC uses specific characteristics of the user, resource, and environment. Where RBAC is the simpler model that gives you broad protection across your entire organization, ABAC gives you more hands-on, dynamic control. Let’s dive into each of them—the pros, cons, and which one is right for you.
How RBAC Works
When a company decides to grant access based on roles, they’re limited in how granular their control can be. With this approach, the administrators creating access parameters are forced to make sweeping judgments around which departments need access to what. For example, if you gave a “regional manager” access to a folder with sales leads, every member of the management team would then have access to that file. But what if this file holds confidential information specific to a region on the East Coast? Unfortunately, every manager would still have access. Conversely, since RBAC bases its rules on roles that are most likely repeated across your organization, it makes it extremely easy to get resource access to large teams faster. Here are some different ways to model RBAC:
The Basic Model
Referred to often as a “flat” RBAC model, this approach limits the amount of nuance you can apply to your system. Every user is assigned a role with fixed permissions—so if a user doesn’t have access to something, an administrator would need to add a new role to the user in the system to gain access to that resource. For example, someone who manages a team of data analysts would need the role of “manager” and “data analyst” to access confidential data tables as well as payroll, offer letters, and so on.
The Scaling Model
Considering it still has the same constraints as all RBAC models, this approach cleverly adds intricacies to the roles that are already in the system. For example, if not all salespeople need access to the same things, then you’ll need different sales “roles” in your control system. A senior sales role would include all permissions given to a junior sales role, so they wouldn’t have to hold both roles at the same time. Since the senior role includes everything in the junior role and more, they could remove the junior role from their user profile.
The Verification Model
In this model, we introduce separation of duties (SoD)—a way of holding the team accountable when taking actions on files. If someone wants to make a change to something, they’ll need approval from one other person with that same access. Like a checks and balances system, a manager wouldn’t be able to give someone on their team a pay raise without someone from HR—with the same access—approving it. This protects your company from employees stepping outside the rules and making radical changes to privileged documents.
The Control Model
This model was designed to mitigate the problem with “role bloating”—where too many members in the organization have access to the same things. To avoid this problem, permissions for each role are reviewed regularly and can be revoked or reassigned as needed. Unlike the Scaling Model, users can change roles throughout the company without removing their previous roles—since their previous roles are constantly reassessed.
Advantages of an RBAC System
With RBAC, you’re sacrificing dynamic control for a system that handles issues a little more broadly—which takes a lot of the work off your plate. Here are some of the advantages:
When it comes to implementation, you’re always going to have an easier time launching an RBAC. Since the parameters within RBAC are simple and easy to define, the level of effort to get it up and running is minimal. ABAC is time and resource-intensive during the implementation stage. Administrators are stuck defining all the attributes, variables, and characteristics that don’t already exist in their organization’s infrastructure. When the rules are limited to “what’s your role,” there’s much less strategizing to be done before launch.
Another benefit to a RBAC is that you’re able to streamline your security maintenance. This means adding or editing existing roles quickly, onboarding team members faster, and taking general actions on your control system without worrying about downstream impact.
With an RBAC system, you can reduce costs by limiting access to certain files in your system. This ensures you’re preserving other resources by controlling how many users can access files that drain your bandwidth.
How ABAC Works
With the ABAC approach, you’re essentially breaking down a user—and the circumstances around their request—into attributes that define their access in your system. While the system considers the user’s tags when authorizing, it also considers attributes for the resource, the environment, and the action that user is trying to take. For example, if a customer support representative is trying to open and edit a contract, they might find that they can only read the file. The level of control in this system is high, but so is the effort.
Advantages of an ABAC System
With attribute-based control, every access decision runs through you—which means you have complete control over who gets access to what at any given time. With autonomy like that, there are plenty of advantages:
ABAC systems become most powerful when you’re in the process of scaling your business. Consider being stuck with RBAC when you’re trying to scale—your functionality would be limited to adding more “roles” to your system to ensure some level of control. With ABAC, you’ve already made the effort to establish your rules, so filtering different employees based on location, time, actions, and other factors becomes easier. Role-based access is great for small organizations—but the more you grow, the more complex your needs become. ABAC is your key to scaling securely.
This might sound counterintuitive based on its initial complexity, but once this system is implemented, permission updates are intuitive and streamlined. Since access permissions are updated automatically upon attribute changes to a user, you don’t have to think as strategically about how you’re going to grant permissions to single members of larger teams. Once an attribute changes in an ABAC system, so do the materials they can access.
While RBAC builds a foundational protection for your company’s data, an attribute-based model allows you to be more nuanced with your access. For example, if there’s a user that wants to access a confidential file after-hours from their personal phone, the ABAC control system would flag those two variables (time and device, that is).
Which System is Best for You?
It depends—where you’re at in your business, where you plan to go in the future, what kind of business you’re running, and several other factors. Here are some best practices when deciding:
Use RBAC as a Starting Point
When deciding which control system to implement, a good rule of thumb is to see if an RBAC system can support your organization as it stands. Since ABAC is essentially a more complex version of RBAC, testing the latter can save you valuable processing power and time. You want to crawl before you run, which means minimizing the number of filters your system considers when giving access. RBAC gives you an opportunity to start small before identifying additional layers of protection.
RBAC or ABAC: Why Not Both?
In some cases, you can use a combination of role-based and attribute-based control systems—where the RBAC system establishes your high-level security before fine tuning additional variables through an ABAC system. As an example, an organization might use RBAC to hide sensitive assets from large groups of employees, and ABAC to understand what action the user wants to take on those assets, from where, and when. It’s about using RBAC to create a foundation airtight protection on your files, and ABAC to drill down a layer into the behavior of the user—blending heavy protection with dynamic rules.
Question to Ask Yourself
Since there are clear pros and cons to each access control system, it’s best to consider your own personnel and infrastructure before making a decision. Here are some specific questions to ask yourself and what control systems they lend themselves to:
Is your organization big or small?
As we discussed earlier, a smaller company means fewer people, resources, and variables to consider when you’re thinking about access control. In this case, a RBAC system is perfectly suitable for protecting your assets. If you already have a large, complex organization, an ABAC control system is an inevitability.
Is your organization planning on scaling?
This might seem like a trick question, but it’s not. You can still start with an RBAC system in this case, but with an understanding that as you scale, you’ll be limited in how flexible your control will be. The more people and resources grow within your company, the more iterative and layered your roles become. Instead of adding new “roles” for every single person, you can develop your ABAC strategy to help you scale.
How sensitive is your organization’s data?
You might be at an organization that doesn’t deal with overly sensitive materials. Or maybe your large company’s infrastructure is fairly simple, with minimal layers of roles and duties. If this is the case, then there’s no reason to overcomplicate your security with attribute-based control. RBAC systems will still work in this scenario. But as soon as you need more details pertaining to a user’s access, ABAC is your ticket forward.
When it comes to protecting company data, we’ve never had more options than we do today. With an abundance of experience in identity security, SailPoint can help provide clarity around which access model is right for you. SailPoint Access Modeling uses AI technology to suggest roles based on similar access, offer you insights, and support the dynamic nature of changing identities. Learn more about how it works.
You might also be interested in:
Take control of your cloud platform.
Learn more about Access Modeling.