There’s nothing worse than when you lose the remote to your TV. All you want to do is sit on the couch and change the channel or the volume at your leisure — but when you don’t have a remote you have to get up, walk over to the tv, click the “next channel” button twenty-five times until you get to the channel you want, then walk all the way back to the couch to sit down, exhausted. Oh, then you realize it’s too loud, and now you have to do the whole thing all over again. It’s downright infuriating.
But if you didn’t know that a remote existed, you probably wouldn’t mind it so much, right? If that’s all you ever had, it would seem normal. This is a good way to think about how ALTR works when it comes to sensitive data masking in Snowflake. You can do it without us, but it's a heck of a lot easier to do it with us.
What you do now: write your own data masking policies in Snowflake using SnowSQL
Generally, writing a data masking policy in Snowflake requires roughly 40 lines of SnowSQL per policy. Depending on your business, that can turn into 4,000 lines real quick. And then you have to test to make sure it works as intended. And then you have to go through QA. And then you have to update it and start the process all over. The process can feel endless. Just like going from channel 12 to channel 209 without a remote, it’s exhausting and tedious.
If you look at Snowflake’s documentation, you’ll see that creating data masking in Snowflake requires 5 steps:
1. Grant masking policy privileges to custom role
2. Grant the custom role to a user
3. Create a sensitive data masking policy
4. Apply the data masking policy to a table or view column
5. Query data in Snowflake
That’s just to get started with basic sensitive data masking in Snowflake! If you want to apply different types, like a partial mask, time stamp, UDF, etc. then you’ll need to refer back to the documentation again. To get more advanced with tag-based or row-level policy, you’ll need another deep dive.
The big kicker here is the amount of time it takes to code not only the initial policies, but to update them and test them. No matter how good anyone is at SnowSQL, there’s always room for human error that can lead (at best) to frustration and (at worst) to dangerous levels of data access.
So, what if you could automate that process? What if you could use a remote to do it for you to save time and keep things streamlined for your business?
What you could be doing: automate your data masking policies with ALTR
Setting a sensitive data masking policy in ALTR is like clicking “2-0-9" on your remote when a commercial comes on channel 12; you log in, head to the Locks tab, and use ALTR’s interface to set a policy that has already been tested for you. And when something changes in your org, you log back in and update your data masking policy or add a new one with just a few clicks.
Here’s exactly how that works:
- Navigate to Data Policy --> Locks --> Add new
- Fill out the lock details: name, user groups affected.
- Choose which data the apply policy to, then choose the masking type you’d like to use (full mask, email, show last four of SSN, no mask, or constant mask).
a. Column-based (sensitive columns have been classified and added for ALTR to govern)
b. Tag-based (tags are defined either by Google DLP, Snowflake classification, Snowflake object tags, or tags imported from a data catalog integration).
- (Optional) Add another policy.
- Click “Add Lock”
That’s it; there’s no code required, and anyone in the business can do it if they have permission. To update or remove a lock, all you have to do is edit the existing policy using the same interface.
ALTR’s data masking policies are not only easy to implement, but they leverage Snowflake’s native capabilities, meaning that it’s not only the most cost-effective method, but it ensures that your policy works best with Snowflake.