Dela via

Vägledning om säkerhet på radnivå (RLS) i Power BI Desktop

  • Artikel

Den här artikeln riktar sig till dig som datamodellerare som arbetar med Power BI Desktop. Den beskriver bra designmetoder för att framtvinga säkerhet på radnivå (RLS) i dina datamodeller.

Det är viktigt att förstå hur RLS filtrerar tabellrader. De kan inte konfigureras för att begränsa åtkomsten till modellobjekt, inklusive tabeller, kolumner eller mått.

Kommentar

Den här artikeln beskriver inte RLS eller hur du konfigurerar den. Mer information finns i Begränsa dataåtkomst med säkerhet på radnivå (RLS) för Power BI Desktop.

Den omfattar inte heller att framtvinga RLS i live-anslutningar till externa värdbaserade modeller med Azure Analysis Services eller SQL Server Analysis Services. I dessa fall tillämpas RLS av Analysis Services. När Power BI ansluter med enkel inloggning (SSO) tillämpar Analysis Services RLS (såvida inte kontot har administratörsbehörighet).

Skapa roller

Det går att skapa flera roller. När du överväger behörighetsbehoven för en enskild rapportanvändare ska du sträva efter att skapa en enda roll som ger alla dessa behörigheter, i stället för en design där en rapportanvändare kommer att vara medlem i flera roller. Det beror på att en rapportanvändare kan mappa till flera roller, antingen direkt med hjälp av sitt användarkonto eller indirekt genom medlemskap i säkerhetsgrupper. Flera rollmappningar kan resultera i oväntade resultat.

När en rapportanvändare tilldelas flera roller blir RLS-filter additiva. Det innebär att rapportanvändare kan se tabellrader som representerar de här filtrens union. I vissa scenarier går det dessutom inte att garantera att en rapportanvändare inte ser rader i en tabell. Till skillnad från behörigheter som tillämpas på SQL Server-databasobjekt (och andra behörighetsmodeller) gäller principen "en gång nekad alltid nekad".

Överväg en modell med två roller: Den första rollen, med namnet Arbetare, begränsar åtkomsten till alla lönetabellrader med hjälp av följande regeluttryck:

FALSE()

Kommentar

En regel returnerar inga tabellrader när dess uttryck utvärderas till FALSE.

Men en andra roll, med namnet Managers, ger åtkomst till alla lönetabellrader med hjälp av följande regeluttryck:

TRUE()

Var försiktig: Om en rapportanvändare mappar till båda rollerna visas alla lönetabellrader .

Optimera RLS

RLS fungerar genom att automatiskt tillämpa filter på varje DAX-fråga, och dessa filter kan ha en negativ inverkan på frågeprestanda. Så, effektiv RLS handlar om bra modelldesign. Det är viktigt att följa vägledningen för modelldesign enligt beskrivningen i följande artiklar:

I allmänhet är det ofta effektivare att framtvinga RLS-filter på tabeller av dimensionstyp och inte tabeller av faktatyp. Och förlita dig på väl utformade relationer för att säkerställa att RLS-filter sprids till andra modelltabeller. RLS-filter sprids endast via aktiva relationer. Undvik därför att använda DAX-funktionen LOOKUPVALUE när modellrelationer kan uppnå samma resultat.

När RLS-filter tillämpas på DirectQuery-tabeller och det finns relationer till andra DirectQuery-tabeller bör du optimera källdatabasen. Det kan handla om att utforma lämpliga index eller använda beständiga beräknade kolumner. Mer information finns i DirectQuery-modellvägledning i Power BI Desktop.

Mäta RLS-påverkan

Du kan mäta prestandapåverkan för RLS-filter i Power BI Desktop med hjälp av Prestandaanalys. Börja med att fastställa varaktigheter för rapportvisualiseringsfråga när RLS inte tillämpas. Använd sedan kommandot Visa som på fliken Modellering i menyfliksområdet för att framtvinga RLS och fastställa och jämföra frågevaraktighet.

Konfigurera rollmappningar

När du har publicerat till Power BI måste du mappa medlemmar till semantiska modellroller. Endast semantiska modellägare eller arbetsyteadministratörer kan lägga till medlemmar i roller. Mer information finns i Säkerhet på radnivå (RLS) med Power BI (Hantera säkerhet på din modell).

Medlemmar kan vara användarkonton, säkerhetsgrupper, distributionsgrupper eller e-postaktiverade grupper. När det är möjligt rekommenderar vi att du mappar säkerhetsgrupper till semantiska modellroller. Det handlar om att hantera medlemskap i säkerhetsgrupper i Microsoft Entra-ID. Möjligen delegeras uppgiften till nätverksadministratörerna.

Verifiera roller

Testa varje roll för att säkerställa att den filtrerar modellen korrekt. Det är enkelt att göra det med kommandot Visa som på menyfliken Modellering .

När modellen har dynamiska regler med dax-funktionen USERNAME bör du testa för förväntade och oväntade värden. När du bäddar in Power BI-innehåll – särskilt med hjälp av scenariot för inbäddning för dina kunder – kan applogik skicka valfritt värde som ett effektivt identitetsanvändarnamn. När det är möjligt bör du se till att oavsiktliga eller skadliga värden resulterar i filter som inte returnerar några rader.

Överväg ett exempel med Power BI Embedded, där appen skickar användarens jobbroll som det effektiva användarnamnet: Det är antingen "Manager" eller "Worker". Chefer kan se alla rader, men arbetare kan bara se rader där kolumnvärdet Typ är "Intern".

Följande regeluttryck definieras:

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

Problemet med det här regeluttrycket är att alla värden, förutom "Worker", returnerar alla tabellrader. Därför returnerar ett oavsiktligt värde, som "Wrker", oavsiktligt alla tabellrader. Därför är det säkrare att skriva ett uttryck som testar för varje förväntat värde. I följande förbättrade regeluttryck resulterar ett oväntat värde i tabellen som inte returnerar några rader.

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

Designa partiell RLS

Ibland behöver beräkningar värden som inte begränsas av RLS-filter. En rapport kan till exempel behöva visa ett förhållande mellan intäkter som tjänats in för rapportanvändarens försäljningsregion jämfört med alla intäkter som intjänats.

Även om det inte är möjligt för ett DAX-uttryck att åsidosätta RLS – det kan faktiskt inte ens avgöra att RLS tillämpas – kan du använda en sammanfattningsmodelltabell. Sammanfattningsmodelltabellen efterfrågas för att hämta intäkter för "alla regioner" och den begränsas inte av några RLS-filter.

Nu ska vi se hur du kan implementera det här designkravet. Överväg först följande modelldesign:

En bild av ett modelldiagram visas. Det beskrivs i följande stycken.

Modellen består av fyra tabeller:

  • Tabellen Säljare lagrar en rad per säljare. Den innehåller kolumnen EmailAddress , som lagrar e-postadressen för varje säljare. Den här tabellen är dold.
  • Tabellen Försäljning lagrar en rad per beställning. Den innehåller måttet Intäkter % alla regioner , som är utformat för att returnera ett förhållande mellan intäkter som genererats av rapportanvändarens region jämfört med intäkter som tjänats av alla regioner.
  • Tabellen Datum lagrar en rad per datum och tillåter filtrering och gruppering år och månad.
  • SalesRevenueSummary är en beräknad tabell. Den lagrar totala intäkter för varje orderdatum. Den här tabellen är dold.

Följande uttryck definierar den beräknade tabellen SalesRevenueSummary :

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

Kommentar

En sammansättningstabell kan uppnå samma designkrav.

Följande RLS-regel tillämpas på tabellen Säljare :

[EmailAddress] = USERNAME()

Var och en av de tre modellrelationerna beskrivs i följande tabell:

Förhållande beskrivning
Flödesschemasavgränsare 1. Det finns en många-till-många-relation mellan tabellerna Säljare och Försäljning . RLS-regeln filtrerar kolumnen EmailAddress i den dolda tabellen Salesperson med hjälp av dax-funktionen USERNAME . Kolumnvärdet Region (för rapportanvändaren) sprids till tabellen Försäljning .
Flödesschemasavgränsare 2. Det finns en en-till-många-relation mellan tabellerna Datum och Försäljning .
Flödesschemasavgränsare 3. Det finns en en-till-många-relation mellan tabellerna Date och SalesRevenueSummary .

Följande uttryck definierar måttet Intäkt % all region :

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

Kommentar

Var noga med att undvika att avslöja känsliga fakta. Om det bara finns två regioner i det här exemplet är det möjligt för en rapportanvändare att beräkna intäkter för den andra regionen.

När du ska undvika att använda RLS

Ibland är det vettigt att undvika att använda RLS. Om du bara har några förenklade RLS-regler som tillämpar statiska filter bör du överväga att publicera flera semantiska modeller i stället. Ingen av de semantiska modellerna definierar roller eftersom varje semantisk modell innehåller data för en specifik rapportanvändare som har samma databehörigheter. Skapa sedan en arbetsyta per målgrupp och tilldela åtkomstbehörigheter till arbetsytan eller appen.

Ett företag som bara har två försäljningsregioner bestämmer sig till exempel för att publicera en semantisk modell för varje försäljningsregion till olika arbetsytor. Semantiska modeller framtvingar inte RLS. De använder dock frågeparametrar för att filtrera källdata. På så sätt publiceras samma modell till varje arbetsyta – de har bara olika parametervärden för semantisk modell. Säljare tilldelas åtkomst till bara en av arbetsytorna (eller publicerade appar).

Det finns flera fördelar med att undvika RLS:

  • Förbättrad frågeprestanda: Det kan resultera i bättre prestanda på grund av färre filter.
  • Mindre modeller: Även om det resulterar i fler modeller är de mindre i storlek. Mindre modeller kan förbättra svarstiden för frågor och datauppdateringar, särskilt om värdkapaciteten utsätts för belastning på resurser. Dessutom är det enklare att hålla modellstorlekarna under de storleksgränser som din kapacitet har infört. Slutligen är det enklare att balansera arbetsbelastningar mellan olika kapaciteter eftersom du kan skapa arbetsytor på – eller flytta arbetsytor till – olika kapaciteter.
  • Ytterligare funktioner: Power BI-funktioner som inte fungerar med RLS, till exempel Publicera på webben, kan användas.

Det finns dock nackdelar med att undvika RLS:

  • Flera arbetsytor: En arbetsyta krävs för varje rapportanvändare. Om appar publiceras innebär det också att det finns en app per rapportanvändare.
  • Duplicering av innehåll: Rapporter och instrumentpaneler måste skapas på varje arbetsyta. Det kräver mer arbete och tid för att konfigurera och underhålla.
  • Användare med hög behörighet: Användare med hög behörighet, som tillhör flera rapportanvändare, kan inte se en samlad vy över data. De måste öppna flera rapporter (från olika arbetsytor eller appar).

Felsöka RLS

Om RLS ger oväntade resultat kontrollerar du följande problem:

  • Det finns felaktiga relationer mellan modelltabeller när det gäller kolumnmappningar och filterriktningar. Tänk på att RLS-filter endast sprids via aktiva relationer.
  • Egenskapen Använd säkerhetsfilter i båda riktningarna är inte korrekt inställd. Mer information finns i Vägledning för dubbelriktade relationer.
  • Tabeller innehåller inga data.
  • Felaktiga värden läses in i tabeller.
  • Användaren mappas till flera roller.
  • Modellen innehåller sammansättningstabeller och RLS-regler filtrerar inte aggregeringar och information konsekvent. Mer information finns i Använda sammansättningar i Power BI Desktop (RLS för sammansättningar).

När en specifik användare inte kan se några data kan det bero på att deras UPN inte lagras eller att det har angetts felaktigt. Det kan inträffa plötsligt eftersom deras användarkonto har ändrats till följd av en namnändring.

Dricks

I testsyfte lägger du till ett mått som returnerar DAX-funktionen USERNAME . Du kanske döp det till "Vem är jag". Lägg sedan till måttet i ett visuellt kort i en rapport och publicera det i Power BI.

Skapare och konsumenter med endast läsbehörighet för den semantiska modellen kan bara visa de data som de får se (baserat på deras RLS-rollmappning).

När en användare visar en rapport i antingen en arbetsyta eller en app kanske RLS tillämpas eller inte beroende på deras semantiska modellbehörigheter. Därför är det viktigt att innehållskonsumenter och innehållsskapare bara har läsbehörighet för den underliggande semantiska modellen när RLS måste tillämpas. Mer information om behörighetsregler som avgör om RLS tillämpas finns i artikeln Rapport för konsumentsäkerhetsplanering .

Relaterat innehåll

Mer information om den här artikeln finns i följande resurser: