Global Policies in Immuta
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 Global Policies in Immuta: Global Subscription Policies and Global Data Policies.
Best Practice: Access Controls
In most cases, the goal is to share as much data as possible while still being compliant with privacy regulations. Immuta recommends a scale of wide Subscription Policies and specific Data Policies to give as much access as possible.
Governors 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 Global Subscription Policy for a tutorial.
ABAC Global Subscription Policies Using Advanced DSL
Users can create more complex policies using functions and variables in the Advanced DSL policy builder than the Subscription Policy builder allows.
After an Application Admin has enabled Enhanced Subscription Policy Variables (Public Preview), Data Governors and Owners can create Global Subscription policies using all the functions and variables outlined below.
|@database||Users who have an attribute key that matches a database will be subscribed to the data source(s) within the database.||@hasAttribute('SpecialAccess', '@hostname.@database.*'): If a user had the attribute
|@hasAttribute('Attribute Name', 'Attribute Value')||Users who have the specified attribute are subscribed to the data source.||@hasAttribute('Occupation', 'Manager'): Any user who has the attribute
|@hasTagAsAttribute('Attribute Name', 'dataSource' or 'column' )||Users who have an attribute key that matches a tag on a data source or column will be subscribed to that data source.||@hasTagAsAttribute('PersonalData', 'dataSource'): Users who have the attribute key
|@hasTagAsGroup('dataSource' or 'column' )||Users who are members of a group that matches a tag on a data source or column (respectively) will be subscribed to that data source.||@hasTagAsGroup('dataSource'): If Data Source 1 has the tags
|@hostname||Users who have an attribute key that match a hostname will be subscribed to the data source(s) with that hostname.||@hasAttribute('SpecialAccess', '@hostname.*'): If a user had the attribute
|@iam||Users who sign in with the IAM with the specified ID (ID that displays on the App Settings page) will be subscribed to the data source.||@iam == 'oktaSamlIAM': Any user whose IAM ID is
|@isInGroups('List', 'of', 'Groups')||Users who are members of the specified group(s) can be subscribed to the data source.||@isInGroups('finance','marketing','newhire'): Users who are members of the groups
|@schema||Users who have an attribute key that match this schema will be subscribed to the data source(s) under that schema.||@hasAttribute('SpecialAccess', '@hostname.@database.@schema'): If a user had the attribute
|@table||Users who have an attribute key that match this table will be subscribed to the data source(s).||@hasAttribute('SpecialAccess', '@hostname.@database.@schema.@table'): If a user had the attribute
Manual Approvals in ABAC Global Subscription Policies
Users can specify more than one level of criteria for the Users with Specific Groups/Attributes (or ABAC) Global Subscription Policy. Specifically, users can combine manual approvals with an ABAC Subscription Policy.
After a user selects Users with Specific Groups/Attributes in the Global Subscription Policy builder, they can also enable Request Approval to Access. Selecting this option allows users to request access to a data source and be manually approved by a specified user, even if the requesting user does not meet the group or attribute conditions in the policy. By allowing an approval workflow as an alternative method of access if a user does not meet the ABAC conditions, this feature can reduce the number of policies required and allow more flexibility in approval workflows.
See Global Subscription Policy Merging for a tutorial.
Manually added users will now see data regardless of meeting policy conditions.
In previous versions of Immuta, users who had been manually subscribed to a data source could not see any data. Now, these manually added users will see data even though they don't meet the ABAC conditions in the policy. Governors can change the behavior by switching the Subscription policy to auto-subscribe (which removes any users who don't meet the Subscription policy) or by adding a data policy that redacts rows for users who do not have the groups or attributes specified in the Subscription policy.
Additional Policy Options
Beyond Request Approval to Access, these options are also available:
Allow Data Source Discovery: Users can still see that this data source exists in Immuta, even if they do not have these attributes and groups. This option will automatically be selected and locked if users select Request Approval to Access.
Note: When these policies merge, if one or more policies do not have discovery enabled, then approvals will be removed from the final merged policy.
Require Manual Subscription: Users will not be automatically subscribed to the data source. They must manually subscribe to gain access.
Conditions for Policy Merges
Governors must also select how this policy should be merged with other policies that apply to the same data source:
Always Required: Users must always meet this condition, no matter what other policies apply (it will be AND'ed with other policies that apply to the data source) or
Share Responsibility: Users need to meet the conditions in this policy OR another share responsibility policy that applies to the data source. (It will be OR'ed with other shared responsibility policies that apply.)
Best Practice: Writing Policies
Use the minimum number of policies possible to achieve the data privacy needed.
Data Policies determine what data users see when they've gained access to a data source. The types of Data Policies are defined below, but for a detailed explanation of each type, see the Reference Guide.
|Masking||Masking policies hide values in data, providing various levels of utility while still preserving privacy.|
|Row Redaction||For query-backed data sources, Governors 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
|Purpose-Based Restrictions||Governors in Immuta 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 Global Data Policy for a tutorial.
For all policies except purpose-based restriction policies, inclusionary logic allows Governors to vary policy actions with an Otherwise clause.
For example, Governors 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.
Global Data Policy Custom Certifications
When building a Global Data Policy, Governors can create custom certifications, which must then be acknowledged by Data Owners when the policy is applied to data sources.
When a Global Data Policy with a custom certification is cloned, the certification is also cloned. If the user who clones the policy and custom certification is not a Governor, the policy will only be applied to data sources that user owns.
Templated Global Data Policies
Immuta includes two templated Global Policies: the HIPAA De-identification Policy and the California Consumer Privacy Act (CCPA) Policy. Governors can activate these Global Policies to automatically enforce restrictions on data sources that have had relevant tags applied to them by users or Sensitive Data Discovery.
To learn how to activate a templated policy, navigate to the tutorial.
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
@interpolatedComparisonfor WHERE clause policies can block the creation of views.
- Staged Policies
- Policies in this state are not enforced by Immuta in any access pattern.
- Policies are staged during policy authoring when policy details are being regularly changed. Since a staged policy is not enforced, this state is also useful when editing a policy.
- The staged state is useful for temporarily lifting a policy's enforcement without completely deleting the policy because a staged policy can quickly and easily be re-enforced.
- Active Policies
- Policies in this state are actively enforced by Immuta across all access patterns.
- While in the active state, policies can be edited. Once saved, Immuta immediately enforces any changes made.
- Disabled Policies
- Only Governors and Data Owners can place global policies in this state. This is done at the local level within a data source.
- While in this state, disabled policies are not enforced on the data source. This is similar to staged policies; however, policies can only be disabled at the local level, so they are still enforced on other data sources.
- Deleted Policies
- Deleted policies are not enforced by Immuta in any access pattern and are not able to be reactivated.
- In contrast to the above types of policies, deleted policies cannot move from one state to another.
- Exercise caution when deleting policies. Once a policy is deleted, it cannot be recovered.
Staged Global Policies
Governors stage Global Policies to safely review and edit them without affecting data sources. Once a policy is ready, Governors can activate it to immediately enforce the policy on relevant data sources. See Clone, Activate, or Stage a Global Policy for a tutorial.
Note: Policies that contain the circumstance When selected by data owners cannot be staged.