Separation of Policy Building from Data Tagging
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.
Overview
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.
Business Value
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.
“Experts” in Immuta
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.
Anti-Patterns
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.
Next Steps
Feel free to return to the POV Guide to move on to your next topic.
Last updated