Wat is Row-Level Security in Power BI en wanneer heb je het nodig

Row-Level Security in Power BI is een manier om datatoegang te beperken door rijen te filteren op basis van wie er is ingelogd. Het idee is simpel: dezelfde rapportpagina, dezelfde visuals, maar per gebruiker andere rijen in de onderliggende data. Dat maakt het ideaal voor scenario’s zoals vestigingen, klantportalen, regio’s of afdelingen die allemaal dezelfde definities en KPI’s moeten gebruiken.

Onder de motorkap werkt RLS met rollen die filters toepassen op tabellen in je semantic model. Die filters propagaten via relaties naar andere tabellen, waardoor je modelstructuur opeens onderdeel wordt van je security. Het is ook belangrijk om te beseffen dat RLS dataweergave beperkt, maar geen vervanging is voor workspace- en buildrechten, en het is geen “permission management” voor ontwikkelen of bewerken.

In de praktijk heb je RLS nodig zodra je een rapport met een bredere doelgroep deelt, terwijl niet iedereen dezelfde detaildata mag zien. Denk aan sales per accountmanager, marges per klant, of HR-data per team. Als je nu nog exportjes rondstuurt of rapporten dupliceert per doelgroep, is dat meestal een signaal dat RLS (en je governance) volwassen mag worden.

Statische vs dynamische RLS in Power BI: kies de juiste aanpak

Statische RLS betekent dat je regels vastlegt per rol, zoals “Rol Noord ziet alleen regio Noord”. Dat werkt prima als je weinig varianten hebt en de indeling stabiel is, bijvoorbeeld drie regio’s of vijf business units. Het voordeel is voorspelbaarheid: je ziet snel wat een rol wel en niet ziet, zonder extra mapping-tabellen.

Dynamische RLS maakt de filter afhankelijk van de ingelogde gebruiker, vaak via USERPRINCIPALNAME() of USERNAME() in DAX. Je combineert dat meestal met een mapping-tabel waarin staat welke gebruiker welke entiteiten mag zien, zoals klant-IDs of cost centers. Dit schaalt veel beter, omdat je niet honderden rollen hoeft te bouwen, maar het vraagt wel om strak modeldesign en goede datakwaliteit in de mapping.

Kies statisch als je weinig groepen hebt, governance simpel is, en wijzigingen zeldzaam zijn. Kies dynamisch als je veel gebruikers hebt, rechten vaak wijzigen, of je self-service wil faciliteren zonder handmatig rolbeheer. Een praktische vuistregel is: als je bij groei meer tijd kwijt bent aan role-maintenance dan aan je datamodel, dan ben je toe aan dynamische RLS.

Rollen en DAX in Power BI Desktop: zo implementeer je RLS goed

De implementatie start bijna altijd in Power BI Desktop met het definiëren van rollen en regels via “Manage roles”. Je kiest een tabel waarop je wil filteren en schrijft een DAX-filterexpressie die bepaalt welke rijen zichtbaar zijn. Daarna test je met “View as” om te controleren of je filter doet wat je bedoelt voordat je publiceert.

Voor dynamische RLS gebruik je vaak een mapping-tabel met gebruikers en toegestane sleutels, en een DAX-regel die de ingelogde gebruiker koppelt aan die tabel. De bekende patronen gebruiken USERPRINCIPALNAME() omdat dat in veel organisaties het e-mailadres of de UPN teruggeeft, wat goed aansluit op Entra ID. Belangrijk is dat je relaties zo staan dat je securityfilter ook echt doorwerkt naar je facttabellen, anders voelt het alsof RLS “random” faalt.

In Desktop kun je rollen simuleren, maar je wijst gebruikers niet toe in Desktop zelf. In de Service/Fabric koppel je gebruikers of Entra-groepen aan de rollen die je hebt gepubliceerd, en pas dan zie je het echte gedrag in productie. Als je in Desktop “View as other user” gebruikt, moet je ook de rol aanvinken, omdat Desktop nog niet weet welke rollen een gebruiker in de Service krijgt.

Row-Level Security in Power BI in Microsoft Fabric beheren

In een Fabric-omgeving draait RLS nog steeds om hetzelfde concept: rollen in het semantic model met filters, plus toewijzingen aan gebruikers of groepen. Het verschil zit vooral in beheer: je wil security niet als losse handmatige stap behandelen, maar als onderdeel van je lifecycle in workspaces en deployments. Ook hier geldt dat gebruikers met bepaalde workspace-rollen ruimer kunnen kijken dan je denkt, dus je rechtenmodel bepaalt of RLS echt je veiligheidsgrens is.

Een kritische nuance is dat RLS in de Power BI service niet op dezelfde manier geldt voor iedereen. Microsoft benoemt dat RLS vooral effect heeft voor gebruikers met Viewer-permissies, en niet voor Admins, Members of Contributors in de workspace. Dat betekent dat je voor interne teams die het model beheren, andere afspraken nodig hebt dan voor consumenten van rapporten.

In de praktijk beheer je dit door Entra ID security groups te gebruiken voor roltargeting, en door je workspaces te scheiden: één plek voor development en beheer, en één plek voor consumptie. Als je daarnaast veel deployments doet of templates hergebruikt, is het slim om na te denken over automatisering van securityconfiguraties, zodat updates niet stiekem je rolsetup overschrijven.

Veelgemaakte fouten die je RLS onderuit halen

De meest gemaakte fout is denken dat RLS “magisch” werkt zodra je één filter op een dimensietabel zet. In werkelijkheid is RLS afhankelijk van hoe filters door je model lopen, en bi-directional relaties of many-to-many constructies kunnen onverwachte resultaten geven. Soms zie je te veel data, soms juist te weinig, en soms lijkt het alsof visuals elkaar tegenwerken.

Een tweede klassieker is onduidelijkheid over waar je wat beheert: rollen maak je in Desktop (of met tooling), maar gebruikers toewijzen doe je in de Service. Daardoor testen mensen “als user X” in Desktop zonder rol te selecteren en concluderen ze dat het stuk is, terwijl de test simpelweg niet hetzelfde is als productie. Ook wordt RLS soms misbruikt als permissiemodel voor bouwen of editen, terwijl het primair gaat om beperken van wat je ziet.

De beste preventie is een security-first modelontwerp: duidelijke dimensions, enkelvoudige filterpaden waar mogelijk, en een mapping-tabel die als productiedata wordt beheerd met eigenaarschap. Leg daarnaast vast wie de RLS-eigenaar is en hoe changes verlopen, want dynamische RLS is net zo betrouwbaar als het proces dat je mapping actueel houdt.

Teststrategieën: zo bewijs je dat RLS echt klopt

Testen van RLS is meer dan even kijken of een slicer minder waarden toont. Je wil aantonen dat elke relevante tabel en elke belangrijke visual alleen data toont die de gebruiker mag zien, inclusief drillthrough, tooltips en exports. Begin in Desktop met “View as” en simuleer meerdere typen gebruikers, maar behandel dat als unit test, niet als eindbewijs.

De echte test is in de Service/Fabric, omdat daar de roltoewijzing en de identiteit van de gebruiker samenkomen. Test met echte Entra-groepen en echte accounts, en controleer expliciet de randgevallen: gebruikers zonder mapping, gebruikers met meerdere rechtenpaden, en uitzonderingen zoals tijdelijke toegang. Neem ook performance mee, want dynamische filters en complexe relaties kunnen je rapport traag maken, waardoor gebruikers alternatieve exports gaan zoeken.

Maak tot slot regressietesten onderdeel van je releaseproces, zeker als je model frequent wijzigt. Een simpele wijziging in relaties of filterrichting kan security-propagatie veranderen zonder dat je DAX-regel wijzigt. Als je in je team een vaste set “security persona’s” onderhoudt met verwachte uitkomsten, voorkom je dat RLS per ongeluk degradeert terwijl iedereen denkt dat het nog goed staat.

Samenvatting

Row-Level Security in Power BI is een krachtig mechanisme om rijen te filteren op basis van de ingelogde gebruiker, zonder rapporten te dupliceren. Je kiest statische RLS voor eenvoudige, stabiele segmenten en dynamische RLS voor schaal en flexibiliteit, meestal met USERPRINCIPALNAME() en een mapping-tabel. Rollen bouw je in Desktop, maar de echte werking staat of valt met toewijzingen en rechten in de Service/Fabric, plus een teststrategie die modelwijzigingen en edge cases afdekt.