Using ALTR to Govern Views in Snowflake

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.

Governing Snowflake Data in a View through ALTR

While governing views in ALTR is in beta, limited support is offered for Column Access Policies on columns in Snowflake Views.

Available Offerings of Views

Views enables you to:

• Identify and connect columns to ALTR that exist in Snowflake Views
• Apply column access policies and masking rules to those columns

Unavailable Offerings of Views

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:

• Row Access Policies
• Classification of data
• Importing historical consumption data

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.

How to Govern Data in a View

This section provides the steps to govern data in a View.

PREREQUISITE

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.
‍

Notes:

• After you run the newest stored procedure, any newly connected databases will be able to operate on views shortly afterward.
• It might take up to three days for ALTR to identify view information for Snowflake databases that are already connected.

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.
‍

1. From the Data Management page, click the Add New button.
2. In the resulting form, select a Snowflake database.
3. Next, click the View tab. This will enable you to identify a specific column to connect by selecting the schema and view for that column.
4. Click Connect.
   Once a column in a Snowflake view is connected to ALTR, then it can be included in column access policies just like columns from tables.

NOTE: Columns in views can also be governed through our Management API. For more details, see our Swagger documentation.

When to Use Governance on Snowflake Views versus Tables

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 Cases that Might Warrant Creating Governance Policies on Views

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.

Notice About View-Based Governance (Nested Governance Policies)

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.

Example Scenario

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.

Frequently Asked Questions

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 support@altr.com

‍

‍