Säkerhet på radnivå (RLS) med Power BI

Säkerhet på radnivå (RLS) begränsar dataåtkomsten för specifika användare av en Power BI semantisk modell. Filter begränsar data på radnivå och du definierar filter i roller. I Power BI-tjänst har användare med åtkomst till en arbetsyta åtkomst till semantiska modeller på den arbetsytan. RLS begränsar endast dataåtkomst för användare med visningsbehörighet . Det gäller inte för arbetsyteadministratörs-, medlems- eller deltagarroller .

Följ det här arbetsflödet på hög nivå för att implementera RLS:

1. Definiera roller och regler i Power BI Desktop med DAX-filteruttryck.
2. Publicera semantikmodellen och rapportera till služba Power BI.
3. Lägg till medlemmar till roller i služba Power BI.
4. Verifiera genom att använda funktionen Testa som roll för att bekräfta att datafiltrering fungerar som förväntat.

Du kan konfigurera RLS för importerade semantiska modeller i Power BI Desktop eller služba Power BI. Du kan också konfigurera RLS på semantiska modeller som använder DirectQuery, till exempel SQL Server. För Analysis Services- eller Azure Analysis Services-liveanslutningar konfigurerar du säkerhet på radnivå i modellen, inte i Power BI. Säkerhetsalternativet visas inte för semantiska liveanslutningsmodeller.

Note

Den här artikeln beskriver RLS för Power BI semantiska modeller specifikt. Information om datasäkerhet i andra Microsoft Fabric objekt finns i Säkerhet i Microsoft Fabric.

Note

För Direct Lake-semantiska modeller i Microsoft Fabric stöds RLS. Men om en DAX-fråga återgår till DirectQuery-läge på grund av funktioner som inte stöds gäller fortfarande RLS-filter, men prestandaegenskaperna kan ändras. Övervaka frågeåterställningsbeteende i appen Fabric kapacitetsmått.

Definiera roller och regler i Power BI Desktop

Du kan definiera roller och regler i Power BI Desktop. Med den här redigeraren kan du växla mellan att använda standardlistegränssnittet och ett DAX-gränssnitt. När du publicerar till Power BI publicerar du även rolldefinitionerna.

Så här definierar du säkerhetsroller:

1. Importera data till din Power BI Desktop-rapport eller konfigurera en DirectQuery-anslutning.

   Note

   Du kan inte definiera roller för live-anslutningar i Power BI Desktop för Analysis Services. Du måste göra det i Analysis Services-modellen.

2. På fliken Modellering väljer du Hantera roller.

3. I fönstret Hantera roller väljer du Ny för att skapa en ny roll.

4. Under Roller anger du ett namn för rollen och trycker på Enter.

   Note

   Du kan inte definiera en roll med kommatecken, till exempel London,ParisRole.

5. Under Välj tabeller väljer du den tabell som du vill använda ett säkerhetsfilter på radnivå för.

6. Under Filtrera data använder du standardredigeraren för att definiera dina roller. De uttryck som skapas returnerar ett sant eller falskt värde. Ett DAX-filter utvärderar TRUE/FALSE för varje rad. Endast rader som returnerar TRUE är synliga Allt annat tas bort helt.

   Note

   Alla säkerhetsfilter på radnivå som stöds i Power BI kan inte definieras med hjälp av standardredigeraren. Begränsningarna omfattar uttryck som i dag bara kan definieras med DAX, inklusive dynamiska regler som username() eller userprincipalname(). Om du vill definiera roller med hjälp av dessa filter växlar du till att använda DAX-redigeraren.

7. Du kan också välja Växla till DAX-redigeraren för att växla till att använda DAX-redigeraren för att definiera din roll. DAX-uttryck returnerar ett värde som är sant eller falskt. Exempel: [Entity ID] = “Value”. DAX-redigeraren är komplett med automatisk komplettering för formler (intellisense). Du kan markera kryssrutan ovanför uttrycksrutan för att verifiera uttrycket och X-knappen ovanför uttrycksrutan för att återställa ändringar.

   Note

   Du kan använda username() i det här uttrycket. Tänk på att username() har formatet DOMAIN\username i Power BI Desktop. I Power BI-tjänst och Power BI-rapportserver är det i formatet för användarens användarhuvudnamn (UPN). I den här uttrycksrutan använder du dessutom kommatecken för att separera DAX-funktionsargument även om du använder ett språk som normalt använder semikolonavgränsare, till exempel franska eller tyska.

8. Du kan växla tillbaka till standardredigeraren genom att välja Växla till standardredigeraren. Alla ändringar som görs i något av redigeringsgränssnitten sparas när du byter gränssnitt när det är möjligt. När du definierar en roll med hjälp av DAX-redigeraren som inte kan definieras i standardredigeraren, uppmanas du om du försöker växla till standardredigeraren med en varning om att växlande redigerare kan leda till att viss information går förlorad. Om du vill behålla den här informationen väljer du Avbryt och fortsätter endast att redigera den här rollen i DAX-redigeraren.

   Note

   I den här uttrycksrutan använder du kommatecken för att separera DAX-funktionsargument även om du använder ett språk som normalt använder semikolonavgränsare, till exempel franska eller tyska.

9. Välj Spara.

Du kan inte tilldela användare till en roll i Power BI Desktop. Du tilldelar dem i Power BI-tjänst. Du kan aktivera dynamisk säkerhet i Power BI Desktop genom att använda DAX-funktionerna username() eller userprincipalname() och ha rätt relationer konfigurerade.

Vanliga DAX-filtermönster för RLS-roller

I följande exempel visas vanliga DAX-filteruttryck som du kan använda när du definierar RLS-roller i Power BI Desktop:

• Statisk RLS – begränsar data till ett fast värde:

  [Region] = "West"
  

• Dynamisk RLS med UPN – begränsar data baserat på den inloggade användarens e-postadress:

  [UserEmail] = USERPRINCIPALNAME()
  

• Dynamisk RLS med USERNAME – Begränsar data baserat på användarens domän och användarnamn:

  [UserDomain] = USERNAME()
  

• Dynamisk RLS med CUSTOMDATA – Begränsar data baserat på en anpassad sträng som skickas från inbäddningsprogrammet:

  [AppRole] = CUSTOMDATA()
  

  Note

  CUSTOMDATA() används främst i inbäddade scenarier där programmet skickar en anpassad effektiv identitetssträng via Power BI REST API.

Dynamisk RLS är den vanligaste metoden eftersom den tillåter att en enskild rolldefinition filtrerar data på olika sätt för varje användare, baserat på en tabell med användarmappning i datamodellen.

Exempel: Filtrera Power BI försäljningsdata efter region

Anta att du har en Sales tabell med kolumnerna Region, Productoch Amount. Du vill begränsa användare som tilldelats rollen "Väst" så att de bara ser rader där regionen är "West".

I DAX-filterfältet för rollen "West" anger du följande uttryck:

[Region] = "West"

Före filtrering (alla data):

Region	Product	Tid
Väst	Widget A	500
Öst	Widget B	300
Väst	Widget C	450
Syd	Widget A	200
Öst	Widget C	375

Efter filtrering (vy för "West"-rollanvändare):

Region	Product	Tid
Väst	Widget A	500
Väst	Widget C	450

DAX-uttrycket fungerar som ett radfilter som utvärderar varje rad i tabellen. Endast rader där Region kolumnen är lika med "West" är synliga för användare som tilldelats den rollen.

Tip

Använd funktionen Visa som roll (beskrivs i Verifiera rollen inom služba Power BI) för att verifiera att filtret returnerar de förväntade raderna innan du publicerar rapporten.

Dubbelriktad korsfiltrering med RLS

Som standard använder säkerhetsfiltrering på radnivå enkelriktade filter, oavsett om relationerna är inställda på enkel riktning eller dubbelriktad.

Du kan aktivera dubbelriktad korsfiltrering manuellt med säkerhet på radnivå genom att markera relationen och markera kryssrutan Tillämpa säkerhetsfilter i båda riktningarna . Välj det här alternativet när du också har implementerat dynamisk säkerhet på radnivå på servernivå, där säkerhet på radnivå baseras på användarnamn eller inloggnings-ID. Om en tabell deltar i flera dubbelriktade relationer kan du bara välja det här alternativet för en av dessa relationer.

Caution

Aktivering av dubbelriktad säkerhetsfiltrering kan påverka frågeprestanda negativt, särskilt i modeller med många relationer eller stora datamängder. Testa noggrant innan du implementerar i produktion.

Mer information finns i Dubbelriktad korsfiltrering med DirectQuery i Power BI och den tekniska artikeln Skydda tabell-BI-semantikmodellen .

Hantera säkerhet på din semantiska modell

Om du vill hantera säkerheten för din semantiska modell öppnar du arbetsytan där du sparade din semantiska modell i Microsoft Fabric och gör följande:

1. I Microsoft Fabric väljer du menyn Fler alternativ för en semantisk modell. Den här menyn visas när du hovrar på ett semantiskt modellnamn.

   

2. Välj Säkerhet.

   

Säkerhet öppnar sidan för säkerhet på radnivå där du lägger till medlemmar i en roll som du har skapat. Användare med rollen deltagare i arbetsytan eller högre ser alternativet Säkerhet och kan tilldela användare till en roll. Semantisk modellägarskap eller Skapa-behörighet kan också krävas beroende på scenariot.

Note

Du kan bara hantera säkerhet på semantiska modeller som har säkerhetsroller på radnivå som redan har definierats i Power BI Desktop eller när du redigerar din datamodell i služba Power BI. Om din semantiska modell inte redan har definierat roller kan du inte hantera säkerheten i služba Power BI.

Hantera RLS-rollmedlemskap i služba Power BI

Lägga till medlemmar i en RLS-roll

I služba Power BI kan du lägga till en medlem i en RLS-roll genom att skriva in e-postadressen eller namnet på användaren eller säkerhetsgruppen. Du kan inte lägga till grupper som skapats i Power BI. Du kan lägga till medlemmar utanför organisationen. Vägledning om hur RLS fungerar med externa B2B-gästanvändare finns i Överväganden för externa (B2B-gäst)-användare.

Du kan använda följande Microsoft Entra ID och e-postaktiverade grupper för att konfigurera säkerhet på radnivå:

• Distributionsgrupp
• E-postaktiverad grupp
• Microsoft Entra säkerhetsgrupp – Om säkerhetsgruppen innehåller externa B2B-gästanvändare, se Överväganden för externa (B2B-gäst) användare för kända begränsningar.

Important

Microsoft 365 grupper stöds inte och kan inte läggas till i några RLS-roller. Endast de grupptyper som anges ovan stöds för RLS-rollmedlemskap.

Du kan se hur många medlemmar som är en del av rollen med talet inom parenteser bredvid rollnamnet eller bredvid Medlemmar.

Ta bort medlemmar från en RLS-roll

Du kan ta bort medlemmar genom att välja X bredvid deras namn.

Verifiera rollen i služba Power BI

Du kan kontrollera att RLS-rollen som du definierade fungerar korrekt i služba Power BI genom att testa rollen.

1. Välj Fler alternativ (...) bredvid rollen.
2. Välj Test som roll.

Note

instrumentpaneler är inte tillgängliga för test med funktionen Testa som roll. Du omdirigeras till rapporten som publicerades från Power BI Desktop med den här semantiska modellen, om det finns en sådan.

Kontrollera följande när rapporten läses in:

• Rapporten visar endast datarader som matchar filteruttrycket som definierats i rollen.
• Visuella objekt, tabeller och diagram återspeglar filtrerade data, inte hela datamängden.
• Om du använder dynamisk RLS motsvarar data den identitet som visas i rubriken Nu visas som.

I sidhuvudet visas den roll som tillämpas. Testa andra roller, en kombination av roller eller en specifik person genom att välja Visa som nu. Här ser du viktig behörighetsinformation som rör den person eller roll som testas. Mer information om hur behörigheter interagerar med RLS finns i RLS-användarupplevelsen.

Testa andra rapporter som är anslutna till den semantiska modellen genom att välja Visa i sidhuvudet. Du kan bara testa rapporter som finns på samma arbetsyta som din semantiska modell.

Om du vill återgå till normal visning väljer du Tillbaka till säkerhet på radnivå.

Note

Funktionen Testa som roll fungerar inte för DirectQuery-semantiska modeller med enkel inloggning (SSO) aktiverat. Dessutom kan inte alla aspekter av en rapport valideras i funktionen Testa som roll, inklusive Q&A-visualiseringar, visualiseringar för snabba insikter och .

Tip

Om Test as role inte visar de förväntade resultaten kan du prova följande:

• Kontrollera att syntaxen för DAX-filteruttrycket är korrekt och refererar till de högra kolumnnamnen.
• Kontrollera att du har valt rätt roll att testa.
• För dynamisk RLS bekräftar du att tabellen för användarmappning innehåller matchande värden för USERPRINCIPALNAME() eller USERNAME().
• För DirectQuery-semantiska modeller med SSO aktiverat stöds inte test som roll . Logga i stället in som en faktisk användare av visningsrollen för att verifiera datafiltrering.

Använda DAX-funktionen USERNAME() eller USERPRINCIPALNAME()

Du kan dra nytta av DAX-funktionerna username() eller userprincipalname() i din datauppsättning. Du kan använda dem i uttryck i Power BI Desktop. När du publicerar din modell används den inom Power BI-tjänst.

I Power BI Desktop returnerar username() en användare i formatet DOMAIN\User och userprincipalname() returnerar en användare i formatet user@contoso.com.

Inom Power BI-tjänst returnerar både username() och userprincipalname() användarens huvudnamn (UPN). Detta ser ut ungefär som en e-postadress.

Använd RLS med arbetsytor i Power BI

Om du publicerar din Power BI Desktop-rapport till en arbetsyta i Power BI-tjänsten, tillämpas RLS-rollerna på medlemmar som har tilldelats rollen Visningsprogram i arbetsytan. Även om Tittarna får build-behörigheter för den semantiska modellen gäller RLS fortfarande. Om användare med build-behörigheter till exempel använder Analysera i Excel begränsas deras vy av data av RLS. Arbetsytemedlemmar som tilldelats administratör, medlem eller deltagare har redigeringsbehörighet för den semantiska modellen och därför gäller inte RLS för dem. Om du vill att RLS ska gälla för personer på en arbetsyta kan du bara tilldela dem rollen Läsare . Mer information finns i roller i arbetsytor.

Överväganden för externa (B2B-gäst) användare

Om du delar Power BI innehåll med externa användare via Microsoft Entra B2B bör du vara medveten om följande överväganden för RLS.

Microsoft Entra säkerhetsgrupper med externa medlemmar

Microsoft Entra säkerhetsgrupper som innehåller externa B2B-gästanvändare kanske inte fungerar som förväntat när de används för RLS-rollmedlemskap. I vissa konfigurationer – särskilt när den externa användaren har ett gästtypskonto (i stället för ett konto av medlemstyp) – utvärderas gästens gruppmedlemskap inte korrekt av služba Power BI när RLS-filter används.

Rekommenderad lösning: I stället för att lägga till externa användare i RLS-roller via Microsoft Entra säkerhetsgrupper lägger du till dem direkt i rollen via e-postadress. E-postadressen knyts till användarens B2B-konto. Detta säkerställer att deras identitet matchas korrekt när RLS-filter tillämpas. Mer information finns i Hantera RLS-rollmedlemskap i služba Power BI.

För organisationer med många externa användare bör du överväga att använda dynamisk RLS med USERPRINCIPALNAME() i stället för gruppbaserat rollmedlemskap. Den här metoden utvärderar varje användares identitet individuellt och undviker problemet med gruppmedlemskapslösningen helt och hållet.

Important

Om du för närvarande använder Microsoft Entra säkerhetsgrupper för RLS-rollmedlemskap och dessa grupper inkluderar B2B-gästanvändare kontrollerar du att gästanvändarna ser rätt filtrerade data. Om de inte gör det lägger du till externa användare direkt i RLS-rollen via e-postadress.

Note

Den exakta omfattningen av den här begränsningen kan variera beroende på din Microsoft Entra ID konfiguration och vilken typ av B2B-gästinbjudan som används. Testa alltid med faktiska gästanvändarkonton innan du förlitar dig på gruppbaserad RLS för extern åtkomst.

Om problemet kvarstår efter att du har tillämpat lösningen kan du läsa Felsök: Extern B2B-gäst ser inga data i en Power BI rapport för ytterligare diagnostiksteg.

UPN-upplösning för B2B-gäster i Power BI RLS

När en extern B2B-gästanvändare får åtkomst till en Power BI rapport returnerar dax-funktionen USERPRINCIPALNAME() vanligtvis en e-postliknande identifierare (till exempel user@partner.com). I vissa konfigurationer kan det returnera ett gäst-UPN i #EXT# formatet (till exempel user_partner.com#EXT#@yourtenant.onmicrosoft.com).

Den här skillnaden är viktig för dynamisk RLS. Om tabellen för användarmappning lagrar ett annat ID-format än vad USERPRINCIPALNAME() returnerar, kommer filteruttrycket inte att matcha, och gästanvändaren kanske inte ser några eller felaktiga data.

USERNAME() beteende för B2B-gäster i Power BI RLS

DAX-funktionen USERNAME() returnerar användarens domain\username identifierare. För B2B-gästanvändare USERNAME() returnerar ofta en UPN-liknande identifierare som liknar USERPRINCIPALNAME(), beroende på konfiguration (till exempel user@partner.com) i stället för ett domain\username format. Eftersom USERNAME() och USERPRINCIPALNAME() ofta returnerar samma värde för B2B-gäster används USERPRINCIPALNAME() de flesta implementeringar för konsekvens.

Tip

Om din befintliga dynamiska RLS använder USERNAME()kontrollerar du vilket värde det returnerar för gästanvändare i din miljö innan du delar innehåll externt. Du kan kontrollera genom att lägga till en kortvisualisering som visar USERNAME() i en testrapport.

Rekommenderad metod: Lagra och använd konsekvent samma ID-format i tabellen för användarmappning som värdet som returneras av USERPRINCIPALNAME(). I de flesta fall förenklar användningen av e-postadresser hanteringen:

[UserEmail] = USERPRINCIPALNAME()

Där kolumnen UserEmail innehåller e-postadresser som user@partner.com för både interna och externa användare.

Note

Värdet som returneras av USERPRINCIPALNAME() är användarens inloggningsidentifierare (UPN), inte nödvändigtvis deras e-postadress. För de flesta användare är dessa samma, men de kan skilja sig åt (till exempel när en användares e-post är ett alias). När du skapar tabellen med användarmappning använder du värdet som returneras av USERPRINCIPALNAME() i stället för attributet mail från Microsoft Entra ID.

Important

Om du använder dynamisk RLS med USERPRINCIPALNAME()ska du alltid testa med faktiska externa gästanvändare. Funktionen Testa som roll använder din egen identitet och avslöjar inte problem med UPN-upplösning för externa användare.

Note

UPN-lösningsbeteendet för B2B-gäster kan variera beroende på din Microsoft Entra ID konfiguration, till exempel åtkomstinställningar för flera klientorganisationer och gästanvändare. Verifiera alltid beteendet i din specifika miljö.

Felsökning: Extern B2B-gäst ser inga data i en Power BI rapport

Om en B2B-gästanvändare ser en tom rapport eller får meddelandet "inga data" följer du dessa steg:

1. Kontrollera det returnerade UPN-formatet – Skapa ett testmått med USERPRINCIPALNAME() och visa det i ett visuellt kort. Låt gästanvändaren visa rapporten för att se det faktiska värdet som returneras.
2. Kontrollera användarmappningstabellen — Bekräfta att mappningstabellen innehåller en rad med ett värde som exakt matchar det värde som USERPRINCIPALNAME() returnerar för den gästen.
3. Kontrollera skiftlägeskänslighet – DAX-strängjämförelser är inte skiftlägeskänsliga som standard, men kontrollera att din datakälla inte har infört skiftlägeskänsliga värden.
4. Granska inställningarna för åtkomst mellan klientorganisationer – Om din organisation använder åtkomstprinciper mellan klientorganisationer kan dessa påverka vilket UPN-format som visas för Power BI.
5. Testa med den faktiska gästanvändaren – Funktionen Testa som roll använder din egen identitet. Verifiera alltid med det verkliga externa gästkontot.
6. Verifiera rolltilldelning – Om en gästanvändare ser mer data än förväntat bekräftar du att de har tilldelats en RLS-roll. Användare som inte har tilldelats någon RLS-roll ser vanligtvis inga data (tomma resultat), eftersom RLS tillämpas men ingen matchande roll tillämpas. Ett DAX-filter utvärderar TRUE/FALSE för varje rad. Endast rader som returnerar TRUE visas. Allt annat tas bort helt.

Mer information om hur du delar Power BI innehåll med externa användare finns i Distribute Power BI innehåll till externa gästanvändare med Microsoft Entra B2B.

Beaktanden och begränsningar

Du kan se de aktuella begränsningarna för säkerhet på radnivå på molnmodeller här:

• Om du tidigare har definierat roller och regler i Power BI-tjänst måste du återskapa dem i Power BI Desktop.
• Du kan bara definiera RLS på de semantiska modeller som skapats med Power BI Desktop. Om du vill aktivera RLS för semantiska modeller som skapats med Excel måste du konvertera filerna till Power BI Desktop-filer (PBIX) först. Läs mer.
• Tjänsthuvudnamn kan inte läggas till i en RLS-roll. Därför tillämpas inte RLS för appar som använder tjänstens huvudnamn som den slutgiltiga effektiva identiteten.
• Endast Import- och DirectQuery-anslutningar stöds. Liveanslutningar till Analysis Services hanteras i den lokala modellen.
• När RLS är aktiverat kan användning av funktionen USERELATIONSHIP() i DAX-frågor och mått orsaka oväntade fel. Undvik det här problemet genom att göra om DAX-uttrycken för att undvika USERELATIONSHIP() och använda relationer på modellnivå eller andra DAX-mönster i stället.
• Funktionen Testa som roll/Visa som roll fungerar inte för DirectQuery-modeller med enkel inloggning (SSO) aktiverat.
• Funktionen Testa som roll/vy som roll visar endast rapporter från semantiska modeller arbetsyta.
• Funktionen Testa som roll/Visa som roll fungerar inte för sidnumrerade rapporter.
• Den tokenbaserade identiteten fungerar bara för DirectQuery-modeller på en kapacitet som är ansluten till en Azure SQL Database som är konfigurerad för att tillåta Microsoft Entra-autentisering. Mer information finns i Bädda in en rapport med tokenbaserad identitet
• Parametern IdentityBlob är en OAuth 2.0-åtkomsttoken för Azure SQL och stöds endast för datauppsättningar med en DirectQuery-anslutning till Azure SQL. Själva mekanismen är Azure-SQL-specifik: Bloben is en Microsoft Entra åtkomsttoken som är begränsad till https://database.windows.net/.default. Det finns ingen motsvarande mekanism för tokenöverföring för andra datakällor i app-äger-data-inbäddning. Mer information finns i REST API-referens för GenerateToken.

Överväganden och begränsningar för dynamisk RLS

När du använder dynamisk säkerhet på radnivå (RLS) med DAX-funktioner som USERPRINCIPALNAME(), USERNAME()eller CUSTOMDATA(), bör du vara medveten om följande överväganden.

B2B-scenarier mellan klienter

I B2B-scenarier returnerar USERPRINCIPALNAME() identiteten enligt služba Power BI, som kan variera beroende på klientkonfigurationen. Det kan visas som något av följande:

• Den externa användarens e-postadress (user@partner.com) eller
• Ett klientupplösat värde, till exempel user_partner.com#EXT#@tenant.onmicrosoft.com

Det exakta formatet är inte garanterat och måste verifieras i din miljö.

Om tabellen för användarmappning lagrar identifierare i ett annat format än vad som USERPRINCIPALNAME() returneras för gästanvändare matchar inte RLS-filteruttrycket och gästen ser inga data eller felaktiga data. Kontrollera alltid det exakta värde som USERPRINCIPALNAME() returnerar för externa användare i din miljö.

Tip

Skapa ett testmått med USERPRINCIPALNAME() och visa det i en kortvisual. Låt externa gästanvändare visa rapporten för att bekräfta att det returnerade värdet matchar tabellen för användarmappning. Det här enkla testet kan förhindra timmar av felsökning av felaktiga identitetsvärden.

Testa med rollbegränsningar med dynamisk RLS

Funktionen Testa som roll i služba Power BI använder din egen identitet vid utvärdering av dynamiska RLS-uttryck. Det innebär att USERPRINCIPALNAME()ditt UPN returneras, inte det för den användare som du försöker simulera. Du kan inte använda Testa som roll för att se vad en specifik B2B-gästanvändare eller ett specifikt tjänsthuvudnamn skulle se.

Testa som roll simulerar rollmedlemskap men replikerar inte helt autentiseringskontexten för en annan användare, särskilt för B2B-gäster eller inbäddade scenarier.

Om du vill verifiera dynamisk RLS för externa användare loggar du in som den faktiska gästanvändaren och visar rapporten direkt. Det här är det enda sättet att bekräfta att USERPRINCIPALNAME() returnerar det förväntade värdet och att RLS-filter stämmer korrekt för den användaren.

Inbäddade scenarier med tjänstens huvudnamn

När en rapport nås via ett inbäddat program som autentiserar med tjänstens huvudnamn USERPRINCIPALNAME() och USERNAME() returnerar tjänstens huvudnamns program-ID eller en tom sträng – inte en slutanvändares identitet.

Dessa funktioner returnerar inte slutanvändaridentitet och kan därför inte användas för användarspecifik filtrering i inbäddningsscenarier för tjänsthuvudnamn. Det innebär att dynamiska RLS-filter baserat på dessa funktioner inte filtrerar data per användare i inbäddade scenarier.

Om du vill använda RLS per användare i inbäddade scenarier använder du funktionen effective identity i Power BI REST API. EffectiveIdentity Skicka objektet med lämpligt användarnamn och roller när du genererar en inbäddningstoken. Om dina RLS-regler använder CUSTOMDATA()skickar du den anpassade datasträngen via EffectiveIdentity.CustomData.

Mer information finns i RLS för inbäddade scenarier för ISV:er.

Important

När du bäddar in med tjänstens huvudnamn ska du alltid testa med faktiska inbäddningstoken som inkluderar EffectiveIdentity för att kontrollera att RLS-filter tillämpas korrekt. Funktionen Test as role i služba Power BI simulerar inte inbäddade autentiseringsflöden.

Tänk på att om en Power BI-rapport refererar till en rad med RLS konfigurerat visas samma meddelande som för ett borttaget eller icke-befintligt fält. För dessa användare ser det ut som att rapporten är trasig.

Vanliga frågor

Fråga: Vad händer om jag tidigare har skapat roller och regler för en datauppsättning i Power BI-tjänst? Fungerar de fortfarande om jag inte gör något?
Svar: Nej, visuella objekt återges inte korrekt. Du måste återskapa rollerna och reglerna i Power BI Desktop och sedan publicera till Power BI-tjänst.

Fråga: Kan jag skapa dessa roller för Analysis Services-datakällor?
Svar: Ja, om du har importerat data till Power BI Desktop. Om du använder en live-anslutning kan du inte konfigurera RLS inom Power BI-tjänst. Du definierar RLS i Analysis Services-modellen lokalt.

Fråga: Kan jag använda RLS för att begränsa vilka kolumner eller mått som mina användare kan komma åt?
Svar: Nej, om en användare har åtkomst till en viss rad med data kan de se alla datakolumner för den raden. Om du vill begränsa åtkomsten till kolumner och kolumnmetadata bör du överväga att använda säkerhet på objektnivå.

Fråga: Låter RLS mig dölja detaljerade data men ge åtkomst till data som sammanfattas i visuella objekt?
Svar: Nej, du skyddar enskilda rader med data, men användarna kan alltid se information eller sammanfattade data.

Fråga: Min datakälla har redan säkerhetsroller definierade (till exempel SQL Server-roller eller SAP BW-roller). Vad är relationen mellan de här rollerna och RLS?
Svar: Svaret beror på om du importerar data eller använder DirectQuery. Om du importerar data till din Power BI-datauppsättning används inte säkerhetsrollerna i datakällan. I det här fallet bör du definiera RLS för att framtvinga säkerhetsregler för användare som ansluter i Power BI. Om du använder DirectQuery används säkerhetsrollerna som finns i datakällan. När en användare öppnar en rapport skickar Power BI en fråga till den underliggande datakällan, som tillämpar säkerhetsregler på data baserat på användarens autentiseringsuppgifter.

Fråga: Kan en användare tillhöra mer än en roll?
Svar: En användare kan tillhöra flera roller och rollerna är additiva. Om en användare till exempel tillhör rollerna "Försäljning" och "Marknadsföring" kan de se data för båda dessa roller.

Relaterat innehåll

• Begränsa dataåtkomst med säkerhet på radnivå (RLS) för Power BI Desktop
• Planering av Power BI-implementering: Rapportera konsumentsäkerhetsplanering
• RLS för inbäddade scenarier för ISV:er
• Distribute Power BI innehåll till externa gästanvändare med Microsoft Entra B2B

Frågor? Prova att fråga Power BI-communityn Förslag? Bidra med idéer för att förbättra Power BI