Konfigurera säkerhet på radnivå
Datamodellutvecklare konfigurerar RLS genom att skapa en eller flera roller. En roll har ett unikt namn i modellen och innehåller vanligtvis en eller flera regler. Regler tillämpar filter på modelltabeller med hjälp av DAX-filteruttryck (Data Analysis Expressions).
Anteckning
Som standard har en datamodell inga roller. En datamodell utan roller innebär att användare (som har behörighet att fråga datamodellen) har åtkomst till alla modelldata.
Tips
Du kan definiera en roll som inte innehåller några regler. I det här fallet ger rollen åtkomst till alla rader i alla modelltabeller. Den här rollkonfigurationen är lämplig för en administratörsanvändare som har behörighet att visa alla data.
För modeller som utvecklats i Microsoft Power BI Desktop kan du skapa, validera och hantera roller i Power BI Desktop. För Microsoft Azure Analysis Services- eller SQL Server Analysis Services-modeller kan du skapa, validera och hantera roller med hjälp av SQL Server Data Tools (SSDT).
Dessutom kan du skapa och hantera roller med hjälp av SQL Server Management Studio eller med hjälp av ett externt verktyg, till exempel Tabular Editor.
Använd star schemadesignobjekt
Det första steget för att uppnå en effektiv RLS-lösning är att utveckla en väldesignad modell. Vi rekommenderar att du använder star schemadesignobjekt för att skapa en modell som består av dimensions- och faktatabeller. Vanligtvis tillämpar Power BI regler för att filtrera dimensionstabeller, och modellrelationer sprider effektivt dessa filter till faktatabeller.
Följande bild är datamodelldiagrammet Tailspin Toys försäljningsanalys. Den visar en star schemadesign som innehåller en enda faktatabell med namnet Försäljning. De andra fyra tabellerna är dimensionstabeller som stöder analys av försäljningsmått efter datum, delstat, region och produkt. Modellrelationer ansluter alla tabeller. Dessa relationer sprider filter (direkt eller indirekt) till tabellen Försäljning .
Den här modelldesignen stöder exempel som presenteras i den här modulen.
Definiera regler
Regeluttryck utvärderas i radkontext. Radkontext innebär att uttrycket utvärderas för varje rad med hjälp av kolumnvärdena för den raden. När uttrycket returnerar TRUE kan användaren "se" raden.
Tips
Mer information om radkontext finns i modulen Lägg till beräknade tabeller och kolumner i Power BI Desktop modeller. I den här modulen beskrivs processen med att lägga till modellberäkningar, men den innehåller även en enhet som introducerar och beskriver radkontext.
Du kan definiera regler som antingen är statiska eller dynamiska.
Statiska regler
Statiska regler använder DAX-uttryck som refererar till konstanter.
Tänk på följande regel som tillämpas på tabellen Region som begränsar dataåtkomsten till Försäljning i New England:
'Region'[Region] = "New England"
I följande steg förklaras Hur Power BI tillämpar regeln.
Filtrera tabellen Region , vilket resulterar i en synlig rad (för New England).
Använd modellrelationen för att sprida tabellfiltret Region till tabellen Delstat , vilket resulterar i sex synliga rader (New England-regionen innehåller sex delstater).
Använd modellrelationen för att sprida tabellfiltret Delstat till tabellen Försäljning , vilket resulterar i tusentals synliga rader (försäljningsfakta för de delstater som tillhör new england-regionen).
Den enklaste statiska regeln som du kan skapa begränsar åtkomsten till alla tabellrader. Överväg följande regel som tillämpas på tabellen Försäljningsinformation (visas inte i modelldiagrammet):
FALSE()
Den här regeln säkerställer att användarna inte kan komma åt tabelldata. Regeln kan vara användbar när säljare tillåts visa aggregerade försäljningsresultat (från tabellen Försäljning ), men inte information på ordernivå.
Det är enkelt och effektivt att definiera statiska regler. Överväg att använda statiska regler när du bara behöver skapa ett fåtal av dem, vilket kan vara fallet för Tailspin Toys, som bara har sex regioner. Tänk dock på vissa nackdelar: att konfigurera statiska regler kan innebära stora ansträngningar för att skapa och konfigurera. Statiska regler kräver också att du uppdaterar och publicerar om datauppsättningen när nya regioner introduceras.
Om det finns flera regler för installation och du förväntar dig att nya regler kommer att läggas till i framtiden bör du överväga att använda dynamiska regler i stället.
Dynamiska regler
Dynamiska regler använder specifika DAX-funktioner som returnerar miljövärden (till skillnad från konstanter). Miljövärden returneras från följande specifika DAX-funktioner:
USERNAME eller USERPRINCIPALNAME: När du använder scenariot För din organisation returnerar dessa funktioner ett textvärde som beskriver den autentiserade användaren. När du använder scenariot För dina kunder returnerar de ett textvärde som appen skickar.
CUSTOMDATA: När du använder scenariot För din organisation returnerar den här funktionen customdata-egenskapen som skickas i anslutningssträng. När du använder scenariot För dina kunder returneras ett textvärde som appen skickar.
Anteckning
Funktionen USERNAME returnerar användaren i formatet DOMAIN\username när den används i Power BI Desktop. Men när den används i Power BI-tjänst returneras formatet för användarens huvudnamn (UPN), till exempel username@tailspintoys.com. Du kan också använda USERPRINCIPALNAME funktionen , som alltid returnerar användaren i UPN-format.
Överväg en reviderad modelldesign som nu innehåller tabellen (dold) AppUser . Varje AppUser-tabellrad beskriver ett användarnamn och en region. En modellrelation till tabellen Region sprider filter från tabellen AppUser .
Följande regel som tillämpas på tabellen AppUser begränsar dataåtkomsten till den autentiserade användarens regioner:
'AppUser'[UserName] = USERPRINCIPALNAME()
Det är enkelt och effektivt att definiera dynamiska regler när en modelltabell lagrar användarnamnsvärden. Med dynamiska regler kan du framtvinga en datadriven RLS-design . När säljare till exempel läggs till eller tas bort från tabellen AppUser (eller tilldelas till olika regioner) fungerar den här designmetoden.
Viktigt
När du använder scenariot USERNAMEFör dina kunder behöver funktionerna och USERPRINCIPALNAME inte returnera ett faktiskt användarnamn. I stället kan din app skicka valfritt textvärde för att filtrera modellen.
Validera roller
När du skapar roller kontrollerar du att du testar dem för att säkerställa att de tillämpar rätt filter. För datamodeller som skapas i Power BI Desktop gör funktionen Visa som att du kan visa rapporten när olika roller tillämpas och olika användarnamnsvärden skickas.
Konfigurera rollmappningar
Rollmappning görs på olika sätt beroende på inbäddningsscenariot.
När du använder scenariot För din organisation måste du konfigurera rollmappningar innan användare får åtkomst till Power BI-innehåll. Rollmappning innebär att tilldela Microsoft Azure Active Directory säkerhetsobjekt till roller. Säkerhetsobjekt kan vara användarkonton eller säkerhetsgrupper.
Tips
När det är möjligt är det en bra idé att mappa roller till säkerhetsgrupper. På så sätt finns det färre mappningar och sedan kan du delegera hanteringen av gruppmedlemskap till nätverksadministratörerna.
För Power BI Desktop utvecklade modeller utförs rollmappning vanligtvis i Power BI-tjänst. För Azure Analysis Services eller SQL Server Analysis Services modeller görs rollmappning vanligtvis i SQL Server Management Studio (SSMS).
När du använder scenariot För dina kunder utför appen rollmappning vid körning. Din applogik anger en eller flera effektiva identiteter för att framtvinga RLS. Inställningen av effektiva identiteter beskrivs senare i den här modulen.
Mer information om hur du konfigurerar RLS finns i följande artiklar: