Skip to content

Managing Policies Tutorial

Audience: Data Owners

Content Summary: This page outlines step-by-step instructions for building Local Subscription Policies and Local Data Policies in Immuta.

For information on how to create custom policy handlers, see the Advanced Guide.

Data Source Policies Tab Components

Data Owners and Governors can access the Policies tab from the Data Source Overview page. After navigating to the Policies tab, users can apply 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 with these features appear in an Activity panel on the right side of the screen.

Activity Panel

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.

Subscription Policies

Data Owners can easily control how subscribers can gain access to a data source through the Immuta UI.

These policies comprise four levels of restriction:

  • Anyone: Users are automatically granted access.
  • Anyone Who Asks (and is Approved): Users must request access and then be approved. This restriction supports multiple approving parties, meaning that Data Owners can allow more than one approver or users with specified permission types to approve other users who subscribe to the data source.
  • Users with Specific Groups/Authorizations: Only users with the groups/authorizations Data Owners specify will be able to see and access the data source.
  • Individual Users You Select: Only users Data Owners manually select will be able to see and access the data source.

To manage Subscription policies,

  1. Navigate to the Data Source Overview tab.
  2. Click the Policies tab in the top navigation bar.
  3. Select the level of access restriction you would like to apply to your data source.

    Access Policy

    If you select Anyone Who Asks (and Is Approved),

    1. Click anyone or an individual selected by user from the first dropdown menu in the Subscription Policy Builder.

      Subscription Policy Builder

      Note: If you choose an individual selected by user, when users request access to a data source they will be prompted to identify an approver with the permission specified in the policy and how they plan to use the data.

      Request Access

    2. Select the User_Admin, Governance, or Audit permission from the subsequent dropdown menu.

      Note: You can add more than one approving party by selecting + Add and repeating steps a and b.

    If you select Users with Specific Groups/Authorizations,

    1. Choose the condition that will drive the policy: when user is a member of a group or possesses authorization.
    2. Use the subsequent dropdown to choose the group or authorization key / value pair for your condition.

      Specific Groups or Authorizations

      Note: You can add more than one condition by selecting + ADD. The dropdown menu in the far right of the Subscription 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.

  4. Click Save to finish your policy.

Data Policies

Inclusionary Policies

For all policies except purpose-based restriction policies, inclusionary logic allows Data Owners to vary policy actions with an Otherwise clause.

For example, Data Owners could mask values using hashing for users acting under a specified purpose while masking those same values by making null for everyone else who accesses the data.

Inclusionary Policy

This variation can be created by selecting for everyone who when available from the condition dropdown menus and then completing the Otherwise clause in the bottom half of the Policy Builder. Each section below outlines this process in detail.

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 authorization, belongs to a group, or is acting under a purpose defined by the Data Owner.

Masking Policy Builder Example

To create a masking policy,

  1. Navigate to the Data Source Overview tab.
  2. Click on the Policies tab in the top navigation bar.
  3. In the Data Policies menu, click Add Policy.
  4. Select mask in the first dropdown.
  5. 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, or with format preserving masking.

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

    Masking Policy Enter Constant

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

    Masking Policy Regex

    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:

    Masking Policy Round Number

    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:

    Masking Policy Round Time

  6. Select your desired column in the next dropdown.

  7. 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 authorization 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 authorization 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.
  8. Click Create to finish your policy.

    Masking Policy 1

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

    Masking Policy 2

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, authorizations, or purposes.

For similar policy mechanics in object-backed data sources, see Object-level Security.

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. Navigate to the Data Source Overview tab.
  2. Click on the Policies tab in the top navigation bar.
  3. In the Data Policies menu, click Add Policy.
  4. Select the Only show rows action in the first dropdown.
  5. 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.
  6. Choose the condition that will drive the policy in the next dropdown: is a member of a group or possesses an authorization.
  7. Use the next field to choose the authorization, group, or purpose that you will match values against.
  8. 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.

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

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

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

  11. Click Create to finish your policy.

    Redaction Policy 1

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

    Redaction Policy 2

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. Navigate to the Data Source Overview tab.
  2. Click on the Policies tab in the top navigation bar.
  3. In the Data Policies menu, click Add Policy.
  4. Select the Minimize Data Source action in the first dropdown.
  5. In the next field, type the percentage of the data that you want to limit the data source to.
  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 authorization, 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.
  8. Click Create to finish your policy.

    Minimization Policy 1

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

    Minimization Policy 2

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, authorizations, or purposes.

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

Only Show Objects Policy Builder Example

To create an only show objects policy,

  1. Navigate to the Data Source Overview tab.
  2. Click on the Policies tab in the top navigation bar.
  3. In the Data Policies menu, click Add Policy.
  4. Select the Only show objects action in the first dropdown.
  5. Choose the condition that will drive the policy in the next dropdown.
  6. Use the next field to choose the authorization, group, or purpose that you will match values against.
  7. 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.

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

  9. Use the next field to choose the authorization, 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.

  10. Click Create to finish your policy.

    Object Policy 1

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

    Object Policy 2

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.

This type of policy can be used for both object-backed and query-backed data sources.

Only Show Data by Time Policy Builder Example

To create a time-based policy,

  1. Navigate to the 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.

    Only Show Data by Time

  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 authorization 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. 1. Opt to complete the Enter Rationale for Policy (Optional) field. 1. 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. Navigate to the Data Source Overview tab.
  2. Click on the Policies tab in the top navigation bar.
  3. In the Data Policies menu, click Add Policy.
  4. Select Limit usage to purpose(s) in the first dropdown.
  5. In the next field, select the 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.

  6. 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.

  7. Click Create to finish your policy.

    Purpose Policy 1

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

    Purpose Policy 2

Differential Privacy

Data sources with Differential Privacy policies will only return results for a certain type of SQL query: aggregates, such as the COUNT and SUM functions. Users must avoid aggregate queries that are too specific; Immuta will only return differentially private results for broad aggregate queries.

Note: Differential Privacy is only available for data sources with a configured High Cardinality Column. For guidance on choosing a High Cardinality Column, see the Query-backed Data Source Tutorial.

Differential Privacy Policy Builder Example

To create a differential privacy policy,

  1. Navigate to the Data Source Overview tab.
  2. Click on the Policies tab in the top navigation bar.
  3. In the Data Policies menu, click Add Policy.
  4. Select Make differentially private in the first dropdown.
  5. Select the noise level you would like to apply to your data: small, medium, or large; these values correspond to epsilon-differential privacy, where epsilon (privacy loss) has values of 3, 2.1, and 1.4, respectively.
  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 authorization, 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.
  8. Click Create to finish your policy.

    Differential Privacy Policy 1

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

    Differential Privacy Policy 2

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

To create a custom where clause policy,

  1. Navigate to the Data Source Overview tab.
  2. Click on the Policies tab in the top navigation bar.
  3. In the Data Policies menu, click Add Policy.
  4. Select Only show rows in the first dropdown.
  5. Select where in the next dropdown.
  6. 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.

    WHERE Clause Policy 1

  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 authorization, 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.
  9. Click Create to finish your policy.

    WHERE Clause Policy 2

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

    WHERE Clause Policy 3

Copying 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. Navigate to the Data Source Overview tab.
  2. Click on the Policies tab in the top navigation bar.
  3. In the upper right corner of the Policies page, click on the dropdown menu that says Apply Existing Policies.
  4. 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.

    Copy Policies

Adding Exemptions to a Data Source's Policies

By default, policy exemptions are disabled in Immuta. However, this can be changed via a custom deployment configuration. If policy exemptions are enabled for your Immuta instance, you can add these exemptions on a per data source basis via the Policy Builder.

Exemptions Policy Builder Example

Suppose we have a data source with many policies applied and that we want to exempt one user from all policies on the data source so that this user is able to access everything.

  1. Navigate to the Data Source Overview tab.
  2. Click on the Policies tab in the top navigation bar.
  3. In the Data Policies menu, click Add Exemptions. This button will only be visible if policy exemptions have been enabled in your Immuta instance.
  4. Type the names of the users or groups that you wish to exempt from your policies in the corresponding fields.
  5. Click Create to finish your exemption policy.

    Policy Exemption 1

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

    Policy Exemption 2

Advanced Functions in Data Source Policies

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