What Is Policy-Based Access Control?

In daily conversation, we often use umbrella terms to simplify communication. For instance, if someone tells you they work for “the government,” you get a general understanding of what type of work they do without necessarily knowing their exact agency, office, or role. Categorization allows us to easily discuss a general concept in terms that are broadly understood.

The same is true for access control models. There are several different access control types, but they are generalized under the umbrella of policy-based access control (commonly referred to as PBAC).

Note: At Immuta, we use the PBAC acronym 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 grant or restrict access to data. Policies are built around these contextual factors, and enforced according to how they apply to a given user. This allows for dynamic policy enforcement, as opposed to static, legacy models like mandatory access control (MAC) and discretionary access control (DAC).

RBAC vs. ABAC: Future-Proofing Access Control Models

Dive into the pros and cons of RBAC vs. ABAC and find out why ABAC is the more future-proof option.

Access Now

The Two PBACs: Policy-Based Access Control and Purpose-Based Access Control

The acronym “PBAC” was originally used to refer to “policy-based access control.” However, as access control becomes more granular and regulatory requirements are more specific, a newer “PBAC” has emerged: purpose-based access control. In a field already brimming 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 not interchangeable. We won’t delve too deeply into purpose-based access controls in this article (if you’re interested, check out this article), but the important distinction between these forms comes at the point of enforcement:

  • Policy-based access control enforces policies on system users. Rules determine user access based on the individual’s role or attributes/characteristics.
  • 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 typically include. You can explore how purpose-based access control enforces row- and cell-level security in practice here.

Policy-Based Access Control Examples

Now that we’ve differentiated policy from purpose, we can examine two of today’s most prevalent data access control examples that can be classified as policy-based.

Role-Based Access Control

RBAC (role-based access control) is a model in which system administrators assign predetermined roles to users as they are added to the system, and create policies that make access decisions based on those roles. While the roles are the determining factor for access, the process through which access is granted or denied occurs completely based on the policies.

Attribute-Based Access Control

Attribute-based access control, or ABAC, bases access decisions on user attributes rather than on static roles. An attribute is a characteristic of any piece of system metadata, including the name/title of a system user, the sensitivity level of a data set, the actions a user is taking, and the location of the action. This creates a dynamic, multifaceted matrix through which policies are applied.

To see the ABAC model in action, check out this video:

 

Which Form of Policy-Based Access Control Is Right For You?

As we’ve seen, ABAC and RBAC both fit under the policy-based umbrella. Understanding the necessity of efficient, dynamic data access control, 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 limited set of use cases. If an organization is small, unchanging, and not looking to scale and adapt with the markets, then RBAC’s static nature may 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, a study by GigaOm determined that it would take only eight ABAC policy changes to replicate the effect of 745 changes in an RBAC model – a difference of 93x. This equates to hundreds of thousands of dollars in operational cost savings.

https://www.immuta.com/wp-content/uploads/2022/04/Total-Policy-Changes-by-Scenario.jpg

Why Immuta?

If you’re looking for an access control model to effectively enforce policy now and into the future, ABAC is the model for you. The Immuta Data 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 you create easy-to-understand policies that are automatically enforced across your entire cloud ecosystem, and can be adapted at any time. The true value of policy-based access is realized with dynamic, consistently enforced, and customizable policies that keep your sensitive data secure and compliant.

To see how easy it is to create and enforce your own access controls, check out this short platform demo.

See It In Action

To see how easy it is to create and enforce your own access controls, check out this quick demo.

Watch Now
Blog

Related stories