Policies in Immuta

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

  • Local policies refer to specific tables.

  • Global policies refer to 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 local and global policy examples:

  • Local policy example: Mask using hashing the values in the columns ssn, last_name, and home_address.

  • Global policy example: Mask using hashing values in columns tagged PII on all data sources.

In this scenario, the local policy would mask the sensitive columns specified in the data policy on the single data source it was created for. If only using local policies, a data owner or governor would have to write that policy for every data source on which they wanted to mask sensitive data. The second policy would mask any column tagged PII on all data sources that had the PII tag applied to a column. Because this global policy automatically applies to those qualifying data sources, that policy only needs to be written once.

Consequently, global policies are the best practice for using Immuta: they provide the most scalability and manageability of access control.

For details about subscription and data policy types, see the subscription policies reference guide or data policies 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.

Policy Authors

Global policies can be authored by users with GOVERNANCE permission or data owners. Data owners' global policies will only attach to data sources they own (also called restricted global policies), even if the tags their policies target go beyond their data sources.

Policy Logic

Immuta policies compare data and user attributes at query-time to determine whether or not the querying user should access the data.

Data Attributes

Data attributes are information about the data within the data source. These attributes are then matched against policy logic to determine if a row or object should be visible to a specific user. This matching is usually done between the data attribute and the user attribute.

For example, consider the policy below:

Only show rows where user is a member of a group that matches the value in the column tagged Department.

The data attribute (the value in the column tagged Department) is matched against the user attribute (their group) to determine whether or not rows will be visible to the user accessing the data.

User Attributes

User attributes are values connected to specific Immuta user accounts and are used in policies to restrict access to data. These attributes fall into three categories:

  • attributes: Attributes are custom tags that are applied to users to restrict what data users can see. Attributes can be added manually or mapped from an external catalog.

  • groups: Groups allow System Administrators to group sets of users together. Users can belong to any number of groups and can be added or removed from groups at any time. Like attributes, groups can be used to restrict what data a set of users has access to.

  • permissions: Permissions control what actions a user can take in Immuta, both API and UI actions. Permissions can be added and removed from user accounts by a System Administrator (an Immuta user with the USER_ADMIN permission); however, the permissions themselves are managed by Immuta, and the actions associated with the permissions cannot be altered.

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.

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.

Note: Policies that contain the circumstance When selected by data owners cannot be staged.

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.

Unlike global policies, the application of these policies is restricted to the data sources owned by the users or groups specified in the policy and will change as users' ownerships change.

Data Source Policies Tab

Data owners and governors can access a data source's policies on the policies tab of the data source. There, these users can view existing policies or apply new 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 and see a list of data policies currently applied to the data source.

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.

Last updated

Other versions

SaaS2024.32024.2

Copyright © 2014-2024 Immuta Inc. All rights reserved.