Much like the data they were meant to protect, the earliest forms of data access control were relatively rudimentary. Models like mandatory access control (MAC) and discretionary access control (DAC) were effective for the information and practices of the 1960s and 1970s, targeted more at securing the data rather than sharing it.
As data use became more widespread and uses for this information varied, teams required a more effective way to determine access for a growing number of data users. Role-based access control, or RBAC, was the next step in the evolutionary process of access control. Adopted quickly and ingrained in a wide array of legacy tools and platforms over its 30+ years in practice, RBAC today is inescapable in the data space.
In this guide, we’ll cover the basics of role-based access control–from its origins, to its popularity and practice–and help you answer the question “Is RBAC right for me?”
What is Role-Based Access Control (RBAC)?
RBAC was first formalized in 1992 by researchers David Ferraiolo and Richard Kuhn of the National Institute of Standards and Technology (NIST). It provided data teams with a logical step beyond its predecessors, MAC and DAC, which were largely based on user discretion rather than administrative rules. As a non-discretionary model based on internal company structures, RBAC greatly reduced the risk and margin of error associated with these discretionary access controls, while facilitating smoother data sharing and collaboration.
Role-based access control (RBAC) permits or restricts system access based on a user’s role within their organization. Roles are created and controlled by system administrators, rather than the users themselves, and are assigned to each individual as they are added to the data ecosystem. Once these roles are determined and applied, policies are built using the role(s) as the basis for access permissions. This makes access control static and linear, since users are only able to access specific data if they are assigned a relevant role.
[Read More] RBAC vs. ABAC: Future-Proofing Access Control
Users can also be assigned multiple roles in an RBAC system. An administrator can decide, for example, that a user should be assigned both the roles of “analyst” and “finance team” based on their position within the organization. Each of these roles will be subject to its own unique policies, and access decisions will be determined in a predetermined hierarchical manner.
Data policy authoring with RBAC can be like writing code without using variables: you can repeatedly write the same block, while making slight changes tied to the relevant role. For example, if you wanted to restrict access to a specific U.S. state for each role in your organization, you would write 50 policies — one for each state — as well as maintain 50 roles for each policy. Ultimately, everything with RBAC must be predetermined.
Why is Role-Based Access Control Popular?
With over 30 years (and counting) of use in access management scenarios, RBAC is baked into many modern data practices. For instance, RBAC is present in some form in almost all modern and legacy databases. While data resources and practices have evolved, RBAC has been a go-to for handling how this information is secured and accessed.
Many open source access control frameworks, like Apache Ranger and Sentry, take a role-based approach to their access determinations. With RBAC built into their operations, these frameworks have been adopted and used in some capacity by many modern organizations.
The Pros and Cons of Role-Based Access Control
Over years of use for various purposes, the consistent strengths and weaknesses of role-based access control have come into focus.
Pros of RBAC
Popularity: As the current de facto choice across systems and industries, RBAC still remains a widely-adopted form of access control in contemporary data and information technology. Since it has been a popular approach for many years, RBAC remains in use in countless modern data stacks, even as it begins to lag behind.
Manageability: The RBAC model presents a very manageable, straightforward approach to access for small- or medium-sized organizations with relatively few data needs. Because roles are stable, shareable, and are added to the system from the start, new policies can be put in place relatively easily. Even if an employee were to change roles, only the role assigned to them in the system must be updated; no new policies must be created in this scenario.
Simplicity: RBAC also tends to benefit from its overall simplicity. Since roles and permissions are predetermined, new user access can be virtually automatic whenever required. Instead of requiring administrators to manually assign certain permissions to new employees, they only need to assign them the proper pre-established roles. Once this is done, the new user will have instant access to the data allowed to their assigned roles.
Cons of RBAC
Administrative Bottlenecks: Using RBAC, there is a single map of users and roles that must be kept consistent. This holds administrators solely responsible for user-role mapping changes, creating a bottleneck that delays when a role change can actually be made. Such delays translate to risk when users are assigned roles they no longer should be in, and can decrease productivity for users waiting for their new roles to kick in. These situations can occur even if there are no policy changes required.
Increased Complexity: Adding, modifying, and restructuring roles is a highly complex process with RBAC. This is because user-role mapping for more than a few roles is not an easily verifiable process. To confirm whether an individual actually has been granted appropriate access permissions, they need to log in and manually access the specified resource. An entire policy must be created just for that test to occur; no abstract, auditable validation of role membership is possible. To add to that complexity, policies need to also consider the order in which roles are evaluated; over time, this becomes a house of cards.
Role Explosion: Adding to the complexity of scaling RBAC, role explosion occurs when the number of roles increases exponentially as new ones are added to the system. This is an extremely frequent occurrence for organizations that are updating and evolving their data ecosystems. With more consumers needing to access more data, with different combinations of policies, unique roles and policies must be created for each and every new scenario. This makes it increasingly difficult for admins to understand which roles should have which permissions, and to translate actual user needs to specific role assignments.
Is Role-Based Access Control Right for Me?
As a whole, RBAC has become a standard for a reason: it provided data teams with a relatively simple and secure access control mechanism throughout the late 1990s and early 2000s. Especially when compared to its discretionary predecessors, RBAC was a shiny new option that was quickly adopted and widely implemented. More and more, however, it appears that this shine may be wearing off.
RBAC was practical for smaller organizations with limited user roles and manageable data initiatives. While this still holds, the number of organizations with static user roles and limited data-driven objectives is becoming quite uncommon. Contemporary organizations are fueled by their data, with needs that continue to grow almost daily. In this scenario, RBAC’s efficiency can quickly fall apart. The roles created and preassigned by administrators early on become outdated and burdensome to manage as an organization scales and builds out its various internal teams and data use cases.
For those using RBAC, however, this is no time to panic. Just as RBAC emerged as an evolution to surpass MAC and DAC, newer forms of access control have been introduced and proven by organizations that are pursuing scalable and efficient data operations. Becoming more widely-recognized in the early 2010s, attribute-based access control (ABAC) presents data teams with the next step in modern access control. Not only has the effectiveness and operationalization of ABAC been the subject of further in-depth research by the NIST, it was also recommended by the Federal CIO Council’s FICAM Roadmap and Implementation Plan v2.0 in December 2011. Ultimately, ABAC enables teams with dynamic, scalable policies that can grow alongside the pace of data-driven objectives.
To learn more about how RBAC and ABAC match up, check out the new GigaOm Report: The Advantage of ABAC Over RBAC.