Tapahtumat
Liity seuraamme FabCon Vegasiin
31. maalisk. klo 23 - 2. huhtik. klo 23
Lopullinen Microsoft Fabric-, Power BI-, SQL- ja tekoälyyhteisöjohtoinen tapahtuma. 31.3.–2.4.2025.
Rekisteröidy jo tänäänTätä selainta ei enää tueta.
Päivitä Microsoft Edgeen, jotta voit hyödyntää uusimpia ominaisuuksia, suojauspäivityksiä ja teknistä tukea.
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öä.
Huomautus
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).
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()
Huomautus
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 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.
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.
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.
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()
)
)
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:
Malli sisältää neljä taulukkoa:
Seuraava lauseke määrittää lasketun SalesRevenueSummary-taulukon :
SalesRevenueSummary =
SUMMARIZECOLUMNS(
Sales[OrderDate],
"RevenueAllRegion", SUM(Sales[Revenue])
)
Huomautus
Salesperson-taulukossa käytetään seuraavaa RLS-sääntöä:
[EmailAddress] = USERNAME()
Kaikki kolme mallisuhdetta on kuvattu seuraavassa taulukossa:
Suhde | Kuvaus |
---|---|
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. | |
Date- ja Sales-taulukoiden välillä on yksi-moneen-suhde. | |
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])
)
Huomautus
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.
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:
Rivitason suojauksen käytön välttämiseen liittyy kuitenkin myös haittoja:
Jos rivitason suojaus tuottaa odottamattomia tuloksia, tarkista seuraavat ongelmat:
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 .
Saat lisätietoja tähän artikkeliin liittyen tutustumalla seuraaviin resursseihin:
Tapahtumat
Liity seuraamme FabCon Vegasiin
31. maalisk. klo 23 - 2. huhtik. klo 23
Lopullinen Microsoft Fabric-, Power BI-, SQL- ja tekoälyyhteisöjohtoinen tapahtuma. 31.3.–2.4.2025.
Rekisteröidy jo tänäänOpetus
Moduuli
Rivitason suojauksen toteuttaminen - Training
Rivitason suojauksen (RLS) avulla voit luoda yhden raportin tai joukon raportteja, jotka koskevat tietyn käyttäjän tietoja. Tässä moduulissa opit ottamaan rivitason suojauksen käyttöön joko staattisella tai dynaamisella menetelmällä ja miten Microsoft Power BI yksinkertaistaa RLS-testausta Power BI Desktop ja Power BI -palvelu.
Sertifiointi
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Demonstrate methods and best practices that align with business and technical requirements for modeling, visualizing, and analyzing data with Microsoft Power BI.
Ohjeet
Rivitason suojaus (RLS) Power BI:ssä - Microsoft Fabric
Rivitason suojauksen määrittäminen tuoduille semanttisille malleille ja DirectQuerylle Power BI -palvelussa.
Objektitason suojaus (OLS) Power BI:ssä - Microsoft Fabric
Objektitason suojauksen määrittäminen tuoduille semanttisille malleille Power BI -palvelussa.
Rivitason suojaus (RLS) Power BI -raporttipalvelimessa - Power BI
Lue lisää rivitason suojauksen (RLS) käytöstä Power BI -raporttipalvelimessa.