Merk
Tilgang til denne siden krever autorisasjon. Du kan prøve å logge på eller endre kataloger.
Tilgang til denne siden krever autorisasjon. Du kan prøve å endre kataloger.
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:
- Definer roller og regler i Power BI Desktop ved bruk av DAX-filteruttrykk.
- Publish den semantiske modellen og rapporter til Power Bi-tjeneste.
- Legg til medlemmer i rollene i Power Bi-tjeneste.
- 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.
Merk
Denne artikkelen dekker RLS for Power BI semantiske modeller spesifikt. For datasikkerhet i andre Fabric elementer, se Security i Microsoft Fabric.
Merk
For Direct Lake-semantiske modeller i Microsoft Fabric støttes RLS. Men hvis en DAX-spørring faller tilbake til DirectQuery-modus på grunn av ikke-støttede funksjoner, gjelder fortsatt RLS-filtre, men ytelsesegenskapene kan endres. Overvåk spørrings-fallback-oppførsel i Fabric kapasitetsmetrikk-appen.
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:
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.
Fra Modellering-fanen velger du Behandle roller.
Velg Ny i vinduet Behandle roller for å opprette en ny rolle.
Angi et navn for rollen under Roller, og velg enter.
Merk
Du kan for eksempel
London,ParisRoleikke definere en rolle med komma.Velg tabellen du vil bruke et sikkerhetsfilter på radnivå i, under Velg tabeller.
Bruk standard redigeringsprogram under Filterdata til å definere rollene dine. Uttrykkene som er opprettet, returnerer en sann eller usann verdi.
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.
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.
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.
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 sendt 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 det tillater én rolledefinisjon som filtrerer data forskjellig for hver bruker, basert på en brukerkartleggingstabell i datamodellen din.
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.
Forsiktig!
Å aktivere toveis sikkerhetsfiltrering kan påvirke spørringsytelsen negativt, spesielt i modeller med mange relasjoner eller store datasett. Test grundig før du deployerer til produksjon.
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:
Velg Menyen Flere alternativer for en semantisk modell i Fabric. Denne menyen vises når du holder pekeren over et semantisk modellnavn.
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.
Merk
Du kan bare administrere sikkerhet på modeller som har sikkerhetsroller på radnivå som allerede er definert i Power BI Desktop, eller når du redigerer datamodellen i Power BI-tjenesten. Hvis modellen ikke allerede har definerte roller, kan du ikke administrere sikkerhet i Power BI-tjenesten.
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 Security Group
Viktig!
Microsoft 365-grupper støttes ikke og kan ikke legges til noen roller. Kun gruppetypene nevnt ovenfor støttes for RLS-rollemedlemskap.
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.
- Velg Flere alternativer (...) ved siden av rollen.
- Velg Test som rolle.
Merk
Instrumentbord er ikke tilgjengelige for testing ved hjelp av alternativet Test som rolle . Du blir omdirigert til rapporten som ble publisert fra Power BI Desktop med denne semantiske modellen, hvis en slik finnes.
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å.
Merk
Funksjonen Test som rolle fungerer ikke for DirectQuery-modeller med enkel pålogging (SSO) aktivert. I tillegg kan ikke alle aspekter ved en rapport valideres i funksjonen Test som rolle, inkludert Q&A-visualiseringer, visualiseringer for hurtiginnsikter og Copilot.
Tips
Hvis Test som rolle ikke gir forventede resultater, prøv følgende:
- Sjekk at DAX-filterets uttrykkssyntaks er korrekt og refererer til riktige kolonnenavn.
- Sørg for at du har valgt riktig rolle å teste.
- For dynamisk RLS, bekreft at brukerkartleggingstabellen inneholder matchende verdier for
USERPRINCIPALNAME()ellerUSERNAME(). - For DirectQuery-modeller med SSO aktivert, støttes ikke Test som rolle. Logg heller inn som en faktisk Viewer-rolle-bruker for å validere datafiltrering.
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, er det viktig å forstå hvordan RLS samhandler med gjestebrukeridentiteter.
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 gjestens hjemmeleietaker UPN (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.
Tips
Hvis din eksisterende dynamiske RLS bruker, USERNAME()sjekk hvilken verdi den gir til gjestebrukere i miljøet før du deler innhold eksternt. Du kan sjekke ved å legge til et visuelt kort som vises USERNAME() i en testrapport.
Anbefalt tilnærming: Lagre og bruk konsekvent samme identifikasjonsformat i brukerkarttabellen som verdien returnert av USERPRINCIPALNAME(). I de fleste tilfeller forenkler bruk av e-postadresser administrasjonen:
[UserEmail] = USERPRINCIPALNAME()
Der kolonnen UserEmail inneholder e-postadresser, for user@partner.com både interne og eksterne brukere.
Merk
Verdien som returneres er USERPRINCIPALNAME() brukerens innloggingsidentifikator (UPN), ikke nødvendigvis e-postadressen deres. For de fleste brukere er disse de samme, men de kan variere (for eksempel når en brukers e-post er et alias). Når du bygger brukermapping-tabellen din, bruk verdien som returneres av USERPRINCIPALNAME() i stedet for attributten mail fra Microsoft Entra ID.
Viktig!
Hvis du bruker dynamisk RLS med USERPRINCIPALNAME(), test alltid med faktiske eksterne gjestebrukere.
Funksjonen Test som rolle bruker din egen identitet og vil ikke avsløre UPN-løsningsproblemer for eksterne brukere.
Merk
UPN-oppløsningsoppførsel for B2B-gjester kan variere avhengig av din Microsoft Entra ID-konfigurasjon, som for eksempel kryss-leietaker-tilgangsinnstillinger og gjestebrukertype. Valider alltid atferden i ditt spesifikke miljø.
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:
-
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. -
Sjekk brukerkartleggingstabellen – Bekreft at kartleggingstabellen inneholder en rad med en verdi som nøyaktig matcher det som
USERPRINCIPALNAME()returnerer for den gjesten. - 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.
- 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.
- Test med den faktiske gjestebrukeren – Funksjonen Test som rolle bruker din egen identitet. Valider alltid med den ekte eksterne gjestekontoen. 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.
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