Händelser
31 mars 23 - 2 apr. 23
Det ultimata Community-ledda evenemanget för Microsoft Fabric, Power BI, SQL och AI. 31 mars till 2 april 2025.
Anmäl dig i dagDen här webbläsaren stöds inte längre.
Uppgradera till Microsoft Edge och dra nytta av de senaste funktionerna och säkerhetsuppdateringarna, samt teknisk support.
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.
Anteckning
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).
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()
Anteckning
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 .
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.
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.
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.
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()
)
)
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:
Modellen består av fyra tabeller:
Följande uttryck definierar den beräknade tabellen SalesRevenueSummary :
SalesRevenueSummary =
SUMMARIZECOLUMNS(
Sales[OrderDate],
"RevenueAllRegion", SUM(Sales[Revenue])
)
Anteckning
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 |
---|---|
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 . | |
Det finns en en-till-många-relation mellan tabellerna Datum och Försäljning . | |
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])
)
Anteckning
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.
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:
Det finns dock nackdelar med att undvika RLS:
Om RLS ger oväntade resultat kontrollerar du följande problem:
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.
Tips
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 .
Mer information om den här artikeln finns i följande resurser:
Händelser
31 mars 23 - 2 apr. 23
Det ultimata Community-ledda evenemanget för Microsoft Fabric, Power BI, SQL och AI. 31 mars till 2 april 2025.
Anmäl dig i dagUtbildning
Modul
Implementera säkerhet på radnivå - Training
Med säkerhet på radnivå, RLS, kan du skapa en enskild rapport eller en uppsättning rapporter med data för en viss användare. I den här modulen får du lära dig hur du implementerar RLS med hjälp av antingen en statisk eller dynamisk metod och hur Microsoft Power BI förenklar testning av RLS i Power BI Desktop och Power BI-tjänst.
Certifiering
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Demonstrate methods and best practices that align with business and technical requirements for modeling, visualizing, and analyzing data with Microsoft Power BI.