Understanding Masking Exceptions and Underlying Policies

Public preview: The Marketplace app is available to select accounts. Contact your Immuta representative for details.

One of the key benefits of using the Immuta Marketplace app 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 Marketplace 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 data products are published

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 in Marketplace, the columns can be found by data consumers in the Columns tab. 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 Immuta Governance app:

1. The columns requested are tagged with a new tag:

   Immuta Marketplace.[data product ID].[data source ID].[column name].Masking Exception

   This ensures that exceptions are uniquely scoped to both the product and the column. This way, if access is provisioned through two different data products, 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 products.

2. The user that was approved access has a new attribute added to them, which cannot be removed unless the user is manually revoked access through Marketplace or the data product is deleted:

   Immuta Marketplace Masking Exception: Immuta Marketplace.[data product ID].[data source ID].[column name].Masking Exception

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.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 on data platforms where Immuta supports data policies with the exception of . See the current support matrix below:

	Masking policies	Masking exceptions
Amazon Redshift	✅	✅
Amazon S3	❌	❌
AWS Lake Formation	❌	❌
Azure Synapse Analytics	✅	✅
Databricks Unity Catalog	✅	✅
Databricks Spark	✅	❌
Google BigQuery	✅	✅
Oracle	❌	❌
PostgreSQL	❌	❌
Snowflake	✅	✅
SQL Server	❌	❌
Starburst (Trino)	✅	❌
Teradata	❌	❌

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. Soon, your exception status will also appear.

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

• Masking exception requests will not have notifications.