Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Requirement: CREATE_PROJECT
Immuta permission
Navigate to the Projects tab under Data in the sidebar, and click the New Projects button.
Fill out the Basic Information:
Enter a name for your project in the Project Name field.
Opt to complete the Project Description field to help identify your project.
Opt to enter project Documentation to provide context for members.
Select the purposes and any policy adjustments:
Choose to select a purpose from the list of purposes or create a new purpose for the project.
To create a new purpose, click Create Purpose and complete the prompts in the modal.
Note that all purposes added to a project will need to be created or approved by a user with the GOVERNANCE
or PROJECT_MANAGEMENT
permission. Once purposes have been applied to a project, only these users can add data sources to the project.
Add a native workspace configuration: Select your workspace configuration from the Workspace Configuration dropdown menu: Databricks or Snowflake.
Databricks: Opt to edit the sub-directory in the Workspace Directory field (this sub-directory auto-populates as the project name) and enter the Workspace Database Name.
Snowflake: Name the Workspace Schema. By default, the schema name is based off of the project name, but you can change it here. Your project workspace will exist within this schema under Snowflake under the database configured by the application admin.
Use the dropdown menu to select the Hostname. Projects can only be configured to use one Snowflake host.
Select one or more Warehouses to be available to project members when they are working in the native workspace.
Add data sources to the project using the dropdown menu. Data sources can also be added after the project is created.
Click Affirm and Create.
Project naming convention
Use a naming convention for projects that reflects the naming convention for databases. (e.g., If the project in Dev is called: “my_project” name the project “dev_my_project.") The data will end up in the project database prefix, so you can trace the source and make edits upstream in that project as necessary.
Projects are private by default but can be made public and shared with other users by changing the subscription policies setting. Governors are the only users who can manage subscription policies for projects with purposes.
In the project, click the Policies tab.
Click Edit Subscription Policy.
Select the group of users who will have access:
Allow anyone: Selecting this option makes the project visible to everyone. Opt to require manual subscription by selecting the checkbox. This will require the users to manually subscribe to the project to gain access.
Allow anyone who asks (and is approved): Selecting this option makes the project visible in search results, but users must request access and be granted permission. This restriction supports multiple approving parties, so project owners can allow more than one approver or users with specified permission types to approve other users who request access to the project.
Click Anyone or An individual selected by user from the first dropdown menu.
Note: If you choose An individual selected by user, when users request access to a project they will be prompted to identify an approver with the permission specified in the policy.
Select the USER_ADMIN, GOVERNANCE, or AUDIT permission from the subsequent dropdown menu. You can add more than one approving party by selecting + Add Another Approver.
Allow users with specific groups/attributes: Selecting this option allows users with the specified groups and attributes to join the project.
Choose whether to build the policy off user groups or user attributes:
is a member of group: Type the group name and select the group.
possesses attribute: Type the attribute and select it. Then select the value from the dropdown menu.
Opt to + Add Another Condition. When adding another condition, choose how the conditions will be required. If you select or, only one of the conditions must apply to a user for them to subscribe to the project. If you select and, all of the conditions must apply.
Opt to allow users who do not meet the restrictions defined in the policy to still be able to discover the project by selecting the Allow Project Discovery checkbox.
Once saved, users with the proper authorizations will be automatically subscribed. Opt to require users to manually subscribe to the project by selecting the Require Manual Subscription checkbox.
Allow individually selected users: Selecting this option hides the project from the search results. Project owners must manually add and remove users, and the Private label will appear next to the project name.
Click Save to finish your policy.
In the project, click the Members tab.
Click the Add Members button.
Start typing a user's or group's name in the Add Members modal and select it from the dropdown that appears.
Opt to add an expiration to the subscription by entering the number of days until the access will expire.
Select the role.
Click Add.
Current project members will receive notifications that new users have been added to the project. A similar entry will be posted to the project's activity pane.
Requirement: GOVERNANCE
or PROJECT_MANAGEMENT
Immuta permission
Click Governance and select Purposes in the navigation menu.
Click + Add Purpose.
Complete the Purpose Name field, and opt to customize the acknowledgement statement or add a description.
Click Create.
Click Governance and select Purposes in the navigation menu.
Open the dropdown menu and click View or Edit in the actions column of the purpose you want to add sub-purposes to.
Click Add Sub-Purposes.
Enter a name in the Enter nested purpose field in the Sub-Purpose Builder.
Click the arrow to the right of the purpose or sub-purpose(s) to continue adding nested purpose fields.
Click Save.
A list of sub-purposes will populate at the bottom of the page. You can manage these sub-purposes by clicking Edit in the Actions column at any time.
Click Data in the navigation menu and select Projects.
Go to the project overview page and click Add Purposes.
Select the purpose from the dropdown menu or click Create Purpose.
Complete the prompts in the modal and then click Save.
For the purpose to go into effect, it must be approved by a user with the GOVERNANCE
or PROJECT_MANAGEMENT
Immuta permission.
Click Governance and select Purposes in the navigation menu.
Open the dropdown menu and click Edit in the Actions column of the purpose you would like to customize.
Click Edit above the acknowledgement statement, customize the text, and then click Confirm.
The page displays the updated statement, which now will be used by all projects and purposes. The updated statement will also be used by any new members joining existing projects containing purposes with default statements.
By default, sub-purposes will inherit the acknowledgment statements of their parent purposes. However, you can customize the acknowledgement statement for an individual sub-purpose as well by following the process above.
Navigate to your user profile page and click the Requests tab.
Approve or deny the purpose request in the actions column.
Click Governance and select Purposes in the navigation menu.
Click the more actions icon in the Actions column of the purpose or sub-purpose you want to delete.
Select Delete, and then click Confirm to approve the deletion.
Any project that contained the deleted purpose will be treated as no longer compliant, so the project overview page will display a violation
tag. Project owners can remediate the violation by removing the purpose from the project.
Purpose-based access control is a method of data access control that makes access decisions based on the reason a user or tool intends to use the data, which provides flexibility data governance teams need to build a high-powered, granular access control model. Furthermore, most regulations (like GDPR and HIPAA) include purpose clauses that require sensitive data only be collected and used for precise reasons.
For example, the GDPR’s Purpose Limitation Principle states that “Personal data should only be collected and processed for a legitimate specific purpose.” Furthermore, the regulation claims that the specific purpose “should be expressed in an unambiguous, transparent, and simple manner” in order to be compliant. The goal of this clause is to ensure that sensitive information is not being unnecessarily collected, stored, and exposed to risk by organizations that use it. With purpose-based access control, organizations can exhibit the granular, purpose-based control over data access that ensures compliance with these standards.
Immuta projects allow you to connect purposes to data sources and users to enforce purpose-based access controls on your data.
This getting started guide outlines how to quickly implement purpose-based access controls for your business use case using Immuta projects, purposes, and global data policies.
The how-to guides in this section illustrate how to create and manage projects and purposes.
Project management: This section guides project owners, governors, and project managers through managing project settings, data sources, and members.
Requirement: You must own the project or have the GOVERNANCE
or PROJECT_MANAGEMENT
Immuta permission
Navigate to the Project Overview tab.
Click + Add Purposes.
Create a new purpose in the modal or select purposes from the dropdown menu.
Click Save, and then click I Agree.
Navigate to the Project Overview tab.
Scroll to the purposes section and click Remove.
Click I Agree
Requirement: CREATE_PROJECT
Immuta permission (and you must own the project)
Click the Project Overview tab.
Click the Edit button in the Documentation section.
Document the details of your project in the text box that appears, and then click Save.
Requirement: CREATE_PROJECT
(and you must own the project), GOVERNANCE
, or PROJECT_MANAGEMENT
Immuta permission
Select a project and navigate to the Project Overview tab.
Scroll to the Tags section and click the Add Tags button.
Begin typing the tag name in the window that appears, and then select the tag from the dropdown menu. A list of chosen tags will populate at the bottom of this window.
After selecting all relevant tags, click the Add button.
Requirement: CREATE_PROJECT
(and you must own the project), GOVERNANCE
, or PROJECT_MANAGEMENT
Immuta permission
Navigate to the Project Overview tab.
Scroll to the Tags section and click on the tag that you want to remove to open its side sheet.
Click Remove.
Click Confirm to delete the tag.
Requirements:
CREATE_PROJECT
(and you must own the project), GOVERNANCE
, or PROJECT_MANAGEMENT
Immuta permission to disable or enable a project
CREATE_PROJECT
Immuta permission to delete a project
Click the Data icon and select Projects in the sidebar.
Select the My Projects tab.
Click the more options icon next to the project and select Disable.
Click the Data icon and select Projects in the sidebar.
Select the My Projects tab.
Click the more options icon next to the project and select Enable.
Deleting a project permanently removes it from Immuta. Projects must first be disabled before they can be deleted.
Click the Data icon and select Projects in the sidebar.
Select the My Projects tab.
Click the more options icon next to the disabled project and select Delete.
Click Confirm.
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.
Documentation: Project users can create documentation within the Immuta project page, allowing for an easy and consistent trail of communication.
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.
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.
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.
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.
When users change project contexts, queries 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.
Requirements:
If a purpose has been added to and approved for the project, you must have the GOVERNANCE
or PROJECT_MANAGEMENT
Immuta permission.
Otherwise, you must be a project member.
Navigate to the Project Overview tab.
Click the Add Data Sources button.
Start typing the name of a data source you'd like to include in the project.
Select the data source from the list of auto-completed options in the dropdown menu.
Repeat this process to add additional data sources to the list. You can remove them using the more options icon.
Opt to re-equalize the project by clicking the toggle on.
When complete, click the Save button at the bottom of the list.
You can automatically add all data sources to a project that contain a Limit usage to purpose policy that matches the purpose of that project.
Select a Project, and click the Add Data Sources button.
Click Add By Purpose.
All data sources matching the project's purpose(s) will populate at the bottom of the dialog. Review this list, and then click Save.
Set your current project to be the one you want new data sources in.
Navigate to the Data Sources page.
Select the checkboxes for the data sources you want in a project.
Select the bulk actions more options icon in the top right corner.
Click Add To Current Project.
Requirement: You must own the project
Navigate to the project.
Click the Policies tab.
In the Project Equalization section, click the toggle button on the far right to On.
Navigate to the project Overview tab.
Click the Add Purposes button in the center of the page.
Select the desired purpose(s) from the dropdown menu. The project must have one purpose with noise reduction for policy adjustments to function. Noise reduction is indicated by the policy adjustment amount highlighted in gray. If there is no policy adjustment shown, it is the default, none.
Click Save.
The purpose will be staged until a user with the GOVERNANCE
or PROJECT_MANAGEMENT
permission approves and activates it. If you have one of these permissions, the staging will be skipped.
After the purpose has been approved, click I Agree to agree to the terms of the purpose.
Note: All members of the project must agree to the terms of the purpose; if they decline, they will be removed from the project.
Navigate to the Policy Adjustment tab.
Select the data source from the dropdown menu. You will receive a No Adjustments Available message if there are no columns in the data sources that are associated with adjustable policies.
Select the columns from the dropdown menu.
In the priority ranking window, give weight from most to least important columns. The higher the weight the more usability will be provided, while still providing de-identification through the other columns.
After assigning the weight and ensuring that the remaining weight is zero, click the Adjust button.
Check that the percent NULL is appropriate for your usability. If you are content with the percent NULL, move on to the next step; if you are not satisfied with the percent NULL, repeat the previous steps until satisfied.
Click Apply after you have made the acceptable adjustments.
After you ensure that your data source has two columns with k-anonymization policies applied,
Navigate to your project and click the Overview tab.
Click Add Purposes and select a purpose with a Noise Reduction and Fields in Clear tags, or create a new purpose with Noise Reduction and Fields in Clear enabled.
Click Save, and then click I Agree.
Navigate to the Policy Adjustment tab.
Select the data source(s) and columns from the subsequent dropdown menus.
Select the Keep in the Clear checkbox next to columns to be kept in the clear.
Adjust the weight for the remaining columns. The Remaining Weight must equal 0.
Click Adjust and then Apply.
The values for the fields you selected will now be visible to users acting under the project.
: Create a project to group data sources and users.
: Create a purpose for your project to enforce access restrictions on the project data sources.
: Redistribute the noise of k-anonymization across multiple columns of a data source within a project to make specific columns more useful for analysis.
: Immuta projects allow you to connect purposes to data sources and users to enforce purpose-based access controls on your data.
: Project owners can use policy adjustments to increase a data set's utility while retaining the amount of k-anonymization that upholds de-identification requirements. With this feature enabled, users can redistribute the noise across multiple columns of a data source within a project to make specific columns more useful for their analysis.
: This explanatory guide contains a conceptual overview of purposes in Immuta and the business value achieved by using purpose-based access controls.
See the guide.
See the guide.
: The users who will create, manage, and use projects.
: 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 , despite their subscription to other data sources.
Subscription policy: Project users with the appropriate permissions can on a project to control the users who can join.
: Project equalization ensures 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 or workspaces where users can view and write data.
: Derived data sources are the data sources that come from workspaces. Once they are created, they automatically inherit policies from their parent sources.
: Within a project, users can join masked columns.
Project role | capabilities |
---|
Purposes help define the scope and use of data within a project and allow users to meet . 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.
Purposes can be constructed as a hierarchy, containing nested sub-purposes, much like in Immuta. This design allows more flexibility in managing purpose-based restriction policies and transparency in the relationships among purposes.
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 leaks when users collaborate. Users can 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.
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 .
If or is enabled, you must own the project.
Opt to select for specific columns.