Write a Local Policy

Masking

If a column contains sensitive data (i.e. credit card or social security numbers), Data Owners can apply a masking policy to conceal the data in that column to users unless the user possesses an attribute, belongs to a group, or is acting under a purpose defined by the Data Owner.

Masking Policy Builder Example

1. Select a data source and click the Policies tab.
2. In the Data Policies section, click New Policy.
3. Select mask in the first dropdown.

4. Select a custom masking type in the next dropdown menu: using hashing, with reversibility , by making null, using a constant, using a regex , by rounding, with format preserving masking, with K-Anonymization , using randomized response , or using the custom function.

   using a constantusing a regexby roundingwith K-Anonymizationusing the custom function

   If you select using a constant as your masking type, enter a constant in the field that appears next to the masking type dropdown:

   If you choose using a regex as your masking type, enter a regular expression and replacement value in the fields that appear next to the masking type dropdown. Another dropdown will appear with possible modifiers for your regular expression. Make your regex case insensitive and/or global:

   If you choose by rounding to mask a column with a numerical value, select the number to the nearest in the resulting dropdown. A field will appear for you to enter a bucket size or use the suggested bucket size, which is generated by the data fingerprint.

   The example below would round the column value to the nearest 50:

   If you choose by rounding to mask time-based values, the time to the nearest will autogenerate to the suggested time bucket, which is determined by the data fingerprint, in the resulting dropdown. If you click this dropdown menu, other time bucket options will appear:

   If you select with K-Anonymization (which will be available after the fingerprint service has been run on the data source) to mask columns, you can choose using fingerprint or requiring a group size of at least to auto-populate or manually select the group size, respectively.

   Note: Selecting many columns to mask with K-Anonymization increases the processing that must occur to calculate the policy, so saving the policy may take time.

   If you select using the custom function, enter the custom function native to the underlying database.

   Note: The function must be valid for the data type of the column. If it is not, Immuta will error and send a message that the function is not valid.

5. Select your column in the next dropdown.

6. Choose the condition that will drive the policy: for or when, which allows conditional masking driven by data in the row.

   If you choose for,

   1. Use the next dropdown to continue the condition: everyone, everyone except, or everyone who.
   2. Use the subsequent dropdown to choose the group, purpose, or attribute key / value pair for your condition.

   If you choose when,

   1. Enter your custom SQL clause in the next field. When you place your cursor in this field, a tool-tip appears that details valid input and the column names of your data source.
   2. Choose the condition that will drive the policy: for everyone, for everyone except, or for everyone who.
   3. Use the next field to choose the group, purpose, or attribute key / value pair for your condition.

   Notes:

   • If you choose for everyone who as a condition, complete the Otherwise clause before continuing to the next step.
   • You can add more than one condition by selecting + ADD. The dropdown menu in the far right of the Policy Builder contains conjunctions for your policy. If you select or, only one of your conditions must apply to a user for them to see the data. If you select and, all of the conditions must apply.
   • When building conditional masking policies or row-level policies with custom SQL statements, avoid using a column that is masked using randomized response in the SQL statement, as this can lead to different behavior depending on whether you’re using the Query Engine, Spark, or Snowflake and may produce results that are unexpected.

7. Click Create to finish your policy.

8. Click Save All to apply the policy to your data source.

Row Redaction

For query-backed data sources, Data Owners can restrict which rows in the data source tables are visible to which users. This redaction is done by matching values in a specific column against a user's groups, attributes, or purposes.

Note: A data source cannot have more than one row redaction policy applied.

Row Redaction Policy Builder Example

To create a row redaction policy,

1. Select a data source and click the Policies tab.
2. In the Data Policies menu, click New Policy.
3. Select the Only show rows action in the first dropdown.
4. Choose where user in the next dropdown. Note that you can also redact rows based on column values or by using a custom WHERE clause. (See the Filtering Data with a Custom WHERE Clause tab.)
5. Choose the condition that will drive the policy in the next dropdown: is a member of a group or possesses an attribute.
6. Use the next field to choose the attribute, group, or purpose that you will match values against.

7. Use the next dropdown menu to choose the column that will drive this policy.

   Note: You can add more than one condition by selecting + ADD. The dropdown menu in the far right of the Policy Builder contains conjunctions for your policy. If you select or, only one of your conditions must apply to a user for them to see the data. If you select and, all of the conditions must apply.

8. Choose the condition that will drive the policy: for everyone, for everyone except, or for everyone who.

9. Use the subsequent dropdown to choose the group, purpose, or attribute key / value pair for your condition.

   Note: If you choose for everyone who as a condition, complete the Otherwise clause by before continuing to the next step.

10. Click Create to finish your policy.

11. Click Save All to apply the policy to your data source.

Minimization

Data sources may contain minimization policies that hide a specified percentage of query results from a user, based on a column with high cardinality (e.g. an employee ID number or other unique identifier), is auto-selected based on the statistics of the data fingerprint.

Minimization Policy Builder Example

To create a minimization policy,

1. Select a data source and click the Policies tab.
2. In the Data Policies menu, click New Policy.
3. Select the Minimize Data Source action in the first dropdown.
4. In the next field, type the percentage of the data that you want to limit the data source to.
5. Choose the condition that will drive the policy: for everyone, for everyone except, or for everyone who.

6. Use the next field to choose the attribute, group, or purpose that you will match values against.

   Notes:

   • If you choose for everyone who as a condition, complete the Otherwise clause before continuing to the next step.
   • You can add more than one condition by selecting + ADD. The dropdown menu in the far right of the Policy Builder contains conjunctions for your policy. If you select or, only one of your conditions must apply to a user for them to see the data. If you select and, all of the conditions must apply.

7. Click Create to finish your policy.

8. Click Save All to apply the policy to your data source.

Object-level Security

Data Owners can use the Policy Builder to restrict access to objects (blobs) in object-backed data sources. This is done by matching values in a specific blob metadata attribute against a user's groups, attributes, or purposes.

For similar policy mechanics in query-backed data sources, see the Row Redaction tab or the Filtering Data with a Custom WHERE Clause tab.

Only Show Objects Policy Builder Example

To create an only show objects policy,

1. Select a data source and click the Policies tab.
2. In the Data Policies menu, click New Policy.
3. Select the Only show objects action in the first dropdown.
4. Choose the condition that will drive the policy in the next dropdown.
5. Use the next field to choose the attribute, group, or purpose that you will match values against.

6. Use the next dropdown menu to choose the blob metadata attribute that will drive this policy.

   Note: You can add more than one condition by selecting + ADD. The dropdown menu in the far right of the Policy Builder contains conjunctions for your policy. If you select or, only one of your conditions must apply to a user for them to see the data. If you select and, all of the conditions must apply.

7. Choose the condition that will drive the policy: for everyone, for everyone except, or for everyone who.

8. Use the next field to choose the attribute, group, or purpose that you will match values against.

   Note: If you choose for everyone who as a condition, you will need to complete the Otherwise clause before continuing to the next step.

9. Click Create to finish your policy.

10. Click Save All to apply the policy to your data source.

Time-Based Restrictions

These policies restrict access to rows/objects/files that fall within the time restrictions set in the policy. If a data source has time-based restriction policies, queries run against the data source by a user will only return rows/blobs with a date in its event-time column/attribute from within a certain range.

Only Show Data by Time Policy Builder Example

To create a time-based policy,

1. Select a data source and click the Policies tab.
2. In the Data Policies section, click Add Policy.
3. Select the Only show data by time action in the first dropdown menu.

4. In the subsequent dropdown menu, select more recent than or older than, and then complete the enter number of field.

5. Select MINUTES, HOURS, DAYS, or YEARS from the next dropdown menu.

6. Then, choose the condition that will drive the policy: for everyone, for everyone except, or for everyone who.

7. Use the subsequent dropdown to choose is a member of group, is acting under purpose, or possesses attribute key / value pair for your condition.

   Note: If you choose for everyone who as a condition, complete the Otherwise clause by before continuing to the next step.

8. Opt to complete the Enter Rationale for Policy (Optional) field.

9. Click Create, and then click Save All.

Purpose-Based Restrictions

Data Owners in Immuta can restrict usage of any data source to one or more purposes. If a user wishes to run SQL queries against a purpose-restricted data source, they must use the SQL credentials provided by a project containing that purpose.

Purpose-Based Restrictions Policy Builder Example

To create a purpose-based restrictions policy,

1. Select a data source and click the Policies tab.
2. In the Data Policies menu, click Add Policy.
3. Select Limit usage to purpose(s) in the first dropdown.

4. In the next field, select ANY PURPOSE or the specific purpose that you would like to restrict usage of this data source to.

   Note: You can add more than one condition by selecting + ADD. The dropdown menu in the far right of the Policy Builder contains conjunctions for your policy. If you select or, only one of your conditions must apply to a user for them to see the data. If you select and, all of the conditions must apply.

5. In the next dropdown, select for everyone or for everyone except. If you select for everyone except, you must select conditions that will drive the policy.

6. Click Create to finish your policy.

7. Click Save All to apply the policy to your data source.

If a description has been added to the purpose, the description will be visible when you hover over the purpose name in the policy or on the project page.

Filtering Data with a Custom WHERE Clause

Data Owners can apply the most fine-grained control of their data by creating a custom WHERE clause policy. Using the Policy Builder, you can type your desired SQL clause directly into the policy statement. Unlike row redaction, the policy conditions that you select need to match exactly with cells in your data source. As demonstrated in the example below, Data Owners can pair a custom WHERE clause with any condition(s) that they desire in the policy statement.

Custom WHERE Clause Policy Builder Example

• If you choose for everyone who as a condition, you will need to complete the Otherwise clause before continuing to the next step.
• You can add more than one condition by selecting + ADD. The dropdown menu in the far right of the Policy Builder contains conjunctions for your policy. If you select or, only one of your conditions must apply to a user for them to see the data. If you select and, all of the conditions must apply.
• When building conditional masking policies or row-level policies with custom SQL statements, avoid using a column that is masked using randomized response in the SQL statement, as this can lead to different behavior depending on whether you’re using the Query Engine, Spark, or Snowflake and may produce results that are unexpected.

To create a custom where clause policy,

1. Select a data source and click the Policies tab.
2. In the Data Policies menu, click Add Policy.
3. Select Only show rows in the first dropdown.
4. Select where in the next dropdown.

5. The next field allows you to enter your custom SQL clause. When you place your cursor in this field, a tool-tip should appear that details valid input and the column names of your data source. For example, loan_amnt >= 10000.

6. Choose the condition that will drive the policy: for everyone, for everyone except, or for everyone who.

7. Use the next field to choose the attribute, group, or purpose that you will match values against.

   Notes:

   • If you choose for everyone who as a condition, you will need to complete the Otherwise clause before continuing to the next step.
   • You can add more than one condition by selecting + ADD. The dropdown menu in the far right of the Policy Builder contains conjunctions for your policy. If you select or, only one of your conditions must apply to a user for them to see the data. If you select and, all of the conditions must apply.
   • When building conditional masking policies or row-level policies with custom SQL statements, avoid using a column that is masked using randomized response in the SQL statement, as this can lead to different behavior depending on whether you’re using the Query Engine, Spark, or Snowflake and may produce results that are unexpected.

8. Click Create to finish your policy.

9. Click Save All to apply the policy to your data source.

Dev User

Test User

Prod User

Create Subscription Policies with Advanced Rules DSL Builder

You can use the Advanced Rules DSL Builder to create more complex policies for Users with Specific Groups/Attributes than the Subscription Policy Builder allows. To begin,

1. Select Users with Specific Groups/Attributes, and then click the Advanced Rules DSL bubble.

2. Complete the Enter Rules field with the available functions and variables: @iam, @isInGroups, and @hasAttribute. When you place your cursor in this field, a tooltip appears with the functions and values you can use to build your policy.

3. If you would like to make your data source visible in the list of all data sources in the UI to all users, click the Allow Discovery checkbox. Otherwise, this data source will not be discoverable by users who do not meet the criteria established in the policy.

4. Check the Require users to take action to subscribe checkbox to turn off automatic subscription. Enabling this feature will require users to manually subscribe to the data source if they meet the policy.

5. Click Save to finish your policy.

Certify Global Policies

After the HIPAA De-identification Policy or CCPA policy is applied to your data source, you will receive a notification indicating that you need to certify the policy.

To certify the policy,

1. Navigate to the Policies tab of the affected data source, and review the policy in the Data Policies section.

2. Click the Certify Policy icon in the top right corner of the policy.

3. In the Policy Certification modal, click Sign and Certify.

Copy Policies from Other Data Sources

If you have created a data source that is similar to an existing data source and you would like to apply the same policies, you can quickly copy those policies from the Policy Builder.

1. Select a data source and click the Policies tab.
2. In the upper right corner of the Policies page, click on the dropdown menu that says Edit Subscription Policy and then select Apply Existing Policies from Data Source.
3. Search for and select the data source that you would like to copy policies from. If your data source is capable of supporting these policies, they will appear in the Policy Builder. If not, you will receive an error. Be sure that the data source that you are copying policies from follows a similar structure to your current data source so that the policies remain relevant.

Custom Where Clause Functions

Immuta offers several custom PostgreSQL functions for advanced data source policy logic. You can learn about these functions here.

View Policy Diffs

Once you have a Data Policy in effect, you can view the changes in your policies by clicking the Policy Diff button in the top right of the Data Policies section on a data source's Policies tab.

The Policy Diff button displays previous policies and the current policy applied to the data source. In the example below, the previous policy masked social security numbers for everyone except users who possessed the attribute environment prod. The current policy has been changed to mask social security numbers for everyone except users who possess the attribute environment prod and environment test.

Add Policy Exemptions

Once this setting is enabled on the App Settings page, you can exempt users from policies on a per-data-source basis. Note: By default, policy exemptions are disabled in Immuta.

1. Select a data source and click the Policies tab.

2. In the Data Policies menu, click Add Exemptions. This button will only be visible if policy exemptions have been enabled in your Immuta instance.

3. Type the names of the users or groups that you wish to exempt from your policies in the corresponding fields.

4. Click Create to finish your exemption policy.

5. Click Save All to apply the policy to your data source.

Write Restricted Global Policies

Data Owners who are not Governors can write two types of Restricted Global Policies on the Policies page: Subscription and Data Policies. 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.