Dynamic Row-Level Security implementeren in Power BI en Microsoft Fabric: architectuur, DAX-patronen en governance op enterprise-niveau

By Mirko Peters · 2025-11-21 · Updated 2025-11-26

Implementeer dynamische row-level security in Power BI en Microsoft Fabric om de toegang van gebruikers tot data te beheersen, compliance te waarborgen en mee te bewegen met veranderingen in de organisatie.

Automatically translated with AI from the original post. Read the English original

Zie dynamische Row-Level Security als een systeem dat kan veranderen. Het groeit mee en verandert met je organisatie. Datamodelontwerp, DAX-expressies, gebruikersidentiteit en governance bepalen samen hoe de beveiliging werkt in Power BI en Microsoft Fabric. Als je het goed inricht, bepaal je wie bepaalde data mag zien.

Belangrijkste punten

• Dynamische Row-Level Security past zich aan aan de behoeften van je bedrijf. Het laat je bepalen wie bepaalde data mag zien. Dat gebeurt door de identiteit van elke gebruiker te controleren.

• Gebruik USERPRINCIPALNAME() voor beveiliging in de cloud. Deze functie zorgt ervoor dat gebruikers alleen hun eigen data zien. Zo blijft je informatie veilig.

• Controleer je beveiligingsinstellingen en gebruikersgroepen regelmatig. Zo voorkom je dat mensen data zien die ze niet mogen zien. Dit helpt om je data veilig te houden.

• Maak duidelijke beveiligingstabellen om machtigingen van gebruikers te beheren. Zo houd je grip op wie wat ziet, ook naarmate je bedrijf groeit.

• Test je beveiligingsregels in de cloud met echte gebruikers. Zo weet je zeker dat je data veilig is. Gebruikers zien alleen wat ze mogen zien.

Row-Level Security-systemen opnieuw bekeken

Beveiliging als modelgedreven systeem

Row-level security is een systeem dat verschillende onderdelen van je analyseplatform met elkaar verbindt. Wanneer je je datamodel maakt, begin je met het bouwen van de databeveiliging. De manier waarop je tabellen inricht, ze koppelt en rollen maakt, bepaalt hoe mensen data zien. Als je bedrijf groeit of nieuwe teams erbij komen, moet je je beveiligingsregels bijwerken. Row-level security is niet iets dat je één keer instelt en dan vergeet. Het verandert mee met je bedrijf en met nieuwe behoeften.

Tip: Controleer je datamodel regelmatig. Een goed model maakt beveiliging eenvoudiger en helpt je fouten te voorkomen.

Je model moet duidelijke koppelingen en speciale beveiligingstabellen bevatten. Zo bepaal je wie bepaalde data ziet en blijven privégegevens beschermd. Dynamic row-level security kan wat gebruikers zien koppelen aan hun groep of functie in Fabric. Zo kun je machtigingen snel aanpassen wanneer je bedrijf verandert.

Statische versus dynamische Row-Level Security

Er zijn twee hoofdmanieren om databeveiliging in te richten: statische en dynamische row-level security. Statische beveiliging werkt met vaste regels. Je maakt rollen en filters per groep. Dit is geschikt voor kleine teams of wanneer de toegang weinig verandert. Dynamische row-level security gebruikt wie er is ingelogd en koppeltabellen. Het controleert de gebruiker en past direct aan welke data die ziet. Dit is beter voor grote organisaties met veel gebruikers en wisselende regels.

Hier is een tabel met de verschillen:

Dynamische row-level security geeft je meer mogelijkheden om toegang te beheersen. Het gebruikt zaken als USERPRINCIPALNAME() en koppeltabellen om gebruikers aan de juiste data te koppelen. Statische beveiliging is eenvoudig, maar werkt niet goed als je bedrijf groeit of sterk verandert.

• Statische row-level security gebruikt vaste regels om data te beperken.

• Dynamische row-level security verandert wat gebruikers zien op basis van wie ze zijn.

• Dynamische beveiliging is het beste voor grote organisaties met veel regels.

Kies om je data veilig te houden de aanpak die het beste bij je behoeften past. Goede planning en een sterk model helpen je privégegevens te beschermen en je analyses veilig te houden.

Dynamische Row-Level Security-patronen in Fabric

DAX-functies: USERPRINCIPALNAME() versus USERNAME()

Het is belangrijk om te weten hoe identiteit werkt in Fabric. Twee hoofdfuncties helpen bij het inrichten van row-level security. Dit zijn USERPRINCIPALNAME() en USERNAME(). Beide functies controleren wie het rapport bekijkt. USERPRINCIPALNAME() geeft het e-mailadres van de gebruiker uit de cloud. USERNAME() geeft vaak een lokale accountnaam, vooral in Power BI Desktop. Als je USERNAME() in de cloud gebruikt, werkt het mogelijk niet goed. Dat kan je data minder veilig maken.

Tip: Kies altijd USERPRINCIPALNAME() voor dynamische row-level security in Fabric. Deze functie komt overeen met het cloud-e-mailadres van de gebruiker en beveiligt je data.

Als je de verkeerde functie gebruikt, kunnen gebruikers gegevens zien die ze niet mogen zien. Test je beveiliging in de cloud, niet alleen in Desktop.

Veilige DAX-patronen en anti-patronen

Je wilt dat je data veilig blijft. Je hebt sterke DAX-patronen nodig voor dynamische row-level security. De beste manier is het gebruik van mappingtabellen en dynamische regels. Zo bepaal je wie wat mag zien.

• Rijfilters beperken wat gebruikers kunnen zien. Je kunt data blokkeren op regio, afdeling of account.

• Kolommaskers maken het mogelijk om gegevens te verbergen of aan te passen op basis van wie de gebruiker is.

Een goed DAX-patroon gebruikt een opzoeking om gebruikers aan hun groep te koppelen. Dit werkt goed bij bedrijven met veel groepen. Hier is een goed voorbeeld:

Organizations[Id] = LOOKUPVALUE(
    AspNetUsers[OrganizationId],
    AspNetUsers[Email],
    USERPRINCIPALNAME()
)

Dit patroon controleert het e-mailadres van de gebruiker en zoekt de bijbehorende groep op. Zo toon je alleen de juiste data. Deze aanpak is beter dan alleen e-mailadressen vergelijken. Hij werkt goed naarmate je bedrijf groeit en beveiligt je data.

Let op: zet geen e-mailadressen hardcoded in je model en gebruik geen berekende kolommen voor toegang. Deze methoden kunnen fout gaan als gebruikers wijzigen of je bedrijf groeit.

Sommige slechte patronen kunnen datalekken veroorzaken:

• USERNAME() gebruiken in de cloud.

• E-mailadressen of domeinen van gebruikers hardcoden.

• Beveiligingslogica in berekende kolommen plaatsen.

Gebruik altijd dynamische regels en mappingtabellen. Zo blijft je datamodel eenvoudig en je data veilig.

Hiërarchieën en de PATH()-functie

Soms heb je beveiliging nodig voor managers, teams of afdelingen. Hiërarchieën helpen je hierbij. De PATH()-functie in DAX laat je oudergerichte koppelingen bouwen. Zo bepaal je wie op elk niveau wat ziet.

Je kunt bijvoorbeeld een tabel maken met medewerker- en manager-ID's. PATH() bouwt een keten van elke medewerker naar hun leidinggevende. Vervolgens gebruik je DAX om de data per niveau te filteren.

PATH(Employee[EmployeeID], Employee[ManagerID])

Deze functie helpt je om dynamische row-level security op te zetten voor grote bedrijven. Managers kunnen de data van hun team zien. Je kunt ook voorkomen dat gewone medewerkers te veel zien.

Tip: Gebruik PATH() voor beveiliging met hiërarchieën. Dit maakt je datamodel flexibel en houdt je data veilig.

Je kunt rijfilters, kolommaskers en hiërarchiefuncties samen gebruiken. Zo bescherm je privégegevens en beheer je de toegang naarmate je bedrijf groeit.

Rol- en relatiearchitectuur

Ontwerp van beveiligingstabellen

Je moet beveiligingstabellen maken voor dynamische row-level security. Deze tabellen laten zien welke gebruikers welke data mogen zien. Gebruik kolommen voor e-mailadres, groep en toegangsniveau. Zo blijft je data beveiligd naarmate je bedrijf groeit.
Houd bij het maken van rollen strikte en open rollen gescheiden. Als één rol iemand alles laat zien, werken andere rollen met row-level security mogelijk niet goed. Voorkom dat rollen met elkaar conflicteren, zodat je data beveiligd blijft.

• Maak beveiligingstabellen met duidelijke kolommen voor gebruiker en machtigingen.

• Houd rollen gescheiden zodat ze elkaar niet overlappen en problemen veroorzaken.

• Controleer je beveiligingstabellen regelmatig om wijzigingen bij te houden.

Relaties in het datamodel

Hoe je je datamodel opbouwt, bepaalt hoe je toegang beheert. Gebruik eenrichtingsrelaties tussen tabellen. Dit maakt je model eenvoudig en helpt fouten te voorkomen.
Het is beter om speciale beveiligingstabellen te gebruiken dan machtigingen in feitentabellen op te nemen. Je kunt je beveiligingstabel koppelen aan andere tabellen, zoals afdeling of regio. Zo kun je data per gebruiker of groep filteren.

Tip: Gebruik brugtabellen om gebruikers aan data te koppelen. Dit helpt dynamische row-level security te laten werken en houdt je data veilig.

Rolgranulariteit: kleine versus grote rollen

Je moet bepalen hoe gedetailleerd je rollen moeten zijn. Kleine rollen geven je meer controle. Je kunt toegang geven per functie of groep. Grote rollen dekken meer mensen, maar kunnen riskant zijn als er dingen veranderen.
Controleer regelmatig wie welke rol heeft. Zo blijft je data veilig en kun je indien nodig wijzigingen doorvoeren.
Kies voor kleine rollen voor meer controle en eenvoudige updates. Grote rollen kunnen werken voor eenvoudige groepen, maar ze kunnen problemen veroorzaken in grote organisaties.

Gebruikers- en groepstoewijzingen in Fabric

Azure AD-groepen versus individuele gebruikers

Je geeft toegang in Fabric door gebruikers in Azure AD-groepen te plaatsen. Zo kun je de data van veel mensen tegelijk beheren. Het is veiliger om met groepen te werken dan elke persoon afzonderlijk toe te voegen. Groepen helpen je om je systeem met minder werk te beheren. Wanneer je team verandert, kun je groepen snel bijwerken. Door groepen aan rollen te koppelen, wordt datamodellering eenvoudiger. Je regels voor row-level security blijven duidelijk en eenvoudig.

Tip: Gebruik Azure AD-groepen voor toegangsbeheer. Dit helpt je om minder fouten te maken en bespaart tijd.

Overlappende groepen en schaduwtoegang

Let op overlappende groepen. Soms zit een gebruiker in meer dan één groep. Hierdoor kan die gebruiker data zien die hij of zij niet mag zien. Schaduwtoegang ontstaat wanneer deze fout gebruikers extra data laat zien. Controleer groepslijsten regelmatig om dit te voorkomen. Gebruik tabellen om bij te houden welke gebruikers in welke groep zitten. Goede datamodellering helpt je problemen vroeg te ontdekken. Verwijder gebruikers uit groepen die ze niet meer nodig hebben om data veilig te houden.

Let op: Schaduwtoegang kan privégegevens tonen. Los groepsoverlappingen op om je systeem veilig te houden.

Geplande toegangscontroles

Je moet regelmatig toegangscontroles plannen. Controleer af en toe wie in elke groep zit. Vraag groepseigenaars om aan te geven wie toegang zou moeten hebben. Zo blijft je dynamische row-level security werken terwijl je organisatie groeit. Gebruik Fabric-tools om deze controles te ondersteunen. Verwijder oude gebruikers om je data veiliger te maken. Zo blijft je analysesysteem overzichtelijk en veilig. Maak toegangscontroles een vast onderdeel van je business intelligence-werk.

• Kies data om alle groepen te controleren.

• Gebruik Fabric-tools om groepen te controleren.

• Vraag eigenaars om te bevestigen wie in elke groep zit.

Waarschuwing: Regelmatige controles helpen je fouten te vinden voordat ze problemen veroorzaken.

Identiteitsresolutie: Desktop versus Fabric

Identiteitsfuncties en verschillen in de cloud

Het is belangrijk om te weten hoe identiteit werkt in Power BI Desktop en Microsoft Fabric. In Power BI Desktop toont USERNAME() meestal de naam van je computer. In Microsoft Fabric geeft USERPRINCIPALNAME() je cloud-e-mailadres. Dit verschil is belangrijk om data veilig te houden. Als je USERNAME() in de cloud gebruikt, kunnen de verkeerde mensen data zien. Gebruik voor cloudrapporten altijd USERPRINCIPALNAME(). Zo blijft je data veilig en sluit je aan bij het identiteitssysteem van je organisatie.

Tip: Test je regels voor row-level security in de cloud. Tests op de desktop tonen geen echte toegang van gebruikers.

Dataset-eigenaar en tenantinstellingen

Je moet weten wie eigenaar is van je dataset. De eigenaar kan de vernieuwingsinstellingen wijzigen en beïnvloedt wie data ziet. Als je de eigenaar wijzigt, kun je wijzigen wie privégegevens kan zien. Tenantinstellingen zijn ook belangrijk. Deze instellingen bepalen hoe identiteiten in je organisatie werken. Controleer de tenantinstellingen voordat je rapporten publiceert. Zorg dat je datamodel aansluit op de beveiligingsregels van je organisatie.

Veelvoorkomende oorzaken van RLS-lekken

Je kunt de controle over row-level security verliezen als je niet in de cloud test. Soms zien gebruikers meer data dan ze zouden mogen zien. Dit kan gebeuren als je de verkeerde identiteitsfunctie gebruikt of vergeet groepslidmaatschappen bij te werken. Lekken kunnen ook ontstaan als je je datamodel wijzigt zonder de beveiligingstabellen te controleren. Controleer je instellingen voor gegevensbeveiliging altijd na wijzigingen. Gebruik cloudtests en regelmatige audits om problemen vroeg te vinden.

Waarschuwing: Datalekken kunnen privégegevens tonen. Controleer je instellingen regelmatig om je organisatie veilig te houden.

Testen, auditen en governance

RLS-testen in de cloud

Je moet row-level security in de cloud testen. Zo weet je zeker dat je gegevens veilig zijn voor echte gebruikers. De functie ‘View As’ in Desktop toont alleen een voorbeeld. Die laat niet zien hoe de regels werken in Microsoft Fabric. Test na het publiceren van je rapport met echte gebruikers en groepen. Zo zie je wat elke persoon mag bekijken. Gebruik testaccounts om te controleren of gebruikers alleen hun eigen gegevens zien. Test altijd opnieuw na een wijziging in rollen of een update van je model. Testen in de cloud helpt je problemen op te sporen voordat ze je bedrijf schade toebrengen.

Tip: Test altijd met echte gebruikers in de cloud, niet alleen in Desktop. Zo blijft de beveiliging van je gegevens sterk.

Automatisering voor audits en reviews

Je kunt automatisering gebruiken om audits en reviews in Fabric eenvoudiger te maken. Automatisering controleert op schema de machtigingen van werkruimten, de gegevensstromen en de vertrouwelijkheidslabels. Microsoft Purview biedt dashboards om regels over je platform heen te volgen. Met activiteitenlogboeken en Admin-API’s kun je problemen met compliance opsporen. Automatisering helpt je problemen vroeg te vinden en bespaart tijd. Auditors kunnen het volledige pad van gevoelige kolommen zien, van begin tot rapport. Zo verlopen reviews sneller en nauwkeuriger. Automatisering maakt het ook makkelijker en goedkoper om regels zoals de AVG en HIPAA na te leven.

• Stel automatische controles voor machtigingen en gegevensstromen in.

• Gebruik dashboards om te letten op wijzigingen in beveiligingsregels.

• Bekijk activiteitenlogboeken om snel problemen te vinden.

Documentatie en wijzigingsbeheer

Je hebt goede administratie nodig om je beveiligingssysteem overzichtelijk te houden. Leg je beveiligingsregels, groepslijsten en wijzigingen in rollen vast. Werk je notities bij wanneer je het model aanpast of nieuwe gebruikers toevoegt. Duidelijke administratie helpt je bij te houden wie welke gegevens mag zien. Ook helpt ze nieuwe teamleden om je systeem te leren kennen. Wijzigingsbeheer betekent dat je updates controleert en goedkeurt voordat ze live gaan. Zo blijft je row-level security veilig terwijl je bedrijf groeit.

Let op: houd je administratie up-to-date. Zo beschermt je je gegevens en kun je problemen snel oplossen.

Row-level security kun je het beste zien als iets dat meegroeit met je gegevens en je bedrijf. Een sterke opzet helpt om privégegevens veilig te houden. Goede DAX-patronen en een goed beheer van gebruikersidentiteiten beschermen je gegevens. Door je beveiliging te controleren en wijzigingen vast te leggen, zie je problemen vroeg. Als je vooruitdenkt, bepaal je wie gegevens ziet en blijven je analyses veilig.

• Controleer je beveiligingsopzet regelmatig.

• Gebruik wijzigende regels om gegevens beter te beschermen.

• Zet privacy altijd voorop.

Veelgestelde vragen

Wat is dynamische row-level security in Power BI en Fabric?

Dynamische row-level security bepaalt welke gegevens iemand ziet op basis van wie het rapport bekijkt. Je gebruikt DAX-functies en koppeltabellen om gebruikers aan de juiste gegevens te koppelen.

Waarom moet je USERPRINCIPALNAME() gebruiken in plaats van USERNAME()?

USERPRINCIPALNAME() geeft het e-mailadres van de gebruiker in de cloud. Dat werkt het best in Power BI en Fabric. USERNAME() kan een lokale naam tonen, wat in de cloud tot beveiligingsproblemen kan leiden.

Hoe helpen Azure AD-groepen bij de beveiliging?

Met Azure AD-groepen beheer je de toegang van veel gebruikers tegelijk. Je voegt gebruikers toe aan groepen en wijst rollen toe. Zo is je beveiligingsopzet eenvoudiger en veiliger.

Wat is een beveiligingstabel en waarom heb je die nodig?

Een beveiligingstabel somt gebruikers, groepen en machtigingen op. Je gebruikt haar om te bepalen wie bepaalde gegevens mag zien. Zo houd je gegevens veilig terwijl je bedrijf groeit.

Hoe vaak moet je row-level security in de cloud testen?

Je moet row-level security testen elke keer dat je rollen, groepen of je datamodel wijzigt. Testen in de cloud laat zien wat echte gebruikers kunnen zien en helpt je problemen vroeg te vinden.