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 |
Project Governor | Users with the |
Project Manager | Users with the |
Project Member | Once subscribed to a project, all users can |
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
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 |
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.
Last updated