Dit is een update op de eerder gepubliceerde blog van Chris Love over Tableau Server permissies. Sommige concepten van de Tableau Server permissies zijn gewijzigd in versie 9 en 9.2, dus laten we Chris zijn post eens opnieuw doornemen om te begrijpen hoe permissies nu precies werken…
Tableau heeft een robuust beveiligingsmodel welke soms wat complex kan overkomen. Laten we eens in detail naar permissies kijken en sommige van de vaak voorkomende uitdagingen die mensen tegenkomen.
Wat mensen als eerste in verwarring kan brengen wanneer er voor het eerst gekeken wordt naar Tableau beheer is het aantal gebieden waar permissies kunnen worden ingesteld, er zijn er 6 in totaal: Site, Project, Group, User, Workbook en Data Source. Om te begrijpen hoe Tableau permissies werken is het belangrijk om deze levels te begrijpen en hoe de interactie tussen deze levels plaatsvindt.
Sites
Sites zijn de top van de content hiërarchie en bieden een mogelijkheid om je server te partitioneren in afzonderlijke omgevingen voor gebruikers (ook bekend als multi-tenancy). Elke site wordt apart beheerd en heeft zijn eigen Groups, Users, Projects, Workbooks en Data Sources. Direct na installatie zal er één Site zijn aangemaakt – de “Default” site. Deze site kan van naam gewijzigd worden maar niet verwijderd omdat de Server altijd tenminste één Site moet bevatten.
Gebruikers met toegang tot alleen een of enkele sites op een server zullen niet in staat zijn om toegang te verkrijgen, resources te bemachtigen of überhaupt enige informatie te raadplegen van de andere sites waar ze geen rechten op hebben. Wat je kunt zien en hoe je gebruikers en content kunt beheren over verschillende sites hangt af van ingestelde permissies en of je meer dan één site geactiveerd hebt op je server.
Een (vertaald) stukje uit de Tableau Server User guide:
“In een multi-site omgeving, klik Server menu voor de globale server settings voor configuratie, monitoren en beheren van de Tableau Server. Alleen als server administrator kun je toegang krijgen tot Server pages voor de status, sites, Server Users, schedules, tasks en elke andere instelling die voor de gehele server geldt. Voor single-site omgevingen, zullen alle server en site-gerelateerde menu’s beschikbaar zijn met uitzondering van het Server menu.”
Op een multi-site server zijn dit de Site menu’s die een server administrator zal zien.
Op een multi-site server zijn dit de Server menu’s die een server administrator zal zien.
Op een single-site server zijn dit de menu’s die de administrator zal zien. Om een site aan te maken, klik op het Settings menu.
Als de gebruiker toegang heeft tot meer dan één site, dan zullen ze een keuze dialoog krijgen om aan te geven op welke site hij wil inloggen.
Projects
Projects zijn het eerste onderliggende level in de content hiërarchie. Projects bestaan binnen Sites en ze worden ook gebruikt om content onder te verdelen op de server. Ze kunnen worden vergeleken met folders, zoals in een operating system bestandsstructuur, bijv. Windows folders. Omdat projects Groups en Users delen met andere Projects in de site, is dit typisch een manier om je content in logische groepen in te delen, bijvoorbeeld op basis van afdeling, functie, auteur or zelf SDLC (system development life cycle, ook wel OTAP) omgeving. Je kunt bijvoorbeeld Tableau users hebben in Finance, Marketing, Sales en IT en verschillende content willen aanbieden aan elk team waarbij beheerd kan worden wie precies welke content kan zien en gebruiken. Projects zijn een ideale manier om dit in te regelen. Direct na installatie zal er een Project zijn aangemaakt in de Default site genaamd “Default”, deze kan niet worden hernoemd of verwijderd omdat een Site altijd tenminste één Project moet hebben.
Toegang tot een Project wordt toegekend door de permissies die op dat Project zijn ingesteld, elke Group en/of User kan een set van permissies (zie hier) zijn toegekend in het Project, welke bepalen wat ze (standaard) wel/niet kunnen doen met workbooks die gepubliceerd zijn in dat Project.
Een nieuw aangemaakt Project zal de permissies overnemen van de permissies die ingesteld zijn op het Default Porject in die Site. NB: de default permissies voor het Default Project staan ingesteld om alle Users toegang te geven – het is aan te bevelen om altijd de permissies te verwijderen van het Default Project direct na installatie, zodat elk nieuw Project start zonder permissies totdat je ze expliciet instelt.
Groups
Groups zijn collecties van Users in een Site. Ze helpen je om gebruikers te organiseren en beheren. Groups kunnen handmatig worden aangemaakt of worden geïmporteerd (en gesynchroniseerd) vanuit een Active Directory als die beschikbaar is. Elke Site heeft tenminste één Group genaamd “All Users” – welke, zoals de naam suggereert, een set is van alle Users binnen een Site.
Users
Users zijn de individuele named users die toegang tot de een Site krijgen. Iedere User die wordt toegewezen een Tableau Server moet een gerelateerde site role hebben, deze rollen worden in onderstaande afbeelding afgebeeld. De site role wordt toegewezen door een administrator/beheerder. De site role bepaalt de niveau’s met permissies voor een user, zoals of een user content kan publiceren, interacteren met content, of alleen content weergeven. Administrators zijn ook gebaseerd op de site rol.
Een van de meest voorkomende vragen die we krijgen gaat over de User en Group permissies die de verschillende toegangsniveau’s regelen, welke krijgt voorrang? Nou, om te beginnen zal User Group rechten overrulen, en Deny (niet toegestaan) krijgt overruled Allow (toestaan). Onderstaand een diagram voor een helder overzicht:
Let op het eindpunt van “Denied” – zolang een permissie niet expliciet is toegekend (Allow), dan is deze per definitie niet toegekend (Deny).
Workbooks
Nieuwe workbooks en datasources maken gebruik van de standaard ingestelde permissies van het Project waar ze onderdeel van zijn. Wanneer content permissies niet geblokkeerd zijn, dan kunnen de individuele workbook en datasource permissies bewerkt worden om af te wijken van de standaard instellingen. Dit is het eerste, en meest belangrijke zaak om te onthouden van Tableau permissies: Tenzij permissies zijn geblokkeerd heeft de publisher van een dashboard de finale controle over wie zijn data kan zien wanneer het is gepubliceerd.
Je kunt eerder hierboven al lezen over het concept van permissies blokkeren. Dit is een nieuwe feature in v9.2 en als administrator of projectleader kun je Users ervan weerhouden om de permissies van workbooks en datasources te wijzigen. Om dit in te stellen, kun je de content permissies blokkeren van het project.
Een uittreksel van de Tableau Server user guide:
“When permissions are locked to the project, the default permission settings are applied to all workbooks, views, and data sources in a project and cannot be modified by users (including content owners). When permissions are managed by the owner (“unlocked”), content permissions remain the same as when the project was locked, but the permissions become editable.”
“Wanneer permissies voor het project geblokkeerd zijn, zullen de standaard permissies die zijn ingesteld van toepassing zijn op alle workbooks, views en datasources in het project en kunnen deze niet worden gewijzigd door users (inclusief content eigenaren). Wanneer permissies worden beheerd door de eigenaar (“unlocked” of niet geblokkeerd), zullen de content permissies gelijk blijven aan de standaard instellingen, maar zijn deze wel aan te passen.”
Publishers zullen het verschil zien tussen een geblokkeerd en niet-geblokkeerd project tijdens het publiceren van content naar de Tableau Server vanuit de Tableau Desktop. Hier is een publish dialoogbox in Tableau Desktop voor een niet-geblokkeerd project. Hier kan de user de workbook permissies aanpassen naar zijn of haar voorkeur:
Hier zie je hoe een geblokkeerd project eruit ziet in de publish dialoogbox in Tableau Desktop. Hier heeft de user dus geen controle over de workbook permissies. In plaats daarvan zal het workbook de permissies van het project overnemen:
Permissies kunnen ook worden ingesteld op individueel view level, bijvoorbeeld op views in een workbook. Dit leidt echter wel tot een erg complex beveiligingsmodel en is dan ook sterk af te raden.
Data Sources
Vergelijkbaar met Workbooks, kunnen ook Data Source permissies worden bepaald door ofwel de Publisher, indien er wordt gepubliceerd naar een niet-geblokkeerd project, ofwel door de Project permissies, indien er wordt gepubliceerd naar een geblokkeerd Project.
Goed, wat betekent dit nu?
Nou, wanneer een user is toegevoegd aan een site op de server en een gelicenseerde site rol toegekend heeft gekregen, zullende effectieve user permissies, zoals toegelicht in de user guide, als volgt bepaald worden:
- De maximum functionaliteit van de Site Role van de User. De Site Role bepaalt het “plafond” van welke persmissies zijn toegestaan.
- Afhankelijk of een user eigenaar is van de Content zal de auteur volledige controle hebben over de gepubliceerde content.
- Controle van elke user of group permissie instelling die van toepassing is voor die user of group voor dat specifieke content item.
Om erachter te komen welke permissies van toepassing zijn op specifieke content, ga dan op zoek naar de drie kleine puntjes in de rechterbovenhoek van een content voorbeeld weergave, zoals hieronder afgebeeld, n selecteer de permissies optie in het menu:
Hierdoor opent een nieuw venster waarin je precies kunt zien welke users en groups wel/geen rechten toegekend hebben gekregen:
Als je deze permissies wilt wijzigen in dit venster, ga dan wederom naar de drie kleine puntjes naast de user of group naam en kies ‘edit’ vanuit het menu. Zie hier ook dat als je een group hebt geselecteerd, er een lijst verschijnt van alle users in die group in een aparte tabel eronder, die meteen voor iedere user alle individuele effectieve permissies toont voor die content.
Tips en aanbevelingen
Wat kunnen we dan adviseren als best practice proces voor het opzetten van Tableau Server security? Het eerlijke antwoord is “het hangt ervan af” maar de uiteenzetting hieronder geeft meer inzicht in hoe we zouden kunnen starten bij een klant.
1. Stel permissies in op groups, niet op users
Het toewijzen van individuele user permissies op projecten of andere content wordt snel onoverzichtelijk. Je zou bij voorkeur permissies willen toevoegen/wijzigen/verwijderen op groepen van users, niet op individuele users. Zelfs als een bepaald persoon uitgebreidere rechten moet hebben dan anderen, maak dan een aparte groep en wijs daarop de permissies toe, zodat het later eenvoudig is om extra users aan die groep toe te wijzen. Het zal je op de lange termijn een hoop gedoe besparen.
2. Maak een group voor administrators/beheerders
Het beheren van administrators is een stuk eenvoudiger als je daarvoor een group aanmaakt. Je kunt handmatig een group aanmaken op de Tableau Server, of je kunt een Active Directory group opzetten en deze importeren. Dit stelt je in staat om users met een beheerders rol (admin) toe te voegen waar nodig.
3. Wees terughoudend met toekennen van administrator rechten
System en site administrators kunnen alle data en visualisaties zien binnen de Server en Site(s), dus geef ook alleen permissies aan diegenen die geacht worden alles te kunnen zien.
4. Brainstorm je Beveilgigingsmodel
Breng een aantal desktop gebruikers en stakeholders bijeen en bespreek de dashboards die men op het oog heeft en de typische use-cases. Probeer en beantwoord een aantal van de volgende vragen en gebruik de Permissions Reference om te bespreken welke type users/rollen je hebt:
– Visualiseren we vertrouwelijke data die beheerd moeten worden middels speciale sites?
– Wie moet er kunnen publiceren? Mag je dashboards van andere users ook bewerken?
– Welke viewer (raadpleger) rollen hebben we? Zijn alle viewers voor wat betreft de benodigde permissies gelijk of zijn er nuance verschillen?
– Welke projecten zijn vereist, hoe verschillende de publishing en viewing permissies per project?
– Zijn er mensen die altijd een bepaalde rol moeten hebben, ongeacht het project?
Uit deze brainstorm zou een goed inzicht moeten ontstaan van welke permissies nodig zijn, hou het simpel omdat je de complexere zaken altijd later kunt toevoegen – het is moeilijker om de complexiteit weer eruit te krijgen als je eenmaal een bepaald pad bent ingeslagen.
5. Verwijder alle permissies van het Default project direct na installatie
Dit geeft je de zekerheid dat nieuw aangemaakte projecten altijd starten zonder enige permissies totdat je expliciet toekent welke permissies je wilt op dat project.
6. Start simpel
Als je nog niet helemaal zeker bent van de aanpak, start dan met het maken van een gr0up met users voor elke combinatie van rol en project, bijvoorbeeld Project1_Publisher, Project1_Interactor, Project2_Interactor, Project2_Publisher, AllProjects_Interactor etc., en stel de bijbehorende permissies voor de groups in de projecten in. Stel een UAT (user acceptatie test) periode in om de permissies grondig te testen alvorens direct een project live te zetten.
7. Stel aanvullende beveiliging in op database niveau voor extra gevoelige informatie
Limiteer de velden die users kunnen benaderen in een data warehouse door gebruik te maken van views, zodat het per ongeluk vrijgeven van gevoelige data, bijvoorbeeld persoonsgegevens als naam, salrus, etc. wordt beperkt. Deze hoeven doorgaans niet te worden gevisualiseerd en er is dan dus ook geen reden voor users om er bij te kunnen komen.
8. Blokkeer (Lock) permissies op projects
Blokkeer (lock) de permissies op projects waar toegang tot content streng gecontroleerd moet worden. Aanvullend, blokkeer permissies op projects die data sources bevatten. Doorgaans moeten data sources wat strenger beheerd worden, en het blokkeren helpt tegen het per ongeluk verwijderen of overschrijven van data sources door users.
9. Maak een ‘sandbox’ omgeving waar auteurs kunnen publiceren zonder resrticties
Zorg ervoor dat de users een plek hebben waar ze zonder limitaties kunnen publiceren en permissies kunnen instellen naar hun wensen. Zet en ‘speeltuin’ of ‘sandbox’ project op waar permissies niet geblokkeerd zijn en sta de users toe om hun eigen ad-hoc content en permissies te publiceren. Als beheerder/admin wil je deze omgeving echter waarschijnlijk wel een beetje in de gaten houden en wellicht wat basis spelregels commuiceren, zoals dat er geen support zal worden gegeven op content in deze omgeving. Je zou ook een beleid kunnen maken, waarbij er bijvoorbeeld op gezette tijden (bijv. elk half jaar) een grote schoonmaak plaatsvindt, om ervoor te zorgen dat de ruimte niet helemaal volloopt met niet gebruikte content en probeersels.
10. Ontmoedig maatwerk (custom) permissies op workbook level of lager
We hebben het er al over gehad, maar we raden je sterk af om maatwerk cq. afwijkende permissies in te stellen bij het publiceren. Als dit per se nodig is maak dan een aparte beveiligde Site waar users hun dashboards kunnen publiceren en de users er zeker van kunnen zijn dat hun permissies niet worden overschreven als er wijzigingen worden doorgevoerd op Project level.
11. Gebruik het Gast (Guest) account om Tableau te promoten
Als je de beschikking hebt over een core licentie, dan kun je gebruik maken van het Guest account om ongelicenseerde users te voorzien van een sneak-preview van Tableau of om je beste dashboards te showen. Mensen krijgen doorgaans vaak enthousiaste geluiden van collega’s over Tableau en willen dan vaak graag zelf ook eens zien waar dat enthousiasme nu over gaat. Het is dan handig om ook meteen een soort Help info over “hoe toegang te krijgen” beschikbaar te stellen. Hou er wel rekening mee dat het Guest account alleen permissies krijgt voor een beperkt aantal niet gevoelige views, de mensen die hier gebruik van maken loggen immers niet in.
12. Continu reviewen
Als je een beheerder bent, instrueer je users dan over het permissie model en zorg ervoor dat de Tableau desktop gebruikers een korte toelichting krijgen over hun eigen verantwoordelijkheden. Zorg er ook voor dat je als groep tijd inruimt om het permissie model te reviewen – het komt maar al te vaak voor dat users zich niet meer verbonden/verantwoordelijk voelen als ze het idee krijgen dat er geen feedback mogelijkheden zijn naar jou als beheerder.
Verder inlezen
Working with Permissions – Tableau help heeft een uitgebreide set artikelen die permissies en het Tableau security model toelichten.
Creating Project Based Permissions – Dit Tableau Knowledge Base artikel loopt door het proces van het maken van permissies voor elk project en volgt globaal de best practice zoals hierboven beschreven.
Data Security – Begrijpen welke users toegang krijgen tot welke data via een live data source is belangrijk.
Row level Security and User Filters – Niet een onderwerp wat in dit artikel is behandeld, maar wel de moeite om te lezen om de mogelijkheden hiervan te kennen. Hou onze blog in de gaten voor een eigen blog over dit onderwerp.
Wil je meer?
Onthoudt dat Tableau luistert naar je ideeën. Als je extra functionaliteit zou willen voor Tableau Server security, waarom stem je dan niet voor of voeg je een idee toe in de Idea Place op de Tableau Community, of bespreek je idee met anderen op het Tableau Server Administration Forum.
Originele (Engelstalige) blog is van Chris Love van TIL UK, 4 februari 2016.
Prefer to read the original blog from Chris Love in English? Click here