Approaches to Access Control

Humanizing Policy Logic

When thinking about data, compliance requirements, and policies, it’s easy to forget about the central, human element and to become wrapped up in the abstract. Let’s humanize and concretize Immuta policy logic by examining a simple scenario.

Scenario: Role-based Access Control

This data scientist, Leslie, leads the research team and was recently appointed to the hiring committee.

She and her team are conducting a new project and they need access to the following data sources:

• Data Source A
• Data Source B
• Data Source C

Currently, the research team is the only team who needs to access this data, and they’re able to see all the raw, un-redacted values, so these users have been grouped and granted access to all three data sources.

However, now that she’s been appointed to the hiring committee, Leslie needs access to another data source, Data Source D. Unlike the other data sources she has access to, the rest of her team is not allowed to view this data; this data source is only accessible to others on the hiring committee. Consequently, another group is created for users who are a part of the hiring committee, and the group is given access to all raw data.

So far, this role-based access approach isn’t overwhelming and seems manageable. But what do we do when the inevitable happens:

• compliance regulations change and controls need to be added to data sources
• employee turnover and new hires
• changes in management/organizational structure
• more data sources are added

Although not visible in its current state, this role-based access approach is unsustainable because it’s not scalable. Watch what happens as different controls are added to each of the data sources:

• some people need to have visit_id masked from them (Group 3),
• some people need to have total_claims masked (Group 4),
• and some people need to have dates of birth masked (Group 5).

Group 1 gets access to all the raw data for A, B, and C, and then new groups have to be added for other fine-grained controls over these data sources.

We suddenly have more groups than data sources and users don’t know what they should be requesting access to: a group or a data source?

The Flaw

Here’s the flaw with this approach above: We’re missing the why? Why does group 1 get access to A, B, and C? Why does group 5 get access only to Data Source A and 3 doesn’t get access to it at all?

In this scenario, groups are replacing the why and creating confusion. Determining which users should be in which group by what types of data they need to see becomes complicated and inefficient because someone has to 1. figure out which group users need to be in and 2. create new groups when things change.

Immuta Logic and Attribute-based Access Control

Immuta shifts this paradigm through policy logic.

Let’s recreate this scenario with the same data sources and controls, but we’ll add user attributes to Leslie instead of adding her to groups depending on which data sources she wants access to.

Instead of lumping users in groups as the only way to gain access to the data, we’re going to use these attributes of Leslie in a realistic way — one that actually represents who she is — to determine whether or not she should access data sources.

To grant or deny access in this scenario, we’ll set policies on the data sources; these policies are the why that was missing in the first scenario:

• Allow access if you’re in the Research department

Next, we’ll compare the user attributes to the policy and make a decision, explicitly stating why she’ll get access: Leslie would get access to all 3 of these data sources because she’s in the Research department.

Now that we’ve established user attributes for Leslie, if we add data source D, you just need to have a different policy:

• allow access if user is on hiring committee and is a supervisor.

When Leslie’s user attributes are compared to this policy, she would get access to this data source as well.

If fine-grained controls over these other 3 data sources become necessary, we just need to write other policies like this:

• A mask dob unless is researcher
• B mask total_claims unless is accountant 
• C mask visit_id unless is supervisor

When Leslie’s user attributes are compared to these policies, she would see raw data for all data sources except for Data Source B: since she does not have an accountant attribute, the total_claims values would be masked from her in this data source.

When the why is explicitly stated by policies, users can ask for the data instead of asking for roles or groups. This approach results in fewer manual approvals, since user attributes are approved instead of roles for every single data source that users might want access to. Additionally, different groups can contribute their rules or governance components to the data in a way that everyone understands.

RBAC vs. ABAC

Despite the benefits outlined above, few organizations use attribute-based access controls because RBAC is widely adopted and, for small- to medium-sized organizations, manageable. However, RBAC introduces the potential for “role explosion” (highlighted in the example above).

If you’re interested in further reading, “Role-Base Access Control vs. Attribute-Based Access Control — Explained,” an article by Steve Touw, clearly illustrates the complexities, challenges, benefits, and uses of RBAC and ABAC.