Authoring Policies at Scale
Last updated
Was this helpful?
Last updated
Was this helpful?
Immuta policies restrict access to data and apply to data sources at the local or global level:
Local policies are authored against specific tables, one at a time.
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 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 or .
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.
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 ), even if the tags their policies target go beyond their data sources.
When building global policies at scale, never reference individual users. The goal is to instead reference metadata about users. This way, as users gain or lose that metadata, access logic is automatically updated. This future proofs policies.
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). These attributes fall into three categories:
attributes: Attributes are key/value pairs that can be assigned to users.
groups: Groups are similar to roles in a data platform; users can be assigned to one or many groups.
group attributes: It is possible to assign attributes to groups. This 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.
The table below outlines the various states of global policies in Immuta.
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
Staged
Not enforced
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.
Data ownership can be assigned, but it is also automatically granted to the user that registered the data source with Immuta.
All data source subscribers can access a data source's policies on the policies tab of the data source, but only data owners and governors can edit it. Although not recommended, from there users can view existing policies or apply new local 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.
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.
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 guide for strategies to address policy latencies.
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 for a tutorial.
Note: Policies that contain the circumstance cannot be staged.
There is no special configuration necessary, once a user is a data owner, the global policy builder is available to them, and they can . The only difference is that global policy will be additionally restricted to only the data sources the user owns.