.png)
It goes without saying that in today’s environment, governing and protecting sensitive data requires using different tactics to execute an effective security strategy. Here at ALTR we offer numerous methods to choose from for your business needs; the capability to govern Snowflake data views in situations where you might want to see data that’s combined or separated is one to consider.
This blog provides a high-level explanation of what a ‘view’ is, the benefits it offers, how it works to manually govern views in Snowflake, and how to use ALTR to automate the governing of views by taking advantage of Snowflake’s native capabilities without needing to write SQL code. A couple of use case examples and a how-to demonstration video are also included that we hope you’ll find helpful.
What are Views and What are the Benefits it Offers?
A ‘view’ is a Snowflake object that allows a query result to be accessed just like it was a table. Think of it as a named query that has been saved. Snowflake users can then query this saved query as if it were a table.
Since the data within the view is the result of the query, then data engineers can create separate views that meet the needs of different types of employees, such as accountants and HR administrators at a hospital.
There are several different types of views in Snowflake that all have different behaviors such as ‘Regular Views’, ‘Materialized Views’, and ‘Secure Views’; however, for the sake of brevity, this blog will only explain views in general terms. For details on how the types of views in Snowflake differ, visit Snowflake Overview of Views.
Benefits that Views Offer
Using ALTR to govern views will enable you to only extract the data that you want to see. As a result, it will be easier to understand when you have a large amount of data.
You will also benefit by being able to grant privileges on a particular view to a specific role, without the people in that role having privileges on the table(s) underlying the view. For example, you can have one view for the HR staff and one view for the accounting staff, so that each of those roles in the hospital can only see the information needed to perform their jobs.
How Snowflake Views Work if You DIY
As stated earlier, there are different types of views that Snowflake supports. Each of them will require you to write SQL code to do it and will require you to define each ‘view’ based on the type you prefer to implement. This can be time-consuming to do and must be maintained as your business scales.
How ALTR’s Policy Automation Works with Snowflake Views
Our policy automation on Snowflake views supports column access and masking. It also enables you to identify and connect columns that exist in Snowflake Views and apply column access policies and masking rules to those columns all without writing SQL code.
Like 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.
- From the Data Management page, click the Add New button.
- In the resulting form, select a Snowflake database.
- Next, click the View tab (shown in the screenshot). This will enable you to identify a specific column from the view to connect by selecting the schema and view for that column.
- 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.
ALTR Use Cases for Snowflake Views
Good to Know: 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(s). 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. However, there are some cases where you may want to apply and manage policies at the View level. As seen in the previous section, ALTR makes adding and/or updating data access policies on views very simple.
Here are a couple of use case examples where using ALTR to govern sensitive data from Snowflake Views can benefit your business as it scales up with Snowflake usage.
Use Case 1. Your organization has a database that’s shared across different Snowflake accounts that you don’t want others to query directly. In addition, Snowflake limits the application of masking policies on the share.
To govern data within a share, you can create a separate database with views that select from the shared database. You can then govern access to columns in these views from the ALTR UI without writing SQL code. This means that you can delegate this administrative task to members of your infosec team instead of DBAs.
Use Case 2. Your Snowflake configuration primarily relies on users, BI tools, etc., querying Views instead of Tables.
Similar to the use case above, if your organization only presents views to end users and never exposes the databases directly, then you can control access to columns in these views from the ALTR UI.
Automate Snowflake Views with ALTR
By using ALTR to govern Snowflake Views, you can minimize data breaches and make informed decisions to execute an effective data security strategy. We’ve made it so simple to use that it’s just a point-and-click in ALTR and you’re done!