Many organizations are using Tableau to empower their BI activities for reporting and analytics. These organizations utilize Tableau to access all of their different data sources, such as their data warehouses. Considering also the popularity of Amazon Redshift as a cloud data warehouse, it is no wonder that many companies have a Tableau-Redshift data analytics stack.
Due to data democratization processes, many users and teams are using Tableau to connect to Redshift for data retrieval and analytics. In addition, users are creating dashboards and reports that are often shared with other teams. Data coming from the Redshift data warehouse is also commonly merged with external data. Merging data can be beneficial either by enriching the data or displaying data from different sources in one single pane.
By adding Satori to this stack, you can further simplify data access and enable secure data access across various users and teams. In addition, as Satori is a universal platform, you can use it even when Tableau is accessing data from multiple platforms, not only from Redshift. Satori’s unique universality is very useful in managing the common scenario where organizations use data from various platforms.
In this guide, we will explore the benefits of a Tableau-Redshift-Satori data analytics stack and discuss the following topics:
- Simplified Redshift data access using Tableau
- Locking Analysts to Tableau
- Automated sensitive data discovery on Redshift data
- Roles, identities, and privileges management
- Applying row-level security data presented in Tableau
- Universal security policies
- Seamless integration
- Conclusion
Simplified Redshift Data Access Using Tableau
Companies often use Tableau to enable many different teams to consume data. Teams such as marketing, sales, and operations rely on Tableau to create valuable data visualizations for information in data stores like Amazon Redshift. This process is a classic example of harnessing data to create business value.
However, an aspect that can slow down this process is the need to authorize many different users to access the data, especially when it may contain sensitive information, such as PII, healthcare data, or private business data. This challenge often leads to one of the following issues:
- It may create a “time penalty” whenever users require data. This delay occurs because the data access process requires tickets to be opened, IT and data engineering teams to change settings, and data stewards to approve access requests. This inefficiency increases time-to-value, harming business results.
- Data teams can give up on these tedious processes and provide data consumers with too broad access. This leniency may pose compliance issues as well as increase the risk of data exposure.
In a “traditional” Tableau-Redshift environment, access is usually restricted at the data infrastructure level (e.g. Redshift), but, in some cases, some of the access restrictions (such as fine-grained access control defining row-level security) are defined in Tableau. Defining data access in Redshift may not be optimal for several reasons: lack of effective granular control, hard-to-maintain security policies defined via views, and the common use of a generic Redshift user for all Tableau access.
By using Satori, data owners or data stewards can set data access instead of (or in addition to) placing the responsibility on data engineers and IT teams. This data access management can be performed in a simple manner, 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 intuitively and significantly reduces the time it takes to allow data access without compromising on compliance. Satori also makes decoupling security from the data infrastructure or data analytics platforms more simple, universal, and effective (e.g. you may set policies for specific Tableau users rather than the generic Redshift user).
Tableau Self-Serve Data Access on Redshift
In addition to the traditional process of configuring data access to users and groups of users, Satori also enables defining datasets with self-service data access. The benefit of this capability is that a user cannot accidentally access such datasets, but rather they need to provide a business justification for access attempts. Additionally, all such access attempts are audited.
This shift reduces a lot of white noise from managing data access which, according to security policies you define, may be granted to certain groups of users. In combination with capabilities like dynamic masking, the self-served data can be automatically anonymized to ensure that it does not contain any sensitive data. When enabling self-service data access, you can also configure this access to be temporary, so that users will have to request access again after a certain period of time. This regulation prevents over-privileged users from gaining more data access over time without proper justification.
Removing Bottlenecks in Data Authorization
In addition to the capacity to allow self-service data access on Redshift data utilized by Tableau users, data owners can also allow certain user groups to request data access by specifying their reason for access. When data consumers make these requests, data owners can easily approve or reject them. This access can again be granted for a specific, limited period of time or revoked when it is no longer in use.
The simplified data access process using Satori:
- The image below shows the error message which directs the user to request access using the company’s data access portal.
- The user then fills out their business justification for accessing the data. If the data owner configured the dataset to be self-service for the user (based on user or group definitions), they will immediately gain access after entering this information. Otherwise, the data owner will approve or deny the request manually.
Locking Analysts to Tableau
Many organizations expect that data analysts (or other data consumers) only access Redshift data using Tableau as an interface. This requirement may be in place because some fine-grained access control policies are implemented in Tableau, or it may be simply to reduce the risk of data exposure or operational issues due to automation.
Configuring such a security policy in Satori is straightforward. The policy can be applied to all data and users or to certain datasets and users. Below, you can see the custom policy enabling certain users to only access data by using Tableau:
|
rules: |
(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 on Redshift Data
Unlike simple orchestration solutions, when you use Satori as a data access platform between Tableau and Redshift, it automatically analyzes the data, as it is being accessed. By performing this analysis, Satori creates a continuously updating data inventory across all of your connected data stores. This classified data is also displayed in the data access audit and is used in security policies. For example, you can create a security policy that masks certain types of data, preventing their exposure.
In addition, you can use Satori’s capability of applying custom data classification, defining your own data classification tags, and “teaching” Satori how to classify such types of data.
The image below depicts sensitive data locations in a Redshift cluster which are automatically classified by Satori when accessed using Tableau:
Roles, Identities, and Privileges Management
Tableau Users in Query Audit
In a typical Tableau-Redshift stack, you configure Tableau to utilize a certain Redshift user to access the data. This configuration not only limits your ability to define access control policies in AWS Redshift, but it also makes your audit log much less useful and compliant (as it does not contain information about the actual users accessing the data).
Satori can inherit the user identities from Tableau and thus add this important context to the audits, as well as consider user identities in regulating access control.
Creating Identity Groups for Tableau Data Access
Whether it is grouping users according to their role for implementing RBAC or performing specific projects, grouping different users helps maintain more simple access control and save time. In many cases, you do not want to change your IdP groups for specific data access requirements.
In Satori, you can define custom directory groups for the sole purpose of data access and use them when users connect through Tableau to Redshift.
These groups can be any combination of the following:
- IdP groups (e.g. Okta, OneLogin, or Azure AD)
- Redshift users
- Tableau users
- Other Satori directory groups
Managing these directory groups outside of the Identity Provider allows you to save time, as you no longer need to implement group changes using IT. Rather, you can do it using your data access platform. By managing these groups in Satori rather than in Redshift, you gain added flexibility (e.g. when such groups are applicable to other platforms as well). In addition, anyone, even people who are not data engineers, can set these groups, thereby reducing the data engineering bottleneck.
In the image below, you can see a simple definition of such a directory group, which includes anyone accessing the data using the Snowflake analyst role, using the EU Users Okta group, or anyone on the Satori directory group called PII.
Applying Row-Level Security Data Presented in Tableau
You can use Tableau’s native Dynamic Filtering feature to enable row-level security (you can find a simple guide here). You can also define row-level security in Redshift (though it may be hindered by the lack of user identity context). Satori will not interfere with existing row-level access configurations.
However, beyond these capabilities, using Satori to configure row-level access control has many benefits:
- The policies can be easily configured using UI, API, or Terraform and are simple enough to be defined or updated by data stewards or security teams, rather than only data engineers.
- You can apply the same row-level policies across different data platforms (e.g. Redshift and Postgres), or data clients (e.g. Tableau as well as Python).
- Satori enables row-level access control for semi-structured data as well as structured data.
Setting row-level security in Satori is straightforward and can be handled using the Satori UI or API integration, as shown below:
Universal Security Policies
Security policies in Satori can be applied not only on data retrieved by Tableau but also on all other BI tools, connectors, and applications. In the same way, security policies can be applied not only on the data you are accessing in AWS Redshift but also on data that is stored elsewhere.
This capability enables you to gain a simpler, more business-oriented policy. It also makes it easier to migrate from one BI tool to another, or from one data source to another, without breaking compliance or increasing risk.
Seamless Integration
To put it simply—Satori does not make changes to your Tableau or Redshift configurations. It also does not require credentials to any of these platforms. This means that Satori has minimal intrusion and will not, for example, pollute your Redshift cluster with views or require credentials to either platform.
Conclusion
Using Satori simplifies your DataSecOps when enabling users to access Redshift data using Tableau as a BI tool. It allows for faster and more secure data democratization and lets organizations share data in an easier way. In addition, it allows you to set effective access controls, including fine-grained access policies on your data. If you would like to learn more visit this page, or schedule a demo using the form below.
