Automate Data Access Control Decisions

This section focuses on how to use Immuta to automate decisions that determine whether users should have access to data objects. The image below illustrates where tags, groups and attributes, data identification and classification, and policy sit within your data ecosystem and how they interact to automate access controls.

You will learn about each of these features, how they interact to automate and enforce access controls on your data, and how to implement them to meet your business objectives.

Who is this for?

This guide is intended for users who want to build table access control policies in a scalable manner using Immuta.

Prerequisites

• Data platform integration configured in Immuta

• Users and data sources registered in Immuta

Goals

This use case is the most common across Immuta users. With it, you solve the problem of entitlement of users to data based on metadata about the user (attributes and groups) and metadata about the data (tags).

This use case is unique to Immuta, because rather than coupling an access decision with a role, you are able to instead decouple access decisions from user and data metadata. This is powerful because it means when metadata about the users or metadata about the data changes, the access for a user or set of users may also change - it is a dynamic decision.

Decoupling access decisions from metadata also eliminates the classic problem of role explosion. In a world where policy decisions are coupled to a role, you must manage a new role for every permutation of access, causing an explosion of roles to manage. Instead, with this use case you decouple that logic from the user metadata and data metadata, so real-time, dynamic decisions are possible. Immuta’s method of building policies allows for these many permutations in a clear, concise manner through the decoupling of policy logic from the user and data metadata.

This use case also eliminates the need to have a human in-the-loop for approval to data access. If you can describe clearly why the approver would approve an access request - that can instead be expressed as an Immuta subscription policy, as you’ll see below. Removing humans from this process increases the speed to access data, makes access decisions consistent, and removes error and favoritism.

Want to learn more? Check out this ABAC 101 blog on the methodology.

Table vs column access

Lastly, this use case is primarily focused on automating table grants, termed subscription policies in Immuta. We recommend you also read the Compliantly open more sensitive data for ML and analytics use case to learn about column masking, which will allow you to enforce more granular controls so that you can open more data. It's common to see users mix the automate data access control decisions use case with the compliantly open more sensitive data for ML and analytics use case, so it's recommended to read both.

Business value

Following this use case will reap huge operational cost savings. You will have to manage far fewer data policies; those policies will be more granular, accurate, and easily authored; and you will be able to prove compliance more easily. Furthermore, instead of an explosion of incomprehensible roles, the users and data will have meaningful metadata matched with clear policies.

Quantified benefits:

• 75x fewer policy changes required to accomplish the same use cases

• 70% reduction in dedicated resources to data access management and policy administration

• Onboarding new employees two weeks faster and provisioning new data one week faster

• 5% to 15% increase in client contract values to improve revenue

Unquantified benefits:

• Improved compliance standard and security posture

• Enhanced employee satisfaction

• Better user experiences

More details on the business value can be found in these reports:

• GIGAOM: ABAC vs RBAC: The Advantage of Attribute-Based Access Control over Role-Based Access Control (Immuta is an OT-ABAC approach)

• Forrester: The Total Economic Impact Of Immuta

Next steps