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.

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.

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.