Organization and Collaboration through Projects

Audience: Data Users

Content Summary: Projects allow users to logically group work by linking data sources and can be created by Data Users who want to efficiently organize their work or by Data Owners who want to provide special access to data to specific users. Additionally, Data Governors can act as project owners for any project in their organization.

This overview describes concepts related to and major features of projects; for instructions detailing how to join projects, navigate to the Joining Projects Tutorial.

Project Roles

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 Owner Capabilities

Users with the CREATE_PROJECT permission are considered owners of the projects they create and have the following capabilities:

• manage project members
• manage project documentation and purposes
• set subscription policies on the project
• enable Project Equalization
• enable Masked Joins
• manage project data sources
• manage project tags
• post, reply to, delete, and resolve discussion threads
• disable, delete, and restore the project
• create derived data sources
• create fingerprint versions
• switch project contexts

Governor Capabilities

Governors have the following capabilities for any project in their organization, even for projects that are private or that they are not members of:

• manage project members
• set subscription policies on the project
• add data sources to and delete data sources from the project
• manage project tags
• post and reply to discussion threads and delete their own threads and replies
• disable and restore a project
• configure project purposes, acknowledgement statements, and settings
• switch project contexts

Project Member Capabilities

Once subscribed to a project, all Immuta users have the following capabilities as project members:

• 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 and delete their own discussion threads and replies
• create derived data sources
• create fingerprint versions
• switch project contexts

Project Purposes, Acknowledgement Statements, and Settings

The Data Governor is responsible for configuring project purposes, acknowledgement statements, and settings.

• Purposes: Purposes help define the scope and use of data within a project and allow users to meet purpose restrictions on policies. Governors can create purposes for project owners to use or owners can create their own purposes when they create their project (if the Governor allows them to). However, only Governors can delete purposes.

  

• Acknowledgement Statements: Projects containing purposes require owners and subscribers to acknowledge that they will only use the data for those purposes by affirming or rejecting acknowledgement statements. If users accept the statement, they become a project member. If they reject the acknowledgement statement, they are denied access to the project. Once acknowledged, data accessed under the provision of a project will be audited and the purposes will be noted. Immuta provides default acknowledgement statements, but Data Governors can customize these statements in the Purposes or Settings tabs.

  

• Settings: Governors can also determine if purposes are required to create a project, if purposes can be customized by project owners or must be chosen from purposes created by the data governor, or if a project can have more than one purpose. These settings are adjusted in the Settings tab of the Governance page and include the following options:

  • A purpose must be included in projects: Selecting this option will require that every project contain a purpose. Utilizing data within a project outside of the stated purposes is prohibited. Projects without purposes, however, have no set restrictions.
  • All data sources require a purpose restriction: Selecting this option will require every data source to have a purpose restriction.
  • A project can have more than one purpose: Selecting this option allows projects to have more than one purpose.
  • A project's purpose can change: Selecting this option will allow a project’s purpose to change at any time during the life of the project. Only users who created the project can change the purpose.
  • Projects can have custom purposes: Selecting this option will allow project owners to describe the purpose of their project themselves, rather than choosing from a list of purposes created by a Governor.

  

Switching Project Contexts

The Immuta UI provides a simple way to switch project contexts so that users can 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.

Project Equalization

The same security restrictions regarding data sources are applied to projects; project members still need to be subscribed to data sources in order to access data, and only users with appropriate attributes and credentials will be able to 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.

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

For instructions on enabling Project Equalization, navigate to the Managing Projects Tutorial.

Equalized Entitlements

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

• If you add attributes, 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 an attribute or group, the project will be open to users with fewer privileges, but this change might make less data visible to all project members. Removing attributes 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. Validation Frequency provides those means of verification.

Masked Joins

This feature allows masked columns to be joined within the context of a project.

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

For instructions on enabling Masked Joins, navigate to the Managing Projects Tutorial.

Derived Data Sources

Demo: Automated Policy Inheritance

When Project Equalization is enabled, members can use data sources within the project to create a derived data source. This derived data source dynamically inherits the Subscription Policies and purpose restriction Data Policies from the parent source(s).

For example, consider these data sources, each containing a Subscription and Data Policy:

Data Source A

Subscription Policy: Allow users to subscribe to the data source when user is a member of group Medical Claims

Data Policy: Mask by making null the value in the column(s) address except for members of group Legal

Data Source B

Subscription Policy: Allow users to subscribe to the data source when user is approved by anyone with permission Owner and anyone with permission Governance

Data Policy: Limit usage to purpose(s) Research for everyone

If a user creates a derived data source from these two data sources, then that source (Data Source C) will inherit these policies, and these inherited policies are unchangeable:

Data Source C

Subscription Policy: Allow user to subscribe when they satisfy all of the following:

• is a member of group Legal and is a member of group Medical Claims
• is approved by anyone with permission Owner (of Data Source B) and anyone with permission Governance

Data Policy: Limit usage to purpose(s) Research for everyone

Note: If members use data outside the project to create their data source, then they must first add that data to the project and re-derive the data source through the project connection. When creating a derived data source, members are prompted to certify that their data is derived from the parent data sources they selected upon creation.

For detailed instructions on creating a derived data source, navigate to the Project Owner Guide.