In part two<\/a>, we discussed ways to think about data access and control at a granular level. In this blog, we\u2019ll look at a newer Snowflake feature, object tagging, which gives us another tool in our toolbox to identify which data needs granular security.<\/p>\n First, let\u2019s review a key concept relevant to Snowflake tags: data vs. metadata.<\/p>\n Data is the information itself \u2013 date, amount, product, customer, and so on. Metadata is information about the data. For example, we know that this nine-digit number (our data) is a social security number (our metadata).<\/strong> Historically, we had to rely on a combination of naming conventions and human judgment to glean the metadata about our data, hoping the table is called something like \u201cemployee\u201d and the relevant column has a name like \u201csocial_security_number,\u201d or we look for patterns like \u201c123-45-6789.\u201d Now, we can tag our tables and columns directly, making it easy to keep track of important fields and control access to them.<\/p>\n Typical databases, feeds and files hold only data with minimal metadata (e.g., column names). However, Snowflake<\/a> provides the opportunity to store much more metadata in the form of tags. Snowflake offers the ability to create and apply tags to databases, schemas, tables, views and columns (and also to users and roles, which we will discuss in a future post)<\/strong>.<\/p>\n Tags are made of key-value pairs. For example, \u201ccost_center = finance\u201d or \u201cprotection_level = PII\u201d or \u201cPII_type = email.\u201d Equally as important, you can set up multiple tags and apply them to the same piece of data: \u201cpersonally-identifiable: true; sensitive: true; type: SSN; category: employee, owner: HR\u201d and so on. These tags can be anything we like and therefore require careful management to be useful.<\/p>\n Further, tags are inherited based on where you apply them \u2013 so if you tag a table \u201cprotection_level = private,\u201d every column in that table will also be tagged as \u201cprotection_level = private.\u201d This applies the same way at higher levels: if you tag an entire database as \u201cprotection_level = private,\u201d then every schema, every table, every view and every column in that database will be tagged as \u201cprotection_level = private.\u201d This again argues for careful management but is ultimately very useful. If you write a query that brings back columns from multiple places, each column pulled from anywhere in the private database will carry the \u201cprotection_level = private\u201d tag in Snowflake\u2019s tagging repository.<\/p>\n You can also override or add to tags. A specific table in the \u201ccost_center = finance\u201d schema may have its tag overridden to \u201ccost_center = finance_north_america.\u201d All the columns in a table with \u201cprotection_level = PII\u201d will have the same \u201cprotection_level = PII\u201d tag but can also have a specific tag such as \u201cPII_type = email\u201d appended, so both pieces of information are returned when you query information about that column.<\/strong><\/p>\n Important note: Many different tags can be applied to the same table or column, but you cannot set multiple values for the same tag on the same column. We need to plan and organize our tags carefully in situations where multiple pieces of similar information may apply. For example, you cannot combine \u201cprotection_level=PII\u201d and \u201cprotection_level=GDPR\u201d, but you can combine \u201cPII=true\u201d and \u201cGDPR=true\u201d.<\/p>\n In the previous entry in this series, we discussed the Dynamic Data Masking feature that lets us hide the contents of sensitive fields from people without access. Now, we can use tagging to support and improve our masking efforts. Snowflake has not yet implemented a fully-dynamic combination of tagging and masking: you must set Dynamic Data Masking explicitly on each column, and the masking rule cannot simply look up and use that column\u2019s tags. However, we can still use this information to drive our masking implementation and audit for completeness. We can query Snowflake to find out all tagged columns that should be masked per our rules, query to find out which ones are or are not masked, and apply masking where it\u2019s missing.<\/strong> We can also query Snowflake\u2019s history tables to see who accessed tagged tables or columns and when.<\/p>\n Combining tagging capability with Dynamic Data Masking, we can create and enforce a hierarchy of permissions:<\/p>\n You can keep this simple by using tags to inform your masking requirements, or you can write a slightly more complicated masking policy that reads from the SYSTEM$GET_TAG function to enforce masking based directly on the tags in place. This isn\u2019t completely dynamic \u2013 you need to code for the specific tag and column combinations you want to check \u2013 but it does make your code more self-documenting and secure.<\/strong> (Since processing this lookup logic will take some computing resources, you\u2019ll want to do a proof-of-concept to make sure your specific implementation still performs well if you go this route).<\/p>\n Given a masking implementation using the example tags above, if any user in your company who has not been granted access to the \u201cemployee_data\u201d tag happens to find the Employee table and tries to query it, they\u2019ll get:<\/p>\nWhat Are Tags in Snowflake?<\/h2>\n
Combining Tagging and Masking<\/h2>\n
Database Tag: \u201cowner = HR\u201d\r\nSchema Tag: \u201ccategory = employee_data\u201d\r\nTable Tag: \u201cprotection_level = PII\u201d\r\nColumn Tags: \u201cPII_type = firstname,\u201d \u201cPII_type = lastname,\u201d \u201cPII_type = work_email,\u201d \r\n\u201cPII_type = work_phone,\u201d \u201cPII_type = personal_phone,\u201d \u201cPII_type = dob,\u201d and \u201cPII_type = ssn\u201d<\/pre>\n
![\"Snowflake](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2022\/10\/Snowflake-Series-PT3-Tagging-Blog-Graphic-01-1024x120.png\")
<\/a><\/p>\n![\"Snowflake](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2022\/10\/Snowflake-Series-PT3-Tagging-Blog-Graphic-02-1024x103.png\")
<\/a><\/p>\n