Local Policies in Immuta
Audience: Data Owners and Governors
Content Summary: Policies in Immuta are managed and applied to data sources and projects by Data Owners and Governors to restrict access to data. Global Policies are created by Data Governors and apply to all data sources across an organization. In contrast, Local Policies can be created by Data Owners or Data Governors and apply to a specific data source. This page details the types of Local Policies in Immuta: Subscription Policies and Data Policies.
Introduction
Data Source Policies Tab Components
Data Owners and Governors can access the Policies tab from the Data Source Overview page. After navigating to the Policies tab, users can apply policies to the data source with the following features:
-
Apply Existing Policies Button: By clicking this button in the top right corner of the Policies tab, users can search for and apply existing policies to the data source from other data sources or Global Policies.
-
Subscription Policy Builder: In this section, users can determine who may access the data source. If a Subscription Policy has already been set by a Global Policy, a notification and a Disable button appear at the bottom of this section. Users can click the Disable button to make changes to the Subscription Policy.
-
Data Policy Builder: In this section, users can create policies to enforce privacy controls on the data source. A list of data policies currently applied to the data source populates here as well.
All changes made to policies by Data Owners or Governors appear in a collapsible Activity panel on the right side of the screen.
The information recorded in the Activity panel includes when the data source was created, the name and type of the policy, when the policy was applied or changed, and if the policy is in conflict on the data source. Additionally, Global policy changes are identified by the Governance icon; all other updates are labeled by the data sources icon.
Subscription Policies
Data Owners control how subscribers gain access to a data source through Subscription Policies.
These policies comprise four levels of restriction:
- Anyone: Users are automatically granted access.
- Anyone Who Asks (and is Approved): Users must request access and then be approved. This restriction supports multiple approving parties, meaning that Data Owners can allow more than one approver or users with specified permission types to approve other users who subscribe to the data source.
- Users with Specific Groups/Attributes: Only users with the groups/attributes Data Owners specify will be able to see and access the data source.
- Individual Users You Select: Only users Data Owners manually select will be able to see and access the data source.
See Write a Local Policy for a tutorial.
Data Policies
Data Policies determine what data users see when they've gained access to a data source. The types of Data Policies are defined below.
| Policy Type | Description |
|---|---|
| Masking | Masking policies hide values in data, providing various levels of utility while still preserving privacy. |
| Row Redaction | For query-backed data sources, Data Owners can restrict which rows in the data source tables are visible to which users. This redaction is done by matching values in a specific column against a user's groups, attributes, or purposes. |
| Minimization | These policies hide a specified percentage of query results from a user, based on a column with high cardinality (e.g., an employee ID number or other unique identifier). |
| Time-Based Restrictions | If a data source has time-based restriction policies, queries run against the data source by a user will only return rows/blobs with a date in its event-time column/attribute from within a certain range. |
| Purpose-Based Restrictions | Data Owners can restrict usage of any data source to one or more purposes. If a user wishes to run SQL queries against a purpose-restricted data source, they must use the SQL credentials provided by a project containing that purpose. |
See Write a Local Data Policy for a tutorial.
Inclusionary Policies
For all policies except purpose-based restriction policies, inclusionary logic allows Data Owners to vary policy actions with an Otherwise clause.
For example, Data Owners could mask values using hashing for users acting under a specified purpose while masking those same values by making null for everyone else who accesses the data.
This variation can be created by selecting for everyone who when available from the condition dropdown menus and then completing the Otherwise clause.
SQL Support Matrix
The SQL Support Matrix button in the top right corner of the Data Policy Builder allows users to view all masking policy types and details what is supported for each integration.
Integration Support Matrix
Certain policies are not supported, or supported with caveats*, depending on the integration:
*Supported with Caveats:
- On Databricks data sources, joins will not be allowed on data protected with replace with NULL/constant policies.
- On Trino data sources, the Immuta functions
@iamand@interpolatedComparisonfor WHERE clause policies can block the creation of views.