What is RBAC? Role-based access control explained

Role-based access control, or RBAC, is an approach for restricting access to digital resources based on a user’s role in an organization. For instance, under RBAC, a company’s accountant should be able to access corporate financial records but not the content management system used to update the company’s website, while those permissions would be reversed for that company’s web development team.

Just about every organization enforces some kind of access controls on its digital assets—indeed, every operating system in use today has access controls built in. Access controls generally grant specific permissions to (and impose restrictions on) individual users or groups that those users might belong to. What distinguishes the RBAC model from other forms of access control is that the users are grouped together based on the roles they play, and permissions are determined primarily by those roles, rather than being tailored for each individual user. In this article, you’ll learn how RBAC works, and see the advantages and disadvantages of this approach.

How RBAC works

RBAC is fundamentally based on what’s known as the principle of least privilege, which essentially says that any user should have access to the data and functionality they need and nothing else. This sounds reasonable in theory, but one of the central dilemmas when implementing access controls is how make that work in practice: how do you determine what users will need to do, and how do you apply permissions and restrictions to all your users in a way that doesn’t burden administrators?

RBAC solves these problems in way that’s based on what users do rather than who they are. Rather than establishing a bespoke set of permissions for each user, under RBAC there is a limited set of predefined roles within an organization, and every user fulfills one (or more) of those roles. A set of permissions is tailored for each role to meet its particular needs and is inherited by all the users who fulfill that role. If the permissions for a role need to be changed, those changes are similarly passed on to the users, which eases the system’s administration.

RBAC roles

Roles are, obviously, at the heart of role-based access control. But it’s important to keep in mind that the definition of roles is an administrative and conceptual exercise, not a technical one. As far as the underlying systems are concerned, each of these roles is just a group of users; it’s up to your organization to define what the logical division of roles is for your staff and who falls into each category, and this is one of the most important parts of the process of rolling out RBAC.

As such, roles could differ greatly from organization to organization. That said, most enterprises will establish roles based in one way or another on their own internal organizational structure. On its blog, security vendor UpGuard gives some examples of roles broken out in this way and the applications they would have permissions to access:

• Software engineering: GCP, AWS, and GitHub
• Marketing: HubSpot, Google Analytics, Facebook Ads, and Google Ads
• Finance: Xero and ADP
• Human resources: Lever and BambooHR

It’s also key to note that a user can be assigned to more than one role. For instance, there could be a base-level “employee” role that everyone in your organization is assigned to that grants permission to org-wide services like email and calendar apps, in addition to the more specialized roles that offer access to departmental data and applications. There might also be a “manager” role that provides certain users with greater access to some data within each department.

RBAC matrix

Once you’ve defined your roles, the next step in the planning process is to figure out what rights and restrictions apply to each of those roles. One way to game-plan that out is to use an RBAC matrix, which is a table in which roles form the rows and various objects or actions form the columns.

David W. Enstrom’s Unified Architecture Method has a couple of great examples of what an RBAC matrix might look like. The first is for a specific data object in your infrastructure. The rows represent some abstract roles that users might have within an organization, and the columns represent actions a user could potentially take on that protected object. If a role has the right to perform one of the actions, the cell where the column and row intersect is marked with an X.

As you can see, you can get quite granular in terms of what users with different roles are and are not allowed to do to different objects. The next table is perhaps a little less abstract. The rows are roles defined by job titles, while the columns are specific objects users with these roles might interact with. Each cell includes the letters from the CRUDE (create, read, update, delete, execute) actions from the first table that describe what each role can do to each object.

This gives you a sense of how RBAC can really help define the capabilities of individual users in practice. Upper-level sales employees can create new invoices, while lower-level ones can only read them. A specialized stock manager and the overall department manager can update product records, whereas mid-level employees can only read them.

Again, creating these matrices is an exercise that you’ll do independent of any technical implementation. The goal is to capture your organizational structure and data access needs, which your RBAC will end up making concrete.

RBAC best practices

If you want to take a deep dive into best practices for implementing RBAC, you might want to check out INCITS 359-2012, the RBAC standard as established by ANSI. For a shorter read, MorganFranklin consulting has a good list of best practices to consider as you start your journey. Some of their key tips include:

• Think of RBAC as an ongoing program, not a project. Don’t expect the initial set of roles and permissions you establish to be set in stone. You’ll need to modify them as you see how RBAC works in practice and as your organization grows and changes.
• Clean up bad data. It’s difficult to know what roles should have access to which data if your data structure itself is muddled. Clean data is a major ingredient of the recipe for a successful RBAC program implementation.
• Assign a role owner to represent each area from the business side. Who has the best “insider knowledge” about each department? You’ll want these people on the team that defines your organization’s roles.
• Make roles reusable. If only one person in the whole organization has a particular role, maybe that access shouldn’t be managed via RBAC. One of the biggest pitfalls in RBAC is “role explosion,” in which many increasingly granular roles are created to capture every nuance of different employees’ job descriptions. Going too far down this road brings you to place where you end up with unique roles for nearly every employee, which obviously eliminates many of RBAC’s benefits. You want to keep things as simple as possible to reduce the administrative burden on IT.

RBAC benefits and disadvantages

Hopefully at this point many of the benefits of RBAC are clear. The RBAC model provides a way for companies to apply the principle of least privilege, while reducing the administrative burden and potential for error that would come from tailoring permissions for every individual user. Restricting permissions in this way can prevent insider attacks and block accounts compromised by outside attackers from escalating privileges.

In addition, many security and data protection regulations specify what job roles within a company should and should not have access to sensitive data. A documented RBAC program can help organizations comply with these laws.

That said, RBAC is not a panacea. As you read the section above on RBAC matrices, you might’ve thought that putting them together sounded like a lot of work, and you’d be right. While RBAC can save a lot of ongoing administrative labor, it does require quite a bit of work to get it ramped up, which may not pay off in the long run, especially for smaller companies. Meanwhile, big companies with lots of separate departments may have a lot of different roles to establish, which means RBAC complexity can increase with headcount.

RBAC vs. ACL, ABAC, and IAM

With the disadvantages of RBAC in mind, you might want to contemplate a couple alternatives. One of the most common is access control lists, or ACL. If an RBAC mindset thinks about permissions from the perspective of the user and the roles they play, the ACL approach is from the perspective of the data or functionality that users will interact with. An ACL is simply a list for each data object that details who can perform what operations on that object. This is conceptually simpler and may involve less work than setting up RBAC if you don’t have that many data objects to deal with, but you can see how it wouldn’t scale to a large company.

Attribute-based access control (ABAC), meanwhile, is a paradigm that in some ways builds on RBAC. ABAC takes the emphasis off users and instead, as the name implies, focuses on attributes of all the elements in your system, combining them together into Boolean rulesets. For instance, under an ABAC paradigm, if a certain type of user takes a certain type of action on a certain type of object at a certain time of day, all of those attributes can be taken into consideration when it comes to determining if permission should be granted. Maybe anyone can read and update financial records during the workday, but only managers in the accounting department can do so after hours. ABAC is obviously more granular than RBAC, but also requires much more administrative support. 

There’s one more acronym you might hear when people talk about RBAC and similar paradigms: IAM, or identity and access management. However, RBAC and IAM don’t stand in opposition. IAM defines and manages the roles and access privileges of individual network entities to a variety of cloud and on-premises applications.

In other words, RBAC represents one way to implement IAM (and ABAC and ACLs represent other ways). That brings us to our final question: how, from a technical perspective, is RBAC implemented?

RBAC tools, solutions, and examples

The good news is that you don’t have to cook up an RBAC solution from scratch: you can use one of the many IAM offerings on the market to implement an RBAC solution for your business. There are a number of IAM suites out there—check out the list of top vendors from eSecurity Planet and Toolbox—and almost all of them allow you to establish RBAC for your users. Major cloud services like Amazon AWS and Microsoft Azure also offer RBAC capabilities.

If you want to get a look at an example of how this all plays out in practice, you can check out this sample use case from IAM vendor Auth0. That document walks you through an example of implementing RBAC with their platform, showing you how to customize it for your needs. Moving to RBAC can be a journey, but the rewards can be great.