2022 Data Access & Analytics Trendbook
Expert perspectives on where data use is heading
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.
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
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.
Expert perspectives on where data use is heading
For a quick refresher on how ABAC policy rules can be merged, consider the following policies:
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')))
The same logic above applies to merged approvals. Let’s modify these policies to allow approvals as follows:
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.
With this capability, it is important to note that:
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.
Innovate faster in every area of your business with workflow-driven solutions for data access governance and data marketplaces.