.png)
When Tableau was founded in 2003, business intelligence (BI) was still in its infancy. It was a critical but specialized skillset utilized by a handful of power users in a company who ran reports and pulled visualizations for the rest of the company. When the quantity of users was small it was doable to install the Tableau desktop client on that limited number of systems, and the relatively small number of users made tracking every user’s access to data feasible.
Since then, the amount of data business creates, stores and utilizes has exploded, along with the value extracted in analysis of that data. Whether it was the insights gained by using a BI tool or just the dazzle of gorgeous charts and dashboards, business professionals have clamored for access to Tableau, drastically increasing the number of users.
In order to scale with this growth, Tableau transitioned to a more modern architecture. Multiple instances of Tableau Desktop are no longer installed on individual desktops but instead one instance of Tableau Online lives on a server – either in the company’s datacenter or on the cloud – that users access via web browser. With no need to install or manage software on each desktop, many thousands of employees from a single company can be set up as users and easily access the tool.
However, just like with any move from a client/server application to a web-based application, there was a tradeoff. With the increase in scalability there came a loss in granularity over who is accessing the data. This leads to the critical question: how to govern individual user access to Snowflake data via Tableau?
The Tableau-Snowflake conundrum
Users still have individual username and password to access Tableau, but the data itself lives in a separate cloud-based database like Snowflake. Tableau admins have at least two options for configuring the tool’s access to Snowflake:
- Create individual Snowflake accounts for each Tableau user: This is the approach recommended by many experts in the data governance realm: Fred Bliss from Aptitive talked about why this is better on The Data Planet. Individual accounts enable visibility and control over specific user access and data usage, but also come with downsides. Set up requires a significant amount of work from DBAs: they have to create and administer two accounts for every user – a Tableau account and a Snowflake account. This becomes quickly unmanageable when you’re talking about 10,000 users. And, having thousands of access points into Snowflake creates an exponential data security risk; every additional account is another that could be compromised.
- Utilize a single Snowflake service account for Tableau: this is the approach many companies take to get started faster. In this scenario, when individuals log into Tableau and request data, there is a single Tableau service account that accesses Snowflake and withdraws the data. This provides simplicity of management, but completely removes the ability to place user-based governance or security on the data. If you can’t see which user is accessing which data, you can’t apply masking on specific columns. You can’t stop credentialed access threats because there’s no way to limit consumption for specific users. It’s just one huge firehose of 10,000 users all appearing to Snowflake as if they’re one person. All of the users share the same permissions which gives any user the power to download all of the data because there’s simply no way to differentiate. This means there’s no audit trail or record of individual data consumption which can lead to serious compliance issues. And, if there is a breach, access would need to be cut off completely. It’s binary – data is either flowing to everybody or data is flowing to nobody. All of this combines to create a huge hole around data security in Tableau.
Ideally, governance and security policies could be configured and managed on the user accounts in Tableau, but that feature isn’t available today. Tableau sees this as a database function. Which brings us full circle back to creating thousands of user accounts in Snowflake in order to govern individual access.
Tableau and Snowflake user-level data access visibility and control with ALTR
We’ve run into several companies facing this same issue and have developed a unique solution: ALTR can employ contextual info provided by Tableau to distinguish users and apply governance policies on the data in Snowflake. With a simple, one-time configuration of a SQL variable in Tableau server, the service account that Tableau uses to connect to Snowflake can send through information on which one of the thousands of Tableau users is making the request and share that information with ALTR. ALTR can then apply governance and security policy on that Tableau user as it would on any other individual Snowflake account.
And that’s it – there are no additional steps required in Tableau, Snowflake or ALTR. If you're an ALTR customer with Snowflake and you use Tableau server or Tableau online, you can get to this specific level of individual user visibility and governance in less than an hour just by making that one small change.
The best of both worlds for Tableau and Snowflake users
Without a way to ensure that sensitive and regulated PII data can be monitored and controlled when accessed by BI tools via bulk service accounts, many companies are forced to exclude that data from their analytics tools, leading to a less than 360 view of the business.
ALTR’s solution delivers the best of both worlds: Snowflake DBAs only have to configure and manage the one Tableau Snowflake service account, yet they get per user visibility and governance as if every end user had their own account. This means they can implement access controls, apply masking policies, and stop credentialed access threats on thousands of end users — allowing continued access to data without putting the data at risk. That means companies can include the sensitive data they need in order to get a full view of the business and extract the most value from their data and Snowflake.
And ALTR is the only data governance and security provider for Snowflake delivering this capability. It’s another example of our drive to build SaaS-based functionality that is quick and easy for our customers to deploy while delivering powerful data control and protection.