No matter the type, amount, or desired application of your organization’s data, all data users have one common requirement: accessibility. Without access, any repository of data would sit useless in your on-premises or cloud storage platforms. By providing secure, efficient access to this information, organizations can ensure that their resources are leveraged for a range of business-driving purposes.
However, access must not be granted universally. Sensitive data–such as social security numbers, credit card information, and medical data–should not be accessible to just any user in a data ecosystem, especially those who have no defined purpose for viewing or using it. Instead, data access controls need to be created and enforced to guarantee that only the right users are accessing the necessary data at the proper times.
Logical data access control policies must be applied across a data ecosystem to maintain the desired access restrictions for any user on any relevant data resources. As data sets, users, and use cases grow, managing these policies at scale can become quite complicated. Contemporary access control models, such as role-based access control (RBAC) and attribute-based access control (ABAC), take different policy approaches that can have a measurable impact on this policy management burden.
In this guide, we elaborate upon these different policy approaches, and determine which access control method enables more streamlined policy management for modern data teams.
RBAC and ABAC Policy Explained
While both are regularly implemented in contemporary data ecosystems, RBAC and ABAC take distinctly different approaches to determining data access. Each has its own strengths, areas for improvement, and use cases.
RBAC Policy Basics
Formalized in 1992, RBAC models use policies built on user roles to dictate access to specific data. These roles are created and controlled by system administrators, and are assigned to new users as they enter the data ecosystem. This creates a framework that is static and linear, since users are only permitted to access data if they are assigned certain predetermined roles.
In some RBAC frameworks, users can be assigned multiple roles, creating a hierarchy in which roles are managed by their relevance. For instance, a user could be assigned both the “analyst” and “finance” roles, and thereby gain the access permitted to each. Users can access any data within the system that is associated with the role(s) they are assigned.
RBAC can be an effective access control model for smaller organizations. Once determined, additional policies must be written and enforced to satisfy any subsequent organizational, regulatory, or staffing changes. With stable and shareable roles that don’t often change, new policies can be put in place with relative ease. Even if an employee changes roles, all that must be updated is the role assigned to them; no new policies must be created. This does not, however, always carry over to organizations that are large, growing, or subject to evolving regulations.
ABAC Policy Basics
ABAC takes a more dynamic approach to data access and security than RBAC, which is why it has become more widely adopted in recent years. It defines what can be thought of as dynamic roles by combining the observable attributes of users and data, and determines access decisions using policies built upon those attributes. ABAC also decouples who a user is from what information they have access to, and makes the access decision at runtime rather than based on static policies.
Attributes can encompass a wide range of characteristics in the data ecosystem. They can be ascribed to properties such as:
- System Users: name, title, department, permission level
- System Objects: creator, type, creation date, level of sensitivity
- Actions Taken by Users: reading, editing, approving, deleting
- The Data Environment Itself: location, date of access, level of organizational threat
This varied matrix of characteristics allows data teams to create policies of an extremely dynamic nature.
Once ABAC policies exist, they remain in place unless otherwise adjusted. If a new data set is entered into the system, or relevant metadata about a user changes, preexisting access policies will automatically adjust as necessary. This removes the need for data teams to constantly keep up with policy maintenance, and provides a more consistent level of security that does not need to rely on regular manual intervention.
Modern Data Policy Management Challenges
In the face of evolving data resources, platforms, and best practices, modern data policy management is not without its challenges. Data teams across all industries face common blockers that make enabling secure accessibility more difficult. These challenges include:
Decentralized Policy Management Responsibilities
Many contemporary organizations struggle with policy management initiatives being spread across various teams and individuals. Without a defined role or group in charge of managing access control policies, the responsibility can be left in limbo, neglected, or approached in conflicting manners by different stakeholders.
This was reflected in the Data Policy Management Report, which asked respondents which roles in their organization held policy management responsibilities. While options included roles like the Chief Technology Officer (CTO), Chief Information Security Officer (CISO), and data architects and stewards, no more than 38% of respondents agreed on a single role holding these responsibilities. This demonstrates the distributed nature of policy management responsibilities, and hints at widespread “citizen” ownership of these important duties. While this is not inherently negative, it can lead to inconsistent management without the proper tools and/or organizational best practices.
Access Control Policies that Cannot Scale
As organizations grow and expand, their data resources follow suit. Access control methods must scale in tandem with data volumes to maintain consistent security and accessibility. Unfortunately, many legacy access control systems use policies that simply cannot scale at the speed of business development.
When user roles are created and preassigned by administrators early on, they quickly become outdated as an organization builds out its various internal teams and data use cases. Data teams often end up saddled with the challenge of “role explosion.” This occurs when an excessive number of new roles and policies must be manually created and maintained in order to keep up with growth. In turn, additional bottlenecks and increasingly complex management requirements become more prevalent, and teams struggle to keep up with the requirements of data users.
Immature and Outdated Policy Management Tools
Modern organizations frequently rely on a mix of in-house tools that have been in place since the creation of their data ecosystem, and highly specialized purchased options that serve more advanced purposes. The Data Policy Management Report found that almost half (43.7%) of organizations follow this hybrid methodology. These legacy tools and specialized platforms often struggle to cooperate and meet the unique needs of a given organization. Instead, they can cause friction and stunt whatever data-driven objectives teams are striving to achieve.
This is especially true when tools rely on legacy access control methods. Determining access based on unscalable policies simply because that’s how the system was built severely limits the ability to streamline policy management. If tools are implemented in conflict with one another, or just simply in an ineffective manner, then policies will not achieve the kind of coverage required to truly secure sensitive data at scale.
RBAC and ABAC Policy Implementation in Practice
Let’s consider a scenario where both RBAC and ABAC could be applied to user access. Imagine a sales team is focused only on engaging with prospective customers within the United States. Each member of the team is assigned a certain region of the country, and policies are required to ensure access to their region’s data. As the organization and business objectives grow, they are tasked with doubling their team size and expanding to international markets. The new international sales team will also be region-based, with each member responsible for their own assigned area. What would this require of their access controls?
With RBAC, roles and policies would have to be built for the original salespeople, to ensure that they can access data from their respective domains. Unique policies would be required for each state in their region, and they would need additional policies to determine individual user access to data from multiple states. Unfortunately, these existing role-based policies would not extend to their new international colleagues. Each new salesperson would require wholly new roles and policies, facilitating access to only their specific regional data, and not information from the United States. These roles would need to be created and maintained manually by data teams, adding to the already-existing policies for which they are responsible.
With ABAC, policies would have been built for the U.S. sales team based on a collection of user attributes, including those such as department (i.e. “Sales”) and location (i.e. “Northeast”). Instead of needing unique policies for each state salesperson, a policy could state:
“Only show rows where user is a member of a group that matches the value in column tagged Discovered.Entity.Location for everyone.”
This would dynamically assess a user access request at query time and only allow sales users to view the data that matches their assigned location attributes. When adding new international salespeople to the team, their regional attributes would be covered by this same policy. This eliminates the need for individual manual policies, and instead requires only the addition of new regional attributes into the data ecosystem.
RBAC vs. ABAC for Streamlined Policy Management
With an understanding of the differences between RBAC and ABAC policy use and an idea of common modern policy management challenges, how can data teams most effectively streamline the management of their access and security policies?
Ultimately, ABAC policy usage provides data teams with the enhanced flexibility, security, and scalability they need to address policy management roadblocks.
Bridging Decentralized Responsibilities
When policies can be written and applied by any stakeholder, regardless of technical expertise, it removes barriers that would have likely siloed policy management in the past. ABAC policies can be written logically in plain language, providing all stakeholders–from the CISO to legal and marketing teams–to understand which policies are applied for which reasons. Creating alignment with streamlined policies facilitates a smoother delegation of responsibilities that are understood by all involved.
Combatting Policies that Cannot Scale
One policy in an ABAC model can effectively replace hundreds of roles that would’ve previously been necessary to achieve the same result with RBAC. Need proof? A recent study by GigaOm found that ABAC policies reduced required policy changes by 93x when compared to RBAC. It took researchers only eight ABAC policy changes to achieve the same results as 745 RBAC changes. These enhanced policy capabilities alleviate the burdens of role explosion and excessive policy changes, making required changes much more manageable.
Reinvigorating Outdated Platforms, Tools, and Practices
Becoming overly reliant on a mix of legacy methods and hyper-specific modern tools can only serve to further complicate policy management objectives. Aligning objectives under tools that can adjust to unique situations enables teams to better simplify their access policies. ABAC policies provide teams with understandable rules that have the capacity to more effectively scale across platforms. When these comprehensive policies are coupled with ABAC’s capacity for automation, administrators avoid the pitfalls of manual role creation and the risk of role explosion and data chaos.
To learn more about how RBAC and ABAC match up, check out the new GigaOm Report: The Advantage of ABAC Over RBAC.