Veiledning for sikkerhet på radnivå (RLS) i Power BI Desktop

Denne artikkelen er rettet mot deg som datamodellerer som arbeider med Power BI Desktop. Den beskriver gode utformingspraksiser for å håndheve sikkerhet på radnivå (RLS) i datamodellene.

Det er viktig å forstå at RLS filtrerer tabellrader. De kan ikke konfigureres til å begrense tilgangen til modellobjekter, inkludert tabeller, kolonner eller mål.

Merk

Denne artikkelen beskriver ikke RLS eller hvordan du konfigurerer den. Hvis du vil ha mer informasjon, kan du se Begrense datatilgang med sikkerhet på radnivå (RLS) for Power BI Desktop.

Den dekker heller ikke fremtving av RLS i live-tilkoblinger til eksterne modeller med Azure Analysis Services eller SQL Server Analysis Services. I slike tilfeller håndheves RLS av Analysis Services. Når Power BI kobler til ved hjelp av enkel pålogging (SSO), håndhever Analysis Services RLS (med mindre kontoen har administratorrettigheter).

Opprett roller

Det er mulig å opprette flere roller. Når du vurderer tillatelsesbehovene for én enkelt rapportbruker, bør du arbeide for å opprette én enkelt rolle som gir alle disse tillatelsene, i stedet for en utforming der en rapportbruker skal være medlem av flere roller. Det er fordi en rapportbruker kan tilordne til flere roller, enten direkte ved hjelp av brukerkontoen eller indirekte av medlemskap i sikkerhetsgrupper. Flere rolletilordninger kan resultere i uventede resultater.

Når en rapportbruker er tilordnet flere roller, blir RLS-filtre additive. Det betyr at rapportbrukere kan se tabellrader som representerer unionen av disse filtrene. I noen scenarioer er det heller ikke mulig å garantere at en rapportbruker ikke ser rader i en tabell. Så i motsetning til tillatelser som brukes på SQL Server-databaseobjekter (og andre tillatelsesmodeller), gjelder ikke prinsippet «én gang nektet alltid».

Vurder en modell med to roller: Den første rollen, kalt Arbeidere, begrenser tilgangen til alle lønnstabellrader ved hjelp av følgende regeluttrykk:

FALSE()

Merk

En regel returnerer ingen tabellrader når uttrykket evalueres til FALSE.

En annen rolle, kalt Ledere, gir likevel tilgang til alle tabellrader for lønn ved hjelp av følgende regeluttrykk:

TRUE()

Vær forsiktig: Hvis en rapportbruker tilordner til begge rollene, vil de se alle tabellrader for lønn .

Optimaliser RLS

RLS fungerer ved automatisk å bruke filtre på hver DAX-spørring, og disse filtrene kan ha en negativ innvirkning på spørringsytelsen. Så effektiv RLS kommer ned til god modellutforming. Det er viktig å følge veiledningen for modellutforming, som beskrevet i følgende artikler:

• Forstå stjerneskjema og viktigheten for Power BI
• Alle artikler om relasjonsveiledning som finnes i veiledningsdokumentasjonen for Power BI

Generelt sett er det ofte mer effektivt å fremtvinge RLS-filtre på dimensjonstypetabeller, og ikke faktatypetabeller. Du kan også stole på godt utformede relasjoner for å sikre at RLS-filtre overføres til andre modelltabeller. RLS-filtre overføres bare gjennom aktive relasjoner. Så unngå å bruke LOOKUPVALUE DAX-funksjonen når modellrelasjoner kan oppnå samme resultat.

Når RLS-filtre håndheves i DirectQuery-tabeller og det finnes relasjoner til andre DirectQuery-tabeller, må du passe på å optimalisere kildedatabasen. Det kan innebære utforming av passende indekser eller bruk av faste beregnede kolonner. Hvis du vil ha mer informasjon, kan du se Veiledning for DirectQuery-modell i Power BI Desktop.

Mål RLS-innvirkning

Det er mulig å måle ytelsesvirkningen av RLS-filtre i Power BI Desktop ved hjelp av Ytelsesanalyse. Først må du bestemme varigheten for rapportvisualobjekter når RLS ikke håndheves. Bruk deretter kommandoen Vis som på båndfanen Modellering til å fremtvinge RLS og bestemme og sammenligne spørringsvarigheter.

Konfigurere rolletilordninger

Når du har publisert til Power BI, må du tilordne medlemmer til semantiske modellroller (tidligere kalt et datasett). Bare semantiske modelleiere eller administratorer for arbeidsområder kan legge til medlemmer i roller. Hvis du vil ha mer informasjon, kan du se Sikkerhet på radnivå (RLS) med Power BI (Administrer sikkerhet på modellen).

Medlemmer kan være brukerkontoer, sikkerhetsgrupper, distribusjonsgrupper eller e-postaktiverte grupper. Når det er mulig, anbefaler vi at du tilordner sikkerhetsgrupper til semantiske modellroller. Det innebærer administrasjon av sikkerhetsgruppemedlemskap i Microsoft Entra ID (tidligere kjent som Azure Active Directory). Muligens delegerer den oppgaven til nettverksadministratorene.

Validere roller

Test hver rolle for å sikre at den filtrerer modellen riktig. Det gjøres enkelt ved å bruke kommandoen Vis som på fanen Modelleringsbånd .

Når modellen har dynamiske regler som bruker USERNAME DAX-funksjonen, må du teste for forventede og uventede verdier. Når du bygger inn Power BI-innhold , spesielt ved hjelp av innebygging for kundenes scenario, kan applogikken sende en hvilken som helst verdi som et effektivt identitetsbrukernavn. Når det er mulig, må du sørge for at utilsiktede eller skadelige verdier resulterer i filtre som ikke returnerer noen rader.

Vurder et eksempel ved hjelp av Power BI embedded, der appen sender brukerens jobbrolle som det effektive brukernavnet: Det er enten «Leder» eller «Arbeider». Ledere kan se alle rader, men arbeidere kan bare se rader der typekolonneverdien er intern.

Følgende regeluttrykk er definert:

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    TRUE()
)

Problemet med dette regeluttrykket er at alle verdier, unntatt «Arbeider», returnerer alle tabellrader. Så, en utilsiktet verdi, som "Wrker", returnerer utilsiktet alle tabellrader. Derfor er det tryggere å skrive et uttrykk som tester for hver forventede verdi. I det følgende forbedrede regeluttrykket resulterer en uventet verdi i at tabellen ikke returnerer noen rader.

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    IF(
        USERNAME() = "Manager",
        TRUE(),
        FALSE()
    )
)

Utform delvis RLS

Noen ganger trenger beregninger verdier som ikke er begrenset av RLS-filtre. En rapport må for eksempel kanskje vise et forhold mellom inntekter som er opptjent for rapportbrukerens salgsområde over alle inntjente inntekter.

Selv om det ikke er mulig for et DAX-uttrykk å overstyre RLS– faktisk kan det ikke engang fastslå at RLS håndheves – du kan bruke en sammendragsmodelltabell. Tabellen for sammendragsmodell blir spurt om å hente inntekter for «alle områder», og den er ikke begrenset av noen RLS-filtre.

La oss se hvordan du kan implementere dette utformingskravet. Først bør du vurdere følgende modellutforming:

Modellen består av fire tabeller:

• Selger-tabellen lagrer én rad per selger. Den inneholder Kolonnen EmailAddress , som lagrer e-postadressen for hver selger. Denne tabellen er skjult.
• Salg-tabellen lagrer én rad per ordre. Det inkluderer målet Omsetning i % alle områder , som er utformet for å returnere et forhold mellom omsetning opptjent av rapportbrukerens område over inntekter opptjent av alle områder.
• Datotabellen lagrer én rad per dato og tillater filtrering og gruppering av år og måned.
• SalesRevenueSummary er en beregnet tabell. Den lagrer total omsetning for hver ordredato. Denne tabellen er skjult.

Følgende uttrykk definerer den beregnede tabellen SalesRevenueSummary :

SalesRevenueSummary =
SUMMARIZECOLUMNS(
    Sales[OrderDate],
    "RevenueAllRegion", SUM(Sales[Revenue])
)

Merk

En aggregasjonstabell kan oppnå samme utformingskrav.

Følgende RLS-regel brukes i Selger-tabellen :

[EmailAddress] = USERNAME()

Hver av de tre modellrelasjonene er beskrevet i følgende tabell:

Relasjon	Bekrivelse
	Det finnes en mange-til-mange-relasjon mellom tabellene Selger og Salg . RLS-regelen filtrerer EmailAddress-kolonnen i den skjulte Selger-tabellen ved hjelp av USERNAME DAX-funksjonen. Områdekolonneverdien (for rapportbrukeren) overføres til Salg-tabellen.
	Det finnes en én-til-mange-relasjon mellom tabellene Dato og Salg .
	Det finnes en én-til-mange-relasjon mellom tabellene Date og SalesRevenueSummary .

Følgende uttrykk definerer målet Omsetning i % alle områder :

Revenue % All Region =
DIVIDE(
    SUM(Sales[Revenue]),
    SUM(SalesRevenueSummary[RevenueAllRegion])
)

Merk

Pass på å unngå å avsløre sensitive fakta. Hvis det bare er to områder i dette eksemplet, er det mulig for en rapportbruker å beregne omsetning for det andre området.

Når du bør unngå å bruke RLS

Noen ganger er det fornuftig å unngå å bruke RLS. Hvis du bare har noen få forenklede RLS-regler som bruker statiske filtre, bør du vurdere å publisere flere semantiske modeller i stedet. Ingen av de semantiske modellene definerer roller fordi hver semantiske modell inneholder data for en bestemt rapportbrukergruppe, som har de samme datatillatelsene. Deretter oppretter du ett arbeidsområde per målgruppe og tilordner tilgangstillatelser til arbeidsområdet eller appen.

Et firma som for eksempel bare har to salgsområder, bestemmer seg for å publisere en semantisk modell for hvert salgsområde til forskjellige arbeidsområder. Semantiske modeller håndhever ikke RLS. De bruker imidlertid spørringsparametere til å filtrere kildedata. På denne måten publiseres den samme modellen til hvert arbeidsområde – de har bare forskjellige semantiske modellparameterverdier. Selgere får tilgang til bare ett av arbeidsområdene (eller publiserte apper).

Det finnes flere fordeler forbundet med å unngå RLS:

• Forbedret spørringsytelse: Det kan resultere i forbedret ytelse på grunn av færre filtre.
• Mindre modeller: Selv om det resulterer i flere modeller, er de mindre i størrelse. Mindre modeller kan forbedre svargraden for spørring og dataoppdatering, spesielt hvis vertskapasiteten opplever press på ressurser. Det er også enklere å holde modellstørrelser under størrelsesgrensene som er pålagt av kapasiteten din. Til slutt er det enklere å balansere arbeidsbelastninger på tvers av ulike kapasiteter, fordi du kan opprette arbeidsområder på – eller flytte arbeidsområder til – ulike kapasiteter.
• Tilleggsfunksjoner: Power BI-funksjoner som ikke fungerer med RLS, for eksempel Publiser på nettet, kan brukes.

Det er imidlertid ulemper forbundet med å unngå RLS:

• Flere arbeidsområder: Ett arbeidsområde kreves for hver rapportbrukergruppe. Hvis apper publiseres, betyr det også at det finnes én app per rapportbrukergruppe.
• Duplisering av innhold: Rapporter og instrumentbord må opprettes i hvert arbeidsområde. Det krever mer innsats og tid til å konfigurere og vedlikeholde.
• Brukere med høye rettigheter: Brukere med høye rettigheter, som tilhører flere rapportbrukere, kan ikke se en konsolidert visning av dataene. De må åpne flere rapporter (fra forskjellige arbeidsområder eller apper).

Feilsøke RLS

Hvis RLS gir uventede resultater, kan du se etter følgende problemer:

• Det finnes feil relasjoner mellom modelltabeller når det gjelder kolonnetilordninger og filterretninger. Husk at RLS-filtre bare overføres gjennom aktive relasjoner.
• Relasjonsegenskapen Bruk sikkerhetsfilter i begge retninger er ikke riktig angitt. Hvis du vil ha mer informasjon, kan du se Veiledning for toveis relasjoner.
• Tabeller inneholder ingen data.
• Feil verdier lastes inn i tabeller.
• Brukeren er tilordnet til flere roller.
• Modellen inkluderer aggregasjonstabeller, og RLS-regler filtrerer ikke konsekvent aggregasjoner og detaljer. Hvis du vil ha mer informasjon, kan du se Bruke aggregasjoner i Power BI Desktop (RLS for aggregasjoner).

Når en bestemt bruker ikke kan se noen data, kan det skyldes at UPN-en ikke er lagret eller at den skrives inn feil. Det kan skje brått fordi brukerkontoen er endret som følge av en navneendring.

Tips

For testformål kan du legge til et mål som returnerer USERNAME DAX-funksjonen. Du kan kalle det noe sånt som "Hvem Er jeg". Deretter legger du til målet i et kortvisualobjekt i en rapport og publiserer det i Power BI.

Opprettere og forbrukere med bare lesetillatelse på den semantiske modellen vil bare kunne vise dataene de har tillatelse til å se (basert på deres RLS-rolletilordning).

Når en bruker viser en rapport i et arbeidsområde eller en app, kan det hende at RLS eller kanskje ikke håndheves avhengig av semantiske modelltillatelser. Derfor er det viktig at innholdsforbrukere og opprettere bare har lesetillatelse på den underliggende semantiske modellen når RLS må håndheves. Hvis du vil ha mer informasjon om tillatelsesreglene som bestemmer om RLS håndheves, kan du se artikkelen om planlegging av rapportforbrukersikkerhet.

Relatert innhold

Hvis du vil ha mer informasjon om denne artikkelen, kan du se følgende ressurser:

• Sikkerhet på radnivå (RLS) med Power BI
• Begrense datatilgang med sikkerhet på radnivå (RLS) for Power BI Desktop
• Modellrelasjoner i Power BI Desktop
• Planlegging av Power BI-implementering: Planlegging av rapportforbrukersikkerhet
• Spørsmål? Prøv å spørre Power BI-fellesskap
• Forslag? Bidra med ideer for å forbedre Power BI