Tableau is one of the most widely used BI tools which provides a wealth of analytics and functionality and connects to many different data sources. One such data source that has been gaining popularity in the last few years is Snowflake, the fastest-growing cloud data warehouse.
Teams that connect to Snowflake using Tableau can extract information, analyze data, and build dashboards and reports on top of the data. The data used can either be entirely consumed from Snowflake or coupled with data from other sources (combined into one dataset or as separate components of the same worksheet or dashboard).
Adding Satori to the Tableau-Snowflake data analytics stack accelerates data usage in an organization by resolving certain security, privacy, and governance issues. This addition not only allows data consumers to access data faster with features like self-service data access or simple security policies but also reduces risks for the organization by integrating security into the data access process.
In this guide, we will explore the benefits of a Tableau-Snowflake-Satori stack and discuss the following topics:
2. The user then fills in the business justification for accessing the data. If the data owner configured the dataset to be self-service for the user (based on user, role, or group), they will immediately gain access. Otherwise, the data owner will approve or deny the request.
In addition to these benefits, in a case where you want Satori to be aware of users' identities, regardless of whether you are using OAuth integration between Tableau and Snowflake, you can change the Initial SQL as described in our documentation. This capability is useful for situations where Tableau is relying on generic credentials when querying Snowflake.
The following diagram demonstrates how Satori is located as a proxy for your Tableau-Snowflake database access:
- Simplified Tableau Data Access
- Self-Serve Data Access
- Managing Data Access Requests
- Locking Users to Tableau
- Automated Sensitive Data Discovery
- Roles, identities, and privileges management
- Applying Row-Level Security on Tableau Data
- Universal Security Policies
- Seamless Integration
- Learn More
Simplified Tableau Data Access
In many organizations, diverse teams such as marketing, sales, and customer success use Tableau for data visualization. However, an obstacle that often inhibits productive data use within an organization is allowing each team the exact privileges they require. This challenge creates situations where either sensitive data is not maintained in a strict enough manner or data access is slowed. This issue is in part due to a bottleneck in data engineering teams that configure the privileges directly in Snowflake. By using Satori, data access can be set by data owners or data stewards instead of (or in addition to) data engineers. This can be done in a simple way, either through the Satori UI or integrated using our REST API or Terraform provider. Allowing data owners to manage access to their own data makes a lot of sense and significantly reduces the time it takes to allow access to data.Self-Serve Data Access
In addition to configuring data access, Satori allows you to enable automated data access granting. For example, a data owner may decide to enable consumer access to a certain dataset if the data consumer fills out a business justification when they first access the data. In addition, this access can be automatically revoked after a certain period of time, or even after a certain period of idle time.Managing Data Access Requests
In addition to the possibility of allowing self-service data access, data owners can allow certain groups of users to request access to the data by specifying the reason they want to access it. When data consumers make these requests, the data owners can approve or reject them. This access can again be granted only for a specific time period or revoked when it is no longer in use.Here’s what it looks like:
1. In the image below, you can see the error message, directing the user to request access using the company’s data access portal.
2. The user then fills in the business justification for accessing the data. If the data owner configured the dataset to be self-service for the user (based on user, role, or group), they will immediately gain access. Otherwise, the data owner will approve or deny the request.
Locking Users to Tableau
In several companies, access to the Snowflake data presented on Tableau is given to a large number of users. However, to mitigate risks (or for operational reasons), we want to limit these users’ access so that they can only access Snowflake using Tableau. This configuration can be achieved in a simple way by applying a security policy in Satori. This policy can be applied on all data or specific parts of the data and on defined users or groups of users. You can read more about locking down Snowflake users to specific client applications in our guide. Below, you can see the custom policy enabling certain users to only access data by using Tableau:rules: # Limiting access by client application - name: Analysts can only use Tableau action: block priority: 1 data_tags: - not client.tool.id::12 identity_tags: - "'identity.idp.group::BI ANALYSTS'"(note that I referred to Tableau by its id, but you can also refer to it by its name or type, as per our documentation).
Automated Sensitive Data Discovery
Satori continuously scans the data to discover sensitive data as it is being accessed and displayed in Tableau. It then uses the data’s classification to create a continuously updated data inventory, as well as to display the types of data classified in Satori’s data audit. You can also use the classified data to create dynamic data classification policies which mask sensitive data regardless of its location. For example, whenever PII is detected, it is redacted for all analysts so that, even if a user accidentally shares sensitive data to Snowflake and that data is accessible using Tableau, the data becomes masked. In the image below, you can see sensitive data locations which are automatically classified by Satori when accessed using Tableau:
Roles, Identities, and Privileges Management
Tableau Users in Query Audit
Even if you are not using OAuth integration for your Tableau-Snowflake integration, Satori can retrieve your data users’ identities from Tableau. You can then employ this identity information for auditing the data access and applying security policies according to the identities. This ability can help both in cases where a change to OAuth is a project that will take a while and in cases where you do not integrate Snowflake using OAuth for other reasons.Creating Identity Groups for Tableau Data Access
In many cases, you want to create groups of users for the purpose of data access, without this grouping affecting your IdP (Identity Provider) groups. This can be useful in working on cross-team projects; for example, specific data scientists can be allowed to access certain marketing data for a defined period of time. By using Satori, you can create custom directory groups for the sole purpose of data access. These groups can be comprised of any combination of the following:- IdP groups (such as Okta, OneLogin, or Azure AD)
- Snowflake users
- Snowflake roles
- Other Satori directory groups
Applying Row-Level Security on Tableau Data
You can configure row-level security using Tableau by applying dynamic filtering (you can find a simple guide here). You can also use Snowflake’s row access policies or other methods of row-level security in Snowflake. Satori does not interfere with any of these, and you can continue using them while gaining Satori’s other benefits. However, you can also set row-level security policies using Satori. Doing so allows you to set and maintain these policies with great simplicity (this can be done directly by data owners with no need for data engineering resources). In addition, you can implement row-level security policies for datasets that use different technologies (e.g. for your Snowflake data as well as data queried using Athena, MSSQL, or Redshift). Setting row-level security in Satori is straightforward and can be handled using Satori UI or API integration. Satori also gives you the ability to apply row-level security on semi-structured data.
Universal Security Policies
Once you set security policies in Satori, they can be applied to data in the same way, regardless of whether the data is retrieved using Tableau or with other clients. The universal security policies can also be applied regardless of whether the data is stored in Snowflake, other platforms, or a combination of both. These universal policies allow you to then focus on the business goal; for example, you may want to apply security policies that block access to certain types of sensitive data from all users except a selected group, or you may want to mask all sensitive data unless a user is specifically allowed to access it.Seamless Integration
As with other platforms, Satori integrates without any intrusion to data consumers or data stores. You do not need to install any specific drivers or change anything in your queries, and Satori does not pollute your Snowflake with additional roles, views, or other objects. Satori is integrated as a reverse proxy, and all you need to do for a basic integration is change the “Server” value of your Snowflake DB connector in Tableau, as per the below image (of course, you would enter your own Satori hostname instead of the one in the example below):
In addition to these benefits, in a case where you want Satori to be aware of users' identities, regardless of whether you are using OAuth integration between Tableau and Snowflake, you can change the Initial SQL as described in our documentation. This capability is useful for situations where Tableau is relying on generic credentials when querying Snowflake.
The following diagram demonstrates how Satori is located as a proxy for your Tableau-Snowflake database access:
