Sorszintű biztonsági (RLS) útmutató a Power BI Desktopban

Ez a cikk a Power BI Desktopban dolgozó adatmodellezőkre irányul. Az adatmodellekben a sorszintű biztonság (RLS) kikényszerítésére vonatkozó ajánlott tervezési eljárásokat ismerteti.

Fontos megérteni az RLS-szűrők táblázatsorait. Nem konfigurálhatók a modellobjektumokhoz való hozzáférés korlátozására, beleértve a táblákat, oszlopokat vagy mértékeket.

Feljegyzés

Ez a cikk nem ismerteti az RLS-t vagy annak beállítását. További információ: Adathozzáférés korlátozása sorszintű biztonsággal (RLS) a Power BI Desktophoz.

Emellett nem terjed ki az RLS kényszerítésére az Azure Analysis Services vagy az SQL Server Analysis Services szolgáltatással külsőleg üzemeltetett modellek élő kapcsolataiban. Ezekben az esetekben az RLS-t az Analysis Services kényszeríti ki. Ha a Power BI egyszeri bejelentkezéssel (SSO) csatlakozik, az Analysis Services kényszeríti az RLS-t (kivéve, ha a fiók rendszergazdai jogosultságokkal rendelkezik).

Szerepkörök létrehozása

Több szerepkör is létrehozható. Ha egy jelentésfelhasználó engedélyigényét mérlegeli, törekedjen arra, hogy egyetlen szerepkört hozzon létre, amely minden engedélyt megad ahelyett, hogy egy jelentésfelhasználó több szerepkör tagja lenne. Ennek az az oka, hogy a jelentésfelhasználók több szerepkörre is leképezhetők, akár közvetlenül a felhasználói fiókjuk használatával, akár közvetetten a biztonsági csoporttagságuk alapján. Több szerepkör-megfeleltetés nem várt eredményeket eredményezhet.

Ha egy jelentésfelhasználó több szerepkörhöz van hozzárendelve, az RLS-szűrők additívvá válnak. Ez azt jelenti, hogy a jelentés felhasználói láthatják a szűrők egyesítő táblázatsorait. Sőt, bizonyos esetekben nem garantálható, hogy a jelentésfelhasználók nem látják a táblák sorait. Így az SQL Server-adatbázisobjektumokra (és más engedélymodellekre) alkalmazott engedélyekkel ellentétben a "ha egyszer megtagadva mindig megtagadva" elv nem érvényes.

Vegyünk egy két szerepkörrel rendelkező modellt: Az első, Feldolgozók nevű szerepkör az alábbi szabálykifejezéssel korlátozza a hozzáférést az összes bértáblázat sorához:

FALSE()

Feljegyzés

A szabály nem ad vissza táblasorokat, amikor a kifejezés kiértékeli a következőt FALSE: .

Egy második, Vezetők nevű szerepkör azonban az alábbi szabálykifejezéssel teszi lehetővé az összes bérszámfejtési táblasor elérését:

TRUE()

Vigyázat: Ha egy jelentés felhasználója mindkét szerepkörhöz megfelelteti a térképet, az összes bérszámfejtési táblasor megjelenik.

RLS optimalizálása

Az RLS úgy működik, hogy automatikusan alkalmaz szűrőket minden DAX-lekérdezésre, és ezek a szűrők negatív hatással lehetnek a lekérdezési teljesítményre. A hatékony RLS tehát jó modelltervezést eredményez. Fontos, hogy kövesse a modelltervezési útmutatót, ahogyan az a következő cikkekben is szerepel:

• A csillagséma és a Power BI fontossága
• A Power BI útmutató dokumentációjában található összes kapcsolati útmutatócikk

Általában hatékonyabb az RLS-szűrők dimenzió típusú táblákon való kényszerítése, nem pedig tény típusú táblákon. A jól megtervezett kapcsolatokra támaszkodva biztosíthatja, hogy az RLS-szűrők más modelltáblákra is propagáljanak. Az RLS-szűrők csak aktív kapcsolatokon keresztül propagálnak. Ezért kerülje a LOOKUPVALUE DAX függvény használatát, ha a modellkapcsolatok ugyanazt az eredményt érik el.

Ha az RLS-szűrőket a DirectQuery-táblákon kényszerítik ki, és más DirectQuery-táblákhoz is vannak kapcsolatok, mindenképpen optimalizálja a forrásadatbázist. Ez magában foglalhatja a megfelelő indexek tervezését vagy a megőrzött számított oszlopok használatát. További információ: DirectQuery-modell útmutató a Power BI Desktopban.

Mérték RLS hatása

Az RLS-szűrők teljesítményhatását a Power BI Desktopban Teljesítményelemző használatával lehet mérni. Először határozza meg a jelentés vizualizációs lekérdezéseinek időtartamát, ha az RLS nincs kényszerítve. Ezután a Modellezés menüszalaglap Nézet másként parancsával kényszerítse ki az RLS-t, és határozza meg és hasonlítsa össze a lekérdezések időtartamát.

Szerepkör-leképezések konfigurálása

Miután közzétette a Power BI-ban, le kell képeznie a tagokat szemantikai modell (korábbi nevén adathalmaz) szerepkörökre. Csak szemantikai modelltulajdonosok vagy munkaterület-rendszergazdák adhatnak hozzá tagokat a szerepkörökhöz. További információ: Sorszintű biztonság (RLS) a Power BI-val (A modell biztonságának kezelése).

A tagok lehetnek felhasználói fiókok, biztonsági csoportok, terjesztési csoportok vagy levelezési csoportok. Amikor csak lehetséges, javasoljuk, hogy a biztonsági csoportokat szemantikai modellszerepkörökre képezje le. Magában foglalja a biztonsági csoporttagságok kezelését a Microsoft Entra-azonosítóban (korábbi nevén Azure Active Directoryban). Lehetséges, hogy a feladatot a hálózati rendszergazdáknak delegálja.

Szerepkörök érvényesítése

Tesztelje az egyes szerepköröket, hogy biztosan megfelelően szűrje a modellt. Ez egyszerűen elvégezhető a Modellezés menüszalaglap Nézet másként parancsával.

Ha a modell dinamikus szabályokkal rendelkezik az U Standard kiadás RNAME DAX függvénnyel, mindenképpen tesztelje a várt és váratlan értékeket. A Power BI-tartalmak beágyazásakor – különösen az ügyfelek számára készült beágyazási forgatókönyv használatával – az alkalmazáslogika bármilyen értéket átadhat érvényes identitás-felhasználónévként. Ha lehetséges, győződjön meg arról, hogy a véletlen vagy rosszindulatú értékek olyan szűrőket eredményeznek, amelyek nem adnak vissza sorokat.

Vegyünk egy példát a Power BI Embedded használatával, ahol az alkalmazás a felhasználó feladatszerepkörét adja át tényleges felhasználónévként: "Kezelő" vagy "Feldolgozó". A vezetők az összes sort láthatják, a feldolgozók azonban csak olyan sorokat láthatnak, ahol a Type oszlop értéke "Belső".

A következő szabálykifejezés van definiálva:

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

Ezzel a szabálykifejezéssel az a probléma, hogy a "Feldolgozó" kivételével minden érték az összes táblasort visszaadja. Tehát egy véletlen érték, például a "Wrker" véletlenül visszaadja az összes táblasort. Ezért biztonságosabb olyan kifejezést írni, amely teszteli az egyes várt értékeket. A következő továbbfejlesztett szabálykifejezésben egy váratlan érték azt eredményezi, hogy a tábla nem ad vissza sorokat.

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

Részleges RLS tervezése

A számításokhoz néha olyan értékekre van szükség, amelyeket nem korlátoznak az RLS-szűrők. Előfordulhat például, hogy egy jelentésnek meg kell jelenítenie a jelentésfelhasználó értékesítési régiójában szerzett bevétel arányát az összes megtermelt bevételhez viszonyítva.

Bár egy DAX-kifejezés nem tudja felülbírálni az RLS-t – sőt, még azt sem tudja megállapítani, hogy az RLS kényszerítve van-e – használhat összefoglaló modelltáblát. Az összegző modell táblázata lekéri az "összes régió" bevételét, és az RLS-szűrők nem korlátozzák.

Lássuk, hogyan implementálhatja ezt a tervezési követelményt. Először vegye figyelembe a következő modelltervet:

A modell négy táblából áll:

• A Salesperson tábla üzletkötőnként egy sort tárol. Tartalmazza a EmailAddress oszlopot, amely az egyes értékesítők e-mail-címét tárolja. Ez a táblázat rejtett.
• A Sales tábla megrendelésenként egy sort tárol. Tartalmazza a Revenue % All Region mértéket, amelynek célja, hogy a jelentésfelhasználó régiója által megtermelt bevétel arányát adja vissza az összes régió által megtermelt bevételhez.
• A Date tábla dátumonként egy sort tárol, és lehetővé teszi az év és a hónap szűrését és csoportosítását.
• A SalesRevenueSummary egy számított tábla. Az egyes rendelési dátumok teljes bevételét tárolja. Ez a táblázat rejtett.

Az alábbi kifejezés a SalesRevenueSummary számított táblát határozza meg:

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

Feljegyzés

Egy összesítő tábla ugyanazt a tervezési követelményt valósíthatja meg.

A következő RLS-szabályt alkalmazza a rendszer az Üzletkötő táblára:

[EmailAddress] = USERNAME()

A három modellkapcsolat mindegyikét az alábbi táblázat ismerteti:

Kapcsolat	Leírás
	A Salesperson és a Sales tábla között több-a-többhöz kapcsolat áll fenn. Az RLS-szabály az U Standard kiadás RNAME DAX függvény használatával szűri a rejtett Értékesítő tábla EmailAddress oszlopát. A Régió oszlop értéke (a jelentésfelhasználó esetében) a Sales táblába propagálja.
	A Dátum és az Értékesítés tábla között egy-a-többhöz kapcsolat áll fenn.
	A Dátum és a SalesRevenueSummary tábla között egy-a-többhöz kapcsolat áll fenn.

A következő kifejezés határozza meg a Revenue % All Region mértéket:

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

Feljegyzés

Ügyeljen arra, hogy ne tegyen nyilvánosságra bizalmas tényeket. Ha ebben a példában csak két régió szerepel, akkor egy jelentésfelhasználó kiszámíthatja a másik régió bevételét.

Mikor kerüljük el az RLS használatát?

Néha érdemes elkerülni az RLS használatát. Ha csak néhány egyszerű RLS-szabálya van, amelyek statikus szűrőket alkalmaznak, fontolja meg több szemantikai modell közzétételét. Egyik szemantikai modell sem határoz meg szerepköröket, mert minden szemantikai modell egy adott jelentés felhasználói célközönségének adatait tartalmazza, és ugyanazokkal az adatengedélyekkel rendelkezik. Ezután hozzon létre egy munkaterületet célközönségenként, és rendeljen hozzáférési engedélyeket a munkaterülethez vagy alkalmazáshoz.

Egy mindössze két értékesítési régióval rendelkező vállalat például úgy dönt, hogy minden értékesítési régióhoz egy szemantikai modellt tesz közzé különböző munkaterületeken. A szemantikai modellek nem kényszerítik az RLS-t. A forrásadatok szűréséhez azonban lekérdezési paramétereket használnak. Így ugyanaz a modell minden munkaterületen közzé lesz téve – csak különböző szemantikai modellparaméter-értékekkel rendelkeznek. Az értékesítők csak az egyik munkaterülethez (vagy közzétett alkalmazáshoz) kapnak hozzáférést.

Az RLS elkerülésének számos előnye van:

• Továbbfejlesztett lekérdezési teljesítmény: Kevesebb szűrő miatt jobb teljesítményt eredményezhet.
• Kisebb modellek: Bár több modellt eredményez, kisebb méretűek. A kisebb modellek javíthatják a lekérdezési és adatfrissítési válaszképességet, különösen akkor, ha az üzemeltetési kapacitás terhelést gyakorol az erőforrásokra. Emellett egyszerűbb a modellméreteket a kapacitás által előírt méretkorlátok alatt tartani. Végül egyszerűbb a számítási feladatok különböző kapacitások közötti egyensúlyba helyezése, mert különböző kapacitásokon hozhat létre munkaterületeket, vagy áthelyezheti a munkaterületeket.
• További funkciók: Az RLS-sel nem működő Power BI-funkciók, például a webes közzététel, használhatók.

Az RLS elkerülésének azonban vannak hátrányai:

• Több munkaterület: Minden jelentés felhasználói célközönségéhez egy munkaterület szükséges. Ha az alkalmazásokat közzéteszik, az azt is jelenti, hogy a jelentés felhasználói közönsége egy alkalmazást fog használni.
• Tartalom duplikálása: A jelentéseket és irányítópultokat minden munkaterületen létre kell hozni. Ez több erőfeszítést és időt igényel a beállításhoz és a karbantartáshoz.
• Magas jogosultsággal rendelkező felhasználók: A több jelentésfelhasználói célközönséghez tartozó magas jogosultságú felhasználók nem láthatják az adatok összesített nézetét. Több jelentést kell megnyitniuk (különböző munkaterületekről vagy alkalmazásokból).

Az RLS hibaelhárítása

Ha az RLS váratlan eredményeket eredményez, ellenőrizze a következő problémákat:

• Helytelen kapcsolatok léteznek a modelltáblák között az oszlopleképezések és a szűrési irányok szempontjából. Ne feledje, hogy az RLS-szűrők csak aktív kapcsolatokon keresztül propagálnak.
• Az Apply security filter in both directions relationship property (Biztonsági szűrő alkalmazása mindkét irányban) tulajdonság nincs megfelelően beállítva. További információkért tekintse meg a kétirányú kapcsolatra vonatkozó útmutatást.
• A táblák nem tartalmaznak adatokat.
• A rendszer helytelen értékeket tölt be a táblákba.
• A felhasználó több szerepkörhöz van leképezve.
• A modell összesítő táblákat tartalmaz, és az RLS-szabályok nem szűrik következetesen az összesítéseket és a részleteket. További információ: Aggregációk használata a Power BI Desktopban (RLS az összesítésekhez).

Ha egy adott felhasználó nem lát semmilyen adatot, az lehet, hogy az egyszerű felhasználónév nincs tárolva, vagy helytelenül lett beírva. Ez azért történhet meg hirtelen, mert a felhasználói fiókjuk megváltozott egy névmódosítás eredményeként.

Tipp.

Tesztelési célokra adjon hozzá egy mértéket, amely az U Standard kiadás RNAME DAX függvényt adja vissza. Nevezd el a "Ki vagyok én" nevet. Ezután adja hozzá a mértéket egy kártyás vizualizációhoz egy jelentésben, és tegye közzé a Power BI-ban.

A szemantikai modellhez csak olvasási engedéllyel rendelkező alkotók és felhasználók csak azokat az adatokat tekinthetik meg, amit láthatnak (az RLS-szerepkör-leképezésük alapján).

Ha egy felhasználó megtekint egy jelentést egy munkaterületen vagy egy alkalmazásban, előfordulhat, hogy az RLS a szemantikai modell engedélyétől függően kényszerítve van vagy sem. Ezért kritikus fontosságú, hogy a tartalomfelhasználók és a tartalomkészítők csak olvasási engedéllyel rendelkezzenek a mögöttes szemantikai modellen, amikor az RLS-t kötelezővé kell tenni. Azoknak az engedélyszabályoknak a részleteiért, amelyek meghatározzák, hogy az RLS kényszerítve van-e, tekintse meg a jelentés fogyasztói biztonsági tervezéséről szóló cikket.

Kapcsolódó tartalom

A cikkhez kapcsolódó további információkért tekintse meg a következő forrásokat:

• Sorszintű biztonság (RLS) a Power BI-jal
• Adathozzáférés korlátozása sorszintű biztonsággal (RLS) a Power BI Desktophoz
• Modellkapcsolatok a Power BI Desktopban
• A Power BI implementálásának megtervezése: Jelentés a fogyasztók biztonságának tervezéséről
• Kérdése van? Kérdezze meg a Power BI-közösség
• Javaslatok? Ötletek hozzáadása a Power BI fejlesztéséhez