Jaa

Rivitason suojauksen (RLS) ohjeet Power BI Desktopissa

  • Artikkeli

Tämä artikkeli koskee tietojen mallintajaa, joka käsittelee Power BI Desktopia. Artikkelissa kuvataan hyvät käytännöt tietomallien rivitason suojauksen suunnittelulle.

On tärkeää ymmärtää rivitason suojauksen suodattimien taulukkorivit. Niitä ei voi määrittää rajoittamaan malliobjektien, kuten taulukoiden, sarakkeiden tai mittareiden, käyttöä.

Muistiinpano

Tässä artikkelissa ei kuvata rivitason suojausta tai sen määrittämistä. Lisätietoja on artikkelissa Tietojen käytön rajoittaminen rivitason suojauksen (RLS) avulla Power BI Desktopissa.

Artikkelissa ei myöskään käsitellä RLS-suojausta reaaliaikaisten yhteyksien kautta ulkoisiin Azure Analysis Services tai SQL Server Analysis Servicesissä isännöityihin malleihin. Näissä tapauksissa rivitason suojauksen toteuttaa Analysis Services. Kun Power BI muodostaa yhteyden kertakirjautumisella, Analysis Services toteuttaa rivitason suojauksen (ellei tilillä ole järjestelmänvalvojan oikeuksia).

Roolien luominen

Voit luoda useita rooleja. Kun harkitset yksittäisen raportin käyttäjän käyttöoikeustarpeita, pyri luomaan yksi rooli, joka myöntää kaikki kyseiset käyttöoikeudet sen sijaan, että myöntäisit rakenteen, jossa raportin käyttäjällä on useita rooleja. Tämä johtuu siitä, että raportin käyttäjä voi yhdistää useisiin rooleihin joko suoraan käyttäjätilinsä avulla tai epäsuorasti käyttöoikeusryhmän jäsenyyden kautta. Useiden roolien yhdistäminen voi aiheuttaa odottamattomia tuloksia.

Kun raportin käyttäjä on määritetty useisiin rooleihin, rivitason suojauksen suodattimista tulee lisääviä. Tämä tarkoittaa sitä, että raportin käyttäjät näkevät ne taulukon rivit, jotka edustavat kyseisten suodattimien liittoa. Lisäksi joissakin tilanteissa ei ole mahdollista taata, että raportin käyttäjä ei näe rivejä taulukossa. Toisin kuin SQL Server -tietokantaobjekteissa (ja muissa käyttöoikeusmalleissa), kerran estetty, aina estetty -periaatetta ei siis sovelleta.

Otetaan esimerkiksi malli, jossa on kaksi roolia: Ensimmäinen Workers-rooli rajoittaa kaikkien Payroll-taulukon rivien käyttöä seuraavalla sääntölausekkeella:

FALSE()

Muistiinpano

Sääntö ei palauta mitään taulukon rivejä, kun sen lausekkeen arvo on FALSE.

Toinen Managers-rooli taas sallii kaikkien Payroll-taulukon rivien käytön seuraavalla sääntölausekkeella:

TRUE()

Ole varovainen: Jos raportin käyttäjä on yhdistetty molempiin rooleihin, hän näkee kaikki Payroll-taulukon rivit.

Rivitason suojauksen optimointi

Rivitason suojaus toimii siten, että se käyttää automaattisesti suodattimia kaikissa DAX-kyselyissä, ja nämä suodattimet voivat heikentää kyselyn suorituskykyä. Tehokas rivitason suojaus perustuu siis hyvään mallirakenteeseen. On tärkeää noudattaa seuraavissa artikkeleissa annettuja mallin suunnitteluohjeita:

Yleisesti ottaen on usein tehokkaampaa pakottaa rivitason suojauksen suodattimet dimensiotyyppisissä taulukoissa, ei faktatyyppisissä taulukoissa. Hyödynnä myös hyvin suunniteltuja suhteita varmistaaksesi, että rivitason suojauksen suodattimet leviävät muihin mallitaulukoihin. RLS-suodattimet leviävät vain aktiivisten suhteiden kautta. Vältä siis DAX:n LOOKUPVALUE-funktion käyttö, jos mallisuhteilla saavutetaan sama tulos.

Kun rivitason suojauksen suodattimia käytetään DirectQuery-taulukoissa ja on olemassa suhteita muihin DirectQuery-taulukoihin, muista aina optimoida lähdetietokanta. Tämä voi tarkoittaa asianmukaisten indeksien suunnittelemista tai pysyvien laskettujen sarakkeiden käyttämistä. Lisätietoja on artikkelissa DirectQuery-mallin ohjeet Power BI Desktopissa.

Rivitason suojauksen vaikutuksen mittaaminen

Voit mitata rivitason suojauksen suodattimien suorituskykyä Power BI Desktopissa Suorituskyvyn analysointi -toiminnolla. Selvitä ensin raportin visuaalisen kyselyn kestot, kun rivitason suojausta ei käytetä. Ota sitten rivitason suojaus käyttöön valintanauhan Mallinnus-välilehden Näytä muodossa -komennolla ja vertaa kyselyjen kestoja.

Määritä roolien yhdistämismääritykset

Kun olet julkaissut Power BI:hin, sinun on yhdistettävä jäsenet semanttisiin mallirooleihin. Vain semanttisen mallin omistajat tai työtilan järjestelmänvalvojat voivat lisätä jäseniä rooleihin. Lisätietoja on artikkelissa Rivitason suojaus (RLS) Power BI:ssä (hallitse mallisi suojausta).

Jäsenet voivat olla käyttäjätilejä, käyttöoikeusryhmiä, jakeluryhmiä tai sähköpostia käyttäviä ryhmiä. Suosittelemme, että yhdistät semanttisten malliroolien käyttöoikeusryhmät aina, kun se on mahdollista. Siihen liittyy käyttöoikeusryhmien jäsenyyksien hallinta Microsoft Entra -tunnuksella. Tämä mahdollisesti delegoi tehtävän verkon järjestelmänvalvojille.

Roolien vahvistaminen

Testaa jokainen rooli ja varmista, että se suodattaa mallin oikein. Voit tehdä tämän helposti valintanauhan Mallinnus-välilehden Näytä muodossa -komennolla.

Kun mallissa on DAX:n USERNAME-funktiota käyttäviä dynaamisia sääntöjä, muista testata odotetut ja odottamattomat arvot. Kun upotat Power BI -sisältöä – erityisesti käyttämällä Upottaminen asiakkaillesi -skenaariota – sovelluslogiikka voi välittää minkä tahansa arvon voimassa olevana käyttäjätietojen käyttäjänimenä. Aina kun mahdollista, varmista, että vahinkoarvot tai haitalliset arvot tuottavat aina suodattimen, joka ei palauta mitään rivejä.

Harkitse esimerkkiä Power BI Embedded -sovelluksella, jossa sovellus välittää käyttäjän työroolin käytettävänä käyttäjänimenä: Se on joko Manager (eli esimies) tai Worker (eli työntekijä). Vastuuhenkilöt näkevät kaikki rivit, mutta työntekijät näkevät vain rivit, joiden Type-sarakkeen arvo on Internal.

Seuraava sääntölauseke on määritetty:

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

Tämän sääntölausekkeen ongelma on se, että kaikki arvot Worker-arvoa lukuun ottamatta palauttavat kaikki taulukon rivit. Vahingossa annettu arvo, esimerkiksi Wrker, palauttaa siis myös kaikki taulukon rivit. Siksi on turvallisempaa kirjoittaa lauseke, joka testaa kutakin odotettua arvoa. Seuraavassa parannetussa sääntölausekkeessa odottamaton arvo ei palauta mitään rivejä taulukosta.

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

Osittaisen rivitason suojauksen suunnitteleminen

Joskus laskutoimitukset tarvitsevat arvoja, joita RLS-suodattimet eivät rajoita. Raportissa täytyy esimerkiksi ehkä näyttää raportin käyttäjän myyntialueelta ansaitseman tuoton suhde kaikkiin tuottoihin.

Vaikka DAX-lauseke ei voi kumota rivitason suojausta (itse asiassa se ei voi edes määrittää rivitason suojauksen käyttöä), voit käyttää yhteenvetomallitaulukkoa. Yhteenvetomallitaulukosta haetaan kyselyllä kaikkien alueiden tuotto. Mikään rivitason suojauksen suodatin ei rajoita sitä.

Tutustutaan nyt siihen, miten voit toteuttaa tämän. Katso ensin seuraavaa mallirakennetta:

Kuvassa näkyy mallikaavio. Se kuvataan seuraavissa kappaleissa.

Malli sisältää neljä taulukkoa:

  • Salesperson-taulukko sisältää yhden myyjän per rivi. Se sisältää EmailAddress-sarakkeen , joka sisältää kunkin myyjän sähköpostiosoitteen. Tämä taulukko on piilotettu.
  • Sales-taulukko sisältää yhden tilauksen per rivi. Siihen sisältyy Revenue % All Region - mittari, joka palauttaa raportin käyttäjän alueen tuoton suhteen kaikkien alueiden tuottoon.
  • Date-taulukko sisältää yhden päivämäärän per rivi. Se sallii suodattamisen ja ryhmittelyn vuoden sekä kuukauden mukaan.
  • SalesRevenueSummary on laskettu taulukko. Se tallentaa kokonaistuoton jokaiselta tilauspäivämäärälle. Tämä taulukko on piilotettu.

Seuraava lauseke määrittää lasketun SalesRevenueSummary-taulukon :

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

Muistiinpano

Saman voisi toteuttaa myös koostetaulukolla .

Salesperson-taulukossa käytetään seuraavaa RLS-sääntöä:

[EmailAddress] = USERNAME()

Kaikki kolme mallisuhdetta on kuvattu seuraavassa taulukossa:

Suhde Kuvaus
Vuokaavion päätetoimenpide 1. Salesperson- ja Sales-taulukoiden välillä on monta-moneen-suhde. Rivitason suojauksen sääntö suodattaa EmailAddress-sarakkeen piilotetusta Salesperson-taulukosta DAX-funktiolla USERNAME . Region-sarakkeen arvo (raportin käyttäjälle) leviää Sales-taulukkoon.
Vuokaavion päätetoimenpide 2. Date- ja Sales-taulukoiden välillä on yksi-moneen-suhde.
Vuokaavion päätetoimenpide 3. Date- ja SalesRevenueSummary-taulukoiden välillä on yksi-moneen-suhde.

Seuraava lauseke määrittää Revenue % All Region -mittarin:

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

Muistiinpano

Vältä näyttämästä luottamuksellisia tietoja. Jos tässä esimerkissä on vain kaksi aluetta, raportin käyttäjän on mahdollista laskea tuotto toiselle alueelle.

Milloin kannattaa välttää rivitason suojauksen käyttöä?

Joskus on järkevää välttää rivitason suojauksen käyttämistä. Jos sinulla on vain muutamia yksinkertaisia rivitason suojauksen sääntöjä, jotka käyttävät staattisia suodattimia, harkitse useiden semanttisten mallien julkaisemista sen sijaan. Mikään semanttisista malleista ei määritä rooleja, koska jokainen semanttinen malli sisältää tietyn raportin käyttäjäryhmän tietoja, joilla on samat tietojen käyttöoikeudet. Luo sitten yksi työtila kullekin käyttäjäryhmälle ja määritä käyttöoikeudet työtilaan tai sovellukseen.

Esimerkiksi yritys, jolla on vain kaksi myyntialuetta, päättää julkaista semanttisen mallin kullekin myyntialueelle eri työtiloihin. Semanttiset mallit eivät ota rivitason suojausta käyttöön. Ne suodattavat kuitenkin lähdetietoja kyselyparametreilla . Näin sama malli julkaistaan jokaisessa työtilassa – niillä on vain erilaiset semanttiset malliparametriarvot. Myyjille määritetään käyttöoikeus vain yhteen työtiloista (tai julkaistuista sovelluksista).

Rivitason suojauksen käytön välttäminen liittyy useisiin etuihin:

  • Kyselyjen parempi suorituskyky: Se voi parantaa suorituskykyä suodattimien vähemmillä toiminnoilla.
  • Pienemmät mallit: Vaikka se tuottaakin enemmän malleja, ne ovat kooltaan pienempiä. Pienemmät mallit voivat parantaa kyselyiden ja tietojen päivittämisen reagointia, varsinkin jos isännöintikapasiteetissa on resurssipaineita. Lisäksi on helpompi pitää mallin koot kapasiteetin asettamien kokorajoitusten alapuolella. Lisäksi on helpompi tasapainottaa kuormituksia eri kapasiteettien välillä, koska voit luoda työtiloja – tai siirtää työtiloja – eri kapasiteetteihin.
  • Lisäominaisuudet: Voit käyttää Power BI -ominaisuuksia, jotka eivät toimi rivitason suojauksen (esimerkiksi Julkaise verkkoon) kanssa.

Rivitason suojauksen käytön välttämiseen liittyy kuitenkin myös haittoja:

  • Useita työtiloja: Kullekin raportin käyttäjäryhmälle vaaditaan yksi työtila. Jos sovellukset julkaistaan, tämä tarkoittaa myös sitä, että jokaista raportin käyttäjäryhmää kohti on yksi sovellus.
  • Päällekkäistä sisältöä: Raportit ja koontinäytöt on luotava kuhunkin työtilaan. Sen määrittäminen ja ylläpito vaatii enemmän vaivaa ja aikaa.
  • Suurten käyttöoikeuksien käyttäjät: Suurten käyttöoikeuksien käyttäjät, jotka kuuluvat useisiin raportin käyttäjäryhmiin, eivät näe tietojen koostetussa näkymässä. Heidän on avattava useita raportteja (eri työtiloista tai sovelluksista).

Rivitason suojauksen vianmääritys

Jos rivitason suojaus tuottaa odottamattomia tuloksia, tarkista seuraavat ongelmat:

  • Mallitaulukoiden välillä on virheellisiä suhteita sarakkeiden yhdistämismääritysten ja suodatusohjeiden osalta. Muista, että RLS-suodattimet leviävät vain aktiivisten suhteiden kautta.
  • Ota suojaussuodattimet käyttöön molempiin suuntiin -yhteysominaisuutta ei ole määritetty oikein. Lisätietoja on artikkelissa Kaksisuuntaisen suhteen ohjeet.
  • Taulukot eivät sisällä tietoja.
  • Taulukoihin on ladattu virheellisiä arvoja.
  • Käyttäjä on yhdistetty useisiin rooleihin.
  • Malli sisältää koostetaulukoita, ja RLS-säännöt eivät suodata koosteita ja yksityiskohtia johdonmukaisesti. Lisätietoja on artikkelissa Koosteiden käyttäminen Power BI Desktopissa (RLS koosteita varten)..

Kun tietty käyttäjä ei näe mitään tietoja, se voi johtua siitä, että hänen upn-käyttäjätunnustaan ei ole tallennettu tai se on annettu virheellisesti. Näin voi käydä yhtäkkiä, jos käyttäjätili on muuttunut nimenmuutoksen seurauksena.

Vihje

Lisää testausta varten mittari, joka palauttaa DAX:n USERNAME-funktion . Voit antaa sille nimeksi vaikkakaan Who Am I. Lisää sitten mittari kortin visualisointiin raportissa ja julkaise se Power BI:ssä.

Tekijät ja kuluttajat, joilla on vain lukuoikeus semanttiseen malliin, voivat vain tarkastella tietoja, jotka heillä on oikeus nähdä (RLS-roolien yhdistämismäärityksen perusteella).

Kun käyttäjä tarkastelee raporttia joko työtilassa tai sovelluksessa, rivitason suojausta saatetaan pakottaa semanttisen mallin käyttöoikeuksista riippuen. Tästä syystä on tärkeää, että sisällönkuluttajilla ja sisällöntekijöillä on lukuoikeus vain taustalla olevaan semanttiseen malliin, kun rivitason suojaus täytyy pakottaa. Lisätietoja käyttöoikeussäännöistä, jotka määrittävät rivitason suojauksen täytäntöönpanon, on artikkelissa Raportin kuluttajasuojauksen suunnittelu .

Liittyvä sisältö

Saat lisätietoja tähän artikkeliin liittyen tutustumalla seuraaviin resursseihin: