Why Don’t All Companies Apply Attribute-Based Access Control on Data Access?

Role-based access control (RBAC) is built for scale. However, when it is implemented in organizations where data and access requirements are changing rapidly, this results in complexities; and complexities can turn into inefficiencies, or even higher security risks and compliance challenges. To cope with some of the limitations and complexities, especially around granularity, many companies either apply or consider applying attribute-based access controls (ABAC).

In this article, we will cover some of the challenges companies face when they design and execute ABAC on data access projects.

In several data platforms, such as Snowflake and AWS Redshift, RBAC is available within the data platform itself. In Snowflake all access must go through roles, and in Redshift, you can optionally use roles, but both platforms support out-of-the-box role-based access control. This is true for other data platforms as well. In addition to being able to support the notion of roles, there is also broad support for integration with your identity management solution (such as AzureAD, Okta, and others).

While RBAC is a useful and quick solution for access control there are some limitations. Some of these limitations occur when there are too many exceptions to the access rules, you frequently require increased granularity, and data access is rapidly changing; you can read about these limitations here. When these occurrences persist, many companies turn to ABAC. However, implementing ABAC is not without its own set of obstacles.

After investigating the limitations associated with only having RBAC, you determine the best course of action is to either switch to an entirely ABAC solution or some combination of ABAC and RBAC.

When dealing with ABAC, in many cases the attributes through which you want to set access (allow, deny, or apply security policies such as data masking) are not internally available in the data platform.

To solve this issue you can import certain attributes from the identity provider to DB tables, or implement external functions. However, this solution is not straightforward and can lead to complexities (which in turn may lead to errors, delays, and risks).

If the organization has data scattered across several data stores, warehouses, and lakes, as many organizations do, the complexity of implementing ABAC increases. For example, each location may require different implementation approaches, introducing additional vagueness and complexity.

Adding requirements across different platforms is difficult, especially when the access controls are built with views and joined tables (necessary for knowing when to allow/disallow access). In order to maintain existing conditions and controls as well as adjust specific access attributes requires manual processes. These processes are not only time-consuming, but also complex and risky.

Sometimes it is challenging to maintain ABAC. One example is when a user connects from specific geolocations, to maintain ABAC is complicated due to the necessary application of data localization policies. To effectively implement ABAC, you first need to dynamically obtain the user’s IP address (when that’s possible), then join or send it to a function that returns the country code, only then can you enact the applicable policy.

There are two possible solutions for ABAC implementation that are scalable and effective. One is to build or buy a data access orchestration solution. This approach automates writing the attribute-based access control mechanisms in your data store. However, most of the complexities remain under the hood, and may be difficult to scale effectively.

The second option is to apply ABAC with a data-access proxy. Meaning that when users access data, the access control solution, which implements the security policies, identifies the necessary controls and applies them.

For example:

1. If the user is identified as coming from a specific network, then serve the data in clear-text, otherwise, mask all PII.
2. If the user is trying to access data during their defined working hours and from an approved IP address, serve them data that’s anonymized. However, if the worker tries to access data outside their defined working hours or from an unapproved IP address, block them.
3. When an analyst attempts to access the data using any tool other than their designated BI tool (i.e. Tableau, Looker, Periscope, Redash, etc), block access.

Attribute-based access control for data access offers significant benefits for organizations. However, in most cases ABAC is significantly more complex to implement than RBAC, especially when there are changing sets of requirements and access restrictions.

If you’d like to learn more about how Satori implements RBAC, ABAC and security policies universally on all your data stores, go here, or book a meeting with one of our experts.