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 how their silver-bullet access control or other security feature 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 for you 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 reality is that 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, because it is easier to implement new types of data projects and share data across them. And with new 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 does a given user have access to. Example: In a purchase order management system, only Managers can approve a PO request. The permission “Approve” is granted to a Manager role and all users belonging to that role will be able perform that action.
• Manage Access to the Administrative Portions of an Application: Examples: In distributed computing systems like Snowflake, which users have access to Operate and Create Warehouse, and Monitor Usage. You want to limit the users who have 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. and there is no requirement for conditional access. In these scenarios, it is recommended to create a service account role and grant 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: For 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 to 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 easily, as this depends on visibility to prove the information is handled according to security and confidentiality standards defined by the job role of the user 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 to 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 a large number of varied users with different attributes, in which 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 being able to access only 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 tenant identifier. Application users who are 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 and requires 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 then need to 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 get access to 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, and they should be leveraged together.

In short, there is no one right method 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 continuously ensure those policies are optimally protecting your data, and 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 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: 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: Can cause users to have incorrect access privileges. This can cause much operational overhead from users complaining they don’t have access to the data they need. However, also consider that nobody 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, look out for 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 control of 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 have a way of monitoring for a broad spectrum of data security risks, and can enable quick resolution regardless of where that risk originated. In “Break the Glass” in case of kinds of emergency scenarios, a 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:

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

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