Example policy 1: employee access

Author a subscription policy that grants read access to users who are a member of group Employees that applies to columns tagged Strictly Confidential:

Allow users to subscribe with read access when user is a member of group Employees on data sources with columns tagged Strictly Confidential.

Example policy 2: country access

Author a subscription policy that grants read access to users with attribute Country.US that applies to columns tagged Strictly Confidential:

Allow users to subscribe with read access when user possesses attribute Country with value US on data sources with columns tagged Strictly Confidential.

Example policy 3: legal team access

Author a subscription policy that grants read access to users who are a member of group Legal Team that applies to columns tagged Strictly Confidential:

Allow users to subscribe with read access when user is a member of group Legal Team on data sources with columns tagged Strictly Confidential.

Example

Let’s say there are Strictly Confidential tables and Public tables. Everyone has access to Public, and only special people have access to Strictly Confidential.

Users are tagged with their access under the Access attribute key:

• Bob: Access: Strictly Confidential

• Steve: Access: Public

Tables are also tagged with the same metadata:

• Table 1: Strictly Confidential

• Table 2: Public

You would build a grant subscription policy that targets all tables like this:

Allow users to subscribe with read access when @hasTagAsAttribute(Access,dataSource) on all data sources.

Referring back to our triangle of access decision, user metadata is the first point of that triangle. User metadata is made up of the following elements:

• Attributes: key:value pairs tied to your users

• Groups: a single value tied to your users - you can think of groups as containing users. Groups can also have their own attributes, a shortcut for assigning attributes to all members of a group. In either case, multiple users can be attached to the same attribute or group.

Referring back to choose your path: orchestrated RBAC and ABAC will help drive how you manage user metadata.

Fact-based user metadata (ABAC) allows you to decouple policy logic from user metadata, allowing highly scalable ABAC policy authoring:

• Steve has attribute: country:USA

• Sara has attribute: role:administrator

• Stephanie has attribute: sales_region: Ohio, Michigan, Indiana

• Sam is in group: developers

• Group developers has attribute: organization:engineering

Logic-based user metadata (orchestrated-RBAC) couples user metadata with access logic:

• Steve has attribute: access_to:USA

• Sara has attribute: role:admin_functions

• Stephanie has groups: Ohio_sales, Michigan_sales, Indiana_sales

• Sam is in group: all_developer_data

• Group developer has attribute: access_to:AWS_all

Typically these groups (most common) and attributes come from your identity management system. If they do, they also potentially contain access logic as part of them (examples in the logic-based user metadata list above). It’s not the end of the world if they do, though this means you are potentially set up for orchestrated RBAC. If each group from your identity management system represents a single static fact that provides access for a set of objects, with no overlap with other facts that provide access - then you can use orchestrated RBAC. A simple example to demonstrate groups ready for orchestrated RBAC is “you must have signed license agreement x to see data tagged x” - it’s a simple fact: you’ve signed license agreement x, that provides access to data tagged x. There are no other paths to data tagged x.

But the key to orchestrated RBAC is that it’s a 1:1 relationship with the group from your identity manager and the set of objects that group gives them access to. If this is not true, and there are multiple permutations of groups that have implied policy logic and that logic provides access to the same sets of objects, then you are in a situation with role explosion. This is a problem that Immuta can help you solve, and you should solve that problem with ABAC.

The one exception where you have the above scenario but may want to use orchestrated RBAC is if these multiple paths for access to the same objects are a true hierarchy. For example, data is tagged with Strictly Confidential, Confidential, Internal, and Public:

• users assigned group Strictly Confidential can see data tagged Strictly Confidential, Confidential, Internal, and Public

• users assigned group Confidential can see data tagged Confidential, Internal, and Public

In this case, you could use orchestrated RBAC even though there are multiple paths of access to the same objects because it is a one-to-one relationship represented in a hierarchy that contains all paths. How you actually write this policy will be described later.

Orchestrated RBAC: user attributes and groups

Since orchestrated RBAC is a one-to-one match (or a true hierarchy), you can use your groups as-is from your identity manager or other custom sources.

Without getting into the details of how the policy is authored (yet), it is possible to leverage a user attribute hierarchy to contribute to access decisions through hierarchical matching. For example, users with attributes that are either a hierarchical parent or an exact match to a given data tag can be subscribed to the data source via a hierarchical match. To better illustrate this behavior, see the matrix below:

So you should take care organizing your user attributes with a hierarchy that will support the hierarchical matching.

Going back to our hierarchical example of Strictly Confidential, Confidential, Internal, and Public above, you would want to ensure that user attributes follow the same hierarchy. For example,

• A user with access to all data: Classification: Strictly Confidential

• A user with access to only Internal and Public: Classification: Strictly Confidential.Confidential.Internal

Remembering the last row in Figure 3, hierarchical matching only happens in a single direction → user attribute contains the data source tag. Since the user attribute is more specific (Strictly Confidential.Confidential.Internal) than data tagged Strictly Confidential and Strictly Confidential.Confidential, the user would only gain access to data tagged Strictly Confidential.Confidential.Internal and Strictly Confidential.Confidential.Internal.Public.

ABAC: user attributes and groups

To use ABAC, you need to divorce your mind from thinking that every permutation of access requires a new role. (We use the word role interchangeably with groups in this document, because many identity and access systems call groups roles, especially when they contain policy logic.)

Instead you need to focus on the facts about your users they must possess in order to grant them access to data. Ask yourself, why should someone have access to this data? It’s easiest to come at this from the compliance perspective and literally ask yourself that question for all the compliance rules that exist in your organization.

Why should someone have access to my PHI data? Example answers might be

• If they are an analyst

• If they have taken privacy training

So, at a minimum, you are going to need to attach attributes or groups to users representing if they are an analyst and if they have taken privacy training. Note you do not have to (nor should you) negate these attributes, meaning nobody should have a group not_analyst and no_privacy_training.

Repeat this process until you have a good starting point for the user attributes you need. This is a lot of upfront work and may lead to the perception that ABAC also suffers from attribute explosion. However, when attributes are well enumerated, there’s a natural limit to how many different relevant attributes will be present in an organization. This differs substantially from the world where every permutation of access is represented with a role, where role growth starts off slow, but increases linearly over time.

As an illustration, well-defined subject attributes tend to follow the red curve over time, while roles and poorly defined subject attributes tend to follow the blue and quickly become unwieldy.

Applying user metadata

Where do those attributes and groups come from? Really, wherever you want - Immuta has several interfaces to make this work, and you can combine them:

Option 1: Store them in your identity manager. If you have the power to do this, you should. It becomes the primary source of facts about your users instead of the source of policy decisions, which should not live in your identity manager. We recommend synchronizing this user metadata from your identity manager to Immuta over SCIM where possible.

Option 2: Store them directly in Immuta. It is possible to manually add attributes and groups to users directly in the Immuta UI or through the API.

Option 3: Refer to them from some other external source of truth. For example, perhaps training courses are already stored in another system. If so, you can able to build an external user into endpoint to pull those groups (or attributes) into Immuta. However, there are some considerations with this approach tied to which IAM protocol you use. If your identity manager restricts you from using the approach in the “Consume attributes/groups from arbitrary sources” row in the IAM protocol table, you can instead periodically push the attributes from the source of truth into Immuta using our APIs.

All of these options assume you have already configured your identity manager in Immuta. This has to be done in order to create the user identities that these attributes and groups will be attached to.

Next steps

Immuta permission: USER_ADMIN

Prerequisite

Identity access manager configured

Select your metadata strategy

• Fact-based (ABAC): Use this strategy if you have many variables that determine access.

• Logic-based (orchestrated RBAC): Use this strategy if a single variable determines access.

Organize your user metadata

Add user metadata to Immuta

Once you've organized your user metadata, you can add that metadata in Immuta in these ways:

1. Add attributes and groups to users in your identity manager. Then, sync your users, groups, and attributes from your external identity manager to Immuta:

   1. LDAP: Enable LDAP sync and sync groups and attributes to Immuta for your provider.

   2. OpenID Connect or SAML: Enable SCIM for your provider and enable sync attributes and groups.

Next steps

• A user with access to all data: Classification: Strictly Confidential

• A user with access to only Internal and Public: Classification: Strictly Confidential.Confidential.Internal

With orchestrated RBAC you have established one-to-one relationships with how your users are tagged (attribute or group) and what that single tag explicitly gives them access to. Remember, the user and data metadata should be facts and not reflect policy decisions veiled in a single fact; otherwise, you are setting yourself up for role explosion and should be using ABAC instead.

Since orchestrated RBAC is all about one-to-one matching of user metadata to data metadata, Immuta has special functions in our subscription policies for managing this:

• @hasTagAsAttribute('Attribute Name', 'dataSource' | 'column')

• @hasTagAsGroup('dataSource' | 'column')

The first argument for @hasTagAsAttribute is the attribute key whose value tags will be matched against (or for @hasTagAsGroup simply the group name), and the second argument specifies whether the attribute values are matched against data source tags or column tags.

Understanding this, let’s use a simple example before we get into a hierarchical example. For this simple example, let’s say there are Strictly Confidential tables and Public Tables. Everyone has access to Public, and only special people have access to Strictly Confidential. Let’s also pretend there aren’t other decisions involved with someone getting access to Strictly Confidential (there probably is, but we’ll talk more about this in the ABAC path). It is just a single fact: you do or you don’t have that fact associated with you.

Then we could tag our users with their access under the Access attribute key:

• Bob: Access: Strictly Confidential

• Steve: Access: Public

Then we could also tag our tables with the same metadata:

• Table 1: Strictly Confidential

• Table 2: Public

Now we build a grant subscription policy using the advanced DSL builder that targets all tables:

Allow users to subscribe with read access when @hasTagAsAttribute(Access,dataSource) on all data sources.

Here is the policy definition payload YAML for the above policy using the v2 api:

Since this policy applies to all data sources, you only need a single policy in Immuta. When you change user metadata or data metadata, the access to those tables will automatically be updated by Immuta through the matching algorithm (user metadata matches the data metadata).

We could also use column tags instead, by tagging the columns appropriately:

• Table 1 -> Column 2: Strictly Confidential

  This tag change would require the following alteration to the function: @hasTagAsAttribute('Access', 'column') instead of @hasTagAsAttribute('Access', 'dataSource').

Finally, we could use groups instead of attributes:

• Bob: Strictly Confidential

• Steve: Public

  This change would require the following alteration to the function: @hasTagAsGroup('Access', 'column') instead of @hasTagAsAttribute('Access', 'column').

In the above case, we are using column tags again, but it could (and probably should) be data source tags. The reason is that orchestrated RBAC is not using facts about what is in your data source (the table) to determine access. Instead, it's using the single variable as a tag, and because of that, the single variable is better represented as a table tag. This also reduces the amount of processing Immuta has to do behind the scenes.

We can get more complicated with a hierarchy as well, but the approach remains the same: you need a single policy and you use the hierarchy to solve who should gain access to what by moving from most restrictive to least restrictive in your hierarchy tree on both the users and data metadata.

Groups approach:

• Bob: Strictly Confidential

• Steve: Strictly Confidential.Confidential.Internal.Public

In this case, Steve would only gain access to tables or tables with columns tagged Strictly Confidential.Confidential.Internal.Public, but Bob would have access to tables or tables with columns tagged Strictly Confidential, Strictly Confidential.Confidential, Strictly Confidential.Confidential.Internal, and Strictly Confidential.Confidential.Internal.Public.

Orchestrated RBAC one-to-one matching can be powerful, but can also be a slippery slope to role explosion. You can quickly fall into rolling-up many decisions into a single group or attribute tied to the user (like Strictly Confidential) instead of prescriptively describing the real root reason of why someone should have access to Strictly Confidential in your policy engine. This is the power behind ABAC, and using the ABAC method of access can give you ultimate scalability and evolvability of policy with ease.

Path 2: ABAC policy authoring

Let’s say that having access to Strictly Confidential data isn’t a single simple fact attached to a user like we described in the orchestrated RBAC section (it likely isn't). Instead, let’s try to boil down why you would give someone access to Strictly Confidential. Let’s say that to have access to Strictly Confidential, someone should be

• an employee (not contractor)

• in the US

• part of the Legal team

Those are clearly facts about users, more so than Strictly Confidential. If you can get to the root of the question like this, you should, because Immuta allows you to pull in that information about users to drive policy.

Why should you bother getting to the root?

Well, consider what we just learned about how to author policy with orchestrated RBAC above. Now let’s say your organization changes their mind and now wants the policy for access to Strictly Confidential to be this:

• be an employee (not contractor)

• be in the US or France

• be part of the Legal team

With orchestrated RBAC this would be a nightmare, unless you already have a process to handle it. You would have to manually figure out all the users that meet that new criteria (in France) and update them in and out of Strictly Confidential. This is why orchestrated RBAC should always use a single fact that gains a user access.

However, if you are on the ABAC path, it’s a single simple policy logic change because of our powerful triangle that decouples policy logic from user and metadata attributes.

Let’s walk through an example:

The best approach is to build individual policies for each segment of logic associated with why someone should have access to Strictly Confidential information. Coming back to the original logic above, that would mean 3 (much more understandable) separate policies:

Policy #1: Employee Access

Author a guardrail policy that grants read access to users who are a member of group Employees that applies to columns tagged Strictly Confidential:

Prevent users from subscribing with read access unless user is a member of group Employees on data sources with columns tagged Strictly Confidential.

Here is the policy definition payload YAML for the above policy using the v2 api:

Policy #2: Country Access

Author a guardrail policy that grants read access to users with attribute Country.US that applies to columns tagged Strictly Confidential:

Prevent users from subscribing with read access unless user possesses attribute Country with value US on data sources with columns tagged Strictly Confidential.

Here is the policy definition payload YAML for the above policy using the v2 api:

Policy #3: Legal Team Access

Author a guardrail policy that grants read access to users who are a member of group Legal Team that applies to columns tagged Strictly Confidential:

Prevent users from subscribing with read access unless user is a member of group Legal Team on data sources with columns tagged Strictly Confidential.

Here is the policy definition payload YAML for the above policy using the v2 api:

Each policy targets columns tagged Strictly Confidential (they could alternatively target tables tagged that). When each of those policies converge on a single table tagged Strictly Confidential, they will be merged together appropriately by Immuta, demonstrating Immuta's conflict resolution:

Allow users to subscribe to the data source when user (@isInGroups('Legal Team')) AND (@isInGroups('Employees')) AND (@hasAttribute('Country', 'US')).

And whether merged with an AND or an OR is prescribed by which subscription policy type is selected in the policy builder for each of the 3 individual policies:

• Guardrail: Multiple guardrail policies will result in an AND

• Grant: Multiple grant policies will result in an OR.

In this case, each of the 3 policies were guardrail policies, which is why the three policies were AND’ed together on merge. Note this merging behavior is relevant to how you can have different users manage policies without risk of conflicts. See the Subscription policy reference guide for details about these two policy types.

Now let’s move into our nightmare (without Immuta) scenario where the business has changed the definition of who should have access to Strictly Confidential data by adding France along with the other existing three requirements.

With Immuta, all you’ve got to do is change that single Country Access subscription policy to include France, and voila, you’re done:

Prevent users from subscribing with read access unless user possesses attribute Country with value US OR France on data sources with columns tagged Strictly Confidential.

Here is the policy definition payload YAML for the above policy using the v2 api:

Which results in this merged policy on all the Strictly Confidential tagged tables:

Allow users to subscribe to the data source when user (@isInGroups('Legal Team')) AND (@isInGroups('Employees')) AND (@hasAttribute('Country', 'US') or @hasAttribute('Country', 'France')).

As you can see, ABAC is much more scalable and evolvable. Policy management becomes a breeze if you are able to capture facts about your users and facts about your data, and decouple policy decisions from it.

Also be aware, this auto-merging logic Immuta provides enables you to also combine orchestrated RBAC and ABAC policies.

Manual overrides of grant subscription policies

Last but not least are manual overrides for grant subscription policies. While this use case is all about automating access decisions, there may be cases where you want to give a user access even if they don’t meet the automated criteria.

This is possible through the Request Approval to Access setting on a grant subscription policy:

In this scenario, users marked as Owner of the registered data source in Immuta have the power to approve this override request by the user. There are ways to specify different approvers as well, or multiple approvers.

Also notice the grayed out Allow Data Source Discovery: normally, if you do not meet the criteria of a policy, the data source is not even visible to you in the Immuta UI or the data platform. However, if you have this checked, it is visible in the Immuta UI even if you don’t meet the policy. This must be checked in order to request approval to access. Otherwise, users would never find the data source to ask for approval in the Immuta UI.

Be aware that all policies that land on the table must have this same setting turned on in order to allow the manual override.

Next steps

Immuta permission: APPLICATION_ADMIN (if using an external catalog or identification) or GOVERNANCE (if manually adding tags in Immuta)

Prerequisites

• Data platform connected to Immuta

• Data sources registered in Immuta

• External catalog connected to Immuta (optional)

Select your strategy

• Fact-based (ABAC): Use this strategy to tag data sources at the column and table level.

• Logic-based (orchestrated RBAC): Use this strategy to tag data sources at the table level.

Organize your data metadata

Enable schema monitoring

Enable schema monitoring to allow Immuta to actively monitor your data platform to find when new tables or columns are created or deleted. Immuta will then automatically register or disable those tables and update the tags.

If you registered your data through connections, object sync will ensure the objects in your database stay synchronous with the registered objects in Immuta.

Apply tags to data in Immuta

There are several options for applying data tags:

1. Use identification: This is the most powerful option. Immuta can discover your sensitive data, and you can extend what types of entities are discovered to those specific to your business. Identification can run completely within your data platform, with no data leaving at all for Immuta to analyze. Identification is more relevant for the ABAC approach because the tags are facts about the data.

2. Sync tags from an external source: You may have already done all the work tagging your data in some external catalog or your own homegrown tool. If so, Immuta can pull those tags in and use them.

3. Manually tag: Manually tag tables and columns in Immuta from within the UI, using the Immuta API, or when registering the data, either during initial registration or subsequent tables discovered in the future through .

Next steps