Published in Snowflake
Debi Prasad Mishra
Jan 10 · 5 min read · Listen
Snowflake Row-level Security using Row Access
Policies
A process of maintaining the security on row-level through the use of row access
policies to determine which rows to return in the query result.
Snowflake Row Level Security
This is a continuation of previous post on Snowflake column level security
usage using dynamic data masking and its various characteristics. I would
highly recommend, please check the first blog before moving here.
Prerequisite: Snowflake trial account with object read/write access is must
and SQL understanding is required. Concept of data loading & unloading in
Snowflake is good to have but not mandatory. Using Snowflake web UI able
to load data into table(s). Snowflake concept is nice to have.
What is Row-level Security: A row access policy can be relatively simple to
allow one particular role to view rows or to be more complex to include a
mapping table when needed in the policy definition to determine access to
rows in the query result. By implementing a row access policy defined on
the base table we protect that data at its lowest level of granularity.
What are the benefits:
- Enables an organization to properly balance data security, governance.
- Allows one or more conditions to be added or removed at any time.
- Write a policy once and apply it to tables across databases and schemas.
- Easily change in access policy definitions without having to reapply.
- Easy to manage and support through centralized, decentralized to support
segregation of duties.
Limitations:
- Not supports the external tables as a mapping table in a row access policy.
- Not supports attaching a row access policy to the stream object itself.
- Future grants of privileges on row access policies are not supported.
- Future grants cannot be used with row access policies.
- Supports AND clauses in the subquery of the access policy. As a result of
this, it does not support multiple single values. For example, a user cannot
see data from multiple regions.
Business Scenario: Consider a user demographics data of an organization
split across multiple tables for customer 360 view analytics. Below are the
specific security use cases required to secure this data:
1 — Since demographics information contains sensitive information such as
PII data and all, this data should have access their own departments only.
2 — The divisional managers should have access only to their divisions.
3 — Division specific IT teams should have analyst role to perform certain
business analytics.
Conceptual View: Following steps to configure row access policy privileges
and to add row access policies to the tables and views.
Step 1: Create a table and load sample records for demonstration
Step 2: Create mapping table, custom role and grant select privilege
Step 3: Create a row access policy
Step 4: Grant the privileges to custom roles
Step 5: Add the row access policy to the table created at step 1
Step 6: Allow a role to query the protected table data
Step 7: Test the policy! Enjoy :-)
Demonstration/ Coding:
Step 1: Let’s create a sample table and insert some records as mentioned.
Search Medium Write Sign up Sign In
Database, schema and table setup
Step 2: Inserted records displayed as below.
Insert statements
Table display
Step 3: Let’s design a user role mapping table as displayed below.
Role mapping table based on defined Roles
Step 4: Now it’s time for custom role creation, make sure the role name
should be same as the role mapping table as we defined.
Debi Prasad Mishra
243 Followers
Custom role creation
Engineer by Profession, Student by Passion.
Working as a Senior Business Intelligence
Engineer. Snowflake Data Superhero 2022
Step 5: Let’s grant the privilege's on database, schema and tables as below.
Follow
8 1 More from Medium
John Ryan in Snowflake
Top 14 Snowflake Data
Engineering Best Practices
Grant permissions Rajiv Gupta in Dev Genius
Database Role V/S Account
Role in Snowflake
Step 6: Let’s assign the custom roles to the current user to test functionality.
Rajiv Gupta in Dev Genius
When To Use Which Table In
Snowflake?
Rajiv Gupta in Snowflake
Snowflake Micro-partitions &
Table Clustering
Grants permissions and the current user to Test
Step 7: Finally let’s create a row access policy and add the policy using alter
statement as displayed below.
Policy association
Step 8: Now let’s start the code we developed. Please do follow my code and
will see the records returning from table.
Role having private banking records
Step 9: Let’s see the output of another role we have created.
Help Status Writers Blog Careers Privacy Terms About
Text to speech
Role having personal banking records
Step 10: Let’s user account admin role to see the output.
No output
Why no records, very simple is not it? As we don’t have account admin role
defined in the role mapping table. That’s why restricts the output.
Step 11: Let’s insert below records into role mapping table and will see.
Account Admin role inserts in role mapping table
Role mapping table
Account Admin role having all records
Conclusion: This explains, how row level security is defining & restricting
the rows in tables based on a users required level of access which helps in
preventing the sensitive data externally. Thank you for reading this post.
I hope this blog will help you to get understanding of the row access policy
usage and how efficiently we can build this fashion to protect data. Please
feel free to chat with me in case of more questions you have, on my twitter
handle or my LinkedIn or leave a comment below. Good luck!
Reference(s):
https://docs.snowflake.com/en/user-guide/security-row-intro.html
https://docs.snowflake.com/en/user-guide/security-row.html
Snowflake Data Engineering Business Intelligence Data Security
Data Superhero
Get an email whenever Debi Prasad Mishra publishes.
Subscribe
Your email
By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our
privacy practices.
About Help Terms Privacy