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 your Snowflake Masking Policy. You can do dynamic data masking in Snowflake without us, but it's a heck of a lot easier to do it with us.
What you do now: write your Snowflake masking policy using SnowSQL
Generally, writing a Snowflake masking policy 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 a Snowflake masking policy requires 5 steps:
1. Grant Snowflake masking policy privileges to custom role
2. Grant the custom role to a user
3. Create a Snowflake dynamic data masking policy
4. Apply the Snowflake masking policy to a table or view column
5. Query data in Snowflake
That’s just to get started with a basic Snowflake Masking Policy! 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 Snowflake 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: automating your Snowflake 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 Snowflake masking 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:
1. Navigate to Data Policy --> Locks --> Add new
2. Fill out the lock details: name, user groups affected.
3. Choose which data to apply policy to, then choose the dynamic data masking type you’d like to use (full mask, email, show last four of SSN, no mask, or constant mask).
a. Column-based data masking (sensitive columns have been classified and added for ALTR to govern)
b. Tag-based data masking (tags are defined either by Google DLP, Snowflake classification, Snowflake object tags, or tags imported from a data catalog integration).
4. (Optional) Add another policy.
5. Click “Add Lock”
That’s it; there’s no code required, and anyone in the business can set up a Snowflake masking policy if they have the right Snowflake permissions. To update or remove a lock, all you have to do is edit the existing policy using the same interface.
ALTR’s data masking in Snowflake policies are not only easy to implement, but they leverage Snowflake’s native capabilities, like Snowflake tag-based masking. That means that ALTR is not only the most cost-effective method, but it ensures that your policy works best with Snowflake.