Richtlijnen voor beveiliging op rijniveau (RLS) in Power BI DesktopRow-level security (RLS) guidance in Power BI Desktop

Dit artikel is geschreven voor iedereen die gegevensmodellen maakt met Power BI Desktop.This article targets you as a data modeler working with Power BI Desktop. Er worden goede ontwerpprocedures beschreven voor het afdwingen van beveiliging op rijniveau (RLS) in uw gegevensmodellen.It describes good design practices for enforcing row-levels security (RLS) in your data models.

Het is belangrijk dat u de werking van tabelrijen van RLS-filters begrijpt.It's important to understand RLS filters table rows. Deze kunnen niet worden geconfigureerd om de toegang tot modelobjecten, zoals tabellen, kolommen of maateenheden, te beperken.They can't be configured to restrict access to model objects, including tables, columns, or measures.

Notitie

In dit artikel wordt niet beschreven wat beveiliging op rijniveau is of hoe u deze kunt instellen.This article doesn't describe RLS or how to set it up. Zie Gegevenstoegang met beveiliging op rijniveau (RLS) beperken voor Power BI Desktop voor meer informatie.For more information, see Restrict data access with row-level security (RLS) for Power BI Desktop.

Ook het afdwingen van beveiliging op rijniveau in live-verbindingen met extern gehoste modellen met Azure Analysis Services of SQL Server Analysis Services komt niet aan de orde in dit artikel.Also, it doesn't cover enforcing RLS in live connections to external-hosted models with Azure Analysis Services or SQL Server Analysis Services. In die gevallen wordt beveiliging op rijniveau afgedwongen door Analysis Services.In these cases, RLS is enforced by Analysis Services. Als Power BI verbinding maakt met behulp van eenmalige aanmelding (SSO), dwingt Analysis Services beveiliging op rijniveau af (tenzij het account beheerdersbevoegdheden heeft).When Power BI connects using single-sign on (SSO), Analysis Services will enforce RLS (unless the account has admin privileges).

Rollen makenCreate roles

Het is mogelijk om meerdere rollen te maken.It's possible to create multiple roles. Als u overweegt de machtigingsvereisten voor één rapportgebruiker te maken, dient u bij voorkeur één rol maken waarmee alle machtigingen worden verleend, in plaats van een ontwerp waarbij een rapportgebruiker lid is van meerdere rollen.When you're considering the permission needs for a single report user, strive to create a single role that grants all those permissions, instead of a design where a report user will be a member of multiple roles. De reden hiervoor is dat een rapportgebruiker kan zijn toegewezen aan meerdere rollen. Zo kunnen ze rechtstreeks toegang krijgen door gebruik te maken van hun gebruikersaccount, of indirect door het lidmaatschap van een beveiligingsgroep.It's because a report user could map to multiple roles, either directly by using their user account or indirectly by security group membership. Toewijzingen van meerdere rollen kunnen leiden tot onverwachte resultaten.Multiple role mappings can result in unexpected outcomes.

Wanneer een rapportgebruiker aan meerdere rollen wordt toegewezen, worden de filters voor beveiliging op rijniveau additief.When a report user is assigned to multiple roles, RLS filters become additive. Dit betekent dat rapportgebruikers tabelrijen kunnen zien die de combinatie van die filters vertegenwoordigen.It means report users can see table rows that represent the union of those filters. In sommige scenario's is het niet mogelijk om te garanderen dat een rapportgebruiker geen rijen in een tabel ziet.What's more, in some scenarios it's not possible to guarantee that a report user doesn't see rows in a table. In tegenstelling tot machtigingen die worden toegepast op SQL Server-databaseobjecten (en andere machtigingsmodellen), is het principe 'eenmaal geweigerd, altijd geweigerd ' niet van toepassing.So, unlike permissions applied to SQL Server database objects (and other permission models), the "once denied always denied" principle doesn't apply.

Overweeg een model met twee rollen: De eerste rol, met de naam Workers (Medewerkers), beperkt de toegang tot alle tabelrijen van Payroll (Salarisadministratie) met behulp van de volgende regelexpressie:Consider a model with two roles: The first role, named Workers, restricts access to all Payroll table rows by using the following rule expression:

FALSE()

Notitie

Een regel retourneert geen tabelrijen als de expressie wordt geëvalueerd als onwaar.A rule will return no table rows when its expression evaluates to false.

Een tweede rol, met de naam Managers, geeft toegang tot alle tabelrijen van Payroll met behulp van de volgende regelexpressie:Yet, a second role, named Managers, allows access to all Payroll table rows by using the following rule expression:

TRUE()

Let op: Als een rapportgebruiker aan beide rollen wordt toegewezen, zien zij alle rijen van de tabel Salary (Salaris).Take care: Should a report user map to both roles, they'll see all Salary table rows.

Beveiliging op rijniveau optimaliserenOptimize RLS

Beveiliging op rijniveau werkt door automatisch filters toe te passen op elke DAX-query. Deze filters kunnen een negatieve invloed hebben op de queryprestaties.RLS works by automatically applying filters to every DAX query, and these filters may have a negative impact on query performance. Een efficiënte beveiliging op rijniveau staat of valt dus met een goed modelontwerp.So, efficient RLS comes down to good model design. Het is belangrijk om de richtlijnen voor het ontwerpen van een model te volgen, zoals beschreven in de volgende artikelen:It's important to follow model design guidance, as discussed in the following articles:

Over het algemeen is het vaak efficiënter om filters voor beveiliging op rijniveau af te dwingen voor dimensietabellen dan voor feitentabellen.In general, it's often more efficient to enforce RLS filters on dimension-type tables, and not fact-type tables. Zorg ook voor goed ontworpen relaties zodat filters voor beveiliging op rijniveau worden doorgegeven aan andere modeltabellen.And, rely on well-designed relationships to ensure RLS filters propagate to other model tables. Vermijd daarom het gebruik van de DAX-functie LOOKUPVALUE als hetzelfde resultaat kan worden verkregen met modelrelaties.So, avoid using the LOOKUPVALUE DAX function when model relationships could achieve the same result.

Wanneer beveiliging op rijniveau wordt afgedwongen in DirectQuery-tabellen en er relaties zijn met andere DirectQuery-tabellen, moet u ervoor zorgen dat u de brondatabase optimaliseert.Whenever RLS filters are enforced on DirectQuery tables and there are relationships to other DirectQuery tables, be sure to optimize the source database. Dit kan inhouden dat u de juiste indexen moet ontwerpen of persistent berekende kolommen moet gebruiken.It can involve designing appropriate indexes or using persisted computed columns. Zie Richtlijnen voor het DirectQuery-model in Power BI Desktop voor meer informatie.For more information, see DirectQuery model guidance in Power BI Desktop.

Impact op beveiliging op rijniveau metenMeasure RLS impact

Het is mogelijk om de impact op de prestaties van filters voor beveiliging op rijniveau in Power BI Desktop te meten met behulp van Performance Analyzer.It's possible to measure the performance impact of RLS filters in Power BI Desktop by using Performance Analyzer. Bepaal eerst de duur van query's op visuals in een rapport als beveiliging op rijniveau niet wordt afgedwongen.First, determine report visual query durations when RLS isn't enforced. Gebruik vervolgens de opdracht Weergeven als op het linttabblad Model maken om beveiliging op rijniveau af te dwingen en bepaal en vergelijk de duur van de query's.Then, use the View As command on the Modeling ribbon tab to enforce RLS and determine and compare query durations.

Roltoewijzingen configurerenConfigure role mappings

Nadat u ze naar Power BI hebt gepubliceerd, moet u leden toewijzen aan de gegevenssetrollen.Once published to Power BI, you must map members to dataset roles. Alleen eigenaren van een gegevensset of werkruimtebeheerders kunnen leden aan rollen toevoegen.Only dataset owners or workspace admins can add members to roles. Zie Beveiliging op rijniveau (RLS) met Power BI (Beveiliging voor uw model beheren) voor meer informatie.For more information, see Row-level security (RLS) with Power BI (Manage security on your model).

Leden kunnen gebruikersaccounts of beveiligingsgroepen zijn.Members can be user accounts or security groups. U wordt aangeraden om waar mogelijk beveiligingsgroepen toe te wijzen aan gegevenssetrollen.Whenever possible, we recommend you map security groups to dataset roles. Hiervoor moeten lidmaatschappen van beveiligingsgroepen worden beheerd in Azure Active Directory.It involves managing security group memberships in Azure Active Directory. Mogelijk wordt deze taak overgedragen aan uw netwerkbeheerders.Possibly, it delegates the task to your network administrators.

Rollen validerenValidate roles

Test elke rol om ervoor te zorgen dat het model correct wordt gefilterd.Test each role to ensure it filters the model correctly. U kunt dit eenvoudig doen met behulp van de opdracht Weergeven als opdracht op het linttabblad Model maken.It's easily done by using the View As command on the Modeling ribbon tab.

Wanneer het model dynamische regels bevat met de DAX-functie USERNAME, moet u testen op verwachte en onverwachte waarden.When the model has dynamic rules using the USERNAME DAX function, be sure to test for expected and unexpected values. Bij het insluiten van Power BI-inhoud, met name als de app eigenaar is van gegevens, kan de app-logica elke waarde doorgeven als effectieve gebruikersnaam voor een identiteit.When embedding Power BI content—specifically using the App owns data scenario—app logic can pass any value as an effective identity user name. Indien mogelijk, moet u ervoor zorgen dat onbedoelde of schadelijke waarden resulteren in filters die geen rijen retourneren.Whenever possible, ensure accidental or malicious values result in filters that return no rows.

Bekijk een voorbeeld waarin Power BI is ingesloten, waarbij de functierol van de gebruiker door de app wordt doorgegeven als de effectieve gebruikersnaam: Deze is 'Manager' of 'Worker'.Consider an example using Power BI embedded, where the app passes the user's job role as the effective user name: It's either "Manager" or "Worker". Managers kunnen alle rijen zien, maar medewerkers kunnen alleen rijen zien waarin het Type van de kolomwaarde 'Internal' (intern) is.Managers can see all rows, but workers can only see rows where the Type column value is "Internal".

De volgende regelexpressie is gedefinieerd:The following rule expression is defined:

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

Het probleem met deze regelexpressie is dat alle waarden, met uitzondering van 'Worker', alle tabelrijen retourneren.The problem with this rule expression is that all values, except "Worker", return all table rows. Een onbedoelde waarde, zoals 'Wrker', retourneert per ongeluk alle tabelrijen.So, an accidental value, like "Wrker", unintentionally returns all table rows. Daarom is het veiliger om een expressie te schrijven waarmee een controle wordt uitgevoerd op elke verwachte waarde.Therefore, it's safer to write an expression that tests for each expected value. In de volgende verbeterde regelexpressie heeft een onverwachte waarde als resultaat dat de tabel geen rijen retourneert.In the following improved rule expression, an unexpected value will result in the table returning no rows.

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

Gedeeltelijke beveiliging op rijniveau ontwerpenDesign partial RLS

Soms zijn er waarden nodig voor berekeningen die niet worden beperkt door filters voor beveiliging op rijniveau.Sometimes, calculations need values that aren't constrained by RLS filters. Zo moet een rapport mogelijk een verhouding weergeven tussen de verdiende omzet in de verkoopregio van de rapportgebruiker en alle verdiende omzet.For example, a report may need to display a ratio of revenue earned for the report user's sales region over all revenue earned.

Hoewel beveiliging op rijniveau niet kan worden overschreven door een DAX-expressie (of door een DAX-expressie kan worden bepaald of beveiliging op rijniveau wordt afgedwongen), kunt u een overzichtsmodeltabel gebruiken.While it's not possible for a DAX expression to override RLS—in fact, it can't even determine that RLS is enforced—you can use a summary model table. Op de overzichtsmodeltabel wordt een query uitgevoerd om de omzet voor alle regio's op te halen. Deze wordt niet beperkt door filters voor beveiliging op rijniveau.The summary model table is queried to retrieve revenue for "all regions" and it's not constrained by any RLS filters.

Laten we eens kijken hoe u deze ontwerpvereiste kunt implementeren.Let's see how you could implement this design requirement. Bekijk eerst het volgende modelontwerp:First, consider the following model design:

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

Het model bestaat uit vier tabellen:The model comprises four tables:

  • In de tabel Salesperson (Verkoper) wordt één rij per verkoper opgeslagen.The Salesperson table stores one row per salesperson. Het bevat de kolom EmailAddress, waarin het e-mailadres van elke verkoper wordt opgeslagen.It includes the EmailAddress column, which stores the email address for each salesperson. Deze tabel is verborgen.This table is hidden.
  • In de tabel Sales (Verkoop) wordt één rij per order opgeslagen.The Sales table stores one row per order. Het bevat de meting Revenue % All Region (omzetpercentage van alle regio's), die is ontworpen om een verhouding te retourneren tussen de verdiende omzet van de regio van de rapportgebruiker en de verdiende omzet van alle regio's.It includes the Revenue % All Region measure, which is designed to return a ratio of revenue earned by the report user's region over revenue earned by all regions.
  • In de tabel Date (Datum) wordt één rij per datum opgeslagen en kan worden gefilterd en gegroepeerd op jaar en maand.The Date table stores one row per date and allows filtering and grouping year and month.
  • SalesRevenueSummary is een berekende tabel.The SalesRevenueSummary is a calculated table. Hierin wordt de totale omzet voor elke orderdatum opgeslagen.It stores total revenue for each order date. Deze tabel is verborgen.This table is hidden.

Met de volgende expressie wordt de berekende tabel SalesRevenueSummary gedefinieerd:The following expression defines the SalesRevenueSummary calculated table:

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

Notitie

U kunt ook een aggregatietabel gebruiken voor deze ontwerpvereiste.An aggregation table could achieve the same design requirement.

De volgende regel voor beveiliging op rijniveau wordt toegepast op de tabel Salesperson:The following RLS rule is applied to the Salesperson table:

[EmailAddress] = USERNAME()

Elk van de drie modelrelaties wordt beschreven in de volgende tabel:Each of the three model relationships is described in the following table:

RelatieRelationship BeschrijvingDescription
Stroomdiagramafsluiter 1. Er is een veel-op-veel-relatie tussen de tabellen Salesperson en Sales.There's a many-to-many relationship between the Salesperson and Sales tables. De regel voor beveiliging op rijniveau filtert de kolom EmailAddress van de verborgen tabel Salesperson met behulp van de DAX-functie USERNAME.The RLS rule filters the EmailAddress column of the hidden Salesperson table by using the USERNAME DAX function. De waarde van de kolom Region (voor de rapportgebruiker) wordt doorgevoerd in de tabel Sales.The Region column value (for the report user) propagates to the Sales table.
Stroomdiagramafsluiter 2. Er is een een-op-veel-relatie tussen de tabellen Date en Sales.There's a one-to-many relationships between the Date and Sales tables.
Stroomdiagramafsluiter 3. Er is een een-op-veel-relatie tussen de tabellen Date en SalesRevenueSummary.There's a one-to-many relationships between the Date and SalesRevenueSummary tables.

Met de volgende expressie wordt de meting Revenue % All Region gedefinieerd:The following expression defines the Revenue % All Region measure:

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

Notitie

Voorkom dat gevoelige feiten worden weergegeven.Take care to avoid disclosing sensitive facts. Als er in dit voorbeeld slechts twee regio's waren,zou een rapport gebruiker de omzet van de andere regio kunnen berekenen.If there are only two regions in this example, then it would be possible for a report user to calculate revenue for the other region.

Geen beveiliging op rijniveau gebruikenAvoid using RLS

Vermijd het gebruik van beveiliging op rijniveau als dat zinvol is.Avoid using RLS, whenever it makes sense to do so. Als u slechts een klein aantal vereenvoudigde beveiliging op rijniveau hebt waarmee statische filters worden toegepast, kunt u overwegen om in plaats daarvan meerdere gegevenssets te publiceren.If you have only a small number of simplistic RLS rules that apply static filters, consider publishing multiple datasets instead. Geen van de gegevenssets definiëren rollen, omdat elke gegevensset gegevens bevat voor een specifieke doelgroep van rapportgebruikers met dezelfde gegevensmachtigingen.None of the datasets define roles because each dataset contains data for a specific report user audience, which has the same data permissions. Maak vervolgens één werkruimte per doelgroep en wijs toegangsmachtigingen toe aan de werkruimte of app.Then, create one workspace per audience and assign access permissions to the workspace or app.

Bijvoorbeeld, een bedrijf met slechts twee verkoopregio's besluit voor elke verkoopregio een gegevensset te publiceren in verschillende werkruimten.For example, a company that has just two sales regions decides to publish a dataset for each sales region to different workspaces. Beveiliging op rijniveau wordt niet afgedwongen voor de gegevenssets.The datasets don't enforce RLS. Ze gebruiken echter queryparameters om brongegevens te filteren.They do, however, use query parameters to filter source data. Op deze manier wordt in elke werkruimte hetzelfde model gepubliceerd. Alleen de parameterwaarden verschillen per gegevensset.This way, the same model is published to each workspace—they just have different dataset parameter values. Verkopers krijgen slechts toegang tot één van de werkruimten (of gepubliceerde apps) toegewezen.Salespeople are assigned access to just one of the workspaces (or published apps).

Het vermijden van beveiliging op rijniveau biedt verschillende voordelen:There are several advantages associated with avoiding RLS:

  • Verbeterde queryprestaties: De prestaties kunnen hoger zijn omdat er minder filters worden gebruikt.Improved query performance: It can result in improved performance due to fewer filters.
  • Kleinere modellen: Het resulteert in meer modellen, maar deze zijn wel kleiner.Smaller models: While it results in more models, they are smaller in size. Kleinere modellen kunnen de reactiesnelheid van query's en gegevensvernieuwing verbeteren, met name als de hostcapaciteit voor resources onder druk staat.Smaller models can improve query and data refresh responsiveness, especially if the hosting capacity experiences pressure on resources. Bovendien is het eenvoudiger om de grootte van modellen onder uw capaciteitslimieten te houden.Also, it's easier to keep model sizes beneath size limits imposed by your capacity. Ten slotte is het eenvoudiger om werkbelastingen te verdelen over verschillende capaciteiten, omdat u werkruimten kunt maken op of verplaatsen naar verschillende capaciteiten.Lastly, it's easier to balance workloads across different capacities, because you can create workspaces on—or move workspaces to—different capacities.
  • Aanvullende functies: Power BI-functies die niet met beveiliging op rijniveau werken, zoals Publiceren op internet, kunnen worden gebruikt.Additional features: Power BI features that don't work with RLS, like Publish to web, can be used.

Het vermijden van beveiliging op rijniveau kent echter ook nadelen:However, there are disadvantages associated with avoiding RLS:

  • Meerdere werkruimten: Voor elke gebruikersdoelgroep van het rapport is een werkruimte vereist.Multiple workspaces: One workspace is required for each report user audience. Als apps worden gepubliceerd, betekent dit ook dat er één app per rapportgebruikersdoelgroep is.If apps are published, it also means there's one app per report user audience.
  • Duplicatie van inhoud: Rapporten en dashboards moeten in elke werkruimte worden gemaakt.Duplication of content: Reports and dashboards must be created in each workspace. Het instellen en onderhouden hiervan kost extra moeite en tijd.It requires additional effort and time to set up and maintain.
  • Gebruikers met hoge bevoegdheden: Gebruikers met hoge bevoegdheden, die deel uitmaken van meerdere doelgroepen van rapportgebruikers, kunnen geen geconsolideerde weergave van de gegevens bekijken.High privilege users: High privilege users, who belong to multiple report user audiences, can't see a consolidated view of the data. Ze moeten meerdere rapporten (vanuit verschillende werkruimten of apps) openen.They'll need to open multiple reports (from different workspaces or apps).

Problemen met beveiliging op rijniveau oplossenTroubleshoot RLS

Als er onverwachte resultaten worden gegenereerd door beveiliging op rijniveau, voert u een controle uit op de volgende problemen:If RLS produces unexpected results, check for the following issues:

  • Er bestaan onjuiste relaties tussen modeltabellen, in termen van kolomtoewijzingen en filterrichtingen.Incorrect relationships exist between model tables, in terms of column mappings and filter directions.
  • De relatie-eigenschap Beveiligingsfilter in beide richtingen toepassen is niet juist ingesteld.The Apply security filter in both directions relationship property isn't correctly set. Raadpleeg Richtlijnen voor bidirectionele relaties voor meer informatie.For more information, see Bi-directional relationship guidance.
  • Tabellen bevatten geen gegevens.Tables contain no data.
  • Onjuiste waarden worden in tabellen geladen.Incorrect values are loaded into tables.
  • De gebruiker is toegewezen aan meerdere rollen.The user is mapped to multiple roles.
  • Het model bevat aggregatietabellen en de aggregaties en details worden niet consistent gefilterd door de regels voor beveiliging op rijniveau.The model includes aggregation tables, and RLS rules don't consistently filter aggregations and details. Zie Aggregaties gebruiken in Power BI Desktop (Beveiliging op rijniveau voor aggregaties) voor meer informatie.For more information, see Use aggregations in Power BI Desktop (RLS for aggregations).

Wanneer een specifieke gebruiker geen gegevens kan zien, is de UPN mogelijk niet opgeslagen of onjuist ingevoerd.When a specific user can't see any data, it could be because their UPN isn't stored or it's entered incorrectly. Dit kan abrupt gebeuren omdat het gebruikersaccount is gewijzigd als gevolg van een naamswijziging.It can happen abruptly because their user account has changed as the result of a name change.

Tip

Voeg voor testdoeleinden een meting toe die de DAX-functie USERNAME retourneert.For testing purposes, add a measure that returns the USERNAME DAX function. U kunt deze bijvoorbeeld 'Wie ben ik' noemen.You might name it something like "Who Am I". Vervolgens voegt u de meting toe aan een kaartvisual in een rapport en publiceert u deze naar Power BI.Then, add the measure to a card visual in a report and publish it to Power BI.

Wanneer specifieke gebruikers alle gegevens kunnen zien, is het mogelijk dat ze rechtstreeks toegang hebben tot rapporten in de werkruimte en ze de eigenaar van de gegevensset zijn.When a specific user can see all data, it's possible they're accessing reports directly in the workspace and they're the dataset owner. Beveiliging op rijniveau wordt alleen afgedwongen in de volgende gevallen:RLS is only enforced when:

  • Het rapport wordt geopend in een app.The report is opened in an app.
  • Het rapport wordt geopend in een werkruimte en de gebruiker is toegewezen aan de rol Lezer.The report is opened in a workspace, and the user is mapped to the Viewer role.

Volgende stappenNext steps

Bekijk de volgende resources voor meer informatie over dit artikel:For more information related to this article, check out the following resources: