Local 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
- Global policy example: Mask using hashing values in columns tagged
PIIon 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
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.
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.
Local policies can be authored by users with GOVERNANCE permission or data owners.
Immuta policies compare data and user attributes at query-time to determine whether or not the querying user should access the data.
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
Country='US' for everyone except when user is a member of group
The data attribute (
US in the
Country column) is matched against the user attribute
Finance group) to determine whether or not rows will be visible to the user accessing the data. In this case only
users who are a member of the Finance group will see all rows in the data source.
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_ADMINpermission); however, the permissions themselves are managed by Immuta, and the actions associated with the permissions cannot be altered.
Data owners control how subscribers gain access to a data source through subscription policies.
The types of subscription policies are defined in the subscription policies reference guide.
See Write a Local Policy for a tutorial on creating a subscription policy.
Data policies determine what data users see when they've gained access to a data source. The types of data policies are defined in the data policies reference guide.
See Write a Local Data Policy for a tutorial on creating a data policy.
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. 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.