Projects and Purposes

Immuta projects combine users and data sources under a common purpose. Sometimes this purpose is for a single user to organize their data sources or to control an entire schema of data sources through a single projects screen; however, most often this is an Immuta purpose for which the data has been approved to be used and will restrict access to data and streamline team collaboration.

For more information on the value projects can add to your organization, see the Project Use Cases page.

Project Components

• Project Members: The users who will create, manage, and use projects.

• Purposes: Purposes allow Governors to define exceptions to policies based on how a user will use the data.

• Data Sources: Projects create an environment within Immuta where the user will only see the data sources within the project, despite their subscription to other data sources.

• Subscription Policy: Project users with the appropriate permissions can set a subscription policy on a project to control the users who can join.

• Documentation and Discussions: Project users can create documentation and have discussions within the Immuta project page, allowing for an easy and consistent trail of communication.

• Equalization: Project Equalization improves collaboration by ensuring that the data in the project looks identical to all members, regardless of their level of access to data.

• Workspaces: With equalization enabled, project users can create Snowflake or Databricks workspaces where users can view and write back data to Immuta.

• Derived Data Sources: Derived data sources are the data sources that come from workspaces. Once they are created, they automatically inherit policies from their parent sources.

• Masked Joins: Within a project, users can join masked columns.

Members

The features and capabilities of each user differ based on the user's role within the project and within Immuta. Roles and their capabilities are outlined below.

Project Role	Capabilities
Project Owner	Users with the CREATE_PROJECT permission can create projects set project subscription policies manage project members, project documentation, project data sources, project tags, and discussion threads enable Project Equalization and Masked Joins disable, delete, and enable projects create Snowflake or Databricks workspaces create derived data sources
Project Governor	Users with the GOVERNANCE permission can configure project purposes and acknowledgement statements manage project members, project tags, and project subscription policies add and remove project data sources disable and enable projects
Project Manager	Users with the PROJECT _MANAGEMENT permission can approve or deny purposes in a project create purposes add and remove project data sources
Project Member	Once subscribed to a project, all users can add data sources to the project (unless Project Equalization or Masked Joins is enabled) remove data sources they’ve added to the project post and reply to discussion threads delete their own discussion threads and replies create derived data sources

Purposes

Best Practice: Purposes

Consider purposes as attributes. Attributes identify a user, and purposes identify why that user should have access.

Data Governors and users with the PROJECT_MANAGEMENT permission are responsible for configuring and approving project purposes and acknowledgement statements.

Purposes help define the scope and use of data within a project and allow users to meet purpose restrictions on policies. Governors create and manage purposes and their sub-purposes, which project owners then add to their project(s) and use to drive Data Policies. Project owners can also create a purpose; however, they remain in a staged state until a Governor or Project Manager approves the purpose request.

Sub-Purposes

Purposes can be constructed as a hierarchy, containing nested sub-purposes, much like tags in Immuta. This design allows more flexibility in managing purpose-based restriction policies and transparency in the relationships among purposes.

For example, if the purpose Research included Marketing, Product, and Onboarding as sub-purposes, a governor could write the following global policy:

Limit usage to purpose(s) Research for everyone on data sources tagged PHI.

This hierarchy allows you to create this as a single purpose instead of creating separate purposes, which must then each be added to policies as they evolve.

Now, any user acting under the purpose or sub-purpose of Research - whether Research.Marketing or Research.Onboarding will meet the criteria of this policy. Consequently, purpose hierarchies eliminate the need for a Governor to rewrite these Global Policies when sub-purposes are added or removed. If new projects with new Research purposes are added, the relevant Global Policy will automatically be enforced.

Acknowledgement Statements

Projects with purposes require owners and subscribers to acknowledge that they will only use the data for those purposes by affirming or rejecting acknowledgement statements. Each purpose has its own acknowledgement statement, and a project with multiple purposes requires users to accept more than one acknowledgement statement. Immuta keeps a record of each project member's response to the acknowledgement statement(s) and records the purpose, the time of the acknowledgement, and the text of the acknowledgement. Purposes can use Immuta's default acknowledgement statement or one customized by a Data Governor.

If users accept the statement, they become a project member. If they reject the acknowledgement statement, they are denied access to the project.

Project Contexts

When a user is working within the context of a project, they will only see the data in that project. This helps to prevent data leakage when users collaborate. Users can switch project contexts to access various data sources while acting under the appropriate purpose. By default, there will be no project selected, even if the user belongs to one or more projects in Immuta.

When users change project contexts, all SQL queries or blob fetches that run through Immuta will reflect users as acting under the purposes of that project, which may allow additional access to data if there are purpose restrictions on the data source(s). This process also allows organizations to track not just whether a specific data source is being used, but why.

Equalization

The same security restrictions regarding data sources are applied to projects; project members still need to be subscribed to data sources to access data, and only users with appropriate attributes and credentials can see the data if it contains any row-level or masking security.

However, Project Equalization improves collaboration by ensuring that the data in the project looks identical to all members, regardless of their level of access to data. When enabled, this feature automatically equalizes all permissions so that no project member has more access to data than the member with the least access. For a tutorial on enabling equalization, navigate to Create a Project.

Note: Only project owners can add data sources to the project if this feature is enabled.

Once Project Equalization is enabled, the Subscription Policy for the project is locked and can only be adjusted by the project owner by changing the Equalized Entitlements.

Equalized Entitlements

This setting adjusts the minimum entitlements (i.e., users' groups and attributes) required to join the project and to access data within the project. When Project Equalization is enabled, Equalized Entitlements default to Immuta's recommended settings, but project owners can edit these settings by adding or removing parts of the entitlements. However, making these changes entails two potential disadvantages:

• If you add entitlements, members might see more data as a whole, but at least some members of the project will be out of compliance. The status of users' compliance is visible from the Members tab within the project.

• If you remove entitlements, the project will be open to users with fewer privileges, but this change might make less data visible to all project members. Removing entitlements is only recommended if you foresee new users joining with less access to data than the current members.

Validation Frequency

This setting determines how often user credentials are validated, which is critical if users share data with project members outside of Immuta, as they need a way to verify that those members' permissions are still valid.

Project Equalization and Subscription Policies

Once Project Equalization is enabled, the project Subscription Policy builder locks and can only be adjusted by manually editing the Equalized Entitlements. Then, the Subscription Policy will combine with the entitlement settings, depending on the policy type.

Combinations by Policy Type

Combinations by Policy Type

The way entitlements and approvals combine differs depending on the policy type; for clarity, the table below illustrates various scenarios for each type. Every row demonstrates how a specific project Subscription Policy changes after Project Equalization is enabled (when an equalized entitlement is set and when no entitlement is set) and how the policy reverts if Project Equalization is subsequently disabled.

Original Policy	Equalized Policy (Example Entitlement: member of group Accounting)	Equalized Policy (No Entitlement)	Policy After Disabling Equalization
Anyone	Allow user to subscribe when user is a member of group Accounting	Individual Users You Select	Individual Users You Select
Allow users to subscribe when approved by anyone with permission Owner (of this project)	Allow users to subscribe when they satisfy all of the following: is a member of group Accounting and is approved by anyone with permission Owner (of this Project)	Allow users to subscribe when approved by anyone with permission Owner (of this project)	Allow users to subscribe when approved by anyone with permission Owner (of this project)
Allow users to subscribe to the project when user is a member of group Legal	Allow users to subscribe to the project when user is a member of group Accounting	Individual Users You Select	Individual Users You Select
Individual Users You Select	Allow users to subscribe to the project when user is a member of group Accounting	Individual Users You Select	Individual Users You Select

Example

Example

For example, consider the Subscription Policy of the following sample project, Fraud Prevention, before Project Equalization is enabled:

Fraud Prevention

Subscription Policy: Allow users to subscribe when approved by anyone with permission Owner (of this project).

After enabling Project Equalization, the following Equalized Entitlement is recommended by Immuta: User is a member of group Claims and Billing Department.

In this particular example, the Equalized Subscription Policy contains the Equalized Entitlement and the approval of the original policy, so users must satisfy both conditions to subscribe:

• the user must be a member of the group Claims and Billing Department

• the user must be approved by anyone with permission Owner (of this project).

Masked Joins

This feature allows masked columns to be joined within the context of a project. However, joining on columns masked by rounding, by making null, with a constant or regex or on columns that have conditional masking policies applied to them is not supported and will be blocked.

Note: Masked columns cannot be joined across data sources that are not linked by a project.

For instructions on enabling Masked Joins, navigate to Create a Project.

Schema Projects

Schema projects are a collection of data sources that Immuta creates when multiple data sources belong to the same schema. For information about schema projects, see the Schema Project page.