In daily conversation, we often use umbrella terms to group things together. If someone tells you they work for “the government,” they could be referring to any number of agencies, offices, and roles that fit that category. If someone mentions their love for “reality TV,” they could be describing anything from American Idol to The Real Housewives. These categorizing terms allow us to express the ties that bind similar objects or ideas together.
This is evident when discussing a relatively widespread modern access control strategy: policy-based access control, commonly referred to as PBAC.* Since most forms of contemporary access control involve policies that dictate who can access data, they fit under the PBAC umbrella, regardless of how the policies are enforced in practice.
*At Immuta, we use this acronym (PBAC) to describe “purpose-based access control.” We’ll cover the distinction between these two terms below.
In this blog, we flesh out what policy-based access control entails, answering:
- What is PBAC?
- What is PBAC not?
- What is the most effective form of PBAC?
What is Policy-Based Access Control (PBAC)?
According to the federal government’s National Institute of Standards and Technology (NIST), policy-based access control is defined as a “strategy for managing user access to one or more systems, where the business roles of users is combined with policies to determine what access privileges users of each role should have.”
PBAC is a perpetually evolving form of access control, stemming from the need for more vigorous and adaptable methods to keep up with the progression of data use. This access control strategy uses identifying information like roles and attributes to determine whether or not users should see certain data. Policies can be built around these contextual factors, and enforced according to how they apply to a given user. This allows for dynamic policy enforcement, rather than the more static fashion of legacy models like mandatory access control (MAC) and discretionary access control (DAC).
[Tip] For more on the history and evolution of access control, read our free white paper.
Given its broader characterization as an access control strategy that determines access based on policies, it’s easy to think of current access control models that would fit under the PBAC umbrella. Before delving into the forms that fit this description, however, we should make an important distinction.
2022 Data Access & Analytics Trendbook
Expert perspectives on where data use is heading
Download Ebook
The Two PBACs: Policy-Based Access Control and Purpose-Based Access Control
If you’ve been involved in contemporary data science for some time, it’s possible that you’ve seen the acronym “PBAC” used to refer to “policy-based access control”. However, as access methods adapt alongside data, a newer “PBAC” is gaining traction: purpose-based access control. In a field already littered with acronyms and constantly evolving buzzwords, it certainly doesn’t help to have the same shorthand for multiple terms, especially when they’re so similar.
It’s important to note the differences between policy-based and purpose-based access control, as they are very much not interchangeable. We won’t delve too deeply into purpose-based access controls in this article, but the important distinction between these forms comes at the control-enforcement level:
- Policy-based access control enforces policies on system users, letting these rules determine user access based on the role or attributes/characteristics of the individual.
- Purpose-based access control doesn’t just determine access for individual users, but instead adds a layer of specific data use purposes.
Examples of purposes are combining data sets to run analysis reports, pulling data to perform an audit, or more. Real-world applications of purpose-based access are evident through regulations like HIPAA, which requires individuals to have an approved purpose in order to access sensitive health information. This provides a different, context-based axis on which to determine access that policy-based approaches do not necessarily always involve. You can explore how purpose-based access control enforces row- and cell-level security in practice here.
Policy-Based Access Control Models
Now that we’ve differentiated policy from purpose, we can examine two of today’s most prevalent data access control models that can be classified as policy-based.
The first is role-based access control, or RBAC. This method of access control has system administrators assign roles to users as they are added to the system. The roles need to be predetermined within the system in order to be applied to incoming users. System administrators are then able to create policies that make access decisions based on the role(s) that are connected to each user. While the roles are the determining factor for access, the process through which access is granted or denied occurs completely based on the policies involved.
The second (and more modern) of these models is attribute-based access control, or ABAC. Rather than relying on the static role-based approach that RBAC takes, ABAC bases access decisions on user attributes. An attribute can be a characteristic of any piece of metadata in the system, beyond just the title or department that a role may specify. This includes the name/title of a system user, the sensitivity level of a data set, the actions a user is taking, the location of the action, or more. What this creates is a dynamic, multifaceted matrix to which policies can be determined and applied.
Why ABAC is the Ideal Form of Policy-Based Access Control
As we’ve seen, ABAC and RBAC both fit under the policy-based umbrella. Understanding the modern necessity of efficient data access controls, you may be wondering which is best suited for your organization’s data stack.
By nature, RBAC is a more ingrained model in legacy systems. It has traditionally been simple to initially set up, and policies logically link access permissions to static roles. In this way, RBAC can still be workable…for a small selection of use cases. If an organization is small, unchanging, and not looking to scale and adapt with the markets, then RBAC’s static nature could suffice. But realistically, not many organizations fit this mold.
Many modern organizations need data access policies that can scale with their business, providing the flexibility to keep up with the constantly evolving data landscape. For these organizations, ABAC is the best possible access control solution. By basing access policies on a range of attributes rather than single static roles, ABAC eliminates the complex role bloat often caused by RBAC. A single ABAC policy can effectively replace hundreds of RBAC policies. In fact, an independent study by GigaOm determined that it would take only eight ABAC policy changes to replicate the effect of 603 changes in a legacy RBAC model.
Why Immuta?
If you’re looking for an access control model to effectively enforce data access policies now and into the future, ABAC is the model for you. Immuta’s data access and security platform discovers, secures, and monitors your sensitive data to make sure the right users can access the right data at the right time. Its plain language policy builder lets users create simple policies that are automatically enforced across their entire cloud ecosystem, and can be adapted at any time. The true value of policy-based access is recognized when policies are dynamic, universally applied, and keep your sensitive data secure and compliant.
To try creating a policy of your own, test out our self-guided Immuta walkthrough demo.
