Prerequisites: Before using this walkthrough, please ensure that you’ve first completed Parts 1-5 of the POV Data Setup and the Schema Monitoring and Automatic Sensitive Data Discovery walkthrough.
Separation of duties is a critical component of policy enforcement. An additional component to consider is also separation of understanding. What we mean by that is there may be some people in your organization that are much more knowledgeable about what policies must be enforced vs people in your organization that understand deeply what data is contained in certain tables, “experts” on data, so to speak.
If you’ve created a few global policies during this POV guide, you’ve noticed that they are driven based on tags on data. Wouldn’t it be nice if you could rely on data experts to ensure that data is being tagged correctly, and rely on the data engineers to ensure that policy is being authored appropriately based on requirements - separation of understanding? This is possible with Immuta.
As with most features we’ve discussed in this guide, this is an optional approach that can be taken to optimize scalability and avoid costly policy mistakes by separating controls to who knows best.
Because of this, the business reaps
Increased revenue: accelerate data access / time-to-data, tagging and policy building is optimized by those who know it best.
Decreased cost: operating efficiently at scale, everything happens faster because experts of their domain are in charge.
Decreased risk: putting experts in charge of their domain reduces risks and mistakes by avoiding go-betweens.
Assumptions: Your user has the following permissions in Immuta (note you should have these by default if you were the initial user on the Immuta installation):
GOVERNANCE: in order to build policy or assign an expert against any table in Immuta OR
Are a “Data Owner” of the registered tables (you likely are the Data Owner and have GOVERNANCE permission).
We are going to add an Expert to your data table, once an expert, they can manage and validate tags while you focus on policy building.
Log in to Immuta with your user with GOVERNANCE permission (and/or is the Data Owner of the table “Immuta Fake HR Data”).
Visit the Immuta Fake HR Data data source.
Click the Members tab.
Find the non-admin user you created in Part 3 of the POV Data Setup.
Change their Role from subscribed to expert.
Now that user is no longer simply subscribed to that table, as an expert they can manage all metadata surrounding the data source, such as documentation and tags.
Log in to Immuta with the user you just made an expert in the above step.
Visit the same Immuta Fake HR Data data source.
Visit the Data Catalog tab.
Click the Add tags button to the right of the race column.
Start typing Ethnic and you should see the tag Discovered.Entity.Ethnic Group - select that tag.
Note if you have multiple computes/warehouses with this table, you should do this in all of them.
That tag was not automatically discovered by Immuta’s sensitive data discovery but now was added by an expert.
If you had policies that were built referencing Discovered.Entity.Ethnic Group, they would now attach to that column since an expert tagged it as such.
Forcing a single “god” user (or very small set of god users) to manage everything isn’t necessarily an anti-pattern, but it certainly can make things more difficult for those charged with solving your access control problems. You may force some users out of their comfort zone where there are other users more comfortable with making those calls - you should empower them if they exist.
Feel free to return to the POV Guide to move on to your next topic.
Prerequisites: Before using this walkthrough, please ensure that you’ve first completed Parts 1-5 of the POV Data Setup and the Schema Monitoring and Automatic Sensitive Data Discovery walkthrough.
If you’ve already completed the Separation of Policy Building from Data Tagging walkthrough, you’ve seen the power of separating duties (and knowledge). In short, when managing policy, there are many components, and it's best to put those that are experts in their domain in control of their domain.
This walkthrough takes this concept a step further by providing an overview of how you can avoid “god” users that control all and instead use a domain-focused approach where data owners control their own data sources with complete autonomy.
To do this with Immuta you simply remove GOVERNANCE permission from everyone; in doing so, Data Owners have complete autonomy over how their data is controlled because they can write their own policies, even global policies, that are restricted to only their data sources. (You may have noticed this referenced multiple times in the Assumptions section of the walkthroughs.)
As with most features we’ve discussed in this guide, this is an optional approach that can be taken to optimize scalability and avoid costly policy mistakes by separating controls to who knows best.
Because of this, the business reaps
Increased revenue: accelerate data access / time-to-data, policy building is optimized by those who know it best.
Decreased cost: operating efficiently at scale, everything happens faster because experts of their domain are in charge.
Decreased risk: putting experts in charge of their domain reduces risks and mistakes by avoiding go-betweens and also aligns with many extraterritorial regulations.
Assumptions: Your user has the following permissions in Immuta (note you should have these by default if you were the initial user on the Immuta installation):
“Data Owner” of the registered tables (you likely are the Data Owner and have GOVERNANCE permission).
In this walkthrough, we are going to make a user a data owner and have them build a global policy that will only interact with the data sources they own.
Log in to Immuta with the user that owns the data sources you created in the POV Data Setup.
Since this user likely also have GOVERNANCE permission (the default for the first user on the system), we are going to give the non-admin user you created in Part 3 of the POV Data Setup ownership of one of the data sources:
Visit the Immuta Fake Credit Card Transactions data source.
Click the Members tab.
Find the non-admin user you created in Part 3 of the POV Data Setup. (Ensure they do NOT have GOVERNANCE permission.)
Change their Role from subscribed to owner.
That user is now considered a data owner of that data source. Note, you do not need to have GOVERNANCE permission to set ownership on a data source; any data owner of that specific data source can do that. Now, using that user you just made an owner of the “Immuta Fake Credit Card Transactions” data source, let’s build a policy.
Log in to Immuta with the user you just made an owner in the above step.
Click the Policies icon in the left sidebar.
Click + Add New Data Policy.
Name it My Data Owner Policy.
For action, select Minimize data source.
Set the percentage to 90%.
Change for everyone except to for everyone.
Click Add.
For Where should this policy be applied?
Select On data sources.
For circumstance, select tagged.
For the tag, select Immuta POV.
You’ll notice there’s an additional filter to where the policy will be applied: Restricted to data sources owned by users…
If you do not see this, it’s because that user has GOVERNANCE permission.
You’ll notice the user’s name is there.
You cannot edit this since you do not have GOVERNANCE permission, so this policy will automatically be limited to only the data sources this user owns.
Click Create Policy and then Activate Policy.
Note that users with GOVERNANCE permission are the only users who can create tags and purposes in Immuta, so the workflow would be to curate those up front (if necessary) and then trim back GOVERNANCE permissions as necessary.
It could be that you want a central group of users to control all policy on your data ecosystem, where there could be other cases where you want complete autonomy for your data owners, or somewhere in between. So there is no concrete anti-pattern here, just note that Immuta can support either approach.
Feel free to return to the POV Guide to move on to your next topic.