ALTR is constantly looking to solve problems for our customers. A recent challenge some of our customers were running into is governing and securing a Snowflake data share. ALTR’s creative solution enables this through governing views on Snowflake data shares. Here’s how:
Challenge: Extending Governance Across Snowflake Data Shares
In Snowflake, companies may have a primary production database or even a general data source that multiple groups need. This data often sits in a Snowflake account that may be accessible to only a handful of people or none at all. Snowflake admins can “share” read-only portions of that database to different groups on different Snowflake accounts internally across the company. This enables data consumers to utilize the data without risking changes or corruption to the source data or inconsistencies across the data in different accounts. If Snowflake admins are leveraging the native Snowflake governance features to apply governing policies such as data masking or column-level access controls with SQL on the primary database, those controls will be maintained in the shared database.
However, admins offering a Snowflake data share run into the same issues every Snowflake customer faces: managing those SQL policies manually at scale. It’s time-consuming, error-prone and risky. Generally, companies going down the primary/shared database path are large enough to have hundreds of databases and thousands of users. ALTR is the best solution to implement, maintain and enforce these policies at scale in Snowflake. But because these are “shares” (i.e. read-only), Snowflake does not allow data-level protections to be applied. So, we wanted to provide our customers with the ability to extend ALTR’s enforcement across Snowflake data shares in different accounts.
Solution: Create and Govern Views on Snowflake Data Shares
Let’s start with: what is a “view” in Snowflake? You can think of it as a faux table that is defined by a query against other tables. In other words, it’s a query saved, named, and displayed as a table. For example, you could write “Select * from customer data where Country Code = US” and run that each time you need to pull a list of customers from the US. Or you could create and save a view in Snowflake based on that query and access it each time you need the same info. Creating a view is especially useful for complex queries pulling various fields from multiple databases. It allows you to just run a query against the saved view rather than writing out all the queries that go into the master query. Finally, it has the advantage of limiting the data available to table-viewers. Some companies even standardize on only offering data via views.
What this means is that Snowflake admins or even the data-consuming or data-owning line of business users (depending on your company’s approach to data management) can create a second database that can be modified in their own account and create Snowflake views on that database that reference the unmodifiable data share. The view enables limits on what data is pulled by the saved query, but ALTR can then also apply governance and data security policy on those views so that only approved data is accessible in specific formats according to the existing rules. You can set up tag-based policies, column-based access controls, dynamic data masking, and daily rate limits or thresholds as well as de-tokenize data. In other words, by governing the view, you can govern Snowflake data shares the way you would the primary database.
Share to Data Consumer – Govern on Both
Results: Secure Snowflake Data Shares
Common Snowflake data share use cases include a data source that many groups across the company need to access with different permissions: employee database, sales records, customer PII. Or sometimes, companies have a development database, a testing database, and a production database in separate accounts where the data needs to be up-to-date and consistent across them but modifiable only in one. This also makes it possible for companies that have standardized on views for all data delivery to govern those views across their Snowflake usage.
With ALTR, Snowflake admins or various account owners can leverage sensitive data shares in Snowflake and secure them from their single ALTR account. They can set up row- and column-level controls and then apply the applicable policies to the appropriate views to ensure end data share users only see the data they should, automatically.