Prerequisite: Before using this walkthrough, please ensure that you’ve done Parts 1-3 in the POV Data Setup walkthrough.
In the prior walkthroughs in this theme, we’ve spent a lot of time talking about attribute-based access controls and their benefits. However, in today’s world of modern privacy regulations, deciding what a single user can see is not just about who they are, but what they are doing. For example, the same user may not be able to see credit card information normally, if they are doing fraud detection work, they are allowed to.
This may sound silly because it’s the same person doing the analysis, why should we make this distinction? This gets into a larger discussion about controls. When most think about controls, we think about data controls - how do we hide enough information (hide rows, mask columns) to lower our risk. There’s a second control called contextual controls; what this amounts to is having a user agree they will only use data for a certain purpose, and not step beyond that purpose. Combining contextual controls with data controls is the most effective way to reduce your overall risk.
In addition to the data controls you’ve seen in Immuta, Immuta is also able to enforce contextual controls through what we term “purposes.” You are able to assign exceptions to policies, and those exceptions can be the purpose of the analysis in addition to who the user is (and what attributes they have). This is done through Immuta projects; projects contain data sources, have members, and are also protected by policy, but most importantly, projects can also have a purpose which can act as an exception to data policy. Projects can also be a self-service mechanism for users to access data for predetermined purposes without having to involve humans for ad hoc approvals.
Purpose-based exceptions reduce risk and align with many privacy regulations, such as GDPR and CCPA. They also allow policy to be created a priori for exceptions to rules based on anticipated use cases (purposes) in your business, thus removing time-consuming and ad hoc manual approvals.
Because of this, the business reaps
Increased revenue: accelerate data access / time-to-data, no waiting for humans to make decisions.
Decreased cost: operating efficiently at scale, agility at scale because humans are removed from the daily approval flows.
Decreased risk: align to privacy regulations and significantly reduce risk with the addition of contextual controls.
Assumptions: Your user has the following permission in Immuta (note you should have these by default if you were the initial user on the Immuta installation):
GOVERNANCE: in order to add a new purpose, build policy against any table in Immuta, and approve a purpose’s use in a user created project.
In this example we are going to hide credit card data unless acting under a certain purpose. Let’s start by creating the purpose as a user with GOVERNANCE permission.
Click the Governance icon in the left sidebar of the Immuta console.
On the Purposes tab, click + Add Purpose.
For Purpose Name put Fraud Analysis.
Leave the default Statement. However, this statement is important, it is what the user is agreeing to when they use this Purpose; you can edit this to whatever internal legal language you want.
Leave the Description empty.
Click Create.
You should see the Fraud Analysis purpose you created listed now. However, let’s add a hierarchy to this purpose, similar to what we did with tags in the Hierarchical Tag-Based Policy Definitions walkthrough.
Click Edit to the right of your Fraud Analysis purpose to edit it.
Click Add Sub Purpose.
For the nested purpose, enter Charges.
Click Save.
Now let’s build a policy:
Click the Policies icon in the left sidebar.
Click + Add New Data Policy.
Name it Mask Credit Card Numbers.
For action, select Mask.
Leave columns tagged.
Type in the tag Discovered.Entity.Credit Card Number.
Change the masking type to by making null.
Leave everyone except.
Set when user is to acting under purpose.
Set Fraud Analysis.Charges as the purpose.
Click Add.
Now let’s add a second action to this policy:
Click + Add Another Action.
Select Limit usage to purpose(s).
Select Fraud Analysis as the purpose. (Notice that we left off Charges, unlike above.)
Change for everyone except to for everyone.
Click Add.
Leave Where should this policy be applied? as is.
Click Create Policy and then Activate Policy.
Following the Query Your Data guide, confirm that neither your admin user nor the non-admin user you created in Part 3 of the POV Data Setup can see data in the “Fake Credit Card Transactions” table. This is because neither is acting under purpose Fraud Analysis. If they could query the table, they wouldn’t see the credit card numbers either, because they also aren’t acting under purpose Fraud Analysis.Charges.
Ok, so how do we work under a purpose? Let’s use your non-admin user you created in Part 3 of the POV Data Setup for this part to prove that this is completely self service for your users.
Log in to Immuta with your non-admin user you created in Part 3 of the POV Data Setup in a private or incognito window.
Click the Data icon and select Projects in the left sidebar of the Immuta console.
Click + New Project.
Name the Project My Fraud Project.
Set the description as Immuta POV.
Leave the documentation as the default. (You could add markdown to describe your project here.)
Set your purpose to Fraud Analysis.
Ignore Native Workspace.
For Data Sources, select your Fake Credit Card Transactions table(s).
Click Affirm and Create -- note that you are affirming the acknowledgement statement that popped up in the previous section.
Click the Project Overview tab.
You will see the Fraud Analysis purpose there, but it is staged.
At this point you have the project, but until another user with GOVERNANCE or PROJECT_MANAGEMENT permissions approves that purpose on that project, you cannot act under it. This is because a human must confirm that the data sources you added to the project align with the purpose you are acting under and the project you are attempting to accomplish. Yes, this is a manual approval step; however, it is fully documented in the project and audited, allowing the approver to make a decision with all information required. This is not a policy decision - it is a decision on if the project legitimately aligns to the purpose. Let’s go ahead and do that with your other user.
Go to your Immuta window that has the admin user with GOVERNANCE permission logged in.
You should see a little red dot above the Requests icon in the upper right corner of the Immuta console.
If you click on the Requests icon, you will see you have There are 1 pending Purpose Approval request(s).
Click the Review button. This will drop you into your Requests window under your profile. You can review the request by visiting the project through the hyperlink, but since you already know about the project, just click the checkbox on the right to approve it.
Go back to the other non-admin user window and refresh the project screen.
You will be asked to acknowledge the purpose per the statement that was attached when the purpose was created. Click I Agree. (That will be audited in Immuta.)
Now that the Fraud Analysis purpose is active, click in the upper right corner of the console where it says No Current Project - that menu is how you switch your project contexts to act under a purpose.
Set your current project to the one you created: My Fraud Project.
You are now acting under the purpose: Fraud Analysis.
To prove it, following the Query Your Data guide, confirm that non-admin user can see data in the “Fake Credit Card Transactions” table. Make sure you are querying as the non-admin user that just switched their project. Note that it may take 10 - 20 seconds or so before Immuta updates your current project in the enforcement point before you can see the data. (Immuta does some caching.)
Ok, that was cool, but look, the credit card numbers are null. This is because we use a more specific purpose to exception you from the credit card masking policy, remember, it was Fraud Analysis.Charges rather than just Fraud Analysis. So let’s make our purpose more specific in the Project, re-approve it, and then show the credit card numbers are in the clear.
Using the non-admin user that created the project, click Manage above the purposes on the My Fraud Project Overview tab.
In the Purposes drop down, uncheck Fraud Analysis and then select Fraud Analysis.Charges.
This will require you to affirm the new purpose.
Go back to your admin user and go through the flow of approving the purpose again; you will have another Requests notification. (You can just refresh the Requests screen if you are already there.)
Once approved, go back to the non-admin user and refresh their My Fraud Project window.
Click I Agree to the acknowledgement.
You are now acting under the purpose Fraud Analysis.Charges. Now query the data again with your non-admin user following the Query Your Data guide. The credit card numbers are in the clear because you are acting under the appropriate purpose!
But wait, did you notice something? Why are you able to see the table at all? You aren’t working under the purpose of Fraud Analysis anymore? This is because Fraud Analysis.Charges is a more specific subset of Fraud Analysis, so by acting under it you also are acting as any other Purposes further up the tree - the power of hierarchical purposes!
DO THIS: Ok, now we need to do some cleanup because we want to use that credit card data later in these walkthroughs and not have to act under a purpose to do so (this will let the other walkthroughs stand on their own without having to do this walkthrough).
With your admin user, click the Policies icon in the left sidebar.
Find the Mask Credit Card Numbers policy you created in this walkthrough.
Click the menu button to the right of it and select Delete.
Click Confirm.
With your non-admin user, switch your project toggle: Switch Current Project: None. Note: If you do not do this step, you will only be able to see the tables in the My Fraud Project and no tables outside the My Fraud Project when querying data.
Some may claim they can do purpose exceptions using - you guessed it - Roles! Sigh, as we’ve seen, this continues to exacerbate our role explosion problem.
Also, there are two kinds of RBAC models: flat and hierarchical. Flat means you can only work under one role at a time (Snowflake uses this model) which does align well if you wanted to do the anti-pattern and use roles. However, most databases (everything other than Snowflake) have hierarchical roles, meaning you act under all your roles at once. For hierarchical roles, using a role for purpose doesn’t work because at runtime you have no idea which purpose the user is actually acting under - why does that matter? Remember, the user acknowledged to only use the data for that certain purpose, if the user has no way to explicitly state which purpose they are acting under, how can we hold them accountable?
Lastly, there is no workflow for the user to acknowledge they will only use the data for the purpose if you are simply assigning them roles, nor is there a workflow to validate that the purpose is aligned to the project the user is working on.
For these reasons, Purpose needs to be its own object/concept in your access control model.
Feel free to return to the POV Guide to move on to your next topic.