RBAC vs ABAC: Access Control for Sensitive Data

Before the advent of the cloud, remote storage, and remote work, businesses managed data access by assigning a small set of security specialists and administrators to manage data governance, providing users and services with access to sensitive data on an “as needed” basis. 

However, with the increasing volume of data collection, the proliferation of sensitive data use cases, and the multitude of methods that users and services use to access sensitive data, new approaches to access control are needed. To adapt, companies have adopted automated or semi-automated solutions to the problem of managing data access. At the same time, the increasing frequency of data breaches has raised the stakes around data governance and forced companies to reconsider how they ensure the privacy and security of their most sensitive data.

The two most common approaches to access control are role based access control (RBAC) and attribute based access control (ABAC). First, we’ll review RBAC, then ABAC, and finally we’ll look at a new approach to access control that combines the best aspects of these two approaches.

How Does Role Based Access Control (RBAC) Work?

Widely viewed as the more straightforward of the two, RBAC relies on a predefined set of roles which permit, deny, or limit access to certain resources, such as data stores or specific data types (or datasets) within those data stores. These roles are typically configured with specific jobs in mind, for example one role might be set up for employees who are developers, another for customer support agents (CSAs), and yet another for third party services. 

Each of these roles can have sub-roles that further restrict data access to what a specific type of employee or service might need. When a new employee or service needs data access, they are added to an existing role, or an administrator might create a new role if their data access needs don’t match existing roles. 

The following shows a simplified example of access control using RBAC:

As you might imagine, the RBAC approach frontloads a lot of security work, requiring your security team to tweak roles, add new ones, and make other adjustments as needed instead of setting access controls individually for each employee and service. RBAC offers many advantages, but as your team and product offerings grow, your security experts will have to continually add new roles, and deprecate old ones. 

Unfortunately, using RBAC creates situations where security experts and administrators are burdened with managing hundreds of unique roles (or more). This is both burdensome to maintain and risks compromising the privacy of sensitive data if role permissions aren’t set correctly. It’s critical to avoid having data governance be onerous and error-prone, as this could lead to undetected gaps in access control for sensitive data. 

So, how does ABAC improve on what’s offered by RBAC?

How Does Attribute Based Access Control (ABAC) Work?

Rather than relying on predefined roles, ABAC uses a set of attributes to determine which users and services have access to certain types of data. ABAC offers improved granularity compared to RBAC, letting admins and security teams weigh every available attribute to determine whether or not a given access request should be approved.

ABAC lets you control access according to a wide range of user and service attributes, such as: where and when are they accessing the data from, what device or network are they using, the sensitivity of the requested data, the requestor’s stated use for this data, etc. Combinations of these attributes map to policies that govern access to sensitive data. This helps to provide security teams and administrators with an informed assessment of each type of data access request, but sometimes leaves them wishing they could also use roles to simplify data governance. 

The following shows a simplified example of access control using ABAC:

Even a simplified visualization of ABAC ends up being quite complex. Still, the ABAC approach is popular because it executes a “shift left” of some of what’s required to secure sensitive data, letting administrators and security teams take a very close look at data access needs before users and services start making data access requests. 

However, this upfront work can be a heavy lift for many security teams, as they will need to configure each individual attribute, a process which can slow down configuring access controls and delay data access for new users and services. Additionally, any mistakes made early in the process of configuring ABAC can lead to bigger issues later, requiring security teams and administrators to rework the attributes they’re using, and how they’re using them.

Both the RBAC and ABAC approaches to access control have distinct advantages and disadvantages, and how you implement them will depend on several factors, including company size, the sensitivity of the data you typically store and process, and so on. But many administrators and security teams wish there was a way to get the best aspects of both RBAC and ABAC, with less complexity and fewer headaches.

That’s why we designed Skyflow Data Privacy Vault to provide the advantages of both the RBAC and ABAC approaches to access control, while addressing the disadvantages of these approaches and making access control simpler and more intuitive. 

To meet these needs, Skyflow uses a different access control model: policy based access control (PBAC).

Policy Based Access Control (PBAC) with Skyflow

Skyflow uses a Policy Based Access Control (PBAC) model that lets you enforce fine-grained, event-driven, and condition-based policies to govern access to your vault. You can author policies and then attach them to one or more roles. You can then assign these roles to users (UI clients) or service accounts (API clients) to enforce granular data access control. 

This is easier to manage than an RBAC or ABAC approach, but harder to visualize without looking at the policy expression language that gives you intuitive control over the complexity of access control. But, here’s a high-level look at how you can manage access to sensitive data using Skyflow’s PBAC approach to data governance:

Skyflow’s approach to access control with PBAC is built using zero trust architecture, where the guiding principle is “never trust, always verify”. This means that each data access request is treated as unique and not trusted based on superficial factors like the username, whether they’re on the network, etc. Beyond using a zero trust approach, PBAC operates with more nuance than a simple binary approach in which a user or service either has data access, or they don’t. 

Because PBAC leverages Skyflow’s ability to mask or fully redact sensitive data when it’s viewed, you can grant differential access based on the policies you write. With this approach, you could let a customer view all of their own sensitive data, while restricting customer service agents (CSAs) to just the data that they need to help that customer. For more details on how this works, see Dynamic Access Control of Sensitive User Data.

One benefit of PBAC is that you get the easy manageability of roles in an RBAC system while preserving the granularity and dynamism of an ABAC system. But to truly understand the power of a PBAC approach to simplify and improve access control and data governance, you need to look at the policy expression language.

PBAC and Skyflow’s Policy Expression Language

All Skyflow PBAC policies are written using our intuitive and human-readable policy expression language that makes it easy for you to author, maintain, and review complex policies that give you fine-grained access control over sensitive data, including the ability to control masking and redaction of sensitive data. 

This granular level of control lets you enforce the principle of least privilege: that users and services should only have access to those sensitive data resources that are absolutely required to perform authorized activities. If you’re familiar with the EU’s GDPR, and similar data protection laws, you already know that this principle is one of GDPR’s key mandates.

To see how PBAC gives you more control over sensitive data, and strengthens data governance, consider how you would enforce the provision in Brazil’s LGPD (a law that’s similar to GDPR) that restricts access to the personal data of Brazilian residents to only those employees located in Brazil.

The following screenshot shows how to use the Skyflow policy expression language to honor this restriction by giving just those CSAs who are located in Brazil plaintext access to Brazilian customers’ names and email addresses. Additionally, this policy restricts CSAs in Brazil from viewing unredacted plaintext values of customer driver’s license numbers, and instead masks these values. 

Or consider another example, where you need to allow an email-based marketing tool to access only a subset of user information: the customer’s first name and their email address. Everything else in the customer record is redacted when viewed by this email marketing tool, so even if that tool is compromised, a malicious actor can’t use it to steal any customer data beyond these two data types (so customer dates of birth and SSNs remain protected). You could create a policy like the following to enforce these constraints with Skyflow’s policy expression language:

Note that this policy makes no mention of dates of birth or SSNs. That’s because any data that isn’t explicitly authorized as part of a PBAC policy is not available to users or services governed by that policy.

PBAC: The Best Aspects Of RBAC and ABAC

As you can see, Skyflow’s PBAC policies give you the nuance and granularity of ABAC, while grouping users and service accounts for administration the way you can with RBAC. And it gives you all of this control in the form of an intuitive and human-readable policy expression language that maps to the way people naturally express data access and data protection requirements. 

This means that PBAC policy expressions help to avoid the “lost in translation” problem where errors can occur when translating written requirements into access control syntax. And avoiding access control errors greatly reduces the potential risk of a data breach or falling out of compliance with laws and regulations like CPRA, GDPR, PCI DSS, and HIPAA. 

Final Thoughts

Governing access to sensitive data is critically important to any business, so it pays to give serious thought to your approach to data governance. 

To learn more about how Skyflow’s Governance Engine uses PBAC to manage access to sensitive data, see: Introducing the Skyflow Governance Engine.

And, if you’d like to learn more about Skyflow and how its governance engine combines the best features of RBAC and ABAC, give Skyflow a try.