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

Denne artikkelen gjelder for datamodellerere som arbeider med Power BI Desktop. Artikkelen beskriver god utformingspraksis for hvordan du kan håndheve sikekrhet på radnivå (RLS) i datamodellene dine.

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

Obs!

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

Den dekker heller ikke håndhevingen av RLS i live-tilkoblinger til eksternt driftede modeller med Azure Analysis Services eller SQL Server Analysis Services. I disse tilfellene håndheves RLS av Analysis Services. Når Power BI kobler til ved hjelp av enkel pålogging (SSO), vil Analysis Services håndheve RLS (med mindre kontoen har administrator-rettigheter).

Opprett roller

Det er mulig å opprette flere roller. Når du vurderer tillatelsesbehovene for en enkelt rapportbruker, må du prøve å opprette en enkeltrolle som gir tilgang til alle tillatelsene i stedet for en utforming der en rapportbruker må være medlem i flere roller. Dette er fordi en rapportbruker kan tilordnes til flere roller, enten direkte ved å bruke brukerkontoen, eller indirekte ved å bruke medlemskap i sikkerhetsgrupper. Tilordning til flere roller kan resultere i uventede resultater.

Når en rapportbruker er tilordnet flere roller, legges RLS-filtrene til. Det betyr at rapportbrukere kan se tabellrader som representerer sammenslåingen av disse filtrene. I noen scenarioer er det ikke mulig å garantere at en rapportbruker ikke ser radene i en tabell. Så, i motsetning til tillatelser som brukes for databaseobjekter for SQL Server (og andre tillatelsesmodeller), gjelder ikke prinsippet “En gang avslått, alltid avslått”.

Vurder en modell med to roller: Den første rollen, kalt Arbeidere, begrenser tilgangen til alle tabellradene for Lønnskostnad ved å bruke følgende regeluttrykk:

FALSE()

Obs!

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

Men, en andre rolle, kalt Ledere, gir tilgang til alle tabellradene for Lønnskostnad ved å bruke følgende regeluttrykk:

TRUE()

Ta vare på: Skulle en rapportbruker tilordnes begge rollene, ser vedkommende alle tabellradene 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. Effektiv RLS handler derfor om god modellutforming. Det er viktig å følge veiledningen for modellutformingen, slik det går frem i følgede artikler:

Generelt er det ofte mer effektivt å håndheve RLS-filtre på dimensjonstypetabeller, og ikke på faktatypetabeller. Bruk også godt utformede relasjoner for å sikre at RLS-filtrene overføres til andre modelltabeller. Unngå derfor å bruke DAX-funksjonen LOOKUPVALUE når modellrelasjonene kan oppnå samme resultat.

Når RLS-filtrene blir håndhevet på DirectQuery-tabeller, og det finnes relasjoner til andre DirectQuery-tabeller, må du sørge for å optimalisere kildedatabasen. Dette kan involvere utforming av relevante 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åling av RLS-påvirkning

Det er mulig å måle ytelsesinnvirkningen av RLS-filtre i Power BI Desktop ved å bruke Ytelsesanalyse. Først må du avgjøre varigheten av rapportens visuelle spøring når RLS ikke håndheves. Deretter bruker du Vis som-kommandoen på båndfanen Modellering for å håndheve RLS, bestemme og sammenligne spørringsvarigheter.

Konfigurer rolletilordninger

Når du har publisert til Power BI, må du tilordne medlemmer til datasettroller. Bare datasetteiere eller administratorer av arbeidsområder kan legge til medlemmer i roller. Hvis du vil ha mer informasjon, kan du se Sikkerhet på radnivå (RLS) med Power BI (administrering av modellsikkerhet).

Medlemmer kan være brukerkontoer eller sikkerhetsgrupper. Når det er mulig, anbefaler vi at du tilordner sikkerhetsgrupper til datasettroller. Dette innebærer administrering av medlemskap i sikkerhetsgrupper i Azure Active Directory. Det kan hende at den delegerer oppgaven til nettverksadministratorene.

Bekreft roller

Test hver rolle for å sikre at den filtrerer modellen på riktig måte. Dette gjør du enkelt ved å bruke kommandoen Vis som på båndfanen Modellering.

Når modellen har dynamiske roller ved hjelp av DAX-funksjonen USERNAME, må du teste for forventede og uventede verdier. når du bygger inn Power BI innhold – spesielt ved å bruke bygg inn for kunde scenarioet, kan du sende alle verdier som et effektivt bruker navn for identiteten. Når det er mulig, må du sikre at utilsiktede eller skadelige verdier resulterer i filtre som ikke returnerer rader.

Vurder et eksempel ved å bruke Power BI-innebygging der appen sender videre brukerens jobbrolle som det effektive brukernavnet: Det er enten “Leder” eller “Arbeider”. Ledere kan se alle radene, mens arbeiderne bare kan se rader der Typen kolonneverdi er “intern”.

Følgende regeluttrykk er definert:

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

Problemet med dette rolleuttrykket er at alle verdiene, med unntak av “Arbeider” returnerer alle tabellrader. En utilsiktet verdi som “Arbeidr” returerer dermed alle tabellradene. Derfor er det sikrere å skrive et uttrykk som tester for hver forventede verdi. I det følgende forbedrede regeluttrykket, vil en uventet verdi føre til at tabellen ikke returnerer noen rader.

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

Utforming av delvis RLS

Noen ganger trenger beregninger verdier som ikke er begrenset av RLS-filtre. En rapport kan for eksempel måtte vise et forhold mellom omsetningen som er opptjent for rapportbrukerens salgsområde over all omsetning.

Selv om det ikke er mulig for et DAX-uttrykk å overstyre RLS – faktisk så kan det heller ikke bestemme at RLS blir håndhevet – kan du bruke en tabell for sammendragsmodellen. Tabellen for sammendragsmodellen blir bedt om å hente omsetningen for “alle områder” og er ikke begrenset av noen RLS-filtre.

Vi ser på hvordan du kan implementere dette utformingskravet. Først må du vurdere følgende modellutforming:

Et bilde av et modelldiagram blir vist. Utformingen er beskrevet i det følgende avsnittet.

Modellen består av fire tabeller:

  • Selger-tabellen lagrer én rad per selger. Den inkluderer kolonnen EmailAddress som lagrer e-postadressen for hver enkelt selger. Denne tabellen er skjult.
  • Selger-tabellen lagrer én rad per bestilling. Den inkluderer målet Omsetning % alle områder som er utformet for å returnere et forhold mellom omsetning som er inntjent av rapportbrukerens område over omsetning inntjent av alle områdene.
  • Dato-tabellen 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 bestillingsdato. Denne tabellen er skjult.

Det følgende uttrykket definerer den beregnede tabellen SalesRevenueSummary:

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

Obs!

En aggregasjonstabell kan oppnå samme utformingskrav.

Følgende RLS-regel gjelder for Selger-tabellen:

[EmailAddress] = USERNAME()

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

Relasjon Beskrivelse
Flytskjematerminator 1. Det finnes en mange-til-mange-relasjon mellom tabellene Selger og Salg. RLS-regelen filtrerer kolonnen EmailAddress i den skjulte Selger-tabellen ved å bruke DAX-funksjonen USERNAME. Kolonneverdien Område (for rapportbrukeren) overføres til Salg-tabellen.
Flytskjematerminator 2. Det finnes en én-til-mange-relasjon mellom tabellene Dato og Salg.
Flytskjematerminator 3. Det finnes en én-til-mange-relasjon mellom tabellene Dato og SalesRevenueSummary.

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

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

Obs!

Sørg for å unngå å avsløre sensitive fakta. Hvis det bare finnes to områder i dette eksemplet, vil det være mulig for en rapportbruker å beregne omsetningen for det andre området.

Unngå å bruke RLS

Unngå å bruke RLS når det er fornuftig. Hvis du bare har et lite antall forenklede RLS-regler som bruker statiske filtre, bør du vurdere å publisere flere datasett i stedet. Ingen av datasettene definerer roller fordi hvert datasett inneholder data for en bestemt rapportbrukergruppe, som har de samme datatillatelsene. Deretter kan du opprette ett arbeidsområde per gruppe og tilordne tilgang til arbeidsområdet eller appen.

Et selskap som for eksempel bare har to salgsområder, bestemmer seg for å publisere et datasett for hvert område til forskjellige arbeidsområder. Datasettene håndhever ikke RLS. De bruker imidlertid spørringsparamtere til å filtrere kildedata. På denne måten publiseres den samme modellen til hvert arbeidsområde – de har bare forskjellige parameterverdier for datasettene. Selgere er tilordnet tilgang til bare ett av arbeidsområdene (eller publiserte apper).

Det finnes flere fordeler knyttet til det å unngå RLS:

  • Forbedret spørringsytelse: Det kan resultere i forbedret ytelse som følge av færre filtre.
  • Mindre modeller: Selv om dette resulterer i flere modeller, er de mindre i størrelse. Mindre modeller kan forbedre svartiden for spørringer og dataoppdatering, spesielt hvis driftskapasiteten opplever belastning på ressurser. Det er også enklere å holde modellstørrelser under størrelsesgrensene som er pålagt av kapasiteten. Det er også enklere å balansere arbeidsbelastninger på tvers av forskjellige kapasiteter fordi du kan oppretter arbeidsområder på – eller flytte arbeidsområder til – forskjellige kapasiteter.
  • Flere funksjoner: Power BI-funksjoner som ikke fungerer med RLS, som Publiser til nettet kan brukes.

Det finnes likevel flere fordeler knyttet til det å unngå RLS:

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

Feilsøking av RLS

Hvis RLS produserer uventede resultater, kan du sjekke følgende problemer:

  • Det finnes feil relasjoner mellom modelltabeller, i henhold til kolonnetilordninger og filterretninger.
  • Relasjonsegenskapen Bruk sikkerhetsfilter i begge retninger er ikke riktig angitt. Se Retningslinjer for toveisrelasjoner for mer informasjon.
  • Tabellen inneholder ingen data.
  • Feil verdier er lastet 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 Bruk aggregasjoner i Power BI Desktop (RLS for aggregasjoner).

Når en bestemt bruker ikke kan se noen data, kan det være fordi UPN-en ikke er lagret eller er skrevet inn feil. Det kan skje brått fordi brukerkontoen er endret som følge av resultatet av en navneendring.

Tips!

For testformål kan du legge til et mål som returnerer DAX-funksjonen USERNAME. Du kan gi den et navn som “Hvem er jeg”. Legg deretter til målet til et visualobjekt for et kort og publiser det til Power BI.

Når en bestemt bruker kan se alle dataene, er det mulig at de har tilgang til rapporter direkte i arbeidsområdet og at de er eieren av datasettet. RLS håndheves bare når:

  • Rapporten er åpnet i en app.
  • Rapporten er åpnet i et arbeidsområde, og brukeren er tilordnet til Leserrollen.

Neste trinn

Du finner mer informasjon relatert til denne artikkelen i følgende ressurser: