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

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

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

Skapa roller

Det är möjligt 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 blir medlem i flera roller. Anledningen är att en rapportanvändare kan mappa till flera roller, antingen direkt genom att använda sina användarkonton eller indirekt genom säkerhetsgruppsmedlemskap. Flera rollmappningar kan resultera i oväntade resultat.

När en rapportanvändare tilldelas flera roller, så blir RLS-filtren additiva. Det innebär att rapportanvändare kan se tabellrader som representerar unionen av dessa filter. I vissa fall är det dessutom inte möjligt att garantera att en rapportanvändare ser raderna i en tabell. Så till skillnad från behörigheter som tillämpas på SQL Server-databasobjekt (och andra behörighetsmodeller) gäller inte principen "om nekad alltid nekad".

Överväg att använda en modell med två roller: Den första rollen, som kallas Arbetare begränsar åtkomsten till alla tabellrader i Lönelista med hjälp av följande regeluttryck:

FALSE()

Men en annan roll, som kallas Hanterare, tillåter åtkomst till alla tabellrader i Lönelista med hjälp av följande regeluttryck:

TRUE()

Tänk på följande: Om en rapportanvändare mappar till båda rollerna visas alla tabellrader för Lönelista.

Optimera RLS

RLS fungerar genom att filter tillämpas automatiskt på alla DAX-frågor, och dessa filter kan ha en negativ påverkan på frågeprestanda. Så effektiv RLS-hantering handlar om bra modelldesign. Det är viktigt att du följer råden för modelldesign enligt beskrivningarna i följande artiklar:

• Förstå star-schemat och dess betydelse för Power BI
• Alla vägledningar om relationer finns i Power BI-vägledningsdokumentationen

Oftast är det mer effektivt att använda RLS-filter på tabeller av dimensionstyp och inte på tabeller av faktatyp. Och förlita dig på väldesignade relationer när du vill se till att RLS-filter sprids till andra modelltabeller. 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, så var noga med att optimera källdatabasen. Det kan innebära att du måste utforma lämpliga index eller använda bestående beräknade kolumner. Mer information finns i Vägledning för DirectQuery-modeller i Power BI Desktop.

Mäta RLS-påverkan

Du kan mäta RLS-filtrens prestandapåverkan i Power BI Desktop genom att använda Prestandaanalys. Börja med att fastställa de visuella rapportobjektens frågevaraktighet när RLS inte genomdrivs. Använd sedan kommandot Visa som på fliken Modellering för att genomdriva RLS och fastställa och jämföra frågevaraktigheter.

Konfigurera rollmappningar

När du har publicerat till Power BI måste du mappa medlemmarna till datamängdsroller. Endast datamängdsägare eller arbetsytans administratörer kan lägga till medlemmar till roller. Mer information finns i Säkerhet på radnivå (RLS) med Power BI.

Medlemmar kan vara användarkonton eller säkerhetsgrupper. Närhelst det är möjligt rekommenderar vi att du mappar säkerhetsgrupper till datamängdsroller. Det innebär att du får hantera medlemskap i säkerhetsgrupper i Azure Active Directory. Du kan eventuellt delegera uppgiften till dina nätverksadministratörer.

Validera roller

Testa varje roll så att du kan säkerställa att modellen filtreras korrekt. Det åstadkommer du enkelt med kommandot Visa som på menyfliken Modellering.

När modellen har dynamiska regler som använder DAX-funktionen USERNAME, så var noga med att testa för förväntade och oväntade värden. Vid inbäddning Power BI innehåll– särskilt med hjälp av scenariot embed for your customers – kan applogiken skicka val annat värde som ett effektivt identitetsanvändarnamn. Se till, närhelst så är möjligt, att oavsiktliga eller skadliga värden resulterar i filter som inte returnerar några rader.

Tänk på ett exempel som använder Power BI Embedded, och där appen skickar användarens jobbroll som det faktiska användarnamnet: Det är antingen Hanterare eller Arbetare. Hanterare kan se alla rader, men arbetare kan bara se rader där värdet för kolumnen 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 "Arbetare", returnerar Alla tabellrader. Så ett oavsiktligt värde, som exempelvis "Arbtare", returnerar oavsiktligt alla tabellrader. Därför är det säkrare att skriva ett uttryck som testar för alla förväntade värden. I följande förbättrade regeluttryck kommer ett oväntat värde att resultera i att tabellen inte returnerar några rader.

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

Utforma partiell RLS

Ibland kan beräkningar behöva värden som inte begränsas av RLS-filter. En rapport kan exempelvis behöva visa förhållandet mellan den intjänade intäkten för rapportanvändarens försäljningsregion och alla intjänade intäkter.

Även om det inte är möjligt för ett DAX-uttryck för att åsidosätta RLS – i själva verket kan det inte ens fastställa huruvida RLS genomdrivs eller ej – så kan du använda en sammanfattningsmodellstabell. Sammanfattningsmodelltabellen får en fråga om att hämta intäkter för "alla regioner" och den begränsas inte av något RLS-filter.

Låt oss se hur dessa designkrav kan implementeras. Se först till följande modelldesign:

Modellen består av fyra tabeller:

• Tabellen Säljare har en rad per säljare. Den innehåller kolumnen EmailAddress som lagrar e-postadressen för respektive säljare. Den här tabellen är dold.
• Tabellen Försäljning har en rad per order. Det innehåller måttet Intäkter i % för hela regionen, som är utformat att returnera en kvot av intäkterna som intjänats i rapportanvändarens region i förhållande till intäkterna som intjänats i alla regioner.
• Tabellen Datum har en rad per datum och tillåter filtrering och gruppering efter år och månad.
• SalesRevenueSummary är en beräknad tabell. Den lagrar totala intäkter för respektive orderdatum. Den här tabellen är dold.

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

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

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

[EmailAddress] = USERNAME()

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

Relation	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 Säljare med hjälp av DAX-funktionen USERNAME. Kolumnvärdet för 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 Datum och SalesRevenueSummary.

Följande uttryck definierar måttet Intäkter i % för hela regionen:

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

Undvik att använda RLS

Undvik att använda RLS när det är det vettigaste alternativet. Om du bara har ett litet antal förenklade RLS-regler som tillämpar statiska filter bör du överväga att publicera flera datamängder i stället. Ingen av datamängderna definierar roller eftersom varje datamängd innehåller data för en speciell rapportanvändares publik, som har samma databehörigheter. Skapa sedan en arbetsyta per målgrupp och tilldela åtkomstbehörigheter till arbetsytan eller appen.

Anta att ett företag som bara har två försäljningsregioner bestämmer sig för att publicera en datamängd för varje försäljningsregion till olika arbetsytor. Datamängderna genomdriver 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 helt enkelt bara olika datamängdsparametervärden. Säljare tilldelas åtkomst till endast en av arbetsytorna (eller de publicerade apparna).

Det finns flera fördelar med att undvika RLS:

• Förbättrade frågeprestanda: Det kan leda till förbättrade prestanda på grund av färre filter.
• Mindre modeller: Även om det resulterar i fler modeller, så är modellerna mindre i storlek. Mindre modeller kan förbättra svarstiderna för fråge och datauppdatering, särskilt om värdkapaciteten belastas. Det är också enklare att bevara modellstorlekarna under kapacitetens storleksgränser. 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, t. ex. Publicera på webben, kan användas.

Det finns dock flera fördelar med att undvika RLS:

• Flera arbetsytor: En arbetsyta krävs för varje rapportanvändares målgrupp. Om appar publiceras, så betyder det även att det finns en app per respektive rapportanvändares målgrupp.
• Duplicerat innehåll: Rapporter och instrumentpaneler måste skapas för varje arbetsyta. Detta kräver ytterligare arbete och tid för konfiguration och underhåll.
• Högpriviligierade användare: Högpriviligierade användare som tillhör flera målgrupper för rapportanvändare kan inte se någon samlad datavy. De måste öppna flera rapporter (från olika arbetsytor eller appar).

Felsöka RLS

Om RLS ger oväntade resultat, så kontrollera följande saker:

• Det föreligger felaktiga relationer mellan modelltabellerna vad gäller kolumnmappningar och filterriktningar.
• Relationsegenskapen Tillämpa säkerhetsfilter i båda riktningarna har inte konfigurerats korrekt. Mer information finns i Vägledning för dubbelriktad relation.
• Tabellerna innehåller inga data.
• Felaktiga värden läses in i tabellerna.
• Användaren har mappats till flera roller.
• Modellen innehåller aggregeringstabeller, och RLS-reglerna kan inte konsekvent filtrera aggregeringar och annan information. Mer information finns i Använda aggregeringar i Power BI Desktop (RLS för aggregeringar).

När en enskild användare inte kan se några data kan det bero på att användarens UPN inte lagras eller har angetts inkorrekt. Detta kan inträffa plötsligt om användarkontot har ändrats till följd av en namnändring.

När en enskild användare kan se alla data, är det möjligt att hen har åtkomst till rapporter direkt på arbetsytan och att hen är datamängdsägaren. RLS framtvingas endast när:

• Rapporten öppnas i en app.
• Rapporten öppnas på en arbetsyta och användaren mappas till rollen Tittare.

Nästa steg

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

• Säkerhet på radnivå (RLS) med Power BI
• Begränsa dataåtkomsten med säkerhet på radnivå (RLS) för Power BI Desktop
• Modellrelationer i Power BI Desktop
• Har du några frågor? Fråga Power BI Community
• Har du förslag? Bidra till att förbättra Power BI