Data beschikbaar maken in rapportages en dashboards is niet zo complex wanneer alle data voor alle gebruikers zichtbaar mag zijn. Helaas is dit in de meeste gevallen niet zo omdat het doelgebruik van die data die openheid van data niet toestaat. Om deze reden is het noodzakelijk de data voor de presentatie ervan te filteren. Hoe deze filtering plaatsvindt is afhankelijk van de rechten die de gebruiker heeft op de data. Nu steeds meer gebruikers toegang krijgen tot data en Power BI een belangrijk middel is in de keten van waardecreatie op basis van data, is het van belang dat rapport en dashboard creators en gebruikers de beveiliging van data serieus blijven nemen. Deze blog geeft hands-on richting aan de inrichting van Row Level Security (RLS) in Power BI.
Static versus Dynamic Row Level Security
RLS is een techniek waarmee slechts een deel van de data in een rapport kan worden gezien door de gebruiker. Het rapport wordt automatisch gefilterd op basis van wie het bekijkt. Met RLS kunnen alleen specifieke rijen in de data worden gelimiteerd, niet de kolommen. Er zijn grofweg twee manieren om RLS op te zetten. Beide methoden hebben een veld nodig in de dataset dat kan worden gebruikt om de data te filteren voor een specifieke groep of gebruiker.
Static Row Level Security
Het makkelijkst om in te stellen. Static is de beste keuze wanneer er slechts een klein aantal verschillende en te onderscheiden gebruikersgroepen in te stellen zijn. Deze methode vereist dat de data een veld heeft dat gefilterd kan worden om een subset van die data te maken van data voor een specifieke groep.
Dynamic Row Level Security
Dynamic is gecompliceerder om in te stellen en is de beste keuze wanneer er veel gebruikersgroepen zijn om in te stellen en wanneer wanneer die groepen frequent veranderen van samenstelling. Deze methode vereist dat de data een veld met een gebruikersnaam bevat dat wordt gebruikt om de data te filteren. De beste manier om dit te kunnen doen, is om de tabel waar de medewerker ID’s in staan om mee in te loggen op Microsoft Outlook te ontsluiten. Deze medewerker ID’s zijn de credentials in het format van een e-mailadres en kan er uitzien zoals: John.Doe@sogeti.com. Het is het beste om, indien mogelijk, deze data te laten pushen door een bronsysteem om zo te voorkomen dat deze data door het Power BI Competence center moet worden beheerd.
Close the backdoor
Voordat je start met RLS, moet je er zeker van zijn dat de gebruikers geen toegang hebben tot de onderliggende databron. Om dit voor elkaar te krijgen, moeten je twee zaken in overweging nemen:
Limit access to the data source itself
Geef gebruikers geen toegangsrechten op de databron en andere credentials om te connecten met de databron. De tip hierbij is een Functie,- of Serviceaccount toe te passen om te connecten naar de databron.
Limit access to the Workgroup
Wanneer gebruikers in staat zijn om het rapport in de workspace aan te passen, dan kunnen zij ook de instellingen veranderen voor RLS en daarmee RLS uitzetten. Dit is bijzonder belangrijk wanneer het rapport gevoelige informatie bevat zoals details van een enkele klant of medewerker.
Instellingen voor een klassieke workspace:
- Private – Alleen goedgekeurde leden kunnen zien wat er in zit;
- Leden kunnen alleen Power BI inhoud zien
Stel de workspace in op de volgende instellingen voor een nieuwe workspace stijl:
- Wijs gebruikers toe die de RLS nodig hebben om de rol te zien;
- Leden van andere rollen kunnen de RLS overslaan;
Of publiceer de workspace naar een app. Creëer een nieuwe workspace wanneer de instellingen conflicteren met de andere rapporten in de workspace. Controleer ook de instelling van ieder workspace-type om te voorkomen dat de gebruikers het rapport kunnen aanpassen en zo ook de instellingen voor RLS kunnen aanpassen.
Static Row Level Security
1. Prepare the model for Static Row Level Security
Om Static Row Level security in te stellen, moet je eerst het veld selecteren waar je op wil filteren. Deze tabel moet een relatie hebben tot de andere tabellen die de data bevatten waar op gefilterd moet worden.
2. Create Roles
Selecteer vanuit het Modelleer lint onder Security: “Manage Roles”:
Figuur 1: Beheer rollen
Creëer vervolgens tenminste twee rollen. Een rol die gebruikt wordt door Administrators. Mensen die deze rol toegewezen krijgen, zullen niet worden geraakt door Role Level Security. Deze rol kan indien nodig gebruikt worden om aan een kleine groep van functionele managers en administrators toe te wijzen. Additionele rollen voor iedere groep die een andere VIEW op de dataset nodig heeft. Navigeer naar de tabel met het veld dat gefilterd wordt en voer de DAX-expressie in om te filteren op de juiste waarde:
[Region] = "International"
Figuur 2: Voeg een DAX filter toe aan een rol
Herhaal deze stappen voor iedere rol die van toepassing is.
3. Testing the static filter
Om het filter in Power BI te testen, selecteer “View as Roles” en selecteer alleen de rol die je wil zien.
Figuur 3: Views as Role for static RLS
4. Publish to powerbi.com
Zodra de Row Level Security werkt zoals verwacht, moet je het publiceren op Powerbi.com.
De laatste stap is om gebruikers toe te wijzen aan de zojuist gecreëerde rollen. Ga naar de dataset (NIET naar het rapport!) en selecteer het menu bij de drie puntjes. Klik op Security.
Figuur 4: Security instellingen voor de dataset
Wijs de groepen gebruikers toe aan de rollen. Voorkom het toewijzen van rechten aan individuele gebruikers. Dit voorkomt de beheernachtmerrie van het zelf onderhouden van deze individuele rechten. Het niet gebruiken van mailing,- of distributielijsten is de best practice omdat deze niet voldoen aan de regels voor het verlenen van toegang tot gevoelige data.
Figuur 5: Toewijzing van gebruikers
Dynamic Row Level Security
1. Prepare the data model for dynamic RLS
Het instellen van Dynamic Row Level Security vereist enige voorbereiding. Eerst importeren we de tabel met de namen van de geautoriseerde gebruikers. Deze tabel moet verbonden zijn met de tabel die de data zelf bevat. Dit mag via andere tabellen gekoppeld zijn.
Figuur 6: Datamodel for users related to Fact table
In dit voorbeeld bevat de tabel Users de lijst van gebruikers en de tabel CountryUsers bevat de landen die een specifieke gebruiker mag zien. De tabellen Country en FactInternetSales bevatten respectievelijk data over de namen van de landen en is hiermee een dimensie en de feitentabel bevat data over de verkoop. Wees er zeker van dat je specificeert dat de filtering op “Both” staat waar de filter verspreid moet worden via een 1-op-veel relatie die van een veel-op-1 aan de ene kant (van een feittabel naar een dimensietabel). En ook dat de checkbox voor “Apply security filter in both directions” aangeklikt is. In ons voorbeeld zou dat de relatie tussen de tabellen Country en CountryUsers.
Figuur 7: Aanpassen relaties
Om een schoner model te presenteren aan de gebruikers kun je de betreffende tabellen markeren in de mapping naar de gebruiker accounts als “Hide in Report View”. In ons voorbeeld zijn dat de tabellen CountryUsers en Users.
2. Create Roles
Selecteer vanuit het Modelleer lint onder Security: “Manage Roles” en creëer tenminste twee rollen.
Figuur 8: Voeg de DAX filter toe aan rol
Een rol die gebruikt wordt door Administrators. Mensen die deze rol toegewezen krijgen, zullen niet worden geraakt door Role Level Security. Deze rol kan indien nodig gebruikt worden om aan een kleine groep van functionele managers en administrators toe te wijzen. De tweede rol zal worden gebruikt voor de gebruikers die RLS zouden moeten gebruiken. In ons voorbeeld is dit de groep RLSUsers. Navigeer naar de tabel met de gebruikers en stel de volgende DAX expression op filter op de huidige gebruiker.
[AccountName] = userprincipalname()
Figuur 9: Filter setting
3. Testing the dynamic filter
Om het filter te testen in Power BI Desktop selecteer “View as Roles”. Specificeer de gebruiker waarmee je wil testen als “Other user” en selecteer de rol die het dynamische filter bevat.
Figuur 10: View role voor dynamic RLS
De data laat alleen de records zien waar de gebruiker recht op heeft. Om te controleren of de gebruiker correct gefilterd is, kun je een visual in PowerBI toevoegen van de tabel die alleen het veld bevat waar de filter op is toegepast. In ons voorbeeld is dat Users[AccountName]. Je kunt zo zien dat de geselecteerde gebruiker de enige is in de selectie. Je kunt hetzelfde doen voor elk van de tussentabellen, de feittabel en de tabel met het dynamische filter om er zeker van te zijn dat de filter op een correcte manier door de relaties stroomt.
In ons voorbeeld ziet dat er als volgt uit:
Figuur 11: Voorbeeld voor testen van dynamic RLS
4. Publish to powerbi.com
Wanneer de Row Level security werkt zoals verwacht, ga je het rapport publiceren naar powerbi.com. De laatste stap is om gebruikers toe te wijzen aan de rollen die we hebben gecreëerd. Ga naar de dataset (en niet het rapport!) en selecteer de drie puntjes. Klik op Security.
Figuur 12: Security instellingen voor de dataset.
Wijs de groepen van gebruikers toe aan de rollen. Voorkom het toewijzen van rechten aan individuele gebruikers en gebruik groepen. Dit voorkomt namelijk onnodig intensief beheer door het in het Power BI Competence center onderhouden van deze individuele rechten. Het niet gebruiken van mailing,- of distributielijsten wordt als best practice beschouwd omdat deze niet voldoen aan de regels voor het verlenen van toegang tot gevoelige data.
Figuur 13: Toewijzen van gebruikers op rollen
Wees er van bewust dat werken met Power BI Desktop en in de Power BI Service (app.powerbi.com) je een directe lijst resultaat laat zien wanneer je zoekt naar account en groepen.
Implementatie en advies
Deze blog heeft hands-on inzicht gegeven in de stappen die je moet zetten om static en dynamic RLS in te richten. Uiteraard is het van belang dat je planmatig de implementatie doet en hiermee bewust keuzen maakt die hier beschreven zijn. Wij adviseren dan ook de hierboven beschreven activiteiten te borgen bij het Power BI Competence center. Benieuwd? Bekijk onze Data & Business Analytics services of neem direct contact op.
