Skip to content

You are viewing documentation for Immuta version 2023.3.

For the latest version, view our documentation for Immuta SaaS or the latest self-hosted version.

cancel

Policy Best Practices

Start with Subscription Policies and then move to Data Policies

Without Immuta, you may have been manually managing user access to tables, which increases time to data access. Address this challenge first by building automated Subscription Policies to grant access to tables. After you have built your Subscription Policies, start building Data Policies to restrict what data users can see once they've accessed and queried a table.

Build Global Policies using attributes and tags to manage data access

Global Policies can be applied to data sources across your organization, which prevents you from having to write or rewrite single policies for every data source added to Immuta. If you need to mask PII, you want it to apply to all tables that have PII, not just a single table. Global Policies enable scalability across your organization and across all data platforms.

Write policies using ABAC (Attribute Based Access Controls)

Write policies based on who users are (in other words, their attributes: the state they live in, the project they are working on, etc.) and their purpose for accessing data.

For example, consider this policy: “a user is only allowed to see records for a state they live in.” Since there are 50 states,

  • With RBAC you’d have to have one group for each state (50 groups) and put people into those groups, and then write 50 policies that say “if someone is in the OHIO group they are allowed to see rows that match OHIO in the column tagged STATE."
  • With ABAC you would pull the attributes from the user from your IAM, and then write a single policy in Immuta: “Only show rows where user possesses an attribute STATE that matches the value in the column tagged STATE."

For details about the differences between ABAC and RBAC, see the Immuta blog What is ABAC? Attribute Based Access Control 101.

Additional Considerations

  • Immuta contains a Domain Specific Language (DSL) capability that pairs well with ABAC and provides a means of implementing more complex policy logic within a single statement (e.g., matching arrays of user attributes to table or column tagging). Contact your Immuta representative for guidance in writing these complex policies.
  • Match attributes for users with a value in the table. Cross-table lookup is not currently supported because of the additional time required to look up values at query time.

Consider your policy complexity and performance

Immuta is not in the data path at all. Immuta simply takes the ABAC policies you define and pushes those down to your compute system. The more complex the policy that is pushed to that system, the more the potential impact on performance. For example, nulling (or using a static value such as “REDACTED”) is a simpler operation than hashing, so it will actually reduce overhead from a query with no policy at all. Hashing, on the other hand, will increase overhead slightly because of its complexity.

  • Use hashing when you need to join on a value. Hashing allows for an end-user to join on that column when using Immuta projects. However, hashing does take compute power, so consider milliseconds per column X the rows in your table.
  • Avoid row-level security that relies on thousands or millions of attributes per user for filtering. You should try to think of other schemes that either generalize those into fewer coarser lookups or partitioning your data in a way that aligns to those lookups so they run faster.

For details about specific policies and their tradeoffs, see Immuta Masking Functions.