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 Detection walkthrough.
Cell-level security is not exactly an advanced privacy enhancing technology (PET) like we showed in the Example of anonymizing a column rather than blocking it walkthrough, but it does provide impressive granular controls within a column for common use cases.
What is cell level security?
If you have values in a column that should sometimes be masked, but not always, that is masking at the cell level, meaning the intersection of a row with a column. What drives whether that cell should be masked or not is some other value (or set of values) in the rest of the row shared with that column (or a joined row from another table).
Let’s use a silly example. Let’s say we want to mask the credit card numbers, but only when the transaction amount is greater than $500. This allows you to drive masking in a highly granular manner based on other data in your tables.
Creating a balance between privacy and utility is critical to stakeholders across the business. Legal and compliance stakeholders can rest assured that policy is in place, yet data analysts can have access to more data than ever before.
Because of this, the business reaps
- Increased revenue: increased data access by providing utility from sensitive data rather than completely blocking it.
- Decreased cost: the amount of views you would need to create and manage to do cell-level controls manually would be enormous.
- Decreased risk: your organization may end up over-sharing since they don’t have the granular controls at their fingertips, opening up high levels of risk. With Immuta, you can reduce risk through the privacy vs utility balance provided.
Building a cell-level masking policy
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 on any table OR
- “Data Owner” of the registered tables (you likely are the Data Owner and have GOVERNANCE permission).
Let's create a Global masking policy.
- Log in to Immuta with the user that owns the data sources you created in the POV Data Setup.
- Click the Policies icon in the left sidebar.
- Click + Add New Data Policy.
- Name it Mask Credit Cards.
- For action, select Mask.
- Leave columns tagged.
- Type in the tag
Discovered.Entity.Credit Card Number.
- Change the masking type to using a constant.
- Enter the constant REDACTED.
- Change for to where.
- For the where clause, enter transaction_amount > 500.
- Note that you can also reference tags in your where clause, so we could have done something like
@columnTagged(‘amounts’) > 500if the
transaction_amountcolumns are named differently across tables.
- Change everyone except to everyone. (This policy will have no exceptions.)
- Click Add.
- Leave Where should this policy be applied? as is. (Immuta will guess properly based on previous steps.)
- Click Create Policy and then Activate Policy.
You can also test out whether everything was masked correctly in the “Immuta fake credit card transactions” table by
following the Query Your Data guide. Note that if the
transaction_amount column is greater than
$500, the credit card number in that same row is replaced with the word REDACTED.
Note: If you cannot query the “Immuta fake credit card transactions” table it’s likely because you did not remove the purpose restriction policy from the Purpose based exceptions walkthrough.
Coarse-grained access control. Over- and under-sharing gets you in hot water with either Legal and Compliance (want more privacy) or the analysts (want more data), depending on which direction you go. Highly granular techniques like cell-level security give you the flexibility to make these tradeoffs and keep both stakeholders happy.
Feel free to return to the POV Guide to move on to your next topic.