Data Row

Data Governance and Snowflake Row Level Security

Share on facebook
Share on twitter
Share on linkedin

In my last article, I talked about how Snowflake’s dynamic data masking features can be used to implement data governance principles. This time I’m going to talk about another one of Snowflake’s data governance features – row level security. 

One of the big questions we answer with data governance is, “Who can see and use my data?”  A data governance program will put a framework in place to make decisions about who can see what data. Once that question has been answered, it’s up to technology to implement the solution and ensure the data governance policy is being followed, and that’s where some of the innate capabilities in Snowflake start to shine.

Like data masking, which I talked about last time, row-level policies are also applied at query run-time, meaning your underlying data remains unchanged. However, whereas data masking is for obfuscating sensitive data values in specific columns, row-level security does something slightly different. With row-level security, you can control which rows a user can see at all. This means that whether or not the record even shows up for the user depends on whether they have a role which is allowed to see the record or not. If the role they are using is not allowed to see the record, they won’t ever see it or know it existed. 

For example, you can set up a row-level access policy which filters records to users based on which region they are located in – only users in Europe would receive query result rows for Europe inventory, for example. Only users in North America would receive results for North America, and so on. The rules are applied at query run-time, and applied first to tables, then views. So if your user is viewing data via a view, the row-level policy applies and the results they receive from querying a view would still exclude any records they don’t have permission to receive. 

Snowflake includes the capability to make these rules as simple or complex as you need them to be. You can create nested row-level access policies, and you can create mapping tables to execute more complicated mapping of roles to specific data sets. And, in case you’re wondering, data masking and row-level access work together. You can still mask specific columns while filtering the rows that a user receives in their query results. 

This is how Snowflake makes implementing the answers to your data governance questions simple and straightforward. As a data steward or owner, you’ll still need to decide who can see what data, but once those decisions have been made, it’s easy to execute your vision and needs using native capabilities already available within the tool.

 

 

More from Hakkoda:

Download our eBook: THE STATE OF DATA AND THE HIGH COSTS OF DATA SPRAWL

 

Read other blogposts: