Understanding Masking Exceptions and Underlying Policies
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:
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.
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:
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.
Last updated
Was this helpful?