How To Easily Adapt Data Access Management for Table Grants

Attribute-based access control (ABAC) grants or restricts access to data using context-based decisions based on information about the user, the data itself, the intended action, and the environment generally. It’s well-documented that ABAC is the more flexible, scalable access control option when compared to static role-based access control – NIST has formally supported ABAC, and more recently, the US government released a memo recommending ABAC as a key factor in Zero Trust architectures. But, there are exceptions to every rule – so, how can data platform teams solve for them without losing time or trust?

In this blog, we’ll examine how Immuta allows policy authors to adapt data access management for ABAC table grant policies (termed “subscription policies” in Immuta) by adding an approval workflow as an alternative method of access for users that do not meet the base ABAC conditions.

Why Provide An Alternate Data Access Management Option?

When urgent or unpredictable data access needs arise, data users must be able to access the data they need to respond in a timely manner that doesn’t risk compliance violations.

We’ve heard from multiple customers that the need to create subscription policies with the ability to use more than one level of criteria would help avoid bottlenecks and confusion in these scenarios. For instance, one global fintech company wanted to allow users with a specific set of attributes to subscribe to a data source, but also have the ability to manually approve or deny access requests from users without those attributes using their own discretion. This adds increased flexibility without added complexity because data users who do not satisfy the ABAC conditions may still request access, be approved, and view the data.

[Report] DataOps Dilemma: Survey Reveals Gap in the Data Supply Chain

How to Implement Approval Support for Subscription Policies

To configure this option, users first click the “Request Approval to Access” box in the Immuta policy builder:

Once checked, the approval policy builder will appear for configuration. The rules configured in this section will allow users who do not meet the base ABAC policy (in this case, not members of group founders and group tesla_owners) to request access as they would if a normal approval-based policy were applied. In other words, the presence of approvals in an ABAC policy can be thought of as an otherwise condition. For example, “automatically approve users who satisfy the ABAC rules, but allow other users to request approval.”

Say you have multiple different users that have built ABAC policies with approval configurations that happen to be applied to a single data source – how can you ensure nothing falls through the cracks? In this case, the ABAC rules will be merged. This is a powerful feature of Immuta that allows distributed data stewardship and enables different parts of an organization to build new data policy without breaking existing policies.

2022 Data Access & Analytics Trendbook

Expert perspectives on where data use is heading

Download Ebook

Merging ABAC Policy Behavior

For a quick refresher on how ABAC policy rules can be merged, consider the following policies:

1. Allow users to subscribe when user is a member of group founders (Always Required)
2. Allow users to subscribe when user is a member of group engineers (Always Required)
3. Allow users to subscribe when user is a member of group founders and is a member of group tesla_owners (Share Responsibility)
4. Allow users to subscribe when user is a member of group engineers and is a member of group tesla_owners and is a member of group notifications_group (Share Responsibility)

All of the rules are combined in accordance with their Share Responsibility configurations, as shown in the screenshot below.

To sum it up as a formula, the merged policy will be:

([always required rules (n)] AND [always required rules (n+ 1)]) AND
 ([share responsibility rules n] OR [share responsibility rules (n + 1)]) 

Following this logic, the resulting policy is:

Allow users to subscribe to the data source when
 user(@isInGroups('founders')) AND (@isInGroups('engineers')) AND
 ((@isInGroups('founders') and @isInGroups('tesla_owners')) OR
 (@isInGroups('engineers') and @isInGroups('tesla_owners') and
 @isInGroups('notifications_group')))

Merging ABAC Subscription Policy Approvals

The same logic above applies to merged approvals. Let’s modify these policies to allow approvals as follows:

1. When approved by anyone with permission A and anyone with permission B (Always Required)
2. When approved by anyone with permission C and an individual selected by user with permission D (Always Required)
3. When approved by anyone with permission A and anyone with permission B and anyone with permission E (Share Responsibility)
4. When approved by anyone with permission B and an individual selected by user with permission F (Share Responsibility)

The merged policy abides by the same formula and the result is this:

Allow users to subscribe when approved by
( anyone with permission A AND anyone with permission B AND
 anyone with permission C AND an individual selected by user with permission D 
)
AND
( ( anyone with permission A AND anyone with permission B AND anyone with permission E )
 OR ( anyone with permission B AND an individual selected by user with permission F ) )

A requesting user MUST obtain A & B & C & D approvals to satisfy the Always Required portion of the policy. To satisfy the Share Responsibility portion, they will need approval from either a permission E or permission F user.

Additional Considerations for Manual Data Access Management and Approval

With this capability, it is important to note that:

• A data owner (or another privileged user) can now manually add anyone to a data source, meaning they are able to bypass the policy completely – the equivalent of an approval. This was not previously possible.
• Enabling approvals in an ABAC policy will automatically enable data source discovery. Since users who don’t meet the ABAC conditions can’t discover the data source, then the presence of approvals in the policy is unnecessary.
• On merge, if one or more policies do not have discovery enabled, then approvals will be automatically removed from the final merged policy. This is because Immuta will always fall back to principle of least privilege, and in this case, one of the policy owners does not want the table to be discoverable.

Conclusion

Data access management should adapt to an organization’s evolving needs, without the need for burdensome policy workflows that act as workarounds and could introduce risk into data access control processes. Approval support for ABAC subscription policies should significantly decrease (or eliminate) the need for such workarounds, greatly reduce the number of policies required to manage any access request scenario, and open the door to previously impossible data access workflows.

Now that you know how to save time by avoiding workarounds, check out this calculator to find out how much more you could be saving when you switch to automated data access control from a homegrown solution. Or if you’d like to see how to implement manual approval support for yourself, schedule a demo with our team today.