Sikkerhet på radnivå (RLS) med Power BI

Rad-nivå sikkerhet (RLS) begrenser datatilgang for spesifikke brukere. Filtre begrenser data på radnivå, og du definerer filtre innenfor rollene. I Power Bi-tjeneste har brukere med tilgang til et arbeidsområde tilgang til semantiske modeller i arbeidsområdet. RLS begrenser bare datatilgang for brukere med Visningstillatelser . Det gjelder ikke for administratorer, medlemmer eller bidragsytere.

For å implementere RLS, følg denne overordnede arbeidsflyten:

1. Definer roller og regler i Power BI Desktop ved bruk av DAX-filteruttrykk.
2. Publish den semantiske modellen og rapporter til Power Bi-tjeneste.
3. Legg til medlemmer i rollene i Power Bi-tjeneste.
4. Valider ved å bruke funksjonen Test som rolle for å bekrefte at datafiltrering fungerer som forventet.

Du kan konfigurere RLS for importerte semantiske modeller i Power BI Desktop eller Power Bi-tjeneste. Du kan også konfigurere RLS på semantiske modeller som bruker DirectQuery, for eksempel SQL Server. For Live-tilkoblinger for Analysis Services eller Azure Analysis Services konfigurerer du sikkerhet på radnivå i modellen, ikke i Power BI. Sikkerhetsalternativet vises ikke for semantiske modeller for live-tilkobling.

Definer roller og regler i Power BI Desktop

Du kan definere roller og regler i Power BI Desktop. Med dette redigeringsprogrammet kan du veksle mellom å bruke standard rullegardingrensesnitt og et DAX-grensesnitt. Når du publiserer til Power BI, publiserer du også rolledefinisjonene.

Slik definerer du sikkerhetsroller:

1. Importer data til Power BI Desktop-rapporten, eller konfigurer en DirectQuery-tilkobling.

   Merk

   Du kan ikke definere roller i Power BI Desktop for Live-tilkoblinger for Analysis Services. Du må gjøre dette i Analysis Services-modellen.

2. Fra Modellering-fanen velger du Behandle roller.

3. Velg Ny i vinduet Behandle roller for å opprette en ny rolle.

4. Angi et navn for rollen under Roller, og velg enter.

   Merk

   Du kan for eksempel London,ParisRoleikke definere en rolle med komma.

5. Velg tabellen du vil bruke et sikkerhetsfilter på radnivå i, under Velg tabeller.

6. Bruk standard redigeringsprogram under Filterdata til å definere rollene dine. Uttrykkene som er opprettet, returnerer en sann eller usann verdi. Et DAX-filter evaluerer TRUE/FALSE for hver rad. Bare rader som returnerer TRUE er synlige. Alt annet er helt fjernet.

   Merk

   Ikke alle sikkerhetsfiltre på radnivå som støttes i Power BI, kan defineres ved hjelp av standard redigeringsprogram. Begrensninger inkluderer uttrykk som i dag bare kan defineres ved hjelp av DAX, inkludert dynamiske regler som username() eller userprincipalname(). Hvis du vil definere roller ved hjelp av disse filtrene, bytter du til å bruke DAX-redigeringsprogrammet.

7. Du kan også velge Bytt til DAX-redigeringsprogram for å bytte til å bruke DAX-redigeringsprogrammet til å definere rollen. DAX-uttrykk returnerer en verdi som er sann eller usann. Eksempel: [Entity ID] = “Value”. DAX-redigeringsprogrammet er komplett med autofullføring for formler (intellisense). Du kan merke av for uttrykket over uttrykksboksen for å validere uttrykket og X-knappen over uttrykksboksen for å tilbakestille endringene.

   Merk

   Du kan bruke username() i dette uttrykket. Vær oppmerksom på at username() har formatet DOMAIN\username i Power BI Desktop. I Power Bi-tjeneste og rapportserver for Power BI er det i formatet til brukerens brukerhovednavn (UPN). I denne uttrykksboksen bruker du i tillegg komma til å skille DAX-funksjonsargumenter selv om du bruker en nasjonal innstilling som vanligvis bruker semikolonskilletegn, for eksempel fransk eller tysk.

8. Du kan bytte tilbake til standard redigeringsprogram ved å velge Bytt til standard redigeringsprogram. Alle endringer som gjøres i et redigeringsgrensesnitt, vedvarer når du bytter grensesnitt når det er mulig. Når du definerer en rolle ved hjelp av DAX-redigeringsprogrammet som ikke kan defineres i standardredigeringsprogrammet, blir du bedt om en advarsel om at bytte redigeringsprogram kan føre til at noe informasjon går tapt hvis du prøver å bytte til standardredigeringsprogrammet. Hvis du vil beholde denne informasjonen, velger du Avbryt og fortsetter bare å redigere denne rollen i DAX-redigeringsprogrammet.

   Merk

   I denne uttrykksboksen bruker du komma til å skille DAX-funksjonsargumenter selv om du bruker en nasjonal innstilling som vanligvis bruker semikolonskilletegn, for eksempel fransk eller tysk.

9. Velg Lagre.

Du kan ikke tilordne brukere til en rolle i Power BI Desktop. Du tilordner dem i Power Bi-tjeneste. Du kan aktivere dynamisk sikkerhet i Power BI Desktop ved å bruke DAX-funksjonene username() eller userprincipalname() og ha de riktige relasjonene konfigurert.

Vanlige DAX-filtermønstre

Følgende eksempler viser vanlige DAX-filteruttrykk du kan bruke når du definerer RLS-roller:

• Statisk RLS – Begrenser data til en fast verdi:

  [Region] = "West"
  

• Dynamisk RLS med UPN ΓÇö Begrenser data basert på den innloggede brukerens e-postadresse:

  [UserEmail] = USERPRINCIPALNAME()
  

• Dynamisk RLS med BRUKERNAVN ΓÇö Begrenser data basert på brukerens domene og brukernavn:

  [UserDomain] = USERNAME()
  

• Dynamisk RLS med CUSTOMDATA ΓÇö Begrenser data basert på en egendefinert streng som sendes fra embedding-applikasjonen:

  [AppRole] = CUSTOMDATA()
  

  Merk

  CUSTOMDATA() brukes primært i innebygde scenarioer der applikasjonen sender en tilpasset effektiv identitetsstreng via Power BI REST API.

Dynamisk RLS er den vanligste tilnærmingen fordi den tillater én rolledefinisjon som filtrerer data forskjellig for hver bruker, basert på en brukerkartleggingstabell i datamodellen din.

Eksempel: Filtrering av salgsdata etter region

Anta at du har en Sales tabell med kolonnene Region, Product, og Amount. Du vil begrense brukere som er tildelt rollen "Vest" slik at de kun ser rader hvor regionen er "Vest".

I DAX-filterfeltet for "West"-rollen, skriv inn følgende uttrykk:

[Region] = "West"

Før filtrering (all data):

Etter filtrering (se for «Vest»-rollebrukere):

DAX-uttrykket fungerer som et radfilter som evaluerer hver rad i tabellen. Kun rader der kolonnen Region er lik "Vest" er synlige for brukere tildelt den rollen.

Som standard bruker filtrering av sikkerhet på radnivå enkeltveisfiltre, enten relasjonene er satt til én retning eller toveis. Du kan aktivere toveis kryssfiltrering manuelt med sikkerhet på radnivå ved å merke av for relasjonen og merke av for Bruk sikkerhetsfilter i begge retninger . Vær oppmerksom på at hvis en tabell deltar i flere toveisrelasjoner, kan du bare velge dette alternativet for én av disse relasjonene. Velg dette alternativet når du også har implementert dynamisk sikkerhet på radnivå på servernivå, der sikkerhet på radnivå er basert på brukernavn eller påloggings-ID.

Hvis du vil ha mer informasjon, kan du se toveis kryssfiltrering ved hjelp av DirectQuery i Power BI og teknisk artikkel om sikring av semantisk modell for tabell BI.

Toveis kryssfiltrering

Som standard bruker filtrering av sikkerhet på radnivå enkeltveisfiltre, enten relasjonene er satt til én retning eller toveis.

Du kan aktivere toveis kryssfiltrering manuelt med sikkerhet på radnivå ved å merke av for relasjonen og merke av for Bruk sikkerhetsfilter i begge retninger . Velg dette alternativet når du også har implementert dynamisk sikkerhet på radnivå på servernivå, der sikkerhet på radnivå er basert på brukernavn eller påloggings-ID. Hvis et bord deltar i flere toveis relasjoner, kan du bare velge dette alternativet for ett av disse forholdene.

Hvis du vil ha mer informasjon, kan du se toveis kryssfiltrering ved hjelp av DirectQuery i Power BI og teknisk artikkel om sikring av semantisk modell for tabell BI.

Administrer sikkerhet på modellen

Hvis du vil administrere sikkerhet på semantisk modell, åpner du arbeidsområdet der du lagret semantisk modell i Fabric, og gjør følgende:

1. Velg Menyen Flere alternativer for en semantisk modell i Fabric. Denne menyen vises når du holder pekeren over et semantisk modellnavn.

   

2. Velg Sikkerhet.

   

Sikkerhet tar deg til siden Sikkerhet på rollenivå der du legger til medlemmer i en rolle du opprettet. Brukere med Bidragsyter - eller høyere arbeidsområderoller ser sikkerhetsalternativet og kan tildele brukere til en rolle. Semantisk modelleierskap eller byggetillatelse kan også være nødvendig avhengig av situasjonen.

Administrere rollemedlemskap

Legg til medlemmer

I Power Bi-tjeneste kan du legge til et medlem i rollen ved å skrive inn e-postadressen eller navnet på brukeren eller sikkerhetsgruppen. Du kan ikke legge til grupper som er opprettet i Power BI. Du kan legge til medlemmer eksternt i organisasjonen. For veiledning om hvordan RLS fungerer med eksterne B2B-gjestbrukere, se Vurderinger for eksterne (B2B-gjest) brukere.

Du kan bruke følgende grupper til å konfigurere sikkerhet på radnivå.

• Distribusjonsgruppe
• E-postaktivert gruppe
• Microsoft Entra Sikkerhetsgruppen ΓÇö Hvis sikkerhetsgruppen inneholder eksterne B2B-gjestbrukere, se Vurderinger for eksterne (B2B-gjest) brukere for kjente begrensninger.

Du kan se hvor mange medlemmer som er en del av rollen ved tallet i parentes ved siden av rollenavnet, eller ved siden av Medlemmer.

Fjern medlemmer

Du kan fjerne medlemmer ved å velge X ved siden av navnet.

Validerer rollen i Power Bi-tjeneste

Du kan validere at rollen du definerte fungerer korrekt i Power Bi-tjeneste ved å teste rollen.

1. Velg Flere alternativer (...) ved siden av rollen.
2. Velg Test som rolle.

Når rapporten lastes inn, verifiser følgende:

• Rapporten viser kun datarader som samsvarer med filteruttrykket definert i rollen.
• Visualiseringer, tabeller og diagrammer gjenspeiler de filtrerte dataene, ikke hele datasettet.
• Hvis du bruker dynamisk RLS, tilsvarer dataene identiteten som vises i Overskriften Nå som visning.

I toppteksten på siden vises rollen som brukes. Test andre roller, en kombinasjon av roller eller en bestemt person ved å velge Nå som. Her ser du viktige tillatelsesdetaljer som gjelder personen eller rollen som testes. Hvis du vil ha mer informasjon om hvordan tillatelser samhandler med RLS, kan du se brukeropplevelsen for RLS.

Test andre rapporter som er koblet til den semantiske modellen, ved å velge Visning i toppteksten på siden. Du kan bare teste rapporter i samme arbeidsområde som den semantiske modellen.

Hvis du vil gå tilbake til normalvisning, velger du Tilbake til sikkerhet på radnivå.

Bruke DAX-funksjonen username() eller userprincipalname()

Du kan dra nytte av DAX-funksjonene brukernavn() eller userprincipalname() i datasettet. Du kan bruke dem i uttrykk i Power BI Desktop. Når du publiserer modellen, brukes den i Power Bi-tjeneste.

Brukernavn() i Power BI Desktop

I Power Bi-tjeneste vil brukernavn() og userprincipalname() begge returnere brukerens brukerhovednavn (UPN). Dette ligner på en e-postadresse.

Bruke RLS med arbeidsområder i Power BI

Hvis du publiserer Power BI Desktop-rapporten til et arbeidsområde i Power Bi-tjeneste, brukes RLS-rollene på medlemmer som er tilordnet seerrollen i arbeidsområdet. Selv om seere får kompileringstillatelser til semantisk modell, gjelder RLS fortsatt. Hvis brukere med byggtillatelser for eksempel bruker Analyser i Excel, begrenses visningen av dataene av RLS. Workspace-medlemmer som er tildelt Admin, Member eller Contributor har redigeringstillatelse for den semantiske modellen, og derfor gjelder ikke RLS for dem. Hvis du vil at RLS skal gjelde for personer i et arbeidsområde, kan du bare tilordne dem Seer-rollen . Les mer om roller i arbeidsområder.

Vurderinger for eksterne (B2B-gjest) brukere

Hvis du deler Power BI innhold med eksterne brukere gjennom Microsoft Entra B2B, bør du være oppmerksom på følgende hensyn for RLS.

Entra-sikkerhetsgrupper med eksterne medlemmer

Microsoft Entra-sikkerhetsgrupper som inneholder eksterne B2B-gjestebrukere fungerer kanskje ikke som forventet når de brukes for RLS-rollemedlemskap. I noen konfigurasjoner — spesielt når den eksterne brukeren har en gjestetype konto (i stedet for en medlemskonto) — blir gjestens gruppemedlemskap ikke korrekt evaluert av Power Bi-tjeneste når RLS-filtre håndheves.

Anbefalt løsning: I stedet for å legge til eksterne brukere i RLS-roller gjennom Entra-sikkerhetsgrupper, legg dem direkte til rollen via e-postadresse. E-postadressen overføres til brukerens B2B-konto. Dette sikrer at identiteten deres matches korrekt når RLS-filtre brukes. For mer informasjon, se Administrer rollemedlemskap.

For organisasjoner med mange eksterne brukere, vurder å bruke dynamisk RLS med USERPRINCIPALNAME() i stedet for gruppebasert rollemedlemskap. Denne tilnærmingen vurderer hver brukers identitet individuelt og unngår helt problemet med å løse gruppemedlemskap.

For mer informasjon om deling av innhold med eksterne brukere, se Distribuer Power BI innhold til eksterne gjestebrukere med Microsoft Entra B2B.

Hvis problemet vedvarer etter at løsningen er brukt, se Feilsøking: Ekstern gjest ser ingen data for ytterligere diagnostiske steg.

UPN-resolusjon for B2B-gjester

Når en ekstern B2B-gjestebruker får tilgang til en Power BI rapport, returnerer DAX-funksjonen USERPRINCIPALNAME() vanligvis en e-postlignende identifikator (for eksempel user@partner.com). I noen konfigurasjoner kan den returnere et gjeste-UPN i formatet #EXT# (for eksempel user_partner.com#EXT#@yourtenant.onmicrosoft.com).

Dette skillet er viktig for dynamisk RLS. Hvis brukerkartleggingstabellen din lagrer et annet identifikasjonsformat enn det som USERPRINCIPALNAME() returneres, vil ikke filteruttrykket stemme, og gjestebrukeren kan se ingen data eller feil data.

BRUKERNAVN() atferd for B2B-gjester

DAX-funksjonen USERNAME() returnerer brukerens domene/brukernavn-identifikator. For B2B-gjestebrukere returnerer denne funksjonen vanligvis en UPN-lignende identifikator lik USERPRINCIPALNAME(), avhengig av konfigurasjon (for eksempel user@partner.com) i stedet for et domene\brukernavn-format. Fordi USERNAME() og USERPRINCIPALNAME() ofte returnerer samme verdi for B2B-gjester, bruker USERPRINCIPALNAME() de fleste implementasjoner for konsistens.

[UserEmail] = USERPRINCIPALNAME()

Der kolonnen UserEmail inneholder e-postadresser, for user@partner.com både interne og eksterne brukere.

Feilsøking: Ekstern gjest ser ingen data

Hvis en B2B-gjestebruker ser en tom rapport eller mottar en «ingen data»-melding, følg disse trinnene:

1. Verifiser det returnerte UPN-formatet – Lag et testmål ved hjelp av USERPRINCIPALNAME() og vis det i et kortbilde. La gjestebrukeren se rapporten for å se den faktiske verdien som returneres.
2. Sjekk brukerkartleggingstabellen – Bekreft at kartleggingstabellen inneholder en rad med en verdi som nøyaktig matcher det som USERPRINCIPALNAME() returnerer for den gjesten.
3. Sjekk om det er kasusfølsomhet – DAX-strengsammenligninger er som standard små og små og små bokstaver, men sjekk at datakilden din ikke har introdusert små og små bokstaver.
4. Gjennomgå innstillinger for tilgang på tvers av leietakere Hvis organisasjonen din bruker kryss-leietaker-tilgangspolicyer, kan dette påvirke hvilket UPN-format som presenteres for Power BI.
5. Test med den faktiske gjestebrukeren – Funksjonen Test som rolle bruker din egen identitet. Valider alltid med den ekte eksterne gjestekontoen.
6. Bekreft rolletildeling — Hvis en gjestebruker ser mer data enn forventet, bekreft at de er tildelt en RLS-rolle. Brukere som ikke er tildelt noen RLS-rolle ser vanligvis ingen data (tomme resultater), fordi RLS håndheves, men ingen matchende rolle brukes. Et DAX-filter evaluerer TRUE/FALSE for hver rad. Bare rader som returnerer TRUE er synlige. Alt annet er helt fjernet.

For mer informasjon om deling av Power BI innhold med eksterne brukere, se Distribuer Power BI innhold til eksterne gjestebrukere med Microsoft Entra B2B.

Hensyn og begrensninger

Du kan se gjeldende begrensninger for sikkerhet på radnivå på skymodeller her:

• Hvis du tidligere har definert roller og regler i Power Bi-tjeneste, må du opprette dem på nytt i Power BI Desktop.
• Du kan bare definere RLS på semantiske modeller som er opprettet med Power BI Desktop. Hvis du vil aktivere RLS for semantiske modeller som er opprettet med Excel, må du først konvertere filene til Power BI Desktop-filer (PBIX). Finn ut mer.
• Tjenestekontohavere kan ikke legges til i en RLS-rolle. Følgelig brukes ikke RLS for apper som bruker en tjenestekontohaver som den endelige effektive identiteten.
• Bare import- og DirectQuery-tilkoblinger støttes. Live-tilkoblinger til Analysis Services håndteres i den lokale modellen.
• Med RLS aktivert kan bruk av USERELATIONSHIP()-funksjonen i DAX-spørringer og målinger forårsake uventede feil. For å omgå dette problemet, redesign DAX-uttrykkene dine for å unngå USERELATIONSHIP() og bruk modellnivå-relasjoner eller andre DAX-mønstre i stedet.
• Funksjonen Test som rolle/Vis som rolle fungerer ikke for DirectQuery-modeller med enkel pålogging (SSO) aktivert.
• Funksjonen Test som rolle/visning som rolle viser bare rapporter fra arbeidsområdet for semantiske modeller.
• Funksjonen Test som rolle/Vis som rolle fungerer ikke for paginerte rapporter.
• Den tokenbaserte identiteten fungerer bare for DirectQuery-modeller på en kapasitet som er koblet til en Azure SQL Database som er konfigurert til å tillate Microsoft Entra-godkjenning. For mer informasjon, se Embed en rapport med tokenbasert identitet
• Parameteren 'IdentityBlob' er en OAuth 2.0 tilgangstoken for Azure SQL og støttes kun for datasett med en DirectQuery-tilkobling til Azure SQL. Mekanismen i seg selv er Azure-SQL-spesifikk: Bloben is en Microsoft Entra tilgangstoken med scoped til https://database.windows.net/.default. Det finnes ingen tilsvarende token-overføringsmekanisme for andre datakilder i App-owns-data embedding. For mer informasjon, se REST API-referanse for GenerateToken.

Hensyn og begrensninger for dynamisk RLS

Når du bruker dynamisk rad-nivå sikkerhet (RLS) med DAX-funksjoner som USERPRINCIPALNAME(), USERNAME(), eller CUSTOMDATA(), må du være oppmerksom på følgende hensyn.

B2B tverrleietakerscenarier

I B2B-scenarier returnerer USERPRINCIPALNAME() identiteten slik den er løst av Power Bi-tjeneste, som kan variere avhengig av leietakerkonfigurasjon. Den kan se ut som enten:

• Den eksterne brukerens e-postadresse (user@partner.com), eller
• En leietakerløst verdi som user_partner.com#EXT#@tenant.onmicrosoft.com

Det eksakte formatet er ikke garantert og må valideres i ditt miljø.

Hvis brukerkartleggingstabellen din lagrer identifikatorer i et annet format enn det som USERPRINCIPALNAME() returneres for gjestebrukere, vil ikke RLS-filteruttrykket matche, og gjesten ser ingen data eller feil data. Verifiser alltid den eksakte verdien som returneres for USERPRINCIPALNAME() eksterne brukere i miljøet ditt.

Test som rollebegrensninger med dynamisk RLS

Test som rolle-funksjonen i Power Bi-tjeneste bruker din egen identitet når du evaluerer dynamiske RLS-uttrykk. Dette betyr USERPRINCIPALNAME() at du returnerer UPN-et ditt , ikke brukeren du prøver å simulere. Du kan ikke bruke Test som rolle for å se hva en spesifikk B2B-gjestebruker eller tjenesteleder ville sett.

Test som rolle simulerer rollemedlemskap, men replikerer ikke fullt ut autentiseringskonteksten til en annen bruker, spesielt for B2B-gjester eller innebygde scenarier.

For å validere dynamisk RLS for eksterne brukere, logg inn som den faktiske gjestebrukeren og se rapporten direkte. Dette er den eneste måten å bekrefte at USERPRINCIPALNAME() den returnerer forventet verdi og at RLS-filtre stemmer korrekt for den brukeren.

Innebygde scenarier med tjenesteprinsipper

Når en rapport aksesseres gjennom en innebygd applikasjon som autentiserer seg med en tjenesteprincipal USERPRINCIPALNAME() , og USERNAME() returnerer tjenesteprincipalens applikasjons-ID eller en tom streng – ikke sluttbrukerens identitet.

Disse funksjonene returnerer ikke sluttbrukeridentiteten og kan derfor ikke brukes til per-bruker-filtrering i tjenesteprinsipp-embedding-scenarier. Dette betyr at dynamiske RLS-filtre basert på disse funksjonene ikke filtrerer data per bruker i innebygde scenarioer.

For å anvende per-bruker RLS i innebygde scenarioer, bruk funksjonen effective identity i Power BI REST API. Send objektet EffectiveIdentity med riktig brukernavn og roller når du genererer en embed-token. Hvis RLS-reglene dine bruker CUSTOMDATA(), send den egendefinerte datastrengen gjennom EffectiveIdentity.CustomData.

For mer informasjon, se RLS for Embedded scenarios for ISV-er.

Husk at hvis en Power BI-rapport refererer til en rad med RLS konfigurert, vises den samme meldingen som for et slettet eller ikke-eksisterende felt. For disse brukerne ser det ut til at rapporten er brutt.

vanlige spørsmål

Spørsmål: Hva om jeg tidligere har opprettet roller og regler for et datasett i Power Bi-tjeneste? Fungerer de fortsatt hvis jeg ikke gjør noe?
Svar: Nei, visualobjekter gjengis ikke riktig. Du må opprette rollene og reglene i Power BI Desktop på nytt og deretter publisere til Power Bi-tjeneste.

Spørsmål: Kan jeg opprette disse rollene for Analysis Services-datakilder?
Svar: Ja, hvis du importerte dataene til Power BI Desktop. Hvis du bruker en live-tilkobling, kan du ikke konfigurere RLS i Power Bi-tjeneste. Du definerer RLS lokalt i Analysis Services-modellen.

Spørsmål: Kan jeg bruke RLS til å begrense kolonnene eller målene som er tilgjengelige for brukerne mine?
Svar: Nei, hvis en bruker har tilgang til en bestemt rad med data, kan de se alle kolonnene med data for denne raden. Hvis du vil begrense tilgangen til kolonner og kolonnemetadata, kan du vurdere å bruke sikkerhet på objektnivå.

Spørsmål: Lar RLS meg skjule detaljerte data, men gi tilgang til data oppsummert i visualobjekter?
Svar: Nei, du sikrer individuelle rader med data, men brukere kan alltid se enten detaljene eller de summerte dataene.

Spørsmål: Datakilden min har allerede definerte sikkerhetsroller (for eksempel SQL Server-roller eller SAP BW-roller). Hva er relasjonen mellom disse rollene og RLS?
Svar: Svaret avhenger av om du importerer data eller bruker DirectQuery. Hvis du importerer data til Power BI-datasettet, brukes ikke sikkerhetsrollene i datakilden. I dette tilfellet bør du definere RLS for å håndheve sikkerhetsregler for brukere som kobler til i Power BI. Hvis du bruker DirectQuery, brukes sikkerhetsrollene i datakilden. Når en bruker åpner en rapport, sender Power BI en spørring til den underliggende datakilden, som bruker sikkerhetsregler på dataene basert på brukerens legitimasjon.

Spørsmål: Kan en bruker tilhøre mer enn én rolle?
Svar: En bruker kan tilhøre flere roller, og rollene er additive. Hvis en bruker for eksempel tilhører rollene Salg og Markedsføring, kan de se data for begge disse rollene.

Relatert innhold

• Begrense datatilgang med sikkerhet på radnivå (RLS) for Power BI Desktop
• Planlegging av Power BI-implementering: Planlegging av rapportforbrukersikkerhet
• RLS for Embedded-scenarier for ISV-er
• Distribuer Power BI innhold til eksterne gjestebrukere med Microsoft Entra B2B

Spørsmål? Prøv å spørre Power BI-fellesskap forslag? Bidra med ideer for å forbedre Power BI