Sikkerhed på rækkeniveau med Power BI

Række-niveau sikkerhed (RLS) begrænser dataadgang for specifikke brugere. Filtre begrænser data på rækkeniveau, og du definerer filtre inden for rollerne. I Power BI-tjeneste har brugere med adgang til et arbejdsområde adgang til semantiske modeller i det pågældende arbejdsområde. Sikkerhed på rækkeniveau begrænser kun dataadgang for brugere med fremvisertilladelser . Det gælder ikke for administratorer, medlemmer eller bidragydere.

For at implementere RLS skal du følge denne overordnede arbejdsgang:

1. Definér roller og regler i Power BI Desktop ved brug af DAX-filterudtryk.
2. Publicish den semantiske model og rapporter til Power BI-tjeneste.
3. Tilføj medlemmer til roller i Power BI-tjeneste.
4. Valider ved at bruge funktionen Test som rolle for at bekræfte, at datafiltrering fungerer som forventet.

Du kan konfigurere RLS til importerede semantiske modeller i Power BI Desktop eller Power BI-tjeneste. Du kan også konfigurere sikkerhed på rækkeniveau på semantiske modeller, der bruger DirectQuery, f.eks. SQL Server. For Analysis Services- eller Azure Analysis Services-liveforbindelser konfigurerer du sikkerhed på rækkeniveau i modellen, ikke i Power BI. Sikkerhedsindstillingen vises ikke for semantiske modeller med direkte forbindelse.

Definer roller og regler i Power BI Desktop

Du kan definere roller og regler i Power BI Desktop. Med denne editor kan du skifte mellem at bruge standardrullelistegrænsefladen og en DAX-grænseflade. Når du publicerer til Power BI, publicerer du også rolledefinitionerne.

Sådan definerer du sikkerhedsroller:

1. Importér data til din Power BI Desktop-rapport, eller konfigurer en DirectQuery-forbindelse.

   Bemærk

   Du kan ikke definere roller i Power BI Desktop til direkte forbindelser til Analysis Services. Det skal du gøre i Analysis Services-modellen.

2. Under fanen Modellering skal du vælge Administrer roller.

3. I vinduet Administrer roller skal du vælge Ny for at oprette en ny rolle.

4. Under Roller skal du angive et navn til rollen og vælge Angiv.

   Bemærk

   Du kan ikke definere en rolle med et komma, f.eks London,ParisRole. .

5. Under Vælg tabeller skal du vælge den tabel, du vil anvende et sikkerhedsfilter på rækkeniveau på.

6. Under Filtrer data skal du bruge standardeditoren til at definere dine roller. De oprettede udtryk returnerer en true- eller false-værdi.

   Bemærk

   Det er ikke alle sikkerhedsfiltre på rækkeniveau, der understøttes i Power BI, der kan defineres ved hjælp af standardeditoren. Begrænsninger omfatter udtryk, der i dag kun kan defineres ved hjælp af DAX, herunder dynamiske regler som username() eller userprincipalname(). Hvis du vil definere roller ved hjælp af disse filtre, skal du skifte til at bruge DAX-editoren.

7. Du kan også vælge Skift til DAX-editor for at skifte til at bruge DAX-editoren til at definere din rolle. DAX-udtryk returnerer en værdi af typen true eller false. Eksempel: [Entity ID] = “Value”. DAX-editoren er komplet med autofuldførelse af formler (intellisense). Du kan markere afkrydsningsfeltet over udtryksfeltet for at validere udtrykket og knappen X over udtryksfeltet for at gendanne ændringer.

   Bemærk

   Du kan bruge username() i dette udtryk. Vær opmærksom på, at username() har formatet DOMAIN\username i Power BI Desktop. I Power BI-tjeneste og Power BI-rapportserver er det i formatet af brugerens hovednavn (UPN). I dette udtryksfelt skal du desuden bruge kommaer til at adskille DAX-funktionsargumenter, selvom du bruger en landestandard, der normalt bruger semikolonseparatorer, f.eks. fransk eller tysk.

8. Du kan skifte tilbage til standardeditoren ved at vælge Skift til standardeditor. Alle ændringer, der foretages i begge editorgrænseflader, bevares, når der skiftes grænseflader, når det er muligt. Når du definerer en rolle ved hjælp af DAX-editoren, der ikke kan defineres i standardeditoren, bliver du bedt om at få en advarsel om, at skift af editor kan medføre, at nogle oplysninger går tabt, hvis du forsøger at skifte til standardeditoren. Hvis du vil beholde disse oplysninger, skal du vælge Annuller og fortsætte med kun at redigere denne rolle i DAX-editoren.

   Bemærk

   I dette udtryksfelt skal du bruge kommaer til at adskille DAX-funktionsargumenter, selvom du bruger en landestandard, der normalt bruger semikolonseparatorer, f.eks. fransk eller tysk.

9. Vælg Gem.

Du kan ikke tildele brugere til en rolle i Power BI Desktop. Du tildeler dem i Power BI-tjeneste. Du kan aktivere dynamisk sikkerhed i Power BI Desktop ved at gøre brug af DAX-funktionerne username() eller userprincipalname() og have konfigureret de korrekte relationer.

Almindelige DAX-filtermønstre

Følgende eksempler viser almindelige DAX-filterudtryk, du kan bruge, når du definerer RLS-roller:

• Statisk RLS — Begrænser data til en fast værdi:

  [Region] = "West"
  

• Dynamisk RLS med UPN — Begrænser data baseret på den indloggede brugers e-mailadresse:

  [UserEmail] = USERPRINCIPALNAME()
  

• Dynamisk RLS med BRUGERNAVN — Begrænser data baseret på brugerens domæne og brugernavn:

  [UserDomain] = USERNAME()
  

• Dynamisk RLS med CUSTOMDATA — Begrænser data baseret på en brugerdefineret streng, der sendes fra indlejringsapplikationen:

  [AppRole] = CUSTOMDATA()
  

  Bemærk

  CUSTOMDATA() bruges primært i indlejrede scenarier, hvor applikationen sender en brugerdefineret effektiv identitetsstreng via Power BI REST API.

Dynamisk RLS er den mest almindelige tilgang, fordi den tillader en enkelt rolledefinition, der filtrerer data forskelligt for hver bruger, baseret på en brugerkorttabel i din datamodel.

Tovejs krydsfiltrering

Filtrering af sikkerhed på rækkeniveau bruger som standard envejsfiltre, uanset om relationerne er angivet til en enkelt retning eller tovejs.

Du kan aktivere tovejskrydsfiltrering manuelt med sikkerhed på rækkeniveau ved at markere relationen og markere afkrydsningsfeltet Anvend sikkerhedsfilter i begge retninger . Vælg denne indstilling, når du også har implementeret dynamisk sikkerhed på rækkeniveau på serverniveau, hvor sikkerhed på rækkeniveau er baseret på brugernavn eller logon-id. Hvis en tabel deltager i flere tovejsrelationer, kan du kun vælge denne mulighed for én af disse relationer.

Du kan finde flere oplysninger i Tovejskrydsfiltrering ved hjælp af DirectQuery i Power BI og artiklen Sikring af den tabellariske BI Semantiske model .

Administrer sikkerhed på din model

Hvis du vil administrere sikkerheden på din semantiske model, skal du åbne det arbejdsområde, hvor du har gemt din semantiske model i Fabric, og udføre følgende trin:

1. I Fabric skal du vælge menuen Flere indstillinger for en semantisk model. Denne menu vises, når du holder markøren over et semantisk modelnavn.

   

2. Vælg Sikkerhed.

   

Sikkerhed fører dig til siden Sikkerhed på rolleniveau, hvor du føjer medlemmer til en rolle, du har oprettet. Brugere med Bidragyder eller højere arbejdsområde-roller ser Sikkerhedsmuligheden og kan tildele brugere til en rolle. Semantisk modelejerskab eller byggetilladelse kan også være påkrævet afhængigt af scenariet.

Administrer rollemedlemskab

Tilføj medlemmer

I Power BI-tjeneste kan du føje et medlem til rollen ved at skrive mailadressen eller navnet på brugeren eller sikkerhedsgruppen. Du kan ikke tilføje grupper, der er oprettet i Power BI. Du kan tilføje medlemmer uden for din organisation. For vejledning i, hvordan RLS fungerer med eksterne B2B-gæstebrugere, se Overvejelser for eksterne (B2B-gæste) brugere.

Du kan bruge følgende grupper til at konfigurere sikkerhed på rækkeniveau.

• Distributionsgruppe
• Mailaktiveret gruppe
• Microsoft Entra Security Group

Du kan se, hvor mange medlemmer der er en del af rollen, ud fra tallet i parentes ved siden af rollenavnet eller ved siden af Medlemmer.

Fjern medlemmer

Du kan fjerne medlemmer ved at vælge X ud for deres navn.

Validering af rollen i Power BI-tjeneste

Du kan validere, at den rolle, du definerede, fungerer korrekt i Power BI-tjeneste ved at teste rollen.

1. Vælg Flere indstillinger (...) ud for rollen.
2. Vælg Test som rolle.

Når rapporten indlæses, skal du verificere følgende:

• Rapporten viser kun datarækker, der matcher filterudtrykket defineret i rollen.
• Visualiseringer, tabeller og diagrammer afspejler de filtrerede data, ikke hele datasættet.
• Hvis du bruger dynamisk RLS, svarer dataene til den identitet, der vises i Now-visningen som header.

I sidehovedet vises den rolle, der anvendes. Test andre roller, en kombination af roller eller en bestemt person ved at vælge Vis nu som. Her kan du se vigtige tilladelsesoplysninger vedrørende den person eller rolle, der testes. Du kan få flere oplysninger om, hvordan tilladelser interagerer med sikkerhed på rækkeniveau, under RLS-brugeroplevelse.

Test andre rapporter, der er forbundet til den semantiske model, ved at vælge Visning i sidehovedet. Du kan kun teste rapporter, der er placeret i det samme arbejdsområde som din semantiske model.

Hvis du vil vende tilbage til normal visning, skal du vælge Tilbage til Sikkerhed på rækkeniveau.

Brug af DAX-funktionen username() eller userprincipalname()

Du kan drage fordel af DAX-funktionerne username() eller userprincipalname() i dit datasæt. Du kan bruge dem i udtryk i Power BI Desktop. Når du publicerer din model, bruges den i Power BI-tjeneste.

I Power BI Desktop returnerer username() en bruger i formatet DOMÆNE\Bruger, og userprincipalname() returnerer en bruger i formatet user@contoso.com.

I Power BI-tjeneste returnerer brugernavn() og userprincipalname() både brugerens hovednavn (UPN). Dette ligner en mailadresse.

Brug af sikkerhed på rækkeniveau med arbejdsområder i Power BI

Hvis du publicerer din Power BI Desktop-rapport i et arbejdsområde i Power BI-tjeneste, anvendes rollerne for sikkerhed på rækkeniveau på medlemmer, der er tildelt rollen Fremviser i arbejdsområdet. Selvom seere får tilladelsen Opret til den semantiske model, gælder sikkerhed på rækkeniveau stadig. Hvis seere med buildtilladelser f.eks. bruger Analysér i Excel, er deres visning af dataene begrænset af sikkerhed på rækkeniveau. Workspace-medlemmer, der er tildelt administrator, medlem eller bidragyder , har redigeringstilladelse til den semantiske model, og derfor gælder RLS ikke for dem. Hvis RLS skal gælde for personer i et arbejdsområde, kan du kun tildele dem rollen Læser . Læs mere om roller i arbejdsområder.

Overvejelser for eksterne (B2B-gæste) brugere

Hvis du deler Power BI indhold med eksterne brugere gennem Microsoft Entra B2B, er det vigtigt at forstå, hvordan RLS interagerer med gæstebrugeridentiteter.

UPN-resolution for B2B-gæster

Når en ekstern B2B-gæstebruger tilgår en Power BI-rapport, returnerer USERPRINCIPALNAME() DAX-funktionen typisk en e-mail-lignende identifikator (for eksempel user@partner.com). I nogle konfigurationer kan den returnere et gæste-UPN i formatet #EXT# (for eksempel user_partner.com#EXT#@yourtenant.onmicrosoft.com).

Denne sondring er vigtig for dynamisk RLS. Hvis din brugermapping-tabel gemmer et andet identifikatorformat end det USERPRINCIPALNAME() , der returneres, vil filterudtrykket ikke matche, og gæstebrugeren kan måske ikke se nogen data eller forkerte data.

BRUGERNAVN()-adfærd for B2B-gæster

USERNAME() DAX-funktionen returnerer brugerens domæne/brugernavnsidentifikator. For B2B-gæstebrugere returnerer denne funktion typisk gæstens hjemmelejer UPN (for eksempel user@partner.com) i stedet for et domæne/brugernavn-format. Fordi USERNAME() og USERPRINCIPALNAME() ofte returnerer samme værdi for B2B-gæster, bruger USERPRINCIPALNAME() de fleste implementeringer for konsistens.

[UserEmail] = USERPRINCIPALNAME()

Hvor kolonnen indeholder e-mailadresser UserEmail for user@partner.com både interne og eksterne brugere.

Fejlfinding: Ekstern gæst ser ingen data

Hvis en B2B-gæstebruger ser en tom rapport eller modtager en besked om "ingen data", følg disse trin:

1. Verificér det returnerede UPN-format - Opret et testmål ved hjælp af USERPRINCIPALNAME() og vis det i et kortbillede. Få gæstebrugeren til at se rapporten for at se den faktiske returnerede værdi.
2. Tjek brugermapping-tabellen - Bekræft, at mapping-tabellen indeholder en række med en værdi, der præcist matcher det, der USERPRINCIPALNAME() returnerer for den pågældende gæst.
3. Tjek for kasusfølsomhed – DAX-strengsammenligninger er som standard små og små bogstavs-følsomme, men sørg for, at din datakilde ikke har introduceret små og små bogstavs-følsomme værdier.
4. Gennemgå tværlejende adgangsindstillinger - Hvis din organisation bruger kryds-lejer adgangspolitikker, kan disse påvirke, hvilket UPN-format der præsenteres for Power BI.
5. Test med den faktiske gæstebruger – Funktionen Test som rolle bruger din egen identitet. Valider altid med den rigtige eksterne gæstekonto. For mere information om deling af Power BI indhold med eksterne brugere, se Distribuer Power BI indhold til eksterne gæstebrugere med Microsoft Entra B2B.

Overvejelser og begrænsninger

Du kan se de aktuelle begrænsninger for sikkerhed på rækkeniveau i cloudmodeller her:

• Hvis du tidligere har defineret roller og regler i Power BI-tjeneste, skal du genoprette dem i Power BI Desktop.
• Du kan kun definere sikkerhed på rækkeniveau på de semantiske modeller, der er oprettet med Power BI Desktop. Hvis du vil aktivere sikkerhed på rækkeniveau for semantiske modeller, der er oprettet med Excel, skal du først konvertere dine filer til PBIX-filer (Power BI Desktop). Få mere at vide.
• Tjenesteprincipaler kan ikke føjes til en rolle for sikkerhed på rækkeniveau. Derfor anvendes sikkerhed på rækkeniveau ikke for apps, der bruger en tjenesteprincipal som den endelige effektive identitet.
• Det er kun import- og DirectQuery-forbindelser, der understøttes. Direkte forbindelser til Analysis Services håndteres i modellen i det lokale miljø.
• Med RLS aktiveret kan brugen af USERELATIONSHIP()-funktionen i DAX-forespørgsler og målinger forårsage uventede fejl. For at omgå dette problem skal du redesigne dine DAX-udtryk for at undgå USERELATIONSHIP() og i stedet bruge modelniveau-relationer eller andre DAX-mønstre.
• Funktionen Test som rolle/Vis som rolle fungerer ikke for DirectQuery-modeller, hvor enkeltlogon (SSO) er aktiveret.
• Funktionen Test som rolle/visning som rolle viser kun rapporter fra arbejdsområdet semantiske modeller.
• Funktionen Test som rolle/Vis som rolle fungerer ikke for sideinddelte rapporter.

Husk, at hvis en Power BI-rapport refererer til en række med RLS konfigureret, vises den samme meddelelse som for et slettet eller ikke-eksisterende felt. For disse brugere ser det ud til, at rapporten er brudt.

ofte stillede spørgsmål

Spørgsmål: Hvad nu, hvis jeg tidligere har oprettet roller og regler for et datasæt i Power BI-tjeneste? Virker de stadig, hvis jeg ikke gør noget?
Svar: Nej, visualiseringer gengives ikke korrekt. Du skal genoprette rollerne og reglerne i Power BI Desktop og derefter publicere til Power BI-tjeneste.

Spørgsmål: Kan jeg oprette disse roller for Analysis Services-datakilder?
Svar: Ja, hvis du har importeret dataene i Power BI Desktop. Hvis du bruger en direkte forbindelse, kan du ikke konfigurere sikkerhed på rækkeniveau i Power BI-tjeneste. Du definerer sikkerhed på rækkeniveau i Analysis Services-modellen i det lokale miljø.

Spørgsmål: Kan jeg bruge sikkerhed på rækkeniveau til at begrænse de kolonner eller målinger, der er tilgængelige for mine brugere?
Svar: Nej, hvis en bruger har adgang til en bestemt række med data, kan vedkommende se alle kolonner med data for den pågældende række. Hvis du vil begrænse adgangen til kolonner og kolonnemetadata, skal du overveje at bruge sikkerhed på objektniveau.

Spørgsmål: Giver sikkerhed på rækkeniveau mig mulighed for at skjule detaljerede data, men give adgang til data, der er opsummeret i visualiseringer?
Svar: Nej, du sikrer individuelle rækker med data, men brugerne kan altid se enten detaljerne eller de opsummerede data.

Spørgsmål: Min datakilde har allerede defineret sikkerhedsroller (f.eks. SQL Server-roller eller SAP BW-roller). Hvad er relationen mellem disse roller og sikkerhed på rækkeniveau?
Svar: Svaret afhænger af, om du importerer data eller bruger DirectQuery. Hvis du importerer data til dit Power BI-datasæt, bruges sikkerhedsrollerne i din datakilde ikke. I dette tilfælde skal du definere sikkerhed på rækkeniveau for at gennemtvinge sikkerhedsregler for brugere, der opretter forbindelse i Power BI. Hvis du bruger DirectQuery, bruges sikkerhedsrollerne i din datakilde. Når en bruger åbner en rapport, sender Power BI en forespørgsel til den underliggende datakilde, som anvender sikkerhedsregler på dataene baseret på brugerens legitimationsoplysninger.

Spørgsmål: Kan en bruger tilhøre mere end én rolle?
Svar: En bruger kan tilhøre flere roller, og rollerne er additive. Hvis en bruger f.eks. tilhører både rollerne "Salg" og "Marketing", kan vedkommende se data for begge disse roller.

Relateret indhold

• Begræns dataadgang med sikkerhed på rækkeniveau for Power BI Desktop
• Planlægning af Power BI-implementering: Rapportér planlægning af forbrugersikkerhed
• Sikkerhed på rækkeniveau for integrerede scenarier for ISV'er
• Distribuer Power BI indhold til eksterne gæstebrugere med Microsoft Entra B2B

Spørgsmål? Prøv at spørge Forslag til Power BI-community'et ? Bidrag med idéer til forbedring af Power BI