Delen via

Richtlijnen voor beveiliging op rijniveau (RLS) in Power BI Desktop

  • Artikel

Dit artikel is bedoeld voor u als gegevensmodeller die werkt met Power BI Desktop. Hierin worden goede ontwerpprocedures beschreven voor het afdwingen van beveiliging op rijniveau (RLS) in uw gegevensmodellen.

Het is belangrijk om inzicht te hebben in tabelrijen met RLS-filters. Ze kunnen niet worden geconfigureerd om de toegang tot modelobjecten, waaronder tabellen, kolommen of metingen, te beperken.

Notitie

In dit artikel wordt geen RLS beschreven of hoe u dit instelt. Zie Gegevenstoegang beperken met beveiliging op rijniveau (RLS) voor Power BI Desktop voor meer informatie.

Het heeft ook geen betrekking op het afdwingen van beveiliging op rijniveau in liveverbindingen met extern gehoste modellen met Azure Analysis Services of SQL Server Analysis Services. In deze gevallen wordt beveiliging op rijniveau afgedwongen door Analysis Services. Wanneer Power BI verbinding maakt met eenmalige aanmelding (SSO), dwingt Analysis Services RLS af (tenzij het account beheerdersbevoegdheden heeft).

Rollen maken

Het is mogelijk om meerdere rollen te maken. Wanneer u de machtigingsbehoeften voor één rapportgebruiker overweegt, streeft u ernaar om één rol te maken die al deze machtigingen verleent, in plaats van een ontwerp waarbij een rapportgebruiker lid wordt van meerdere rollen. Dit komt doordat een rapportgebruiker kan worden toegewezen aan meerdere rollen, rechtstreeks met behulp van hun gebruikersaccount of indirect door lidmaatschap van een beveiligingsgroep. Meerdere roltoewijzingen kunnen leiden tot onverwachte resultaten.

Wanneer een rapportgebruiker is toegewezen aan meerdere rollen, worden RLS-filters additief. Dit betekent dat rapportgebruikers tabelrijen kunnen zien die de samenvoeging van deze filters vertegenwoordigen. Bovendien is het in sommige scenario's niet mogelijk om te garanderen dat een rapportgebruiker geen rijen in een tabel ziet. In tegenstelling tot machtigingen die zijn toegepast op SQL Server-databaseobjecten (en andere machtigingsmodellen), is het principe 'eenmaal geweigerd altijd geweigerd' niet van toepassing.

Overweeg een model met twee rollen: De eerste rol, werknemers, beperkt de toegang tot alle tabelrijen Salarisadministratie met behulp van de volgende regelexpressie:

FALSE()

Notitie

Een regel retourneert geen tabelrijen wanneer de expressie resulteert in FALSE.

Een tweede rol, managers genoemd, biedt echter toegang tot alle tabelrijen Salarisadministratie met behulp van de volgende regelexpressie:

TRUE()

Let op: Als een rapportgebruiker aan beide rollen is toegewezen, worden alle tabelrijen Salarisadministratie weergegeven.

Beveiliging op rijniveau optimaliseren

Beveiliging op rijniveau werkt door automatisch filters toe te passen op elke DAX-query en deze filters kunnen een negatieve invloed hebben op de queryprestaties. Efficiënte beveiliging op rijniveau komt dus neer op een goed modelontwerp. Het is belangrijk om de richtlijnen voor het ontwerpen van modellen te volgen, zoals beschreven in de volgende artikelen:

Over het algemeen is het vaak efficiënter om RLS-filters af te dwingen op dimensietabellen en niet op feitentabellen. En vertrouw op goed ontworpen relaties om ervoor te zorgen dat RLS-filters worden doorgegeven aan andere modeltabellen. RLS-filters worden alleen doorgegeven via actieve relaties. Vermijd daarom het gebruik van de DAX-functie LOOKUPVALUE wanneer modelrelaties hetzelfde resultaat kunnen bereiken.

Wanneer RLS-filters worden afgedwongen voor DirectQuery-tabellen en er relaties zijn met andere DirectQuery-tabellen, moet u ervoor zorgen dat u de brondatabase optimaliseert. Het kan betrekking hebben op het ontwerpen van de juiste indexen of het gebruik van persistente berekende kolommen. Zie Richtlijnen voor DirectQuery-modellen in Power BI Desktop voor meer informatie.

RLS-impact meten

Het is mogelijk om de prestatie-impact van RLS-filters in Power BI Desktop te meten met behulp van Performance Analyzer. Bepaal eerst de duur van visuele query's voor rapporten wanneer beveiliging op rijniveau niet wordt afgedwongen. Gebruik vervolgens de opdracht Weergeven als op het linttabblad Modelleren om beveiliging op rijniveau af te dwingen en queryduur te bepalen en te vergelijken.

Roltoewijzingen configureren

Zodra het is gepubliceerd naar Power BI, moet u leden toewijzen aan semantische modelrollen. Alleen semantische modeleigenaren of werkruimtebeheerders kunnen leden toevoegen aan rollen. Zie beveiliging op rijniveau (RLS) met Power BI (Beveiliging op uw model beheren) voor meer informatie.

Leden kunnen gebruikersaccounts, beveiligingsgroepen, distributiegroepen of groepen met e-mail zijn. Waar mogelijk raden we u aan beveiligingsgroepen toe te wijzen aan semantische modelrollen. Het omvat het beheren van lidmaatschappen van beveiligingsgroepen in Microsoft Entra-id. Mogelijk wordt de taak gedelegeerd aan uw netwerkbeheerders.

Rollen valideren

Test elke rol om ervoor te zorgen dat het model correct wordt gefilterd. U kunt dit eenvoudig doen met behulp van de opdracht Weergeven als op het linttabblad Modelleren .

Wanneer het model dynamische regels heeft met de DAX-functie USERNAME , moet u testen op verwachte en onverwachte waarden. Bij het insluiten van Power BI-inhoud, met name met behulp van het insluiten voor uw klantenscenario , kan app-logica elke waarde doorgeven als een effectieve gebruikersnaam voor identiteiten. Zorg er indien mogelijk voor dat onbedoelde of schadelijke waarden leiden tot filters die geen rijen retourneren.

Bekijk een voorbeeld van het gebruik van Power BI Embedded, waarbij de app de taakrol van de gebruiker doorgeeft als de effectieve gebruikersnaam: Het is 'Manager' of 'Worker'. Managers kunnen alle rijen zien, maar werkrollen kunnen alleen rijen zien waarin de kolomwaarde Type intern is.

De volgende regelexpressie is gedefinieerd:

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    TRUE()
)

Het probleem met deze regelexpressie is dat alle waarden, met uitzondering van 'Worker', alle tabelrijen retourneren. Een onbedoelde waarde, zoals 'Wrker', retourneert dus onbedoeld alle tabelrijen. Daarom is het veiliger om een expressie te schrijven die voor elke verwachte waarde test. In de volgende verbeterde regelexpressie resulteert een onverwachte waarde in de tabel die geen rijen retourneert.

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    IF(
        USERNAME() = "Manager",
        TRUE(),
        FALSE()
    )
)

Gedeeltelijke beveiliging op rijniveau ontwerpen

Soms hebben berekeningen waarden nodig die niet worden beperkt door RLS-filters. Een rapport moet bijvoorbeeld een verhouding weergeven van de omzet die is verdiend voor de verkoopregio van de rapportgebruiker ten opzichte van alle verdiende omzet.

Hoewel het niet mogelijk is dat een DAX-expressie RLS overschrijft, kan het zelfs niet bepalen of RLS wordt afgedwongen. U kunt een samenvattingsmodeltabel gebruiken. De overzichtsmodeltabel wordt opgevraagd om de omzet voor alle regio's op te halen en deze is niet beperkt door RLS-filters.

Laten we eens kijken hoe u deze ontwerpvereiste kunt implementeren. Overweeg eerst het volgende modelontwerp:

Er wordt een afbeelding van een modeldiagram weergegeven. Dit wordt beschreven in de volgende alinea's.

Het model bestaat uit vier tabellen:

  • In de tabel Verkoper wordt één rij per verkoper opgeslagen. Het bevat de kolom EmailAddress , waarin het e-mailadres voor elke verkoper wordt opgeslagen. Deze tabel is verborgen.
  • In de tabel Sales wordt één rij per order opgeslagen. Het omvat de meting Revenue % All Region , die is ontworpen om een verhouding te retourneren van inkomsten die zijn verdiend door de regio van de rapportgebruiker ten opzichte van de omzet die door alle regio's is verdiend.
  • In de tabel Datum wordt één rij per datum opgeslagen en kunnen jaar en maand worden gefilterd en gegroepeerd.
  • SalesRevenueSummary is een berekende tabel. Het slaat de totale omzet op voor elke orderdatum. Deze tabel is verborgen.

De volgende expressie definieert de berekende tabel SalesRevenueSummary :

SalesRevenueSummary =
SUMMARIZECOLUMNS(
    Sales[OrderDate],
    "RevenueAllRegion", SUM(Sales[Revenue])
)

Notitie

Een aggregatietabel kan dezelfde ontwerpvereiste bereiken.

De volgende RLS-regel wordt toegepast op de tabel Verkoper :

[EmailAddress] = USERNAME()

Elk van de drie modelrelaties wordt beschreven in de volgende tabel:

Relatie Beschrijving
Stroomdiagrameindteken 1. Er is een veel-op-veel-relatie tussen de tabellen Verkoper en Verkoop . De RLS-regel filtert de kolom EmailAddress van de verborgen tabel Verkoper met behulp van de DAX-functie USERNAME . De kolomwaarde Regio (voor de rapportgebruiker) wordt doorgegeven aan de tabel Sales .
Stroomdiagrameindteken 2. Er is een een-op-veel-relatie tussen de tabellen Datum en Verkoop .
Stroomdiagrameindteken 3. Er is een een-op-veel-relatie tussen de tabellen Date en SalesRevenueSummary .

De volgende expressie definieert de meting Revenue % All Region :

Revenue % All Region =
DIVIDE(
    SUM(Sales[Revenue]),
    SUM(SalesRevenueSummary[RevenueAllRegion])
)

Notitie

Zorg ervoor dat gevoelige feiten niet worden opgegeven. Als er in dit voorbeeld slechts twee regio's zijn, is het mogelijk dat een rapportgebruiker omzet voor de andere regio berekent.

Wanneer vermijdt u het gebruik van beveiliging op rijniveau

Soms is het zinvol om te voorkomen dat u RLS gebruikt. Als u slechts een paar eenvoudige RLS-regels hebt die statische filters toepassen, kunt u in plaats daarvan meerdere semantische modellen publiceren. Geen van de semantische modellen definiëren rollen omdat elk semantisch model gegevens bevat voor een specifieke doelgroep van rapportgebruikers, die dezelfde gegevensmachtigingen heeft. Maak vervolgens één werkruimte per doelgroep en wijs toegangsmachtigingen toe aan de werkruimte of app.

Een bedrijf met slechts twee verkoopregio's besluit bijvoorbeeld een semantisch model voor elke verkoopregio naar verschillende werkruimten te publiceren. De semantische modellen dwingen beveiliging op rijniveau niet af. Ze gebruiken echter queryparameters om brongegevens te filteren. Op deze manier wordt hetzelfde model naar elke werkruimte gepubliceerd. Ze hebben alleen verschillende semantische modelparameterwaarden. Verkopers krijgen toegang tot slechts één van de werkruimten (of gepubliceerde apps).

Er zijn verschillende voordelen verbonden aan het voorkomen van beveiliging op rijniveau:

  • Verbeterde queryprestaties: dit kan leiden tot verbeterde prestaties vanwege minder filters.
  • Kleinere modellen: Terwijl het resulteert in meer modellen, zijn ze kleiner in grootte. Kleinere modellen kunnen de reactiesnelheid van query's en gegevensvernieuwing verbeteren, met name als de hostingcapaciteit druk op resources ondervindt. Het is ook eenvoudiger om modelgrootten onder de groottelimieten te houden die door uw capaciteit worden opgelegd. Ten slotte is het eenvoudiger om workloads te verdelen over verschillende capaciteiten, omdat u werkruimten kunt maken op (of werkruimten kunt verplaatsen naar) verschillende capaciteiten.
  • Aanvullende functies: Power BI-functies die niet werken met RLS, zoals Publiceren op internet, kunnen worden gebruikt.

Er zijn echter nadelen verbonden aan het voorkomen van beveiliging op rijniveau:

  • Meerdere werkruimten: er is één werkruimte vereist voor elke doelgroep van rapportgebruikers. Als apps worden gepubliceerd, betekent dit ook dat er één app per rapportgebruikersdoelgroep is.
  • Duplicatie van inhoud: Rapporten en dashboards moeten in elke werkruimte worden gemaakt. Het vereist meer moeite en tijd om in te stellen en te onderhouden.
  • Gebruikers met hoge bevoegdheden: gebruikers met hoge bevoegdheden, die deel uitmaken van meerdere gebruikers van rapporten, kunnen geen geconsolideerde weergave van de gegevens zien. Ze moeten meerdere rapporten openen (vanuit verschillende werkruimten of apps).

Problemen met beveiliging op rijniveau oplossen

Als RLS onverwachte resultaten produceert, controleert u op de volgende problemen:

  • Er bestaan onjuiste relaties tussen modeltabellen, wat betreft kolomtoewijzingen en filterrichtingen. Houd er rekening mee dat RLS-filters alleen worden doorgegeven via actieve relaties.
  • Het beveiligingsfilter toepassen in beide richtingen is niet juist ingesteld. Zie bidirectionele relatierichtlijnen voor meer informatie.
  • Tabellen bevatten geen gegevens.
  • Onjuiste waarden worden in tabellen geladen.
  • De gebruiker is toegewezen aan meerdere rollen.
  • Het model bevat aggregatietabellen en RLS-regels filteren niet consistent aggregaties en details. Zie Aggregaties gebruiken in Power BI Desktop (RLS voor aggregaties) voor meer informatie.

Wanneer een specifieke gebruiker geen gegevens kan zien, kan dit komen doordat de UPN niet is opgeslagen of onjuist is ingevoerd. Dit kan plotseling gebeuren omdat het gebruikersaccount is gewijzigd als gevolg van een naamwijziging.

Tip

Voeg voor testdoeleinden een meting toe die de DAX-functie USERNAME retourneert. Misschien noem je het iets als 'Wie ben ik'. Voeg vervolgens de meting toe aan een kaartvisual in een rapport en publiceer deze naar Power BI.

Makers en consumenten met alleen leesmachtigingen voor het semantische model kunnen alleen de gegevens bekijken die ze mogen zien (op basis van hun RLS-roltoewijzing).

Wanneer een gebruiker een rapport bekijkt in een werkruimte of een app, kan RLS al dan niet worden afgedwongen, afhankelijk van de semantische modelmachtigingen. Daarom is het essentieel dat inhoudsgebruikers en makers alleen leesmachtigingen hebben voor het onderliggende semantische model wanneer beveiliging op rijniveau moet worden afgedwongen. Zie het artikel Over beveiligingsplanning voor consumenten rapporteren voor meer informatie over de machtigingsregels die bepalen of beveiliging op rijniveau wordt afgedwongen.

Gerelateerde inhoud

Raadpleeg de volgende bronnen voor meer informatie over dit artikel: