We have all seen capabilities for publishing data products, surfacing them for data consumers to discover and request access, and making access decisions. But what about when that data product contains sensitive columns that some users should see but others should not?
The state-of-the-art solution to date for this workflow has been to publish multiple versions of the same data product to accommodate different access levels. For example, you might create a “Public” version versus a “Highly Sensitive” version, with potentially many versions in between where some set of the data’s columns is hidden across them.
This approach can be extremely challenging to manage because:
How can we make this a better experience for the data product owners, the consumers requesting access, and the stewards reviewing those requests?
Rather than creating multiple versions to accommodate different access levels, Immuta allows data stewards to approve removal of specific column masks on a per-request basis.
For example, a user can request full access to a set of sensitive columns in a data product. If approved, Immuta modifies the masking policy behind the scenes – without exposing more than what was requested. The data product owner still maintains a single data product, but access becomes personalized.
For the data product owner, this greatly simplifies publishing. Owners can publish a single data product, knowing that masking and exception handling are managed dynamically by policy. Need to give a marketing analyst access to masked email fields but allow an investigator to see full PII? Same data product – different access, granted safely and auditably. The result: less duplication, less overhead, and more confidence that access is aligned with business intent.
For the data consumer, it is also a seamless experience. Once they have access to the data in the data product, it will become clear which columns they need access to in order to accomplish the task at hand. They can simply request access to those very specific columns, and if approved, a dynamic update to the masking policy exceptions in the data platform will provision those columns. No need for an administrator to manually run commands. Data consumers get immediate access to what they need – no more, no less.
For the steward who is responsible for reviewing the access requests, it is clear which columns were requested, how they were tagged to understand their sensitivity level, how they are currently masked, and what utility that masking type provides to aid their decision. They also have the ability to temporarily approve access to the columns in question, reducing risk. And our Review Assist feature will also aid the steward with recommendations based on past approvals to similarly tagged columns.
How does this feature provide value in real customer use cases?
Prior to the availability of this feature, one of our health insurer customers would manage masking exceptions globally. When a user needed access to PII and was approved to do so, they would get access to all PII across all tables(!!). With this feature, their break-glass process is now granular, provisioning only exactly what the user requires.
Another customer, a payroll solution provider, needs to remove masks only for legitimate access purposes. Upon request to have a mask removed, they are now able to require that the requestor provide the purpose via a pre-set list, using our custom request form capability. And if approved, users gain access to only those requested columns.
Finally, internally at Immuta we can use our own software to investigate support tickets in our SaaS environment. All customer-sensitive data is masked from our teams, unless approved for temporary access (a very short period of time). A request can be pushed through our own formal channels and, if approved, access is temporarily provided to diagnose the support case. As with both examples above, access is only given to the precise columns required to do the job.
We’ve discussed how this feature supports revealing masked columns, but what about filtered rows? That’s what’s coming next. Similar to requests to have masks removed for a column, users will be able to request that the row filter be altered. If approved, that underlying policy will be dynamically adjusted to reveal the appropriate approved data – no more, no less.
Explore Immuta AI features.
