Skip to content

You are viewing documentation for Immuta version 2022.5.

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

cancel

Project Use Cases

There are three main use cases Immuta projects can help with:

  1. Allowing policy owners to create exceptions to policies in a proactive manner
  2. Allowing users to collaborate on data, securely
  3. Allowing control over what data can and cannot be joined

Create Exceptions to Policies

The goal of Immuta is to modernize the management of data policies in organizations. One key aspect of modernization is to remove day-to-day human involvement in policy decision making, which is fragile and subjective. One decision process is how and when to make exceptions to policies.

This decision process could be something like: “because Morgan is analyzing employee attrition and retention, they should be able to see employee satisfaction survey data.” Notice it is not “because Morgan is HR, they should be able to see employee satisfaction survey data.” It’s not who Morgan is, but what Morgan is doing that should allow them heightened access. The purpose for data access drives the policy decision and can be approved objectively because you are not approving who can see data, but what can be done with it. However, if Morgan has to ask permission every time there is a new survey, this becomes a subjective and time-consuming process for the organization.

This is where purposes and purpose-based access control can help. Purposes allow you to define exceptions to rules as the purpose for which the user is acting. The key point here is you can define these purposes ahead of time, before any user actually tries to get an exception. Immuta projects are valuable not just for purpose-based access control, but because of the documentation trail they provide, the collaboration they allow, and the data access process they automate.

Additionally, to ensure that purposes are being used correctly and applied accurately, project purposes are approved before the purpose is active in a project. That approver will see the lists of tables, the project members, and project documentation and decide if they want to approve it or not. This approval is recorded by Immuta, creating a documentation trail. After a purpose is approved within a project, any changes to the members or data sources will require the purpose to be re-approved, ensuring that the project continues to be compliant to an organization's requirements.

  1. Create a purpose-based restriction policy.
  2. Create a project with a purpose and add users, data sources, and documentation.
  3. A Governor or Project manager approves the purpose.
  4. Query data while acting in the context of the project.

Key Takeaways

  • Exceptions to policies can be built ahead of time with purposes.
  • Users can independently create projects to use purposes as exceptions to policies.
  • A permissioned user can then approve that purpose to a specific project, when asked, based on the project details.

Collaboration

Let’s say Sally and Bob are working together on a project, and Sally has more data access than Bob. She can see PII and Bob cannot, but they both can see credit card numbers. Without Immuta, an admin would have to know what tables they intend to use, scrub all those tables of PII, and then give Sally and Bob access to those new tables in a place where they can safely work on the data and save any output they create.

With Immuta, this is a lot easier. Sally or Bob could create the project, add the tables as data sources, invite the other person to be a project member, and equalize it. The equalization will compare the members of the project to the data policies on the tables in the project and find the intersection: Sally and Bob both can see credit card numbers. That intersection becomes the equalization setting. Once the project is equalized in this example, Sally will lose access to PII, but both Sally and Bob will retain access to credit card numbers.

Now Sally and Bob want to do some transformation on the data and write it somewhere. This is where project workspaces come into play. Once workspaces are configured in a Snowflake or Databricks integration, Immuta will create a schema in the native database dedicated to this project where Sally and Bob can write their output. Within this workspace

  • Only members of the project will have access to that schema to write to or read from. (For example, in Snowflake Immuta limits it to a particular role it creates in Snowflake.) This is important, because if someone who can’t see credit card numbers somehow had access to where Sally and Bob were writing, they would gain access to data (the credit card numbers) they shouldn’t see.
  • They will only be able to access the tables that are in the project. (This may be critical if someone approved the purpose for only those tables.)

After reading and writing data within the workspace, users can create derived data sources. With derived data sources, Sally and Bob can securely share the data they have written by registering the derived table or view they created within the project and expose that to people outside of the project. Immuta will ensure the proper policy is in place on that shared table based on the equalization setting of the project.

When determining where you should give analysts WRITE access, you need to consider the entire universe of where they have READ access, and that universe is constantly changing. This is an impossible proposition for you to manage without Immuta projects.

Key Takeaways

  • Users at different levels of access can work together without help from an admin (to scrub the data).
  • Customers can avoid data leaks on analyst writes.

Join Data

Sometimes, accessing two tables separately doesn't violate compliance regulations, but accessing these two tables when they are joined creates a serious privacy problem. Immuta can help avoid creating these toxic combinations of data.

Tables are joined on a key, a column in one table that matches a column on the other table and allows the join. To prevent joining those tables, you would mask the keys so they no longer match one another. This is an important distinction: you do not make data anonymous only because it’s directly sensitive (a direct identifier) or because it’s indirectly sensitive (an indirect identifier) but potentially because it’s a join key that you may not want to be used for joining.

Because of this, when masking a column (for the policy types that support it) Immuta breaks referential integrity by default, making sure the masked values aren’t able to join. This means you can’t join on two masked columns unless you tell Immuta you want to allow that. To do so, you have to add those tables with the masked keys to a project and enable Masked Joins.

Key Takeaway

  • Projects give you control over toxic data combinations.

For details about the Immuta project features and components, see the Projects and Purposes page.