My previous post TABLEAU SERVER AND CLOUD SECURITY (9/10): PII and DETECT AND DELETE PII DATA ON TABLEAU SERVER talk about PII detection and deletion scripts. Why and how.

There is another type of concerns related to compartmented secret information on Tableau server got out of hands, like future products, or trade secrets etc. How to protect those type of data?

Here is what I did for my Tableau server to protect trade secret:

Scripts to compare Tableau permissions with trade secrets reference database, send auto email alerts to content owner if discrepancy found.

For example: If trade secrets reference database says that only 3 people are disclosed for the dataset, while Tableau workbook gave permissions to 2 more additional users. Alert email will be sent out.

Let me explain a few key components involved:

1. Trade secrets reference database

This is the single source of the truth about who is allowed to access what secret data. This is outside Tableau. Our Tableau scripts just access this dataset.

2. Linkage between Tableau workbook (or datasource) to the above Trade secrets reference database

Unfortunately there is no such linkage as there is no way to scan the data to tell. Which is why we have to ask content owner to tag the workbook/datasource or project with a specific Trade Secrets code (like ABC-1234). So it is more like a self declaration process.

3. How to find out who has permission to which dashboard?

Using API and SQL to call Tableau’s linage tables, permission tables to figure who has effective permissions for those tagged Trade Secret content.

4. Compare permission difference and send out alert

This concludes this series of TABLEAU SERVER AND CLOUD SECURITY:

1. TABLEAU SERVER AND CLOUD SECURITY (1/10): Overview
2. TABLEAU SERVER AND CLOUD SECURITY (2/10): External Site
3. TABLEAU SERVER AND CLOUD SECURITY (3/10): External Server
4. TABLEAU SERVER AND CLOUD SECURITY (4/10): Extension
5. TABLEAU SERVER AND CLOUD SECURITY (5/10): Explain Data & Data Story
6. TABLEAU SERVER AND CLOUD SECURITY (6/10): Content Owner Left Company
7. TABLEAU SERVER AND CLOUD SECURITY (7/10): All Users Group
8. TABLEAU SERVER AND CLOUD SECURITY (8/10): Large Group
9. TABLEAU SERVER AND CLOUD SECURITY (9/10): PII
10. TABLEAU SERVER AND CLOUD SECURITY (10/10): Trade Secrets

Tableau Cloud or server has one built-in user group : All Users. It is group available in any site.

All Users can be very connivence for content that can be shared to every Cloud or server user.

However in large organization, it likely ends up a lot excess permissions. I used to receive emails asking why he or she has access to a dashboard that the user has nothing to do with it. The user can’t tell if dashboard is shared to All Users as only content owner or project leaders can tell. This is where I realized that All Users group caused more problem than benefits for large org.

Something that I found when a publisher was not sure which group to use, he or she just used All Users group causing excess permission.

I last a few years, I tried many different ways to get rid of this All Users group. Unfortunately I have to give it up as I found that Tableau uses this built-in All Users for its own permission process.

Another thing that I do not like this group is that it always shows on the top of group list during permission process. Then I tried to rename All Users group to something like ZZ All Users (do not use) with intent to let this group show to the bottom of the group but failed as well.

Then I had to come with what I call : ‘After the fact’ governance approach:

The Python scripts will delete any permission uses All Users group, and then send email alert to the content owner. The scripts is scheduled to run hourly to minimize potential excess permission issue. Below is how the alert looks like

What content we check? The scripts checks all type of content: workbook, data source, flow, project, virtual connection, Metrics, Data Role, Lense, etc

Here is how it works:

How to have exception for the above process?

You can add exception to some projects or content owner if you do have use cases where content needs to be shared to everyone on the server site.

Conclusion : This All Users group permissions detection and deletion is a good safe net to govern Tableau server security. This scripts helped me out in many security review process

What should be done when Tableau server or Cloud users left company?

The right process is to un-license AND then delete the users from Tableau server or Tableau when users left company.

• Admins can un-license content owners but Admins can’t delete users who own content even the users left company.
• You will have to change content owner first before deleting the user

Who can change content owner?

1. Owner. The best practice is for owner to change the content owner to someone else in the team.
2. Project Admin (aka project leader) who has publisher site role. For whatever reasons, if content owner left company, project admin can also change the owner to someone else (two step process: change to yourself and then change to someone else)
3. Project Owner (two step process: change to yourself and then change to someone else)
4. Admins

Content owner change tips

• Explorer site role user can be given content ownership but can’t grant permissions to others, can’t change the ownership to anyone else anymore.
• Once content owner is changed, the embedded password will be invalid. The new content owner has to re-embedded the password
• Project admin (aka Project Leader) or Project owner can’t other’s content to someone else although can change someone else’s content to herself or himself. It will be two step process for project admin to change owner content to someone else:
  1. Change owner to project leader himself or herself
  2. Then as content owner, you can change content ownership to someone else

What happed when content owner left company?

• If content ownership is not changed before owner left company, workbook can still be accessed, extract can still run (if embedded credentials not tie to personnel database acct)
• But, Tableau server or Cloud’s email or Slack notifications (failure/suspension, flow failure/suspension) goes to nowhere….
• No action can be taken by owner anymore 

So content owner should be changed. However ….

The Problem : Often Project Admins may not be aware of all content owned by person who left company 

The scalable solution is to build Invalid Content Owner alert

What is Invalid Content Owner alert?
It is a Python scripts to use REST API to find content owned by user who is not an active employee anymore. The content list alert will be sent to project admin (aka project leader) and project owner. It can also be sent to previous manager if possible (see below alert):

The alert can also have a link to the content to make project admin’s life easier. Action is for project admin (aka project leader) to click the link in the alert and change content to himself, then change to someone else if necessary.

Here is the logic used for the alert

Conclusion: We found that it was extremely useful to send invalid owner alert in the daily basis for large Tableau deployment since project leaders don’t have visibility for this data. You do need Tableau server database workgroup readonly user/password, REST API, Python and whatever scheduling tool to implement it.