RBAC (Role-Based Access Control) is a great model of access control for applications and data. The TL;DR of RBAC is that you create a role structure for your organization’s needs, with assigned permissions for the different roles, then assign users to roles. Such roles map to identity groups, enabling access control at scale.
As an example, if Laura is a marketing operations manager, she may have the role of “MarketingOps”, which allows her to access specific applications required to perform her role, as well as access multiple specific datasets (such as churn data, customer demographics, etc).
You can read more about RBAC in our dedicated guide, but in this post, I’d like to touch on the points where RBAC is no longer enough for data access. This is per my personal experience, as well as that of other data and security leaders.
What is RBAC?
RBAC is a permissions management system where access to data is granted based on the individual’s role within the organization. The purpose of which is to provide data security in a scalable way.
RBAC is a relatively quick and simple solution often used in concert with other data security measures to ensure that data is secured. It is generally considered a risk-neutral policy and should be implemented as a broad simple policy to decrease risk, secure sensitive data, and ensure that workers are only granted access to necessary data.
RBAC is typically used in large companies where access is assigned to hundreds and thousands of employees according to their job and responsibility definitions. In this case, RBAC is easy to implement. Smaller firms are also adopting RBAC because of its simplicity.
When is RBAC not enough?
RBAC is a means to an end. However, it stops making sense when applying RBAC (or at least applying it in a pure way) causes more harm than good which can happen in the following situations:
There are too many exceptions to the rule
The benefit of RBAC is its simplicity and the ability to grant access quickly and easily. In many cases it all sounds good that each team requires access to specific datasets. But when data analysts from the same team require access to different data this stops making sense.
Particularly when a large number of employees or teams require an exception a single role definition is no longer sufficient, resulting in a very complex role structure or in the worst case role explosion.
In these cases, particularly when there are a large number of employees and teams who require exceptions, it becomes a time-consuming and overwhelming burden on the data engineering team. Further, it eliminates the benefit of the quick and simple aspect of RBAC.
There is a need to be more granular too often
In many cases, you want to be more granular than a membership to a specific role. For example, you want to rely on other attributes, such as time of day, whether the user is in a specific network, is on shift, or allow different users with the same role differential privacy settings.
In these cases, the granularity necessary to ensure that the data is secure, and adjust access controls are burdensome and almost impossible to keep up with, so it may be easier to decouple the role from access and instead use a more sophisticated method of access control.
Data access is changing quickly
In many cases, data consumers require access to data for a specific task, and the overhead of allowing them access can be substantial (sometimes 3 or 4 teams are needed to “sign off” for such a data access change).
In such cases, users either don’t get access in time to provide value, or get too much access (increasing risk). So it may be more efficient and valuable to use an alternative approach to access control.
Is ABAC The Missing Piece To Make RBAC Work?
It could be that a combination of RBAC and ABAC (attribute-based access control) is optimal. Adding ABAC can be used to impose additional limits based on specified attributes.
It is important to note that while this hybrid approach can streamline the process resulting in cost and time savings, there could be some drawbacks.
The ABAC system is more complex which makes it more difficult to implement. There can be complicated attribute sets, making it more difficult to audit relative to defined attribute conditions.
A benefit is that ABAC can be automated; in a recent survey we found that 61% of respondents use manual processes and tools for data access so that this feature could provide significant savings for data teams. Further, it removes the burden of constantly updating complicated sophisticated roles with diverse permissions.
Adding ABAC to RBAC can help provide a scalable access model while being granular enough to decrease the risk involved from data exposure.
Just-In-Time: Managing Access With Rapid Access Changes
However, in many cases, ABAC alone is not enough. This usually occurs when data access changes have to be done rapidly, and users require temporary access to data.
Whenever there are a lot of data consumers who require a lot of data access changes (such as for organizations with a need to know or a need to share mindset), it makes sense to allow users to receive temporary access to data. This is either done by building an in-house data portal, or using data portals such as Satori’s data portal.
In many cases, having a pure RBAC model simply does not cut it for a “data democratized” organization with a large number of users accessing data, across different locations, requiring numerous exemptions, and complex access controls.