Limiting Snowflake Access to Specific Clients

By Ben Herzberg
Chief Scientist
June 24, 2021

Before we drill down to the “why” and “how” of limiting client tool access in Snowflake using Satori, here’s a short demo video of how this works in reality:

Snowflake Client Tools Access Limitation With Satori Demo

Here’s what we’ll discuss in this blogpost -

Background

It may seem like as long as a user is authenticated and authorized to a specific data within a given data source, the user should have access to the data. However, from a broader and more complete perspective, you may wish to place additional limitations on data access.

One of these limitations, which we will discuss today, is based on the tool, or client, which the user is utilizing to access the data. In many cases, the tool by which a user accesses data is critical. After granting a consumer access, it makes a large difference whether a consumer uses a script or a BI tool to access the data.

In some cases, this distinction may be important for operational reasons, such as the concern that users who pull data programmatically may create logic that unnecessarily processes a large amount of data. In other cases, we may desire this limitation due to security or governance reasons. For example, a limitation can be used to enforce security policies that prevent human analysts from using application credentials.

Though these requirements may sound complex, all of the aforementioned limitations can be achieved by applying filtering on client tools using Satori.

Using Satori to Prevent Data Access Based on Tools

The limitations I mentioned are all built into Satori’s security policy engine and are easy to achieve.

As a recap, let’s examine how Satori controls access to your data. In the following diagram, we can see that the user is implementing a client tool to connect to Snowflake using Satori. The user can be a human or an application, and the client tool can be any client such as a BI tool (e.g. Looker, Tableau, Power BI, etc), DB client, or an application (e.g. Python, Go, NodeJS, etc). By defining a security policy on Satori, access can be granted or blocked based on the specific client tool used.

Now, let’s see some of the use-cases for this capability, as exemplified by some of our customers, and examine how to configure these definitions in Satori.

Use-Case 1: Using Snowflake Web UI as a Data Portal

In this case, a company wants to allow certain consumers to access their data. However, to limit risks, such as users iterating through the data using a script or downloading the data, companies want to allow access to their data only through a web UI. The goal is to limit such users, so they will not be able to access the Snowflake account using scripts or automated tools, but only through the web UI.

This function is performed by employing Satori to block queries sent using any tool other than Snowflake Web UI.

Use-Case 2: Locking Down Users to BI Tools

Another use-case that I have observed, which is quite similar to the previous one, is when companies have analysts or other data consumers who are meant to use Snowflake only through a certain BI tool, and the company does not wish the employees to connect through other client tools for various reasons. The solution, in this case, is using Satori to lock down all SQL queries and commands sent using any other tool, except for the BI tool.

Use-Case 3: Locking Down Applications to a Script

Another use-case I have encountered occurs when some of the data or some of the users in an organization should only be accessed by a certain application. For example, data that is written to a certain database should only be written by a Python or NodeJS connector. This is done by configuring Satori to accept the allowed client tools while disallowing the others.

Partial Lockdown (Limited Only to Specific Data)

In several cases, limitations on use to a specific client tool are only set for certain datasets. Such datasets can be configured in Satori and may contain one or more tables, schemas, or databases from the same Snowflake account.

Let’s Configure These Limitations in Satori

In Satori, you can configure the limitations I described by using custom policies, which you can apply to specific datasets. The datasets you define can be as specific or as generic as necessary. Below is an example of the configuration in Satori which allows the user benherzberg to only access the dataset from Snowflake’s native tools.


rules: # Limiting access to medical results through Web UI only - name: LimitAccesstoWebUIonly action: block priority: 1 data_tags: -notclient.tool.type::native identity_tags: -'identity.principal.name::benherzberg'

Once you save this custom policy, it is automatically enforced in Satori:

However, if we send the query through any other tool, we will not be authorized to retrieve the data:

Alternative Filtering Using Snowflake Secure Views

For very specific purposes, you can also achieve this goal by creating a secure view filter in Snowflake. This capability is achieved by using the CURRENT_CLIENT() context function.

The CURRENT_CLIENT() function returns the client that Snowflake detects. In the following example, we will limit access to the v_research_data view only to Snowflake UI:


CREATE SECURE VIEW v_research_data AS SELECT * FROM research_data WHERE CURRENT_CLIENT() LIKE'Snowflake UI%';

Conclusion

Limiting access by client tools is only a small fraction of the power Satori brings to data engineers and owners when protecting data access and ensuring data democratization.