This page provides information about using ALTR to govern views in Snowflake. ALTR offers the capability for you to govern views (which support basic column access and masking) as part of your data security needs. A 'View' allows a query result to be accessed just like it were a table.
You can use views in situations where you might want to see data that's combined or separated.
While governing views in ALTR is in beta, limited support is offered for Column Access Policies on columns in Snowflake Views.
Views enables you to:
Due to differences in how data technologies treat views, ALTR does not support governing data in views for non-Snowflake data sources (for example, SQL Server, Postgres, etc.,). In addition, ALTR does not currently support the following features in Views:
NOTE: Even though ALTR allows you to create thresholds on View data or analyze query usage analytics on views, there are some known scenarios where thresholds will prematurely trigger for columns in views. In addition, usage analytics will incorrectly count some data accesses on columns in views. This is due to how Snowflake treats masking policies on Views while the rest will be addressed by ALTR.
This section provides the steps to govern data in a View.
You will need to grant the appropriate Service User permissions for ALTR to identify and govern data in a view. For the steps, read the Stored Procedure documentation.
Similar to tables, columns in views must be connected to ALTR before they can be included in governance policies. To govern a column in a Snowflake view, follow the steps below.
NOTE: Columns in views can also be governed through our Management API. For more details, see our Swagger documentation.
Views in Snowflake inherit the governance policies of their base tables; so, if you query data in a view, then Snowflake will still apply any Dynamic Data Masking Policies and/or Row Access Policies assigned to the Views base table. Because of this, it's usually much simpler to only apply governance rules once to the data in tables and leverage this functionality to prevent an explosion of masking policies.
Use Case 1) Databases created from Snowflake Shares where Snowflake limits the application of masking policies
To govern data within a share, you can create a separate database with views that select from the shared database. You can then leverage ALTR to govern access to these views while preventing users from querying the share database directly.
Use Case 2) Materialized Views
Snowflake does not allow materialized views to select from base tables that include Dynamic Data Masking Policies or Row Access Policies. In this scenario, you can leverage ALTR to directly govern the materialized view while preventing users from querying the share database directly.
Use Case 3) Organizations that require different access rules for the same data within a Snowflake account or database
If your organization has a data consumption paradigm that involves a single role having different access to a dataset based on what view it is selecting, then this can be accomplished by using ALTR to govern the view directly.
This section explains the things to be careful about view-based governance.
Nested Governance policies occur when a Snowflake view and its base table have governance rules applied to them. In this scenario, Snowflake applies each governance rule separately. This can be difficult to maintain and can trigger queries that might be confusing to you if these rules aren't consistent for a particular data asset.
When possible, ALTR recommends that you govern data in tables OR in views, but not both. This can help minimize the risk of nested governance policies.
A view in Snowflake can reference a base table and a base view. As a result, an infinity nested view might be created as Snowflake enables policies to be created at each level of the view.
Governance rules applied to a base table execute before those on views. For example, let's use a situation where there are rules designed to prevent the role ANALYST from accessing plain text email addresses. Imagine that there's a table CUSTOMERS that includes a column of email addresses and a view CUSTOMERS_VIEW that is defined as "SELECT * FROM CUSTOMERS". You use ALTR to apply different masking rules to the table and the view.
In the table, the ANALYST role is configured to access the email column with a Last4 mask. In the view, the ANALYST role is configured to access the email column with an email mask. If a user with the ANALYST role queries the data, then they will only see asterisks for the email column. This will occur because the Last4 mask executes first, replacing all of the email addresses with "***.com", "***.net", and so on. Next, the email mask from the view applies and when it cannot find an ampersand to indicate where the domain begins, replaces all characters in every email with an asterisk.
Can I create thresholds on View data?
Yes, you can; however, be aware that there are some known scenarios where thresholds will prematurely trigger for columns in views. In addition, due to how Snowflake treats masking policies on views, usage analytics will incorrectly count some data accesses on columns in views.
Will ALTR identify view information on connected Snowflake databases instantly?
It might take up to three days for ALTR to identify view information for Snowflake databases that are already connected.
How can I provide feedback about this View function through ALTR?
You can send an email to email@example.com