Policies

Immuta allows you to define policies at different levels of granularity in your data stack.

• Subscription policies: These are commonly termed table access grants or table-level access. Subscription policies control access to your tables.

• Data policies: These policies control access more granularly inside a table. For example, Immuta can help you build policies to redact rows, mask columns, or mask cells.

For details about subscription and data policy types, see the subscription policies overview or data policies overview.

Policy scope

Immuta policies restrict access to data and apply to data sources at the local, domain, or global level:

• Local policies are authored against specific tables, one at a time.

• Domain policies apply only to the data sources assigned to that domain.

• Global policies target tags instead of specific tables, allowing you to build a single policy that impacts a large percentage of your data rather than building separate local policies for each table.

Consider the following policy examples.

Local policy example

Mask using hashing the values in the columns ssn, last_name, and home_address.

Domain policy example

Only show rows where user possesses an attribute in OfficeLocation that matches the value in columns tagged Location.Country for everyone on all data sources in domain Sales.

Global policy example

Mask using hashing values in columns tagged PII on all data sources.

In these examples, the local policy masks three sensitive columns (ssn, last_name, home_address) on the single data source it was created for, the domain policy only shows rows that match users' office locations across all data sources in the Sales domain, and the global policy masks any column tagged PII on all data sources registered in Immuta.

Domain and global policies automatically apply to all qualifying data sources, so those policies only need to be written once instead of for every data source with sensitive data. Consequently, global and domain policies provide the most scalable and manageable access control.

For more details about domain policies, see the Domains reference guide.

Only one Immuta tenant should apply policies to a single data source

Avoid having more than one Immuta tenant apply a policy to the same table. Multiple Immuta tenants targeting the same data source will cause issues with your deployment and policy enforcement.

How do global policies work?

Global policies reference metadata about users and data, not individual users or data objects. This way, as users or data objects gain or lose that metadata, access logic is automatically updated. This future-proofs policies.

For example, the global policy below uses the group Legal Team (user metadata) and the tag Strictly Confidential (data metadata):

Grant users read access when user is a member of group Legal Team on data sources tagged Strictly Confidential.

Once that policy is active, it will automatically apply to data sources with the Strictly Confidential tag, and users who are part of the Legal Team group will be granted access. If a member of that department transfers to another, their access to that data source will be revoked once that Legal Team group is removed from their account.

User metadata

User metadata are values connected to specific Immuta users and are used in policies to gain access to tables (with subscription policies) or data (with data policies). This metadata falls into two categories:

• Attributes: Attributes are key/value pairs that can be assigned to users or groups. Assigning attributes to a group is a shortcut for assigning a specific attribute to a large set of users: all the users in the group will be assigned the attribute.

• Groups: Groups are similar to roles in a data platform; users can be assigned to one or many groups.

For more details about how to organize and manage user metadata, see the Managing user metadata section.

Data metadata

For authoring global policies, the data metadata are tags applied to data sources and columns. These tags are used in global policies to determine what users gain access to tables (with subscription policies) or data (with data policies).

Tags can come from several sources:

• External catalogs or data platforms: These are tags stored in your existing catalog or applied to data objects in your that you connect to Immuta.

• Identification and classification: These tags are automatically applied to data that Immuta identifies as sensitive.

• Connections: These connection tags are automatically created by Immuta and applied to data registered through a connection. These tags cannot be edited or deleted.

• Tags created in Immuta: These are tags you manually create and manage in Immuta.

Once tags exist in Immuta, they can be used in policies so that the policies can be automatically applied to the data sources with those tags.

For more details about data metadata, see the Managing data metadata section.

Renaming a tag used in an existing policy

When you rename a tag that is used in an existing policy, the policy itself will not automatically update to reflect the new tag name. The policy continues to reference the old tag name.

To ensure the policy is tied to the correct tag, manually edit the policy and update it with the new tag name. This is an important step to ensure that your policy continues to function as expected after a tag rename. This manual update is necessary for all policies tied to the renamed tag.

Tags applied to data sources will update automatically with the new tag name.

Policy authors

The types of policies users can author in Immuta are dictated by their permissions or data ownership:

• Local policies

  • Users with the GOVERNANCE permission

  • Data owners

• Domain policies

  • Users with the GOVERNANCE permission

  • Users with the Manage Policies domain permission can set global policies to apply to the domains for which they have the Manage Policies permission.

• Global policies

  • Users with the GOVERNANCE permission

For instructions on creating polices, see the subscription policy how-to guides or the data policy how-to guides.

Restricted global policies

Data owners who are not governors can write restricted global policies for data sources that they own. With this feature, data owners have higher-level policy controls and can write and enforce policies on multiple data sources simultaneously, eliminating the need to write redundant local policies on data sources.

Once a user is a , the global policy builder is available to them, and they can build global policies just like any other user with the GOVERNANCE permission. The only difference is that global policy will be restricted to only the data sources the user owns.

Policy states

The table below outlines the various states of global policies in Immuta.

Policy state	Enforcement	Description
Active	Enforced	If policies are edited in this state, the changes will be immediately enforced on data sources when the changes are saved.
Deleted	Not enforced	Once a policy has been deleted, it cannot be recovered or reactivated.
Disabled	Not enforced	Data owners or governors can place a policy in this state at the local level for a specific data source. Although this is similar to the staged policy state, this policy will still be enforced on other data sources after it is disabled for a specific data source.
Pending	Not enforced	When Immuta pushes a new policy or a policy change to the remote platform, the policy state displays as Pending until the change is applied to all relevant data sources in the remote platform. For example, if an active global policy is staged, the policy state is Pending until that policy is removed from all data sources it applied to when it was active. If a policy's conditions are updated to apply to data sources tagged PII, it will display as Pending until it is enforced on all data sources tagged PII and removed from data sources without that tag. Use this state to understand the amount of time your policies take to be applied to or removed from data in your remote platform. See the Data engineering with limited policy downtime guide for strategies to address policy latencies.
Staged	Not enforced	This state is useful when regularly editing and reviewing policies. This state also allows you to lift a policy's enforcement without deleting the policy so that it can easily be re-enforced. See Clone, activate, or stage a global policy for a tutorial.

Audit

The following policy-related events are audited and can be found on the audit page in the UI:

• GlobalPolicyCreated: A global policy is created.

• GlobalPolicyDeleted: A global policy is deleted.

• GlobalPolicyUpdated: A global policy is updated.

• DatasourceGlobalPolicyApplied: A global policy is applied to a data source.

• DatasourceGlobalPolicyConflictResolved: A policy conflict between two global policies on a data source is resolved.

• DatasourceGlobalPolicyDisabled: A global policy is disabled on a data source.

• DatasourceGlobalPolicyRemoved: A global policy is removed from a data source.

• LocalPolicyCreated: A local policy is created on a data source.

• LocalPolicyUpdated: A local policy is updated on a data source.