RBAC or ABAC: Which is Better? Enforcing Risk-Adaptive Access Control in the Cloud

There’s a lot of noise out there! Some vendors will argue that their silver-bullet access control or other security features should be the core of your enterprise’s cloud data security strategy. As a data owner or architect who probably isn’t a security expert, it can be hard to separate signal from noise and figure out how to design security into your overall cloud data architecture without getting hoodwinked by their parochial view of the world. The typical enterprise has diverse datasets and workloads with varying sensitivity and associated risks, which is why TrustLogix has delivered a platform that offers a combination of capabilities and allows you to choose the optimal data security features for each use case.

Your data workloads are diverse, and so should be your approach to securing them.

Most of the major cloud data vendors such as Snowflake, Databricks, AWS and others now embrace a variety of data workloads running on their platforms. These include data applications, data science and machine learning, data sharing and collaboration, and, of course, traditional business intelligence has always been there. Indeed, this diversity is partly why you moved to the cloud: it is easier to implement new types of data projects and share data across them. And with innovations regularly being brought to market by these vendors, you will never be “done” with your cloud data journey.

Meanwhile, there are multiple methods of controlling data access. Role-based access controls (RBAC) grant access based on a user’s role, e.g. are they in sales, marketing, finance, and so forth. Attribute-based access controls (ABAC) grant access based on user attributes that can change over time, such as what region they are in, which customer or partner accounts they own, are they a company insider or not, etc. Attributes can be dynamic, such as looking them up in your HR system, so you can ensure access privileges are always current. Additionally, the data itself can be classified and tagged as sensitive, with access policies then applied based on their classification tags. Finally, these policies can be templatized based on corporate-wide standards or regulations such as GDPR.

Some vendors will claim one or the other is categorically better, either because of performance, or because of ease of managing them, or whatever the reason. The reality is each has pros and cons, depending on workload characteristics and user behaviors.

RBAC

RBAC is particularly well-suited for these use cases:

• Functional Security: Controlling which functional areas in a given application a given user will have access to. Example: In a purchase order management system, only managers can approve a PO request. The permission “Approve” is granted to the manager role, and all users belonging to that role will be able to perform that action.
• Manage Access to the Administrative Portions of an Application: Examples: In distributed computing systems like Snowflake, manage which users have access to operate and create warehouse, and monitor usage. You want to limit users with administrative permissions to set up databases and objects. In these cases, roles are the appropriate mechanism to grant access.
• Manage Object Level Grants: Examples:
  • Typically, a service account connecting to a data source requires various permissions (Insert, Update, Delete, Create, Alter) to Databases and the underlying objects like Tables, Views, Materialized Views, Functions, Procedures, etc.There is no requirement for conditional access. In these scenarios, it is recommended that a service account role be created and granted access to that role.
  • In data visualization tools like PowerBI, in which users can create and/or access workspaces, there will be workspaces or dashboards by subject matter area like revenue dashboards and sales opportunity dashboards. You may want to grant access to the revenue dashboard only to users in the finance department, and sales dashboards only to users in the sales department. You can define this by creating finance and sales roles and grant the necessary permissions to those roles.
• Chargeback Model in Modern Data Clouds: Example: large enterprises typically track costs and credit consumption back to the business unit that incurred it, based on actual usage. In this use case, it is easier to create a compute instance specific to a business unit and allow access to operate that instance only for the business unit-specific role. This role is then assigned to only users in that business unit.

Example of role-based object-level policy with future grants and its SQL statements generated by TrustLogix.

In general, RBAC serves well when the native platform is built using the RBAC engine, and there are no complex data access requirements. Furthermore, the RBAC model helps enterprises meet regulatory requirements such as HIPAA, SOX, SOC2, and ISO 27001, as this depends on visibility to prove the information is handled according to security and confidentiality standards defined by the user's job role in the enterprise. But RBAC does not scale when the requirements are dynamic in nature; customers end up creating a role per business requirement, and that leads to role explosion. ABAC is a more flexible and extensible model that can handle the dynamic real-time nature of such authorization.

ABAC

Some of the use cases where ABAC is most applicable:

• Securing Business Sensitive Data to many varied users with different attributes where access controls are needed on a record, or even field level, based on specific rules. For example:
  • sales managers being able to view only those accounts owned by their respective sales teams
  • purchasing managers not being able to approve purchase orders to vendors they entered into the system, and
  • financial services managers only able to access those accounts and assets belonging to the counterparties they are managing.

  These attributes are subject to frequent change and require looking up the data itself to determine whether the user can access or not.

• Multi-Tenant Solutions that include a unified data model, where the tenant data is pooled into a single data store, and data is striped with a tenant identifier. Application users accessing this data are authorized to view only data belonging to their tenant.
• Unified Access Controls Across Multiple Data Stores, in which the same data is frequently distributed across multiple data stores, require consistent access controls everywhere. It is easier to manage unified access controls if the data is tagged, and those tags can be matched against user attributes across all the data sources. You must then define only one tag-based ABAC policy across all data sources.
• Time-Based Conditions: Many highly regulated industries have use cases where time-based situational conditions determine whether users can access data, for example, a quiet period before quarterly results for a publicly traded company. In this scenario, any user not on the insider list and who might normally have access to current sales and projections data should be blocked during this time period. In this case, date/time and insider-list attributes are used to dynamically control access.

Example of tag-based ABAC policy displayed in TrustLogix policy editor.

While ABAC can be used to achieve all of the above-mentioned RBAC use cases, ABAC can have more operational overhead and thus can be overkill for those use cases. Furthermore, role itself can be used as an attribute in many scenarios in ABAC. So, RBAC and ABAC are not mutually exclusive. They should be leveraged together.

In short, no one correct method exists to control access for all data projects. Anybody claiming one is categorically always better than the other is just contributing to the noise. In principle, you should select a data security platform whose access control capabilities are as diverse as the data workloads you are trying to secure, thus empowering you to make the best choices of access control method for each use case involving sensitive data.

Access controls are necessary but not sufficient. You also need a way to observe and adapt to data access issues and risks as they occur.

As a general good practice, TrustLogix recommends starting with securing some critical assets by leveraging the power of both RBAC and ABAC. However, you still need to ensure those policies are optimally protecting your data continuously and that you have addressed all gaps in your data security posture. Even with the best access control technology, there are numerous types of data access issues that can go undetected, including:

• Overprivileged Accounts: An example would be a user who has administrative privileges when they don’t need them, which can result in exfiltration either from that user or from a bad actor who hijacks that account.
• Ghost Accounts: These may be a former employee or customer whose account has not been disabled, which can result in unauthorized access and exfiltration by that former user.
• Dark Data: Copies of sensitive data no longer needed but still accessible, representing unnecessary attack surface by bad actors.
• Conflicting Role or Attribute Hierarchies: These can cause users to have incorrect access privileges resulting in operational overhead from users complaining they don’t have access to the data they need. However, please consider that noone complains about having too much access.
• Data Sprawl: Data is distributed across multiple data stores, and the downstream stores’ users should not have the same privileges as the users whose access lets them share this data in the first place.
• Data Being Accessed from Unauthorized Clients: Indicative of potential “shadow IT” of accounts being shared by multiple people in order to “work around” data access issues, or even hijacked by a bad actor logging in from another device.

TrustLogix Data Risk Viewer showing example risks and recommendations.

Just having an access control system in place won’t, by itself, identify such issues. Security Observability, which identifies these issues and enables quick resolution, is critical to ensuring your policies are optimal and easily maintained. Also, most data privacy regulations, such as GDPR, require that you have a way of getting visibility and controlling such issues. As a result, “Data Security Posture Management” is becoming its own product category (as defined by Gartner) out of recognition that real-time visibility and control across the entire cloud data landscape is critical.

In short, simply having RBAC and/or ABAC capability is not enough. You should also make sure you can monitor a broad spectrum of data security risks and that you can enable quick resolution regardless of where that risk originated. In “Break the Glass” case of kinds of emergency scenarios, risk-adaptable access control is also required, hence understanding risks is a critical aspect of data security access governance.

LEARN MORE about the 7 types of data security issues here: https://www.trustlogix.io/blog/the-top-7-cloud-data-security-issues-that-you-dont-know-about.

Diverse Workloads Demand Different Data Security Posture Management Approaches

In conclusion, your cloud data landscape:

• has diverse workloads for which no single type of access control policy is appropriate for all of them, and
• is broadly distributed and thus rife with security risks that must be identified and remediated quickly.

As a result, don’t be hoodwinked by the noise of silver-bullet features promising to solve this. Instead, consider that RBAC, ABAC, and security observability are all essential for maintaining a strong data security posture in the cloud.