Understanding Masking Exceptions and Underlying Policies

Public preview: The masking exceptions feature is available to select accounts. Contact your Immuta representative for details.

One of the key benefits of using Immuta is that provisioning for masking exceptions is automatic. This means you can request an exception to any Immuta masking policy and if you're approved for an exception, Immuta automatically updates policies in the data platform so that the approved columns are unmasked for you, while the rest of the policy continues to apply to everyone else.

This is handled using the same Immuta attribute-based access control (ABAC) model that powers all provisioning. Rather than exposing roles or creating duplicate masking policies, Immuta calculates the most efficient exception policy within the data platform and applies it, invisibly and seamlessly to the end user.

Below are the actions Immuta takes in order to provision masking exceptions.

Before any access requests are made

Immuta creates a single global masking exception policy in the Governance app that is ready to service exception approvals. With just this one policy, all masking exception requests can be provisioned. That policy will check if the attribute on the user matches the tag on the column, and if it does, that user is added as an exception to the masking policy.

This policy is hidden in the Governance app, ensuring it is protected and cannot be altered or deleted.

When a data product is published

When a new data product is published, the columns can be found by data consumers in the Columns tab of the data product. Columns that have a masking policy applied will be marked on this page, showing as masked. At this point, no masking exception tags exist yet, but data consumers can select these columns and make a masking exception request. You do not need to be a member of the data product to make a masking exception request.

Once that request is approved, masking exception tags will be added.

When a user is approved for a masking exception

When a data steward approves a masking exception request, the following actions occur in the Governance app:

1. The columns requested are tagged with a new tag depending on if the request came from an asset or a data product:

   1. Asset tags: Immuta Marketplace.{asset ID}.{column name}.Masking Exception

   2. Data product tags: Immuta Marketplace.{data product ID}.{data source ID}.{column name}.Masking Exception

   These asset and data product specific tags ensure that exceptions are uniquely scoped to both the asset (or data product) and the column. This way, if access is provisioned through two different avenues, and then the access is revoked through one of them, the data consumer will still have access through the other. Additionally, it prevents conflicts where the same column appears in multiple assets and data products.

2. The user that was approved access has a new attribute added to them depending on if the approval came from an asset or a data product:

   1. Asset access attributes:

      1. Key: Immuta Marketplace Masking Exception

      2. Value: Immuta Marketplace.{asset ID}.{column name}.Masking Exception

   2. Data product access attributes:

      1. Key: Immuta Marketplace Masking Exception

      2. Value: Immuta Marketplace.{data product ID}.{data source ID}.{column name}.Masking Exception

   This new attribute cannot be removed unless the user's access is revoked or the data product is deleted.

When the attribute and tag align, Immuta provisions unmasked access for that user to just that column in the data platform and only while the user has approved access within the approved data product.

Understanding the policy

To better understand the policy and implementation, here is an example:

Create masking exception on any tag for everyone that @hasTagAsAttribute('Immuta Marketplace Masking Exception', 'column') on data sources with a column tagged Immuta Marketplace

This policy requires Immuta to check the user's attributes under the key Immuta Marketplace and see if anything under that key matches a tag on a data source column.

In this example, the following are the data product's details:

• Column: SSN

• Data product ID: cm4bn6jpi0018wvprctnj5er2

• Data source ID: f42abc99

• Tag created: Immuta Marketplace.cm4bn6jpi0018wvprctnj5er2.f42abc99.SSN.Masking Exception

In this example, the following are the data consumer's details:

• User approved: Taylor

• Attribute assigned to Taylor: Immuta Marketplace Masking Exception.Immuta Marketplace.cm4bn6jpi0018wvprctnj5er2.f42abc99.SSN.Masking Exception

Because Taylor's attribute matches the column tag, Taylor will get a masking exception on the SSN column, providing them with unmasked access to the column. All other users will continue to see the masked data.

Understanding time-bound masking exceptions

When a masking exception request is granted for a set period of time, the user is provisioned unmasked access to the approved column(s) until the expiration. Once the time period ends, Immuta automatically removes the attribute from the data consumer, which ensures the masking policy will start impacting the user again.

The user can re-request the masking exception if they need access again.

Integration support

Masking exceptions are supported with integrations where Immuta supports data policies. See the Data platforms overview page for the data policy support matrix.

Limitations

• Masking exceptions can only be applied to columns in tabular data sources (e.g., tables, views). Non-tabular data, such as S3 objects, are not supported.

• Masking exceptions only work with global data policies; local policies are not supported.

• Masking exceptions are tied to column names. If a column is renamed and masking is reapplied, the exception is believed to still be in place but it is not.

• The Columns tab only shows that a column is masked or not, regardless of your actual exception status.

• Users who do not have access to a data product, but have a masking exception for its columns will not appear in the Members tab.