This guide describes how to organize and manage user metadata, which is used by Immuta to identify users targeted by policy.

No matter if you choose orchestrated RBAC or ABAC as described in the Governance use cases introduction, you must have metadata on your users. This can be done in Immuta, via your identity manager, or other custom sources.

Doing so allows you to build scalable policies that do not reference individual users and instead use metadata about them to target them with access decisions. In Immuta, user metadata is termed user attributes and groups.

Considerations

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 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

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

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 . 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 .

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 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 or other .

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 . 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 . 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 . 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 , 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 . This has to be done in order to create the user identities that these attributes and groups will be attached to.

Next steps

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

• and 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 on the methodology.

Table vs column access

Lastly, this use case is primarily focused on automating table grants, termed in Immuta. We recommend you also read the 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: (Immuta is an OT-ABAC approach)

• Forrester:

Next steps

Authoring global subscription policies to automate access controls involves using the data metadata and user metadata in Immuta to identify the data that should be governed and the users the policy should target.

This how-to guide demonstrates how to author a global subscription policy in Immuta to automat access decisions.

For detailed explanations and examples of how to author subscription policies, see the Author policy guide.

Requirements

Immuta permission: GOVERNANCE global permission, Manage Policies domain permission, or own the data source

Prerequisites

Understand your metadata

How you author policies is dictated by how your user and data metadata is organized to grant access:

• : Many variables determine access, and data sources are tagged at the column and table level.

• : A

Author a subscription policy

Next steps

Before authoring global subscription policies to automate access controls, data metadata must exist in Immuta so that it can be used in the policy to identify the data that should be governed.

This how-to guide demonstrates how to manually manage tags, use data identification, or use existing tags in external catalogs to identify data that should be governed by a subscription policy.

For detailed explanations and examples of how to manage data metadata, see the .

Requirement

Immuta permission: APPLICATION_ADMIN

Once user and data metadata have been added in Immuta, you can use that metadata to create subscription policies that automate granting or revoking access to users. This guide describes how to author policies for orchestrated RBAC and ABAC models.

Now we are ready to focus on the third point of the triangle for data access decisions: access control policies, and, more specifically, how you can author them with Immuta now that you have the foundation with your data and user metadata in place.

It’s important to understand that you only need a starting point to begin onboarding data access control use cases - you do not have to have every user perfectly associated with metadata for all use cases, nor do you need all data tagged perfectly for all use cases. Start small on a focused access control use case, and grow from there.

The policy authoring approaches are broken into the two paths you should choose between discussed previously.

Path 1: Orchestrated RBAC policy authoring

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 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 :

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 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 :

Policy #2: Country Access

Author a 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 :

Policy #3: Legal Team Access

Author a 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 :

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:

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 will result in an AND

• Grant: Multiple 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 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 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 :

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

As you can see, ABAC is much more scalable and evolvable. Policy management becomes a breeze if you are able to capture and , 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 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

This guide describes how to organize and manage data metadata, which is used by Immuta to identify data targeted by policy.

Considerations

Now that we’ve enriched facts about our users, let’s focus on the second point on the policy triangle diagram: the data tags.

Just like you need user metadata, you need metadata on your data (tags) in order to decouple policy logic from referencing physical tables or columns. You must choose between the orchestrated RBAC or ABAC method of data access:

• Orchestrated RBAC method: tag data sources at the table level

• ABAC method: tag data at the table and column level

While it is possible to target policies using both table- and column-level tags, for ABAC it’s more common to target column tags because they represent more granularly what is in the table. Just like user metadata needs to be facts about your users, the data metadata must be facts about the data. The tags on your tables should not contain any policy logic.

Fact-based column tags are descriptive (recommended):

• Column ssn has column tag social security number

• Column f_name has column tag name

• Column dob has column tags date

Logic-based column tags requires subjective decisions (not recommended):

• Column ssn has column tag PII

• Column f_name has column tag sensitive

• Column dob has column tag indirect identifier

But can't I get policy authoring scalability by tagging things with higher level classifications, like PII, so I can build broader policies? This is what Immuta’s are for.

Entity tags are facts about the contents of individual columns in isolation. Entity tags are what we listed above: social security number, name, date, and data of birth. Entity tags do not attempt to contextualize column contents with neighboring columns' contents. Instead, categorization and classification tags describe the sensitive contents of a table with the context of all its columns, which is what is listed in the logic-based tags above, things like PII, sensitive, and indirect identifier.

For example, under the HIPAA framework a list of procedures a doctor performed is only considered protected health information (PHI) if it can be associated with the identity of patients. Since entity tagging operates on a single column-by-column basis, it can’t reason whether or not a column containing procedure codes merits classification as PHI. Therefore, entity tagging will not tag procedure codes as PHI. But categorization tagging will tag it PHI if it detects patient identity information in the other columns of the table.

Additionally, entity tagging does not indicate how sensitive the data is, but categorization tags carry a sensitivity level, the classification tag. For example, an entity tag may identify a column that contains telephone numbers, but the entity tag alone cannot say that the column is sensitive. A phone number associated with a person may be classified as sensitive, while the publicly-listed phone number of a company might not be considered sensitive.

Contextual tags are really what you should target with policy where possible. This provides a way to create higher level objects for more scalable and generic policy. Rather than building a policy like “allow access to tables with columns tagged person name and phone number,” it would be much easier to build it like “allow access to tables with columns tagged PII.”

In short, you must tag your entities, and then rely on a classification framework (provided by Immuta or customized by you) to provide the higher level context, also as tags. Remember, the owners of the tables (those who created them) can tag the data with facts about what is in the columns without having to understand the higher level implications of those tags (categorization and classification). This allows better separation of duty.

For orchestrated-RBAC, the data tags are no longer facts about your data, they are instead a single variable that determines access. As such, they should be table-level tags (which also improves the amount of processing Immuta must do).

Applying data tags

There are several options for applying data tags:

1. Identification: This is the most powerful option. Immuta is able to , and you are able to 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. 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. See the for a list of the supported external catalogs. But remember, just like user metadata, these should represent facts about your data and not policy decisions.

3. Manually tag: Just like with user metadata, you are able to manually tag tables and columns in Immuta from , using the , or when registering the data, either during initial registration or subsequent tables discovered in the future through schema monitoring.

Data tag hierarchy

Just like hierarchy has an impact with user metadata, so can data tag hierarchy. We discussed the matching of user metadata to data metadata in the guide. However, there are even simpler approaches that can leverage data tag hierarchy beyond matching. This will be covered in more detail in the guide, but is important to understand as you think through data tagging.

As a quick example, it is possible to tag your data with Cars and then also tag that same data with more specific tags (in the hierarchy) such as Cars.Nissan.Xterra. Then, when you build policies, you could allow access to tables tagged Cars to administrators, but only those tagged Cars.Nissan.Xterra to suv_inspectors. This will result in two separate policies landing on the same table, and the beauty of Immuta is that it will handle the conflict of those two separate policies. This provides a large amount of scalability because you have to manage far fewer policies.

Imagine if you didn’t have this capability? You would have to include administrators access to every policy you created for the different vehicle makes - and if that policy needed to evolve, such as adding more than administrators to all cars, it would be an enormous effort to make that change. With Immuta, it’s one policy change.

Next steps

Before authoring global subscription policies to automate access controls, user metadata must exist in Immuta so that it can be used in the policy to identify the users that should be granted or revoked access to data.

This how-to guide demonstrates how to manually add groups and attributes or use existing groups in external identity managers to identify users that should be targeted by a subscription policy.

For detailed explanations and examples of how to manage user metadata, see the Managing user metadata guide.

Requirements

Immuta permission: USER_ADMIN

Prerequisite

Select your metadata strategy

• : Use this strategy if you have many variables that determine access.

• : Use this strategy if a

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. : Enable LDAP sync and sync groups and attributes to Immuta for your provider.

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

Next steps