Role Explosion in Data Access

Role Explosion refers to a situation in which an organization is using RBAC (Role-Based Access Control) to allow access to resources, and, over time, the role structure becomes complex with the addition of many roles. This situation is intensified when some of these roles contain overlap, a lack of clear ownership, or complex hierarchical structures.

Role Explosion can occur anywhere in which access to resources is allocated using roles, such as applications, file shares, and network access.

Role Explosion is very common in data access, especially in organizations with large amounts of data users and large amounts of data to be leveraged by these users. This phenomenon is so common  for several reasons:

• It is difficult to authorize access to data. In many cases, understanding who owns each dataset, keeping track of which sensitive data is contained where, and knowing the approval flow for each data access request can be very challenging.
• There are many exceptions to the rules of data access. Mainly, these exceptions occur when someone with a specific role requires data for a different team or business unit.
• There is often a gap between the people authorizing access at the business level (data owners or data stewards) and the people who execute this task at the technical level (data engineers).

Although we discuss Role Explosion in data access in this article, many of the causes and remediations described can be applied to Role Explosion in other domains.

Here are some of the primary reasons we have seen Role Explosion manifest itself in organizations:

Unclear Role Strategies

In many cases, data engineers are the ones in charge of granting access to data at the technical level. Since there are many ways to architect roles, and, in many cases, there is no clear strategy for doing so, data engineers do what is right for each case individually. This may result in a “spaghetti roles structure” (borrowing the term from spaghetti code). 

Role Creep

Another reason is similar to “privilege creep,” in which users accumulate roles over time, and no one revokes these roles from the users, or revoking is done only partially. For example, Dr. Anna Lytics, who is a veteran of ACME Corp, may have several roles that were given to her from previous positions or projects she participated in – and the multitude of roles are unregulated.

Exceptions, Exceptions, & More Exceptions

In data access, there are always exceptions to the rules. For example, a user with a role of “data analyst” requires a dataset from a different business unit (e.g., Finance). That data analyst is a single person, but you do not want to give that user the role of finance, and you also do not want to provide access to the finance dataset for all data analysts.

We have seen it all in terms of exceptions, from roles specific to users (sometimes a role for each user which basically cancels out RBAC) to roles with obscure names created by data engineers who are no longer in the company which no one dares to change (shout out to you, role “BI_AUDIT_FIX_TEMP”).

If you haven’t guessed it by now, Role Explosion is not a good thing. Having a complex roles structure with possibly thousands of different roles can be harmful, and here’s why:

1. 1. It creates an ever-growing operational overhead. When you have an increasingly complex roles structure, it becomes more difficult to give users the access they actually require.
   2. It leaves more room for error. The more objects you have, the higher the chance that something will break. This can mean removing privileges from a role that has unintended consequences or giving the keys to sensitive data to a contractor who should not have access to that data.
   3. It may affect performance. Depending on the platform and its uses, it may cause an overhead for objects like secure views or when using entitlement tables for things like granular security.
   4. It creates a compliance overhead. Imagine, for example, having to describe the roles used in the system for an audit or having to map which ones have access to what sensitive data.
   5. The complexities can also pose security risks, as access control becomes less predictable.

Now that we have learned how a Role Explosion situation occurs and why we would rather avoid it. Let’s discuss some of the ways to eliminate (or reduce) Role Explosion.

Temporary Access to Data

Since one of the reasons for complexities with roles occurs when users require temporary access to data, implementing a process to handle temporary data access can reduce complexities.

This can be a clear process that is followed by data engineering, it can be automated by building in-house tools, or it can be applied by Satori (without changing anything in your databases or data warehouses).

Eliminate Cumbersome Authorization Processes

Many of the complexities which lead to a Role Explosion are because of the access granting process, in which you need to track business users, approve access, and translate the business approval into technical access control.

By enabling self-service access control where business users or security teams can manage access control requests, we can simplify this process as well as role management.

This can be done by building a self-service data portal, or by using a product like Satori. With Satori, you can have a data portal with all of the available datasets in it where users can request access and obtain it following an approval process (or Satori allows you to simply use use Slack).

Go Beyond Pure RBAC

RBAC, or Role-Based Access Control, is awesome. We make use of it ourselves, both in our internal access management at Satori and in our product. However, like many other technologic concepts, it can transform from a tool into a religion.

To remedy this reliance, some complexities can be solved by also applying ABAC, or Attribute-Based Access Control, on data access in some or all cases. This addition may make some new roles redundant and simplify the roles structure.

A few of the benefits of using Satori are a simplification of the data access processes and an elimination of Role Explosion. This improvement frees up data engineering teams to do actual data engineering and data users to actually use data.

This process is done, in part, by applying security policies in a separate layer than the data infrastructure itself and in part by simplifying self-service data access. 

The best way to learn how Satori can help eliminate Role Explosion and simplify data access is to schedule a demo with one of our experts.