Row Level Security (RLS)

Wat is Row Level Security?

Row Level Security (RLS) is een manier om gegevens te beperken tot de rijen in je dataset die een gebruiker mag zien. Je kan een rapport bouwen maar iemand die het rapport opent zal enkel de data zien waarvoor hij of zij toegang heeft.

Het principe is eenvoudig. Je hebt één centrale dataset. Gebruikers zien elk hun eigen deel. Een verkoper ziet enkel de klanten van zijn zone. Een filiaalmanager ziet enkel de cijfers uit zijn eigen winkel. De directie ziet alles. RLS bepaalt dat automatisch op basis van de identiteit van de gebruiker.

RLS werkt door rollen en filters te combineren. In elke rol leg je vast welke rijen toegelaten zijn. Dat gebeurt met een DAX-filter, meestal op een dimensietabel zoals regio, filiaal of klant. De relatie naar de facttabellen zorgt ervoor dat het filter verder doorstroomt naar alle cijfers.

Als je geen RLS gebruikt, moet je vaak aparte rapporten maken voor elke afdeling. Dat geeft meer werk en meer risico op fouten. Met RLS hou je alles centraal en blijft het model overzichtelijk. Nu bouw je eigenlijk één template en iedereeijnnlijk rapport.

Een herkenbaar voorbeeld is een KMO met meerdere magazijnen. De onderneming wil één rapport voor voorraad en bestellingen. Dankzij Row Level Security krijgt elk magazijn alleen zijn eigen producten en transacties te zien. Het model is hetzelfde voor iedereen, maar de zichtbare rijen verschillen per gebruiker.

Wat is het grote voordeel van Row Level Security?

Row Level Security helpt je om betrouwbare rapporten te delen zonder dat gevoelige gegevens zichtbaar worden voor de verkeerde personen. Je hoeft geen aparte datasets of kopieën te maken voor verschillende teams. Eén goed model volstaat voor iedereen. Dat maakt beheer eenvoudiger en vermindert de kans op fouten.

Voor veel KMO’s is dit een groot voordeel. Denk aan een bedrijf met verschillende winkels. Je wil dat elke winkelmanager zijn eigen omzet bekijkt, maar niet die van de andere winkels. Tegelijk wil je dat de directie het totaaloverzicht behoudt. Met RLS regel je dat netjes zonder extra werk.

RLS ondersteunt ook privacyregels en interne afspraken. Afdelingen zoals HR, finance en sales hebben niet altijd dezelfde rechten nodig. Door RLS te gebruiken, toon je alleen de rijen die passen bij hun rol. Dat verhoogt het vertrouwen in het rapport en zorgt ervoor dat je geen gegevens lekt.

Een bijkomend voordeel is dat je geen technische kopieën van het datamodel moet aanmaken. Minder modellen betekent minder onderhoud. Als je bron wijzigt, hoeft dat maar op één plek aangepast te worden. Dat maakt je rapportage stabieler en beter schaalbaar.

Hoe werkt RLS?

Row Level Security werkt met rollen en filters. Een rol bevat de regels die bepalen welke rijen zichtbaar zijn. Het filter zelf is een DAX-expressie die je meestal plaatst op een dimensietabel. Denk aan tabellen zoals regio, filiaal of klant. De relaties in het model zorgen ervoor dat het filter automatisch doorloopt naar de facttabellen.

De gebruiker wordt herkend via USERPRINCIPALNAME(). Dat is meestal het e-mailadres waarmee iemand inlogt in Power BI of Fabric. Die waarde gebruik je om te bepalen welke rijen mogen blijven en welke niet. Zo kan je per persoon, team of Entra groep de juiste subset tonen.

In Power BI Desktop maak je rollen aan in het model. In de Power BI Service en Fabric worden die rollen toegepast zodra iemand het rapport opent of verbinding maakt met het semantisch model. Het werkt dus even goed voor visuele rapporten als voor connecties via Excel of externe tools. Zo hou je de beveiliging centraal en consistent.

Vaak voorkomemde RLS implementaties in DAX

Er zijn verschillende manieren om RLS in te richten. Elke aanpak heeft zijn eigen voordelen afhankelijk van hoe je organisatie werkt. Hieronder vind je de meest gebruikte patronen. Ze bouwen allemaal verder op hetzelfde idee: filter op een dimensie en gebruik de relaties in het model om de rest te beveiligen / filteren.

Statische RLS

Bij statische RLS leg je in de rol zelf vast welke waarde zichtbaar is. Dit is handig als je een vaste groep hebt met steeds dezelfde toegang.

Voorbeeld:

'DimRegio'[Regio] = "Vlaanderen"

Deze rol toont enkel de rijen voor Vlaanderen.

Geschikt voor kleine modellen of tijdelijke scenario’s.

Dynamische RLS via e-mail

Bij dynamische RLS geef je elke gebruiker zijn toegangsrechten in een aparte tabel. In plaats van gebruikers manueel toe te wijzen aan bepaalde groepen zorg je ervoor dat dit dyna;msch gebeurt op basis van op basis van de username. Je filtert op basis van USERPRINCIPALNAME().

Voorbeeld van een rol:

'DimRegio'[Regio] IN
CALCULATETABLE(
    VALUES('UserRegion'[Regio]),
    'UserRegion'[Email] = USERPRINCIPALNAME()
)

In dit voorbeeld heb je een tabel 'UserRegion' nodig. Die bevat per gebruiker de regio’s waarvoor hij toegang heeft. Zo heeft Ava hier toegang tot de regio's Antwerpen en Vlaams-Brabant. Bob heeft enkel toegang tot Antwerpen. In een kleine omgeving kan je rechten beheren in een simpele Excel en die inladen als je basis voor Row Level Security. Vaak komen de rechten echter uit een andere applicatie of uit Entra AD. Op die manier kan je gebruikers beheren in een andere applicatie en de rechten laten doorstromen naar Power Bi en Microsoft Fabric.

|-------------------|-------------------|
| Email             | Region            |
|-------------------|-------------------|
| ava@datapanda.eu  | Antwerpen         |
| ava@datapanda.eu  | Vlaams-Brabant    |
| bob@datapanda.eu  | Antwerpen         |
|-------------------|-------------------|

Er is meestal geen directe relatie nodig tussen 'UserRegion' en 'DimRegio'. De DAX-filter doet dat werk.

Dynamische RLS werkt goed voor grotere groepen en organisaties waar rechten vaak wijzigen.

Hiërarchische RLS met PATH

Hiërarchische RLS gebruik je wanneer iemand niet alleen zijn eigen gegevens mag zien, maar ook die van iedereen onder hem. Denk aan een teamleider die zijn teamleden mag zien, maar niet de teams van andere leidinggevenden. Of een regiomanager die alle provincies in zijn regio mag bekijken. Het model volgt de boomstructuur van je organisatie en geeft op basis daarvan toegang.

Wat heb je nodig in het model?

Je hebt een tabel zoals 'DimEmployee' met minstens:

• [EmployeeID]

• [ManagerID]

• [Email]

Daarmee kan je een hiërarchische lijn opbouwen. In Power BI maak je vervolgens een berekende kolom met PATH(). Die functie maakt een soort spoor van medewerker naar zijn managers of omgekeerd.

Voorbeeld:

Path = PATH('DimEmployee'[EmployeeID], 'DimEmployee'[ManagerID])

Gebruik de DAX PATH() functie in een calculated column. Nu heeft elke rij een volledig pad van boven naar beneden in de structuur.

Vervolgens maak je een RLS rol aan met deze filter:

VAR MeID =
    LOOKUPVALUE(
        'DimEmployee'[EmployeeID],
        'DimEmployee'[Email], USERPRINCIPALNAME()
    )
RETURN
PATHCONTAINS('DimEmployee'[Path], MeID)

Met deze DAX krijgt een gebruiker toegang tot zichzelf (zijn eigen EmployeeID) en iedereen waarvan zijn ID voorkomt in het pad. Dus je ziet je eigen rijen plus alles wat onder je hangt.

Stel dat je een verkoopafdeling hebt met drie niveaus:

• Sales Director

• Regiomanagers

• Verkopers

Een verkoper ziet enkel zijn eigen gegevens.

Een regiomanager ziet zichzelf én alle verkopers in zijn regio.

De Sales Director ziet het volledige team.

Je hoeft geen aparte rollen te maken voor elk niveau. Het pad bepaalt automatisch wie welke rijen krijgt.

Governance van Row Level Security

Een goed RLS-model werkt pas echt als je het makkelijk kan beheren. Hoe meer gebruikers en rollen je hebt, hoe belangrijker het wordt om alles overzichtelijk te houden. Hieronder vind je de meest praktische manieren om je RLS-structuur proper te organiseren en te controleren, zowel in Power BI als in Fabric.

Werk met één centrale security-tabel

Het maakt niet uit of je rechten op basis van regio, klant, filiaal of tenant beheert. Gebruik altijd één security-tabel per domein, of combineer alles in een bredere tabel zoals UserAccess.
Voorbeeldkolommen:

• [Email]

• [Sleutel] (bijv. Regio, Klant, Tenant, Filiaal)

• optioneel: [RoleType] of [AccessLevel]

Voordeel: je beheert rechten op één plek. Je hoeft nooit DAX of rollen aan te passen in het model. Je past gewoon de security-tabel aan en publiceert opnieuw.

Documenteer je rollen

In Power BI Desktop zie je alle rollen via Modeling → Manage roles. Leg die vast in een intern document of wiki. Beschrijf:

• welke tabellen gefilterd worden

• welke kolommen gebruikt worden

• welke DAX-logica erachter zit

• welke security-bron de tabel voedt

Bij grote modellen maakt dit het leven van beheerders veel makkelijker.

Exporteer en controleer RLS via XMLA

Via het XMLA-endpoint kan je alle rollen en DAX-filters uitlezen. Dat kan met PowerShell, SSMS of Tabular Editor.
Je kan bijvoorbeeld dagelijks een export draaien en opslaan in een Git-repo. Zo zie je elke wijziging en kan je RLS-drift opsporen.

Voorbeeldcontrole:

• rol zonder leden

• tabel zonder filter

• filter die TRUE() of leeg is

• externe domeinen in e-mailadressen

• dubbele of tegenstrijdige regels

Zo bouw je een basis voor audit en compliance.

Via XMLA kan je een RLS dashboard bouwen om de rechten op je verschillende datamodellen centraal op te volgen.

Gebruik Tabular Editor voor beheer

Met Tabular Editor kan je rollen sneller bekijken en aanpassen. Je ziet alle filters in één overzicht en kan DAX makkelijk kopiëren of herwerken. Je kan ook scripts maken om rollen te exporteren, na te kijken of automatisch te genereren.

Voordeel: je behandelt RLS meer als “code”, wat goed werkt bij grotere modellen.

Test altijd via View as role

In Power BI Desktop gebruik je View as om te testen hoe een rol zich gedraagt.
Test minstens drie scenario’s:

• gebruiker met één waarde

• gebruiker met meerdere waarden

• gebruiker die niet in de security-tabel zit

Bekijk telkens of alle gevoelige tabellen goed worden gefilterd en of de rijen kloppen. Voeg ook een testgebruiker toe die helemaal niets mag zien, zodat je zeker bent dat RLS geen data lekt.

Scheid rechtenbeheer van workspace-rechten

RLS werkt alleen zoals bedoeld wanneer gebruikers Viewer zijn.

Contributors, Members of Admins omzeilen RLS altijd. Documenteer dit duidelijk en zorg dat gebruikers de juiste rechten krijgen op workspaces en apps.

Automatiseer waar het kan

Met Power Automate, Azure Functions of Fabric pipelines kan je de security-tabel automatisch voeden vanuit een HR-systeem, CRM of Entra AD. Zo vermijd je handmatige fouten.

Combineer dat met een automatische refresh van je dataset, en je RLS is altijd up-to-date.

Zorg voor een fallback

De beste modellen hebben een fallback: een standaardrol of expliciete “geen toegang”-logica voor gebruikers die niet in de security-tabel staan. Zo behandelen rapporten die gevallen veilig, zonder onverwachte resultaten.

Testen en valideren van RLS

Een RLS-model moet je niet alleen configureren, maar ook bewijzen dat het goed werkt. Testen is dus even belangrijk als het bouwen zelf. Je wil zeker zijn dat gebruikers enkel zien wat ze mogen zien, ook wanneer ze verbinding maken via Excel, Analyze in Excel of rechtstreeks op het semantisch model in Fabric. Hieronder vind je de meest praktische manieren om RLS betrouwbaar te testen.

Test met “View as role” in Power BI Desktop

Dit is de snelste manier om te controleren of je filters juist zitten.

1. Ga naar Modeling → View as.

2. Kies de rol die je wil testen.

3. Bekijk of de rijen in je rapport kloppen.

4. Test ook gebruikers die niet voorkomen in de security-tabel.

Gebruik tijdens het testen een paar eenvoudige visuals:

• een kaart met COUNTROWS() van je belangrijkste facttabellen

• een tabel met alle toegestane waarden (regio’s, klanten, filialen)

• een measure die het e-mailadres toont:

Gebruiker = USERPRINCIPALNAME()

Zo zie je meteen welke filter actief is.

Test via echte accounts in Power BI Service

Desktop is handig, maar in de Service werkt USERPRINCIPALNAME() altijd correct. Daarom moet je de rollen ook testen met echte gebruikers of testaccounts.

• Publiceer het model

• Deel het rapport met een testgebruiker

• Geef die gebruiker Viewer-rechten

• Laat hem het rapport openen en bevestigen of de data klopt

Zo weet je zeker dat RLS ook werkt in dashboards, apps en gedeelde rapporten.

Test directe toegang tot het semantische model (bv via Excel)

Gebruikers kunnen in Excel of externe tools verbinden met je dataset. RLS moet ook daar actief blijven.
Test dus:

• Analyze in Excel

• Get Data → Power BI Dataset in Excel

• Query via Fabric semantisch model

Controleer of dezelfde aantallen en dezelfde toegestane rijen zichtbaar zijn. Als iemand via Excel meer ziet dan in Power BI, zit er een probleem in rollen of workspace-rechten.

Soms ziet de data er afgeschremd uit in een Power Bi rapport maar heeft een gebruiker achterliggend toch meer toegang tot de data dan je zou denken.

Test met XMLA-queries

Via het XMLA-endpoint kan je dezelfde test automatiseren. Dit is handig voor grotere modellen. Je stuurt een query uit die telt hoeveel rijen iemand ziet.

Voorbeeld:

EVALUATE
ROW(
    "User", USERPRINCIPALNAME(),
    "RijenDimKlant", COUNTROWS('DimKlant'),
    "RijenFactSales", COUNTROWS('FactSales')
)

Je voert deze query uit voor elke rol of gebruiker. Zo krijg je harde cijfers waarmee je kan bevestigen dat filters goed doorkomen.

Bij organisaties met een sterke nood aan data governance kan een automatisch test systeem via XMLA queries helpen om de compliance op een hoog niveau te houden zonder een al te zare last voor IT. Je kan dit best wel zo vroeg mogelijk in het ontwikkelproces beginnen implementeren zodat je niets vergeet te testen.

Test op gevoelige tabellen

Sommige tabellen zijn gevoeliger dan andere, zoals personeelsgegevens, klantenlijsten of financiële info. Controleer voor deze tabellen extra grondig:

• zijn alle rijen netjes beperkt?

• zijn er geen lege filters of onbedoeld brede filters?

• staan deze tabellen in de juiste relatie met de dimensies waarop RLS zit?

Een kleine fout kan hier snel tot datalekken leiden.

Combinatie RLS + OLS testen

Als je ook Object Level Security toepast, moet je beide samen testen.

• Kan een gebruiker een kolom zien die verborgen moest blijven?

• Kunnen gebruikers via Excel kolommen opvragen die niet zichtbaar mogen zijn?

• Is er overlap tussen rollen die onverwachte toegang geeft?

RLS en OLS zijn aparte lagen. Test ze altijd allebei.

Test gebruikers die buiten de security-tabel vallen

Elke RLS-setup moet duidelijk gedrag hebben voor “vergeten” gebruikers.
Test minstens:

• gebruiker wel in security-tabel → krijgt juiste subset

• gebruiker met meerdere rijen → krijgt gecombineerde subset

• gebruiker zonder match → moet niets of een lege dataset zien

Zo vermijd je verrassingen wanneer nieuwe collega’s of externe partners toegang krijgen.

RLS en Object Level Security (OLS)

Row Level Security en Object Level Security vullen elkaar mooi aan. RLS bepaalt welke rijen een gebruiker mag zien. OLS bepaalt welke kolommen of volledige tabellen zichtbaar zijn. Samen zorgen ze voor een veilige en duidelijke scheiding tussen verschillende gebruikersgroepen. RLS alone is vaak niet genoeg, zeker wanneer er persoonsgegevens of financiële gegevens in het model zitten.

Wat doet RLS?

RLS filtert de data binnen een tabel. Je beperkt dus de rijen op basis van een waarde zoals regio, klant, filiaal of medewerker. Een verkoper ziet alleen zijn eigen klanten. Een filiaalmanager ziet de cijfers van zijn winkel. De directie ziet alle rijen.
RLS werkt in DAX met filters zoals:

'DimRegio'[Regio] IN
CALCULATETABLE(
    VALUES('UserRegion'[Regio]),
    'UserRegion'[Email] = USERPRINCIPALNAME()
)

De filter bepaalt welke rijen overblijven zodra iemand het rapport opent.

Wat doet OLS?

OLS verbergt volledige objecten: kolommen of tabellen. Dat gebeurt niet met DAX, maar via de metadata van het model.
Enkele voorbeelden:

• kolom [Loon] enkel zichtbaar voor HR

• kolom [Email] verbergen voor externe partners

• volledige tabel DimPersoon alleen tonen aan de directie

Als een kolom verborgen is via OLS, dan kan die zelfs niet rechtstreeks opgevraagd worden via Excel, DAX Studio of het XMLA-endpoint. Dat is een belangrijke extra beveiligingslaag.

Wanneer gebruik je RLS?

Gebruik RLS wanneer gebruikers dezelfde kolommen mogen zien, maar niet dezelfde rijen. Bijvoorbeeld:

• verkopers met toegang tot hun regio

• klanten die enkel hun eigen data mogen bekijken

• werknemers die enkel hun teamrapporten zien

RLS is ideaal om data op te splitsen op basis van een sleutel zoals regio of klant.

Wanneer gebruik je OLS?

Gebruik OLS wanneer een deel van je data te gevoelig is om breed te tonen. Denk aan:

• loongegevens

• rijksregisternummer

• medische info

• persoonlijke adressen

• of kolommen die je liever intern houdt

Met OLS verberg je die kolommen volledig. Gebruikers weten zelfs niet dat ze bestaan.

Hoe werken RLS en OLS samen?

De sterke combinatie is als volgt:

• RLS bepaalt welke rijen zichtbaar zijn.

• OLS bepaalt welke kolommen überhaupt bestaan voor die rol.

Voorbeeld:
Een manager mag de rijen van zijn team zien, maar niet de kolom [Loon].
RLS filtert het team.
OLS verbergt de kolom.
Zo krijgt de manager alleen de info die hij echt nodig heeft.

Voorbeeld

Een KMO met tien teams wil één HR-rapport gebruiken voor alle medewerkers.

• HR ziet alles: alle rijen en alle kolommen.

• Teamleiders zien alleen rijen van hun team (RLS).

• Teamleiders mogen geen loongegevens zien, dus [Loon] wordt verborgen via OLS.

• Externe consultants mogen enkel anonieme gegevens zien. Voor hen worden kolommen zoals [Naam] en [Email] verborgen via OLS.

Resultaat: één dataset, drie types gebruikers, allemaal veilig.

Best practices voor beheer van RLS

Een goed RLS-model blijft alleen betrouwbaar als je het slim opbouwt en beheert. Hieronder vind je praktische richtlijnen die ervoor zorgen dat je RLS duidelijk, stabiel en eenvoudig te onderhouden blijft. Ze werken voor zowel Power BI als Fabric en passen bij kleine en grote organisaties.

Gebruik Entra Security Groups

In plaats van individuele e-mailadressen te beheren, kan je beter werken met Entra Security Groups. Je maakt per groep een duidelijke naam, zoals RLS_Sales_Vlaanderen of RLS_KlantA.
Voordelen:

• beheer gebeurt in Entra, niet in Power BI of Fabric

• nieuwe gebruikers krijgen automatisch de juiste rechten

• minder risico op fouten
  Let op dat je echte Security Groups gebruikt, geen Microsoft 365-groepen met mailbox.

Bouw RLS dynamisch met een security-tabel

Gebruik een tabel zoals UserAccess, UserRegion of TenantMap om rechten te bepalen. Dat werkt goed voor scenario’s waar gebruikers vaak veranderen of waar je verschillende sleutels tegelijk wil beheren.
Deze aanpak maakt RLS flexibel: je past enkel de tabel aan en niet het model zelf.

Hou RLS simpel door te filteren op dimensies

Plaats RLS altijd op een dimensietabel, niet op facttabellen. De relaties naar de feiten zorgen voor de rest van de filtering. Dit maakt je DAX eenvoudiger en vermindert het risico op datalekken.
Vermijd bidirectionele relaties, want die kunnen onverwachte filterpaden creëren..

Beperk workspace-rechten

RLS werkt alleen correct wanneer gebruikers “Viewer” zijn in een workspace of via een app.

• Viewer: RLS actief

• Member/Contributor: RLS genegeerd
  Gebruik dus apps om rapporten te delen met eindgebruikers en vermijd brede rechten op workspaces.

Breng RLS mee in je DevOps-pijplijn

Wanneer je CI/CD gebruikt, voeg je best checks toe:

• controleer of elke RLS-rol minstens één filter heeft

• controleer of kritieke tabellen een filter of OLS-regel hebben

• meld rollen zonder leden of security-tabel met ontbrekende waarden
  Zo vermijd je dat verkeerde versies in productie komen.

Vermijd ingewikkelde DAX in je RLS

Hou de RLS-logic zo eenvoudig mogelijk. Gebruik geen zware berekeningen of teksttransformaties in je filter.
Zoiets vermijd je best:

LEFT(UPPER(TRIM('DimRegio'[Regio])), 5) IN ...

Werk liever met opgeschoonde kolommen of met een aangepaste tabel in Power Query.
Eenvoudige, rechtstreekse vergelijkingen zijn sneller en veiliger.

Zorg voor duidelijke fallback-regels

Nieuwe medewerkers, consultants of externe partners staan soms nog niet in je security-tabel. Test wat er dan gebeurt.
Beste praktijk: laat zulke gebruikers gewoon geen rijen zien.

Aandachtspunten

Naast de basisprincipes zijn er enkele minder bekende punten die vaak pas naar boven komen in grotere of gevoelige omgevingen. Deze aandachtspunten helpen je om je RLS-model robuust, betrouwbaar en toekomstbestendig te maken. Ze zijn vooral nuttig voor scenario’s waar veel gebruikers, complexe datastromen of hoge beveiligingseisen spelen.

RLS wordt omzeild door eigenaars en beheerders

Dataset-eigenaars, workspace-admins en gebruikers met bewerkingsrechten zien altijd alle data. Zij vallen buiten RLS. Zorg er dus voor dat eindgebruikers enkel Viewer zijn, en dat beheerders beperkt blijven tot wie het echt nodig heeft. Documenteer dit duidelijk zodat er geen verwarring ontstaat.

Let op bij samengestelde modellen

Bij Composite Models geldt RLS alleen voor de geïmporteerde tabellen. Tabelllen die via DirectQuery komen, moeten hun beveiliging uit de bron halen. Als je zowel RLS in Power BI als in de databron gebruikt, moet je controleren dat beide lagen op elkaar aansluiten.

Shared datasets gebruiken dezelfde RLS

Wanneer meerdere rapporten dezelfde dataset gebruiken, neemt elk rapport automatisch de RLS over. Dit is handig, maar vraagt wel discipline. Als je een belanrijke wijziging in RLS maakt, moet je ook controleren hoe dat invloed heeft op alle rapporten die aan dezelfde dataset hangen.

Prestaties kunnen verschillen per rol

Sommige rollen kunnen trager zijn, zeker wanneer ze veel toegangsrechten hebben. Gebruik DAX Studio om te zien welke rollen zware query’s veroorzaken.
Tips:

• Vermijd functies die kolommen bewerken (zoals UPPER of TRIM) in de RLS-filter

• Filter altijd op de sleutelkolom van een dimensie

• Hou berekeningen zo licht mogelijk. Als transformaties nodig zijn voer ze dan uit tijdens de data load.

Extra beveiliging bij de bron

Voor erg gevoelige datasets kan je in de bron zelf extra beperkingen toevoegen, zoals data masking of row filtering in SQL. Zo heb je twee lagen beveiliging: één in Power BI en één in de databron. Dit is vooral nuttig wanneer je rapporten bouwt die extern gedeeld worden.

RLS in DevOps-pijplijnen

Behandel RLS als code. In een DevOps-pijplijn kan je scripts laten draaien die controleren of alle RLS-rollen bestaan, of de filters niet leeg zijn en of gevoelige tabellen een juiste regel hebben. Zo vermijd je fouten bij automatische deploys.

Bouw een klein intern “RLS logboek”

Hou een eenvoudig overzicht bij van wijzigingen in RLS:

• welke rollen bestaan

• welke filters eraan gekoppeld zijn

• welke tabellen gevoelig zijn

• welke security-tabel als bron gebruikt wordt
  Zo voorkom je dat kennis alleen in het hoofd van één beheerder zit.

Denk na over toekomstig gebruik

Bij uitbreidingen van je model moet je RLS mee laten evolueren. Nieuwe tabellen, relaties of dimensies kunnen invloed hebben op bestaande RLS-filters. Maak RLS daarom een onderdeel van je standaard reviewproces wanneer je het datamodel uitbreidt.

Uitgewerkt voorbeeld

Een concreet voorbeeld maakt snel duidelijk hoe RLS er in de praktijk uitziet. Denk aan een KMO met meerdere vestigingen. Het bedrijf wil één centraal Power BI-rapport voor verkoop, voorraad en personeelsinfo. De data zit in één semantisch model in Fabric. Toch mogen niet alle gebruikers alles zien. Elke filiaalmanager mag enkel zijn eigen winkel zien, accountmanagers mogen enkel hun eigen klanten zien en het hoofdkantoor moet het volledige overzicht behouden.

Opzet van het model

Het bedrijf werkt met drie belangrijke dimensies:

• DimStore met alle winkels en hun StoreID

• DimCustomer met klanten per regio

• DimEmployee met teamstructuur en managerlijnen

Daarnaast is er één security-tabel UserAccess die per gebruiker de toegangsrechten bevat. Die tabel wordt elke nacht automatisch gevuld vanuit het HR-systeem en bevat kolommen zoals:

• [Email]

• [StoreID]

• [CustomerID]

• [RoleType]

Een gebruiker kan meerdere rijen hebben. Zo kan een regiomanager meerdere winkels krijgen en een key account manager meerdere klanten.

Dynamische filter per winkel

Voor de filiaalmanagers wordt RLS toegepast op de tabel DimStore. De DAX-filter bepaalt welke winkels zichtbaar zijn:

'DimStore'[StoreID] IN
CALCULATETABLE(
    VALUES('UserAccess'[StoreID]),
    'UserAccess'[Email] = USERPRINCIPALNAME()
)

Een filiaalmanager van Brugge ziet dus alleen StoreID 103, terwijl een regiomanager misschien 103, 104 en 105 tegelijk ziet.

Filter op klantniveau

De accountmanagers krijgen toegang via dezelfde aanpak, maar nu op DimCustomer:

'DimCustomer'[CustomerID] IN
CALCULATETABLE(
    VALUES('UserAccess'[CustomerID]),
    'UserAccess'[Email] = USERPRINCIPALNAME()
)

Het bedrijf hoeft niet meerdere modellen te maken. Alles gebeurt in één dataset, dankzij dynamische filtering.

Hiërarchie voor het HR-team

De HR-afdeling gebruikt een hiërarchische structuur. Teamleiders mogen hun eigen team zien en alles daaronder. Hiervoor wordt een berekende kolom Path gebruikt in DimEmployee. De rol bevat:

VAR MeID =
    LOOKUPVALUE(
        'DimEmployee'[EmployeeID],
        'DimEmployee'[Email], USERPRINCIPALNAME()
    )
RETURN
PATHCONTAINS('DimEmployee'[Path], MeID)

Zo krijgt elk teamlid een helder en afgebakend zicht op zijn medewerkers.

OLS voor gevoelige info

Loongegevens, rijksregisternummers en privé-adressen worden volledig beschermd via Object Level Security. Enkel HR ziet deze kolommen. Teamleiders en managers zien dezelfde rijen maar zonder deze gevoelige velden. Zo blijft het rapport veilig, terwijl het model centraal blijft.

Wat zien de eindgebruikers

Eindgebruikers openen hun Power BI-app. Ze zien automatisch enkel de data die bij hen hoort. Een filiaalmanager merkt niet eens dat er andere winkels bestaan. De directie ziet uiteraard alles. HR ziet alles, maar met extra kolommen zichtbaar. Accountmanagers hebben alleen zicht op hun eigen portfolio.

Wanneer iemand intern van rol verandert, past HR enkel de UserAccess-tabel aan. Bij de volgende refresh is de RLS in Power BI en Fabric meteen juist. Geen extra rapporten. Geen dubbel werk. Geen risico op fouten.