Rivitason suojaus (RLS) Power BI:ssä

Rivitason turvallisuus (RLS) rajoittaa tiettyjen Power BI-semanttisen mallin käyttäjien pääsyä. Suodattimet rajoittavat dataa rivitasolla, ja määrittelet suodattimet roolien sisällä. Power BI -palvelussa käyttäjillä, joilla on työtilan käyttöoikeus, on käyttöoikeus työtilan semanttisiin malleihin. Rivitason suojaus rajoittaa tietojen käyttöä vain käyttäjille, joilla on Katselija-käyttöoikeudet . Se ei koske työtilan ylläpitäjä-, jäsen- tai avustajan rooleja.

RLS:n toteuttamiseksi seuraa tätä korkeatasoista työnkulkua:

1. Määrittele roolit ja säännöt Power BI Desktopissa DAX-suodatinlausekkeiden avulla.
2. Julkaise semanttinen malli ja raportoi Power BI -palvelu.
3. Lisää jäseniä rooleihin Power BI -palvelu.
4. Varmistakäyttämällä Test as Role -ominaisuutta varmistaaksesi, että datan suodatus toimii odotetusti.

Voit konfiguroida RLS:n tuoduille semanttisille malleille Power BI Desktopissa tai Power BI -palvelu:ssä. Voit myös konfiguroida RLS:n semanttisille malleille, jotka käyttävät DirectQueryä, kuten SQL Server. Jos käytät Analysis Servicesiä tai Azure Analysis Services reaaliaikaisia yhteyksiä, määrität rivitason suojauksen mallissa, et Power BI:ssä. Suojausvaihtoehtoa ei näy reaaliaikaisen yhteyden semanttisille malleille.

Roolien ja sääntöjen määrittäminen Power BI Desktopissa

Voit määrittää rooleja ja sääntöjä Power BI Desktopissa. Tällä editorilla voit vaihtaa avattavan oletuskäyttöliittymän ja DAX-liittymän välillä. Kun julkaiset Power BI:ssä, julkaiset myös roolimääritykset.

Käyttöoikeusroolien määrittäminen:

1. Tuo tietoja Power BI Desktop -raporttiin tai määritä DirectQuery-yhteys.

   Huomautus

   Power BI Desktopissa ei voi määrittää rooleja reaaliaikaisille Analysis Services -yhteyksille. Se on tehtävä Analysis Services -mallissa.

2. Valitse Mallinnus-välilehdestäRoolien hallinta.

3. Luo uusi rooli valitsemalla Roolien hallinta -ikkunassa Uusi .

4. Anna roolille nimi Roolit-kohdassa ja valitse Enter.

   Huomautus

   Et voi määrittää roolia pilkulla, esimerkiksi London,ParisRole.

5. Valitse Valitse taulukot -kohdassa taulukko, johon haluat käyttää rivitason suojaussuodatinta.

6. Määritä roolit oletuseditorin avulla kohdassa Suodata tiedot. Luodut lausekkeet palauttavat arvon tosi tai epätosi. DAX-suodatin arvioi TRUE/FALSE -arvot jokaiselle riville. Vain rivit, jotka palauttavat TOSI, ovat näkyvissä. Kaikki muu poistetaan kokonaan.

   Huomautus

   Kaikkia Power BI:n rivitason suojauksen suodattimia ei voi määrittää oletuseditoria käyttämällä. Rajoituksia ovat lausekkeet, jotka voidaan nykyään määrittää vain DAX:n avulla, mukaan lukien dynaamiset säännöt, kuten username() tai userprincipalname(). Jos haluat määrittää roolit näiden suodattimien avulla, siirry DAX-editorin käyttöön.

7. Voit halutessasi valita Vaihda DAX-editoriin , jos haluat siirtyä käyttämään DAX-editoria roolisi määrittämiseen. DAX-lausekkeet palauttavat arvon tosi tai epätosi. Esimerkki: [Entity ID] = “Value”. DAX-editori on valmis kaavojen (intellisense) automaattisella täydennyksellä. Voit palauttaa muutokset valitsemalla lausekeruudun yläpuolelta valintamerkin lausekkeen vahvistamiseksi ja X-painikkeen lausekeruudun yläpuolella.

   Huomautus

   Voit käyttää username()-funktiota tässä lausekkeessa. Huomaa, että username() on muotoa DOMAIN\username Power BI Desktopissa. Power BI -palvelussa ja Power BI -raporttipalvelimessa se esitetään käyttäjän täydellinen käyttäjätunnus (UPN) muodossa. Voit lisäksi käyttää tässä lausekeruudussa pilkkuja DAX-funktioargumenttien erottamiseen, vaikka käyttäisit tavallisesti puolipisteerottimia, kuten ranskaa tai saksaa.

8. Voit vaihtaa takaisin oletuseditoriin valitsemalla Vaihda oletuseditoriin. Kaikki jommassakummassa editorin käyttöliittymässä tehdyt muutokset säilyvät, kun käyttöliittymää vaihdetaan, kun se on mahdollista. Kun määrität DAX-editorilla roolin, jota ei voi määrittää oletuseditorissa, jos yrität vaihtaa oletuseditoriin, näyttöön tulee varoitus, jonka mukaan editorien vaihtaminen voi johtaa joidenkin tietojen menettämiseen. Jos haluat säilyttää nämä tiedot, valitse Peruuta ja jatka vain tämän roolin muokkaamista DAX-editorissa.

   Huomautus

   Erota DAX-funktioargumentit toisistaan pilkuilla tämän lausekeruudun avulla, vaikka käyttäisit tavallisesti puolipisteerottimia, kuten ranskaa tai saksaa.

9. Valitse Tallenna.

Käyttäjille ei voi määrittää roolia Power BI Desktopissa. Voit määrittää ne Power BI -palvelussa. Voit ottaa dynaamisen suojauksen käyttöön Power BI Desktopissa käyttämällä username() - tai userprincipalname() DAX-funktioita ja määrittämällä oikeat suhteet.

Yleisiä DAX-suodatinkuvioita RLS-rooleissa

Seuraavat esimerkit osoittavat yleisiä DAX-suodatinlausekkeita, joita voit käyttää RLS-roolien määrittelyssä Power BI Desktopissa:

• Staattinen RLS — Rajoittaa datan kiinteään arvoon:

  [Region] = "West"
  

• Dynaaminen RLS UPN :llä — Rajoittaa tietoja kirjautuneen käyttäjän sähköpostiosoitteen perusteella:

  [UserEmail] = USERPRINCIPALNAME()
  

• Dynaaminen RLS käyttäjätunnuksella — Rajoittaa tietoja käyttäjän verkkotunnuksen ja käyttäjätunnuksen perusteella:

  [UserDomain] = USERNAME()
  

• Dynaaminen RLS CUSTOMDATA :lla — Rajoittaa dataa upotussovelluksesta välitetyn mukautetun merkkijonon perusteella:

  [AppRole] = CUSTOMDATA()
  

  Huomautus

  CUSTOMDATA() käytetään pääasiassa sulautetuissa tilanteissa, joissa sovellus välittää mukautetun tehokkaan identiteettimerkkijonon Power BI REST API:n kautta.

Dynaaminen RLS on yleisin lähestymistapa, koska se sallii yhden roolimääritelmän suodattaa dataa eri tavoin jokaiselle käyttäjälle, perustuen käyttäjäkartoitustauluun tietomallissasi.

Esimerkki: Suodata Power BI:n myyntitietoja alueittain

Oletetaan, että sinulla on Sales taulukko, jossa on sarakkeet Region, Product, ja Amount. Haluat rajoittaa käyttäjiä, jotka on määritetty "Länsi"-rooliin niin, että he näkevät vain rivit, joissa alue on "Länsi".

DAX-suodatinkenttään "West"-roolille syötä seuraava lauseke:

[Region] = "West"

Ennen suodatusta (kaikki tiedot):

Suodatuksen jälkeen (näkymä "West"-roolikäyttäjille):

DAX-lauseke toimii rivisuodattimena, joka arvioi jokaisen rivin taulukossa. Vain rivit, joiden sarake Region on "Länsi", näkyvät kyseisessä roolissa oleville käyttäjille.

Kaksisuuntainen ristisuodatus RLS:llä

Oletuksena rivitason suojauksen suodatukseen käytetään yksisuuntaisia suodattimia, olivatpa suhteet sitten määritetty yksi- vai kaksisuuntaisiin.

Voit ottaa kaksisuuntaisen ristisuodatuksen manuaalisesti käyttöön rivitason suojauksen yhteydessä valitsemalla suhteen ja valitsemalla Ota suojaussuodattimet käyttöön molempiin suuntiin -valintaruudun. Valitse tämä vaihtoehto, kun olet ottanut käyttöön myös dynaamisen rivitason suojauksen palvelintasolla, jolla rivitason suojaus perustuu käyttäjänimeen tai kirjautumistunnukseen. Jos taulukko osallistuu useisiin kaksisuuntaisiin suhteisiin, voit valita tämän vaihtoehdon vain yhdelle näistä suhteista.

Lisätietoja on artikkelissa Kaksisuuntainen ristiinsuodatus käyttämällä DirectQueryä Power BI:ssä ja teknisessä artikkelissa Taulukkomuotoisen liiketoimintatietojen semanttisen mallin suojaaminen.

Hallinnoi turvallisuutta semanttisella mallillasi

Hallinnoidaksesi turvallisuutta semanttisessa mallissasi, avaa työtila, johon tallennit semanttisen mallin Microsoft Fabric, ja tee seuraavat vaiheet:

1. Microsoft Fabric -ohjelmassa valitse Lisää vaihtoehtoja semanttista mallia varten. Tämä valikko tulee näkyviin, kun pidät hiiren osoitinta semanttisen mallin nimen päällä.

   

2. Valitse Suojaus.

   

Security vie sinut Row-Level Security -sivulle, jossa lisäät jäseniä luomaasi rooliin. Käyttäjät, joilla on workspace Contributor -rooli tai korkeampi, näkevät Security-vaihtoehdon ja voivat määrittää käyttäjät rooliin. Semanttinen mallin omistajuus tai rakennuslupa voi myös olla tarpeen tilanteesta riippuen.

Hallinnoi RLS-roolijäsenyyttä Power BI -palvelu -palvelussa

Lisää jäseniä RLS-rooliin

Power BI -palvelu:ssä voit lisätä jäsenen RLS-rooliin kirjoittamalla sähköpostiosoitteen tai käyttäjän tai turvaryhmän nimen. Et voi lisätä ryhmiä, jotka on luotu Power BI:ssä. Voit lisätä jäseniä, jotka ovat organisaatiosi ulkopuolisia henkilöitä. Ohjeita siitä, miten RLS toimii ulkoisten B2B-vieraskäyttäjien kanssa, löydät kohdasta Huomiot ulkoisille (B2B-vieras) käyttäjille.

Voit käyttää seuraavia Microsoft Entra ID- ja sähköpostiin perustuvia ryhmiä rivitason turvallisuuden asettamiseen:

• Jakeluryhmä
• Sähköpostiin perustuva ryhmä
• Microsoft Entra -turvallisuusryhmä — Jos tietoturvaryhmässä on ulkoisia B2B-vieraskäyttäjiä, katso ulkoisten (B2B-vieras) käyttäjien huomioitamiset tunnetuista rajoituksista.

Voit nähdä, kuinka monta jäsentä kuuluu rooliin, suluissa roolinimen vieressä olevasta numerosta tai Jäsenistä.

Poista jäsenet RLS-roolista

Voit poistaa jäseniä valitsemalla X :n heidän nimensä vierestä.

Validoi rooli Power BI -palvelu:ssä

Voit varmistaa, että määrittelemäsi RLS-rooli toimii oikein Power BI -palvelu -palvelussa testaamalla roolia.

1. Valitse Enemmän vaihtoehtoja (...) roolin vieristä.
2. Valitse Testaa roolina.

Kun raportti latautuu, varmista seuraavat asiat:

• Raportti näyttää vain datarivejä, jotka vastaavat roolissa määriteltyä suodatinlauseketta.
• Visuaalit, taulukot ja kaaviot heijastavat suodatettua dataa, eivät koko aineistoa.
• Jos käytät dynaamista RLS:ää, data vastaa Now-näkymässä otsikona esitettyä identiteettiä.

Sivun otsikossa näkyy käytettävä rooli. Testaa muita rooleja, roolien yhdistelmiä tai tiettyä henkilöä valitsemalla Tarkastellaan nyt käyttäjänä. Tässä näet testattavaan henkilöön tai rooliin liittyvät tärkeät käyttöoikeustiedot. Lisätietoja oikeuksien vuorovaikutuksesta rivitason suojauksen kanssa on artikkelissa Rivitason suojauksen käyttökokemus.

Testaa muita semanttiseen malliin yhdistettyjä raportteja valitsemalla Sivun otsikossa Tarkasteleminen . Voit testata vain samassa työtilassa olevia raportteja kuin semanttinen mallisi.

Voit palata normaaliin tarkasteluun valitsemalla Takaisin rivitason suojaukseen.

DAX-funktion username() tai userprincipalname() käyttö

Voit hyödyntää tietojoukossa DAX-funktioita username() ja userprincipalname( ). Voit käyttää niitä lausekkeissa Power BI Desktopissa. Kun julkaiset mallin, sitä käytetään Power BI -palvelussa.

Power BI Desktopissa username() palauttaa käyttäjän muodossa TOIMIALUE\Käyttäjä ja userprincipalname() palauttaa käyttäjän muodossa user@contoso.com.

Power BI -palvelussa sekä username()että userprincipalname() palauttavat käyttäjän ensisijaisen nimen (UPN). Se näyttää samalta kuin sähköpostiosoite.

Käytä RLS:ää työtilojen kanssa Power BI:ssä

Jos julkaiset Power BI Desktop -raporttisi työtilaan Power BI -palvelu:ssä, RLS-roolit liitetään jäsenille, jotka on määritetty Viewer-rooliin työtilassa. Vaikka katsojille annettaisiin Build-oikeudet semanttiseen malliin, RLS on silti voimassa. Esimerkiksi, jos Build-oikeudet omaavat katsojat käyttävät Analyze-toimintoa Excel:ssä, heidän näkymänsä dataan on rajoitettu RLS:llä. Työtilan jäsenillä, joille on määritetty Admin, Jäsen tai Contributor, on muokkausoikeudet semanttiseen malliin, joten RLS ei koske heitä. Jos haluat, että rivitason suojaus koskee työtilan henkilöitä, voit määrittää heille vain Katselija-roolin. Lisätietoja löytyy kohdasta roolit työtiloissa.

Huomioitavat huomioita ulkoisille (B2B-vieras) käyttäjille

Jos jaat Power BI sisältöä ulkoisille käyttäjille Microsoft Entra B2B kautta, ole tietoinen seuraavista seikoista RLS:n suhteen.

Microsoft Entra -turvallisuusryhmät, joissa on ulkoisia jäseniä

Microsoft Entra -tietoturvaryhmät, joissa on ulkoisia B2B-vieraskäyttäjiä, eivät välttämättä toimi odotetusti RLS-roolijäsenyydessä. Joissakin kokoonpanoissa — erityisesti jos ulkoisella käyttäjällä on vierastyyppinen tili (eikä jäsentili) — vieraan ryhmäjäsenyyttä ei arvioida oikein Power BI -palvelu RLS-suodattimia valvottaessa.

Suositeltu kiertotie: Sen sijaan, että lisäisit ulkoisia käyttäjiä RLS-rooleihin Microsoft Entra -tietoturvaryhmien kautta, lisää heidät suoraan rooliin sähköpostiosoitteella. Sähköpostiosoite ratkaistaan käyttäjän B2B-tilille. Tämä varmistaa, että niiden identiteetti täsmätään oikein, kun RLS-suodattimia käytetään. Lisätietoja löytyy kohdasta Manage RLS role membership in the Power BI -palvelu.

Organisaatioille, joilla on paljon ulkoisia käyttäjiä, harkitse dynaamista RLS:ää ryhmäjäsenyyden USERPRINCIPALNAME() sijaan. Tämä lähestymistapa arvioi jokaisen käyttäjän identiteetin yksilöllisesti ja välttää ryhmäjäsenyyden ratkaisun kokonaan.

Jos ongelma jatkuu kiertotien soveltamisen jälkeen, katso Vianetsintä: Ulkoinen B2B-vieras ei näe tietoja Power BI-raportissa lisädiagnostiikkavaiheita varten.

UPN-resoluutio B2B-vieraille Power BI RLS:ssä

Kun ulkoinen B2B-vieraskäyttäjä käyttää Power BI-raporttia, USERPRINCIPALNAME() DAX-funktio palauttaa tyypillisesti sähköpostimaisen tunnisteen (esimerkiksi user@partner.com). Joissakin asetuksissa se saattaa palauttaa vieras-UPN:n muodossa #EXT# (esim. user_partner.com#EXT#@yourtenant.onmicrosoft.com).

Tämä ero on tärkeä dynaamisessa RLS:ssä. Jos käyttäjäkartoitustaulusi tallentaa eri tunnistemuodon kuin palautus USERPRINCIPALNAME() , suodatinlauseke ei täsmää, ja vieraskäyttäjä saattaa nähdä tietoja tai virheellistä dataa.

USERNAME()-toiminta B2B-vieraille Power BI RLS:ssä

DAX-funktio USERNAME() palauttaa käyttäjän domain\username tunnisteen. B2B-vieraskäyttäjille se USERNAME() palauttaa usein UPN-tyyppisen tunnisteen, joka muistuttaa USERPRINCIPALNAME(), riippuen kokoonpanosta (esimerkiksi user@partner.com) eikä formaatista domain\username . Koska USERNAME() ja USERPRINCIPALNAME() usein palauttaa sama arvo B2B-vieraille, useimmat toteutukset käyttävät USERPRINCIPALNAME() johdonmukaisuutta.

Suositeltu lähestymistapa: Tallenna ja käytä johdonmukaisesti samaa tunnistemuotoa käyttäjäkartoitustaulussa kuin arvo, jonka palautta USERPRINCIPALNAME(). Useimmissa tapauksissa sähköpostiosoitteiden käyttö helpottaa hallintaa:

[UserEmail] = USERPRINCIPALNAME()

Missä sarakkeessa UserEmail on sähköpostiosoitteet, kuten user@partner.com sekä sisäisille että ulkoisille käyttäjille.

Vianetsintä: Ulkoinen B2B-vieras ei näe dataa Power BI-raportissa

Jos B2B-vieraskäyttäjä näkee tyhjän raportin tai saa "ei dataa" -viestin, noudata näitä ohjeita:

1. Varmista palautettu UPN-muoto — Luo testimittari USERPRINCIPALNAME() ja näytä se kortin visuaalissa. Anna vieraskäyttäjän katsoa raportti ja nähdä todellinen palautusarvo.
2. Tarkista käyttäjäkartoitustaulu — Varmista, että kartoitustaulussa on rivi, jonka arvo täsmälleen vastaa kyseisen USERPRINCIPALNAME() vieraan palautusta.
3. Tarkista kirjainkoon herkkyys — DAX-merkkijonojen vertailut ovat oletuksena kirjainkoon liittymättömiä, mutta varmista, ettei tietolähteesi ole lisännyt kirjakoin herkkiä arvoja.
4. Tarkista vuokralaisten väliset käyttöoikeudet — Jos organisaatiosi käyttää ristiinkäyttökäytäntöjä, ne voivat vaikuttaa siihen, mikä UPN-muoto esitetään Power BI:lle.
5. Testaa varsinaisen vieraskäyttäjän kanssa — Testaa roolina -ominaisuus käyttää omaa identiteettiäsi. Varmista aina oikealla ulkoisella vierastilillä.
6. Vahvista roolijako — Jos vieraskäyttäjä näkee odotettua enemmän dataa, varmista, että hänet on sijoitettu RLS-rooliin. Käyttäjät, joita ei ole määritetty mihinkään RLS-rooliin, eivät yleensä näe dataa (tulokset tyhjät), koska RLS on pakotettu, mutta vastaavaa roolia ei sovelleta. DAX-suodatin arvioi TRUE/FALSE -arvot jokaiselle riville. Näkyvissä ovat vain rivit, jotka palauttavat TRUE:n. Kaikki muu on täysin poistettu.

Lisätietoja Power BI sisällön jakamisesta ulkoisille käyttäjille löytyy osoitteesta Jaa Power BI sisältöä ulkoisille vieraskäyttäjille, joilla on Microsoft Entra B2B.

Huomioitavat asiat ja rajoitukset

Voit tarkistaa pilvimallien rivitason suojauksen tämänhetkiset rajoitukset täältä:

• Jos määritit aiemmin rooleja ja sääntöjä Power BI -palvelussa, sinun on luotava ne uudelleen Power BI Desktopissa.
• Voit määrittää rivitason suojauksen vain semanttisissa malleissa, jotka on luotu Power BI Desktopin avulla. Jos haluat ottaa rivitason suojauksen käyttöön Excelillä luoduille semanttisille malleille, sinun on ensin muunnettava tiedostosi Power BI Desktop (PBIX) -tiedostoiksi. Lisätietoja.
• Palvelun päänimiä ei voi lisätä rivitason suojauksen rooliin. Näin ollen rivitason suojausta ei käytetä sovelluksiin, jotka käyttävät palvelun päänimeä lopullisena voimassa olevana käyttäjätietona.
• Vain tuonti- ja DirectQuery-yhteyksiä tuetaan. Reaaliaikaisia yhteyksiä Analysis Servicesiin käsitellään paikallisessa mallissa.
• Kun RLS on käytössä, DAX-kyselyissä ja mittareissa USERELATIONSHIP()-funktion käyttö voi aiheuttaa odottamattomia virheitä. Tämän ongelman kiertämiseksi suunnittele DAX-lausekkeet uudelleen välttääksesi USERELATIONSHIP():n ja käytä mallitason suhteita tai muita DAX-malleja.
• Testaa roolina/Näytä roolina -ominaisuus ei toimi DirectQuery-malleissa, joissa kertakirjautuminen on käytössä.
• Testaa roolina/näytä roolina -ominaisuus näyttää vain semanttisten mallien työtilan raportit.
• Testaa roolina/Näytä roolina -ominaisuus ei toimi sivutetuissa raporteissa.
• Tunnuspohjaiset käyttäjätiedot toimivat vain DirectQuery-malleissa kapasiteetissa, joka on yhdistetty Azure SQL -tietokantaan, joka on määritetty sallimaan Microsoft Entra -todennus. Lisätietoja löytyy kohdasta Raportti token-pohjaisella identiteetillä
• 'IdentityBlob'-parametri on OAuth 2.0 -käyttöoikeustunnus Azure SQL:lle ja sitä tuetaan vain tietoaineistoille, joilla on DirectQuery-yhteys Azure SQL:ään. Mekanismi itsessään on Azure-SQL-spesifinen: Blob is Microsoft Entra access-token, joka on määritelty https://database.windows.net/.default. Sovellus-owns-data -upotuksessa ei ole vastaavaa token-siirtomekanismia muille tietolähteille. Lisätietoja löytyy REST API -viiteestä GenerateTokenille.

Dynaamisen RLS:n seikat ja rajoitukset

Kun käytät dynaamista rivitason turvallisuutta (RLS) DAX-funktioiden kuten USERPRINCIPALNAME(), USERNAME(), tai CUSTOMDATA(), kanssa, ole tietoinen seuraavista seikoista.

B2B-ristiinvuokralaisten skenaariot

B2B-skenaarioissa USERPRINCIPALNAME() palauttaa identiteetin, jonka Power BI -palvelu on ratkaissut, ja se voi vaihdella vuokralaisen konfiguraation mukaan. Se voi esiintyä kumpaakin:

• Ulkoisen käyttäjän sähköpostiosoite (user@partner.com), tai
• Vuokralaisen ratkaisema arvo, kuten user_partner.com#EXT#@tenant.onmicrosoft.com

Tarkka muoto ei ole taattu, ja se täytyy validoida omassa ympäristössäsi.

Jos käyttäjäkartoitustaulusi tallentaa tunnisteet eri muodossa kuin USERPRINCIPALNAME() vieraskäyttäjien palautus, RLS-suodatinlauseke ei täsmää, eikä vieras näe dataa tai virheellistä dataa. Varmista aina tarkka arvo, jonka USERPRINCIPALNAME() ulkopuoliset käyttäjät ovat palauttaneet ympäristössäsi.

Testi roolirajoituksina dynaamisessa RLS:ssä

Test as role -ominaisuus Power BI -palvelu:ssa käyttää omaa identiteettiäsi arvioitaessa dynaamisia RLS-lausekkeita. Tämä tarkoittaa, että USERPRINCIPALNAME()palautat UPN:si , ei käyttäjän UPN:ää, jota yrität simuloida. Et voi käyttää Testiä roolina nähdäksesi, mitä tietty B2B-vieraskäyttäjä tai palvelupäämies näkisi.

Test as role simuloi roolijäsenyyttä, mutta ei täysin toista toisen käyttäjän todennuskontekstia, erityisesti B2B-vieraiden tai upotettujen skenaarioiden osalta.

Dynaamisen RLS:n varmistamiseksi ulkoisille käyttäjille kirjaudu sisään varsinaisena vieraskäyttäjänä ja katso raportti suoraan. Tämä on ainoa tapa varmistaa, että USERPRINCIPALNAME() odotusarvo palautuu ja että RLS-suodattimet vastaavat oikein kyseiselle käyttäjälle.

Upotetut skenaariot palveluperiaatteineen

Kun raporttiin pääsee käsiksi upotetun sovelluksen kautta, joka autentikoituu palvelupäähenkilön kautta, ja USERPRINCIPALNAME() palauttaa USERNAME() palvelupäämiehen sovellustunnuksen tai tyhjän merkkijonon—ei loppukäyttäjän identiteettiä.

Nämä funktiot eivät palauta loppukäyttäjän identiteettiä, joten niitä ei voi käyttää käyttäjäkohtaiseen suodatukseen palvelupäähenkilöiden upotuksissa. Tämä tarkoittaa, että näihin toimintoihin perustuvat dynaamiset RLS-suodattimet eivät suodata dataa käyttäjäkohtaisesti sulautetuissa tilanteissa.

Käyttäjäkohtaisen RLS:n soveltamiseksi sulautetuissa skenaarioissa käytä Power BI REST API:n effective identity -ominaisuutta. Anna objektille EffectiveIdentity sopiva käyttäjänimi ja roolit, kun luot upotustokenin. Jos RLS-sääntösi käyttävät CUSTOMDATA(), välitä mukautettu datamerkkijono läpi EffectiveIdentity.CustomData.

Lisätietoja löytyy kohdasta RLS for Embedded Scenarios for ISVs.

Muista, että jos Power BI -raportti viittaa riviin, jolle on määritetty rivitason suojaus, sama sanoma tulee näkyviin kuin poistetulle tai ei-olemassa olevalle kentälle. Näillä käyttäjillä vaikuttaa siltä, että raportti on rikki.

usein kysytyt kysymykset

Kysymys: Entä jos olen aiemmin luonut rooleja ja sääntöjä tietojoukolle Power BI -palvelussa? Toimivatko ne edelleen, jos en tee mitään?
Vastaus: Ei, visualisointeja ei hahmonneta oikein. Sinun on luotava roolit ja säännöt uudelleen Power BI Desktopissa ja sen jälkeen julkaistava ne Power BI -palveluun.

Kysymys: Voinko luoda nämä roolit Analysis Services -tietolähteille?
Vastaus: Kyllä, jos tiedot on tuotu Power BI Desktopiin. Jos käytät reaaliaikaista yhteyttä, et voi määrittää rivitason suojausta Power BI -palvelun sisällä. Voit määrittää rivitason suojauksen Analysis Services -mallissa paikallisesti.

Kysymys: voinko käyttää rivitason suojausta rajoittamaan käyttäjien käytössä olevia sarakkeita tai mittareita?
Vastaus: Ei. Jos käyttäjällä on tietyn tietorivin käyttöoikeus, hän voi nähdä kaikki kyseisen rivin tietosarakkeet. Jos haluat rajoittaa sarakkeiden ja sarakkeiden metatietojen käyttöä, harkitse objektitason suojauksen käyttämistä.

Kysymys: Salliiko rivitason suojaus tarkkojen tietojen piilottamisen ja visualisoinneissa olevien yhteenvetotietojen käytön?
Vastaus: Ei, voit suojata yksittäisiä tietorivejä, mutta käyttäjät voivat aina nähdä tarkat tiedot tai yhteenvetotiedot.

Kysymys: Tietolähteeseeni on jo määritetty käyttöoikeusrooleja (esimerkiksi SQL Server -rooleja tai SAP BW -rooleja). Mikä näiden roolien ja rivitason suojauksen välinen suhde on?
Vastaus: Vastaus riippuu siitä, tuotko tietoja vai käytätkö DirectQuerya. Jos tuot tietoja Power BI -tietojoukkoosi, tietolähteesi käyttöoikeusrooleja ei käytetä. Tässä tapauksessa sinun on määritettävä rivitason suojaus, jotta voit pakottaa suojaussäännöt käyttäjille, jotka muodostavat yhteyden Power BI:ssä. Jos käytät DirectQueryä, käytetään tietolähteesi käyttöoikeusrooleja. Kun käyttäjä avaa raportin, Power BI lähettää pohjana olevaan tietolähteeseen kyselyn, joka soveltaa tietoihin suojaussääntöjä käyttäjän tunnistetietojen perusteella.

Kysymys: Voiko käyttäjä kuulua useampaan kuin yhteen rooliin?
Vastaus: Käyttäjä voi kuulua useisiin rooleihin, ja roolit ovat lisääviä. Jos käyttäjä esimerkiksi kuuluu sekä Myynti- että Markkinointi-rooleihin, hän voi nähdä molempien roolien tiedot.

Liittyvä sisältö

• Tietojen käytön rajoittaminen rivitason suojauksen (RLS) avulla Power BI Desktopissa
• Power BI:n käyttöönoton suunnittelu: Raportin kuluttajan suojauksen suunnittelu
• RLS upotetuille isv-ohjelmistokehitysten skenaarioille
• Jaa Power BI sisältöä ulkoisille vieraskäyttäjille Microsoft Entra B2B

Kysyttävää? Voit esittää kysymyksiä Power BI -yhteisön ehdotuksille? Kerro ideasi Power BI:n parantamiseksi