Security in de Power BI-service

Security wordt in modellen vaak gebruikt. Toegang inregelen op werkruimten en/of rapporten is vaak niet toereikend omdat de gebruiker dan via het model toch bij meer data kan. Met security op modelniveau kan men per rol of zelfs per gebruiker bepalen welke objecten een gebruiker wel of niet mag zien en welke data hij mag zien.

Buiten het implementeren van security is er vaak de behoefte om deze makkelijk te kunnen beheren en te testen. Binnen de Power BI-service is het mogelijk om zonder een dataset te moeten aanpassen de security te beheren en te testen.
 
Security implementeren

Het daadwerkelijk implementeren van de security gebeurd uiteraard nog wel in de dataset / het model. De security kan in Power BI Desktop worden geïmplementeerd, maar het kan nog makkelijker worden gedaan in Tabular Editor. In de basis zijn er 2 types security beschikbaar in Power BI. Deze worden hieronder nog even kort toegelicht. In deze blog zullen we niet verder ingaan op de beste manier om security te implementeren, maar vooral op het beheren van de toegang en het testen van de security.

Row-level security
Het woord zegt het al: met row-level security wordt bepaald welke data (regels) een gebruiker mag zien. Een Sales Manager mag bijvoorbeeld alleen de verkoopdata van zijn eigen regio zien. Row-level security kan ook dynamisch op basis van de ingelogde gebruiker worden toegepast.  

Object-level Security
Door middel van object-level security kunnen voor bepaalde rollen en gebruikers objecten worden verborgen. Afhankelijk van de gekozen structuur heeft deze vorm van security niet te voorkeur. Als een gebruiker namelijk een rapportage opent waar objecten in worden gebruikt die voor hem niet toegankelijk zijn, dan zal er een foutmelding worden weergegeven en wordt de visual niet getoond.

Gebruikers beheren
Zodra de security is geïmplementeerd via Power BI Desktop of Tabular Editor kunnen de gebruikers via de Power BI-service worden beheerd. Door naar de security settings van de dataset te gaan kunnen de groepen en gebruikers aan de verschillende rollen toegevoegd worden.

De groepen en gebruikers kunnen hier vanuit Azure Active Directory worden verwijderd en toegevoegd. Vanzelfsprekend wordt hier alleen de toegang tot het model geregeld. De toegang tot de verschillende workspaces moet op de werkruimtes zelf worden ingeregeld.

Security testen
Door in de security settings van de dataset op een rol te klikken en "Test as role" te selecteren kan de security van een rol worden getest.

Als de dataset zich in een werkruimte bevindt met rapportages zal er een rapportage uit de werkruimte worden geopend waarop de security kan worden getest. Als er zich in de werkruimte geen rapportages op de dataset bevinden dan kan er zelf een rapportage uit een andere werkruimte worden geopend om de security te testen.

Door op de dropdown naast de rol te klikken kan de security voor een rol of voor een gebruiker worden getest. In het geval van dynamische row-level security is dat laatste een hele mooie functie om te kunnen testen hoe een eindgebruiker precies de rapportage ziet.

Na het invullen van het e-mailadres van een gebruiker kan de security op dat niveau worden getest. 

Conclusie
Via de security settings van de dataset is het voor beheerders bij klanten mogelijk om zonder het model te moeten aanpassen de toegang voor gebruikers te beheren en te testen. Vooral het testen van de row-level security voor specifieke eindgebruikers is een functionaliteit die veel gebruikt wordt en ook erg welkom is om toegangsissues te kunnen reproduceren en op te lossen zonder daadwerkelijk als de desbetreffende gebruiker te moeten inloggen of met de gebruiker mee te moeten kijken.