Data Source Access Status
When viewing a data product, you can see details about what you’ll be able to query or unmask if approved:
The data product’s data sources (tables, views, files) and your Access Status for each
The data product’s columns and if masking is applied
Understanding access status
There are different statuses based on the type of access you want.
Data source access
There are three possible access statuses for the data sources in a data product:
Current access
: You already have access to this data source through existing policies or a data product approval.Access if approved
: You will gain access to this data source should you request access and it is approved.Access prevented
: There are existing required policies on this data source that you do not meet.
Access prevented status
It is possible that a data consumer will be blocked from accessing certain data sources, despite being granted access to a data product. This can be the case if data sources are protected by a guardrail subscription policy and the consumer does not meet the criteria defined by that policy.
For example, there may be a rule stating that only members of the group HR
can ever be eligible to be subscribed to employee data. Because of that rule, there is a guardrail subscription policy created through the Governance app on that data source that states
Prevent users from subscribing unless user is a member of group
HR
on data sources taggedemployee
.
In this case, even if a consumer was approved access to a data product containing some data sources with employee data, their access will be blocked if they are not part of the group HR
. This provides global governance a guarantee that nobody can bypass policies on extremely sensitive data sources.
If that data source is now made part of a data product, the requesting user must be a member of group HR
to gain access to that particular data source in the data product, even if approved to the data product. Should that policy change in a way that the user now meets the requirements or the user is added to group HR
, Immuta will react by updating the access, giving the user access to that particular data source.
Column access
There are two masking statuses for columns within the data sources of a data product:
Masked
: The column is currently masked by a data policy, but you can request a masking exception.—
: The column is not masked, so no exception is needed.
What happens once approved?
If approved, Immuta automatically provisions access in the data platform:
Data access requests: The user gains query access to the approved data sources in the data product.
Masking exception requests: The user sees unmasked values for the approved columns, while masking continues to apply for all other users.
In both cases, the provisioning is represented as an understandable and scalable Immuta policy, combined with any applicable birthright or guardrail policies.
Statuses are updated accordingly:
Data sources:
Current access
→Current access
Access if approved
→Current access
Access prevented
→Access prevented
Columns:
Masked
→ unmasked (for the approved user only)
The requesting user will also receive a notification through their configured notification platform (either webhook or email) that the access was approved (or denied). A history of requests and their determinations are also visible through the Marketplace app UI.
Temporary approvals
For any data product, a data steward can choose to provide a temporary approval to the access request. This provisions access to the user for a set duration of time and then rescinds access through the data product at the end of the set time. If you have temporary access to a data product, your access status will be updated: Temporarily approved
Both request types can be granted temporarily. When the approval expires, the user's access will be automatically revoked:
Data access requests: Provisioned access to data sources is revoked automatically when the duration expires.
Masking exception requests: Approved columns return to masked automatically when the duration expires.
After expiration, the user can re-request access or exceptions if needed.
Last updated
Was this helpful?