Power BI Row-Level Security (RLS): een uitgebreide tutorial

Row-Level Security (RLS) in Power BI stelt je in staat te bepalen welke rijen data gebruikers mogen bekijken op basis van filters. Deze functionaliteit is vooral waardevol in situaties waarin meerdere gebruikers toegang nodig hebben tot een gedeeld rapport, maar met gepersonaliseerde weergaven afhankelijk van hun rol of afdeling.

In deze tutorial neem ik je mee in een praktische en diepgaande uitleg van RLS, inclusief statische en dynamische configuraties, stappen voor de implementatie, geavanceerde enterprise-technieken en veelvoorkomende valkuilen die ik heb leren vermijden. Ik deel ook best practices en vergelijk RLS met andere beveiligingsmodellen.

Als je net begint met Power BI, raad ik je aan om onze Power BI Fundamentals skill track te bekijken. Daarmee beheers je snel alle essentiële vaardigheden die je nodig hebt.

Wat is Row-Level Security?

Row-Level Security (RLS) is een beveiligingsfunctie in Power BI die de toegang tot rijen in een tabel beperkt op basis van de identiteit van de gebruiker die het rapport bekijkt. In plaats van rapporten te dupliceren voor verschillende gebruikersgroepen, kun je met RLS filters toepassen op dataniveau zodat elke gebruiker alleen de data ziet die hij of zij mag bekijken.

Dit is cruciaal voor het waarborgen van vertrouwelijkheid en integriteit van data, vooral bij gevoelige of propriëtaire informatie. RLS werkt binnen het Power BI-datamodel en zorgt ervoor dat onbevoegde gebruikers geen toegang krijgen tot afgeschermde data, zelfs niet via indirecte methoden zoals slicers of drill-downs.

Rollen en filters

De implementatie van RLS is gebaseerd op drie kernelementen:

• Rollen: Logische groeperingen met gedefinieerde toegangsregels.
• DAX-filters: Expressies die bepalen tot welke data elke rol toegang heeft.
• Gebruikerstoewijzingen: Configuratie van welke gebruikers of groepen bij welke rollen horen.

Deze elementen werken samen om elke query te toetsen aan de toegangsvoorwaarden voordat resultaten worden teruggegeven.

Use-cases

RLS is breed toepasbaar in veel sectoren en scenario’s, waaronder:

• Verkoopregio’s: Salesmanagers zien alleen de prestatiegegevens van hun regio.
• Zorg: Artsen hebben alleen toegang tot dossiers van hun toegewezen patiënten.
• Multi-tenant SaaS: Klanten zien in gedeelde dashboards alleen de data van hun eigen organisatie.

Dit beveiligingsmodel zorgt ervoor dat gedeelde datasets veilig blijven, terwijl duplicatie en beheerlast worden geminimaliseerd.

Statische vs dynamische RLS-architecturen

Row-level security is onder te verdelen in twee typen: statisch en dynamisch.

Ik heb de verschillen samengevat in de onderstaande tabel:

Tip: gebruik statische RLS voor kleine, vaste gebruikersgroepen. Gebruik dynamische RLS voor groeiende of grootschalige omgevingen.

Hieronder laat ik implementaties van zowel statische als dynamische voorbeelden zien.

Implementatie van statische RLS

Statische RLS houdt in dat je rollen maakt met hardgecodeerde DAX-filters. Elke rol komt overeen met een specifieke groep of segment, zoals een geografische regio of een afdeling.

Dit zijn de algemene stappen om een statische RLS te implementeren:

1. Maak een rol met bijvoorbeeld de naam "Region_East".
2. Pas op die rol een filter toe zoals [Region] = "East".
3. Wijs in Power BI Service specifieke gebruikers toe aan de rol.

Implementatie van dynamische RLS

Dynamische RLS gebruikt functies zoals USERNAME() of USERPRINCIPALNAME() in combinatie met mappingtabellen om data dynamisch te filteren op basis van de gebruikersidentiteit.

Dit zijn de algemene stappen om een dynamische RLS te implementeren:

1. Maak een mappingtabel die gebruikers koppelt aan toegangs­niveaus. Dit is je securitytabel. Deze tabel moet kolommen bevatten zoals e-mails van gebruikers, hun toegangsregio’s en hun namen.
2. Schrijf een DAX-filter zoals: [Region] = RELATED(UserRegion[Region])
3. Filter die tabel met: UserRegion[Email] = USERPRINCIPALNAME()

Row-Level Security instellen in Power BI Desktop

We bekijken nu een korte handleiding voor het instellen van statische row-level security met een eenvoudige salesdataset.

1. Een voorbeeld­dataset maken met Python

Maak om RLS te testen een voorbeeld­dataset met Python:

import pandas as pd

data = {
    'Salesperson': ['Alice', 'Bob', 'Charlie', 'Alice', 'Bob', 'Charlie'],
    'Region': ['East', 'West', 'South', 'East', 'West', 'South'],
    'SalesAmount': [15000, 20000, 18000, 17000, 21000, 16000],
    'Email': ['alice@company.com', 'bob@company.com', 'charlie@company.com'] * 2,
    'Date': pd.date_range(start='2025-01-01', periods=6, freq='M')
}

sales_df = pd.DataFrame(data)
sales_df.to_csv('sample_sales_data.csv', index=False)

2. Importeren in Power BI en een referentievisualisatie maken

1. Open Power BI Desktop.
2. Ga naar Home > Get Data > Text/CSV.
3. Selecteer het bestand sample_sales_data.csv.

4. Laad de data in het model.

Zorg voor de juiste datatypen en controleer dat de kolom Email overeenkomt met de loginidentiteit (meestal e-mail).

5. Maak een eenvoudige gestapelde kolomgrafiek in Power BI. Sleep het veld Date naar de X-as en SalesAmount naar de Y-as.

Zo zou je grafiek eruit moeten zien:

Meer over het gebruik van Power BI vind je in onze cheat sheet, zoals hieronder te zien.

3. Rollen maken

Laten we vervolgens enkele rollen maken om te definiëren welke rollen welke rechten hebben.

1. Ga naar Modeling > Manage Roles.

2. Klik op Create en geef je rol een naam, bijvoorbeeld SalesRegionStatic.
3. Selecteer de relevante tabel.
4. Voer een DAX-filterexpressie in:

[Email] = “charlie@company.com”

Zo zou je interface eruit moeten zien:

5. Sla op en sluit het dialoogvenster.

Als de wijzigingen succesvol zijn opgeslagen, verschijnt er een groene balkmelding zoals hieronder.

4. Rollen testen

1. Ga naar Modeling > View as Roles.

2. Kies de rol SalesRegionStatic die we eerder hebben gemaakt.

3. Bekijk de rapportvisuals gefilterd op die identiteit.

Zoals je in de onderstaande afbeelding ziet, is de grafiek gefilterd om alleen data te tonen waarbij de e-mail “charlie@company.com” is.

Dit maakt lokale validatie mogelijk vóór deployment.

Gebruikers toewijzen en rollen beheren in Power BI Service

Als je RLS-rollen zijn ingesteld en getest in Power BI Desktop, is de volgende stap het publiceren van het rapport naar de Power BI Service. Zo kun je specifieke gebruikers of beveiligingsgroepen aan elke rol toewijzen, zodat toegangscontrole wordt afgedwongen wanneer het rapport wordt gedeeld.

1. Het rapport publiceren naar Power BI Service

1. Klik in Power BI Desktop op Home > Publish > To Power BI.
2. Kies de doelwerkruimte in je Power BI Service.

3. Log na het publiceren in op Power BI Service via https://app.powerbi.com.

Zo ziet het er bij mij uit in de Power BI-service op het web.

Publiceren is een vereiste om RLS-roltoewijzingen te configureren, omdat de in Power BI Desktop gedefinieerde rollen samen met de dataset worden overgezet.

2. Beveiligingsinstellingen openen

1. Selecteer het menu Meer opties voor je relevante semantisch model.Klik op de beletseltekens (...) naast de dataset en selecteer Security.
2. Je ziet een lijst met rollen die in Power BI Desktop zijn gedefinieerd.

Hier wijs je gebruikers of Azure Active Directory (AAD)-groepen aan elke rol toe.

3. Individuele gebruikers en beveiligingsgroepen toewijzen

Om gebruikers toe te wijzen, voer je hun volledige e-mailadres in het tekstvak onder de gewenste rol in, druk je op Enter en klik je op Add.

Om AAD-groepen toe te wijzen, gebruik je de naam van de groep (bijv. Sales_Region_East of Finance_Team). Zorg ervoor dat de groep al is gedefinieerd en beheerd in Azure Active Directory.

4. Toegewezen toegang verifiëren

Controleer na het toewijzen van gebruikers of groepen even of de juiste data aan de juiste groep wordt getoond.

Iedereen ziet alleen de data die is gefilterd door de DAX-expressie die aan hun rol is gekoppeld. Ze krijgen niet automatisch een melding van de roltoewijzing, dus je wilt misschien na je verificatie nog instructies over toegang communiceren.

5. Roltoewijzingen testen in Power BI Service

1. Klik op dezelfde pagina op je eerder gedefinieerde RLS-naam, klik op de beletseltekens (...), en daarna op Test as role.

2. Power BI opent een alleen-lezen versie van het rapport met alleen de data die is toegestaan door de geselecteerde rol.

Voor dynamische RLS kun je ook simuleren wat een specifieke gebruiker zal zien:

• Klik op Test as role.
• Voer het e-mailadres van een gebruiker in om hun ervaring te simuleren.

Dit is handig om te controleren of je dynamische filters (bijv. op basis van USERPRINCIPALNAME()) correct werken.

Geavanceerde implementatietechnieken

RLS kan verder in je Power BI-werkstroom worden geïntegreerd met enkele geavanceerde technieken. Hier zijn er een paar om op te letten:

1. Integratie met beveiligingsgroepen

Met beveiligingsgroepen in Azure Active Directory (AAD) kun je toegangsrechten toewijzen aan hele groepen in plaats van aan individuele gebruikers. 

Dit is vooral nuttig in enterprises waar medewerkers vaak aan teams worden toegevoegd of deze verlaten, omdat je dan geen toegangsrechten in Power BI handmatig hoeft bij te werken.

2. Overwegingen bij complexe datamodellen

Zorg er bij grootschalige datamodellen voor dat RLS niet interfereert met relaties en filterpropagatie. 

Enkele tips:

• Gebruik een stermodel om complexe joins te vermijden.
• Beperk het gebruik van bidirectionele relaties tenzij noodzakelijk.
• Vermijd ambiguë relaties die tot onjuiste filtering kunnen leiden.
• Optimaliseer performance door berekende kolommen in zwaar gefilterde tabellen te minimaliseren.

3. Hybride aanpakken

Een hybride aanpak van RLS combineert statische en dynamische technieken. 

Zo kun je bijvoorbeeld een statische rol definiëren om toegang te geven aan een specifieke business unit, en daarbinnen dynamisch filteren op basis van individuele e-mailadressen of gebruikersnamen. Deze methode maakt gelaagde en flexibele beveiligingslogica mogelijk.

4. Object-level security (OLS)

Met Object-Level Security kun je volledige tabellen of kolommen verbergen voor bepaalde rollen. Dit vult RLS aan met een extra beschermingslaag. OLS kan worden gebruikt voor gevoelige velden zoals salaris- of medische informatie.

Test- en validatiestrategieën

1. Testen in Desktop

Power BI Desktop biedt een handige manier om verschillende gebruikersweergaven te simuleren via de “View as”-rolfunctie. Hiermee kunnen rapportontwikkelaars valideren dat de Row-Level Security-logica correct werkt voordat het rapport wordt gepubliceerd.

Zo test je RLS in Power BI Desktop:

1. Klik op het tabblad Modeling.
2. Selecteer View as op het lint.
3. Kies de rollen die je hebt geconfigureerd (bijv. SalesRegionStatic).
4. Voer optioneel een testgebruikersnaam/e-mail in als je dynamische RLS gebruikt.
5. Klik op OK en bekijk hoe visuals worden gefilterd.

Dit simuleert het rapport alsof een gebruiker die aan die rol is toegewezen het bekijkt. Dit is vooral handig bij het testen van dynamische RLS-filters die afhankelijk zijn van DAX-functies zoals USERPRINCIPALNAME().

2. Testen in de Service

Zodra het is gepubliceerd naar Power BI Service, moet RLS opnieuw in de cloudomgeving worden getest om nauwkeurigheid te garanderen.

Zo test je RLS in Power BI Service:

1. Navigeer naar de dataset in je werkruimte.
2. Klik op de ... naast de dataset > Security.
3. Selecteer een rol > klik op Test as role.
4. Gebruik de optie “Test as specific user” om dynamische RLS-filters te simuleren.

Dit zorgt ervoor dat de filters zich gedragen zoals verwacht voor echte gebruikers.

3. Belangrijke validatietips

Voor validatie kun je overwegen om testaccounts of service-identiteiten te gebruiken om echt gebruik na te bootsen. Alle filters op kernvisuals, zoals tabellen en grafieken, moeten ook periodiek worden gecontroleerd.

Controleer ook slicers, drillthrough en bookmarks grondig om te zorgen dat ze geen ongeautoriseerde data prijsgeven.

Veelvoorkomende valkuilen en oplossingen

Bij het implementeren van RLS kunnen problemen optreden. Hier zijn veelvoorkomende issues en hoe je ze oplost.

1. Problemen na publicatie

Na publicatie naar Power BI Service merken sommige gebruikers dat RLS niet werkt zoals verwacht, ook al werkte het in Power BI Desktop wel.

Oplossingen:

• Publiceer het rapport opnieuw nadat je rollen of filters hebt gewijzigd.
• Controleer of de e-mail die in USERPRINCIPALNAME() wordt gebruikt, overeenkomt met het login­domeinformaat in de dataset.

2. Conflicten met werkruimterollen

Gebruikers met bepaalde werkruimterollen (Admin, Member) kunnen RLS onbedoeld omzeilen.

Oplossingen:

• Wijs gebruikers toe als Viewers in de werkruimte om RLS-regels af te dwingen.
• Geef geen Contributor/Admin-rechten tenzij nodig voor contentontwikkeling.

3. Beperkingen van DAX-functies

Veelvoorkomende valkuilen ontstaan door verkeerd gebruik van DAX-functies zoals USERNAME() en USERPRINCIPALNAME():

• USERNAME() kan in Desktop een lokale accountnaam retourneren in plaats van een e-mailadres.
• Gebruik USERPRINCIPALNAME() voor consistentie met cloudidentity-gedrag.

Tips:

• Voeg een referentietabel met voorbeeld­e-mails toe om lokaal testen te vergemakkelijken.
• Gebruik voorwaardelijke logica of standaardwaarden in DAX om filterfouten te voorkomen.

4. Uitdagingen met DirectQuery en SSO

Dynamische RLS met DirectQuery-bronnen vereist extra aandacht, vooral in combinatie met Single Sign-On (SSO).

Veelvoorkomende issues:

• Onjuiste gatewayconfiguratie kan gebruikersimpersonatie blokkeren.
• SSO-instelling met Kerberos kan falen als SPN’s verkeerd zijn geconfigureerd.

Oplossingen:

• Raadpleeg Microsoft-documentatie over SSO met Power BI-gateways.
• Werk nauw samen met IT- en infrastructuurteams om Kerberos-delegatie in te schakelen.

RLS verwijderen of uitschakelen voor openbare toegang

Er zijn situaties waarin RLS tijdelijk moet worden verwijderd (bijv. voor demo’s of open dashboards) of permanent (bijv. bij het delen van data met externe stakeholders). In zulke gevallen moet je voorzichtig omgaan met zichtbaarheid om onverwachte datalekken te voorkomen.

RLS uitschakelen in Power BI Desktop

Zo schakel je RLS uit:

1. Open je rapport in Power BI Desktop.
2. Ga naar Modeling > Manage Roles.
3. Selecteer en verwijder alle rollen of schakel hun filters uit.
4. Sla op en publiceer de dataset opnieuw naar Power BI Service.

Zodra RLS is verwijderd, hebben alle gebruikers toegang tot de volledige dataset, tenzij andere beveiligingsmaatregelen van kracht zijn.

Veilig delen zonder RLS

Als RLS niet haalbaar of niet nodig is, overweeg dan de volgende praktijken om databeveiliging te behouden:

• Gebruik permissies op datasetniveau: Deel de dataset of het rapport alleen met vertrouwde gebruikers en gebruik werkruimte­rechten (Viewer, Contributor) op de juiste manier.
• Publiceren op het web vermijden: “Publish to Web” verwijdert alle beveiligingscontroles. Gebruik in plaats daarvan “Embed for organization” of Power BI Embedded voor veilig delen in publieke stijl.

RLS verwijderen betekent niet dat alle beveiliging verdwijnt. Gebruik andere lagen van toegangscontrole en deelopties in Power BI Service om verantwoorde verspreiding van data te waarborgen.

Best practices voor enterprise-implementatie

Een succesvolle, organisatiebrede implementatie van Row-Level Security vereist doordachte planning, een schaalbare architectuur en goed beheer. Dit onderdeel beschrijft beproefde best practices voor verschillende facetten van RLS-implementatie.

1. Datamodellering

Een goed ontworpen datamodel ondersteunt efficiënte en onderhoudbare RLS-configuraties.

Aanbevelingen:

• Volg een stermodel met duidelijke relaties tussen feit- en dimensietabellen.
• Vermijd onnodige bidirectionele relaties die ambiguïteit in filtering kunnen introduceren.

2. Rolbeheer

Centraal en consistent beheer van RLS-rollen helpt fouten te verminderen en samenwerking te verbeteren.

Aanbevelingen:

• Onderhoud een document met roldefinities om RLS-logica en DAX-expressies bij te houden.
• Gebruik beschrijvende rolnamen (bijv. “Region_East_Sales”) om verwarring te voorkomen.

3. Prestatieoptimalisatie

RLS kan de prestaties van rapporten beïnvloeden, vooral bij complexe filters of grote datasets.

Aanbevelingen:

• Agregeer data vooraf waar mogelijk met samenvattingstabellen.
• Minimaliseer het gebruik van berekende kolommen in RLS-logica.
• Gebruik indexering en geoptimaliseerde queries in bronsystemen om DirectQuery-scenario’s te ondersteunen.

RLS vs alternatieve beveiligingsmodellen

Laten we nu de verschillen vergelijken tussen Row-Level Security (RLS) en andere beveiligingsfuncties, met name Object-Level Security (OLS).

1. Granulariteit en use-case

RLS biedt toegangscontrole op rijniveau, ideaal om data te filteren op gebruikersidentiteit, geografie, afdeling of business unit. OLS daarentegen beheert de toegang tot volledige tabellen of kolommen, wat handig is om gevoelige financiële of HR-informatie te verbergen (bijv. salaris­kolom). 

2. Implementatie en dynamische aanpassing

RLS is eenvoudig te implementeren in Power BI Desktop via DAX-filters op rollen. Deze regels kunnen statisch (hardgecodeerde filters) of dynamisch (gebruikersgestuurde logica) zijn. OLS wordt geconfigureerd via de Tabular Editor of een XMLA-endpoint. Het vereist ook een premium-werkruimte of een Power BI-dataset die wordt gehost in Analysis Services.

Ik heb hieronder een vergelijkingstabel samengesteld:

Conclusie

Kortom, row-level security (RLS) in Power BI is een cruciale methode om datagovernance binnen het platform te waarborgen. Het stelt organisaties in staat om gepersonaliseerde, veilige analytics-ervaringen aan te bieden binnen één rapport of dashboard, zonder de vertrouwelijkheid of integriteit van onderliggende data in gevaar te brengen.

Beveiliging is een steeds belangrijkere factor in databeheer en -governance, en daarmee een belangrijk aspect bij het werken met Power BI. Voor meer diepgaande informatie over Power BI, bekijk onze cursus Deploying and Maintaining Assets in Power BI of onze cursus Reports in Power BI. Voor verdere verdieping zijn onze gidsen over Power BI-hierarchieën en Power BI-dashboards wellicht ook behulpzaam.