A Power BI-modell adataihoz való hozzáférés korlátozása

Befejeződött

Adatmodellezőként egy vagy több szerepkör létrehozásával állíthatja be az RLS-t. Egy szerepkörnek egyedi neve van a modellben, és általában egy vagy több szabályt tartalmaz. A szabályok adatelemzési kifejezések (DAX) szűrőkifejezések használatával kényszerítik a szűrőket a modelltáblákra.

Feljegyzés

Alapértelmezés szerint az adatmodellnek nincsenek szerepkörei. A szerepkör nélküli adatmodellek azt jelentik, hogy a felhasználók (akik rendelkeznek engedéllyel az adatmodell lekérdezésére) hozzáféréssel rendelkeznek az összes modelladathoz.

Tipp.

Olyan szerepkör definiálható, amely nem tartalmaz szabályokat. Ebben az esetben a szerepkör hozzáférést biztosít az összes modelltábla összes sorához. Ez a szerepkör be van állítva egy olyan rendszergazdai felhasználó számára, aki az összes adatot megtekintheti.

Szerepköröket hozhat létre, érvényesíthet és kezelhet a Power BI Desktopban. Azure Analysis Services- vagy SQL Server Analysis Services-modellek esetén az SQL Server Data Tools (SSDT) használatával szerepköröket hozhat létre, érvényesíthet és kezelhet.

Szerepköröket az SQL Server Management Studio (SSMS) vagy egy külső eszköz, például a Tabular Editor használatával is létrehozhat és kezelhet.

Ha jobban szeretné megismerni, hogy az RLS hogyan korlátozza az adatokhoz való hozzáférést, tekintse meg az alábbi animált képet.

Animated diagram demonstrates how row-level security works for two users who each have access to specific country data.

Csillagséma tervezési alapelveinek alkalmazása

Javasoljuk, hogy a csillagséma tervezési alapelveit alkalmazza a dimenzió- és ténytáblákból álló modell létrehozásához. Gyakori, hogy a Power BI-t úgy állítja be, hogy kikényszerítse a dimenziótáblák szűrésére vonatkozó szabályokat, így a modellkapcsolatok hatékonyan propagálja ezeket a szűrőket ténytáblákra.

Az alábbi képen az Adventure Works értékesítési elemzési adatmodelljének modelldiagramja látható. Egy csillagséma-kialakítást jelenít meg, amely egyetlen Sales nevű ténytáblát tartalmaz. A többi tábla dimenziótáblák, amelyek támogatják az értékesítési mértékek dátum, értékesítési terület, ügyfél, viszonteladó, rendelés, termék és értékesítő szerinti elemzését. Figyelje meg az összes táblát összekötő modellkapcsolatokat. Ezek a kapcsolatok szűrőket propagálnak (közvetlenül vagy közvetve) a Sales táblába.

Screenshot shows a Power B I Desktop model diagram comprising the tables and relationships as described in the previous paragraph.

Ez a modellterv az ebben a leckében bemutatott példákat támogatja.

Szabályok definiálása

A szabálykifejezések kiértékelése sorkörnyezetben történik. A sorkörnyezet azt jelenti, hogy a kifejezés kiértékelése minden sorhoz az adott sor oszlopértékeivel történik. Amikor a kifejezés IGAZ értéket ad vissza, a felhasználó "láthatja" a sort.

Tipp.

A sorkörnyezettel kapcsolatos további információkért tekintse meg a Számított táblák és oszlopok hozzáadása a Power BI Desktop modelljeihez modult. Ez a modul a modellszámítások hozzáadását ismerteti, de tartalmaz egy olyan egységet, amely bemutatja és leírja a sorkörnyezetet.

Statikus vagy dinamikus szabályokat is meghatározhat.

Statikus szabályok

A statikus szabályok állandókra hivatkozó DAX-kifejezéseket használnak.

Vegye figyelembe a Régió táblára alkalmazott alábbi szabályt, amely korlátozza a Midwest-értékesítésekhez való adathozzáférést.


'Region'[Region] = "Midwest"

Az alábbi lépések bemutatják, hogyan kényszeríti a Power BI a szabályt. Ez:

  1. Szűri a Region (Régió) táblát, amely egy látható sort eredményez (a Midwest esetében).

  2. A modellkapcsolat használatával propagálja a Region tábla szűrőt az Állapot táblába, ami 14 látható sort eredményez (a Középnyugati régió 14 államból áll).

  3. A modellkapcsolat segítségével propagálja az Állapottábla szűrőt a Sales táblába, ami több ezer látható sort eredményez (a Midwest régióhoz tartozó állapotok értékesítési tényeit).

A létrehozható legegyszerűbb statikus szabály korlátozza az összes táblasorhoz való hozzáférést. Vegye figyelembe a Sales Details táblára alkalmazott alábbi szabályt (a modelldiagramon nem látható).


FALSE()

Ez a szabály biztosítja, hogy a felhasználók ne férhessenek hozzá táblaadatokhoz. Hasznos lehet, ha az értékesítők számára engedélyezett az összesített értékesítési eredmények megtekintése (a Sales táblából), de a rendelésszintű adatok nem.

A statikus szabályok meghatározása egyszerű és hatékony. Fontolja meg a használatukat, ha csak néhányat kell létrehoznia, ahogyan az Adventure Works esetében is, ahol csak hat usa-beli régió van. Azonban vegye figyelembe a hátrányokat: a statikus szabályok beállítása jelentős erőfeszítést igényelhet a létrehozáshoz és a beállításhoz. Emellett az új régiók előkészítésekor frissítenie és újra közzé kell tennie az adathalmazt.

Ha sok szabályt kell beállítani, és a jövőben új szabályokat szeretne hozzáadni, fontolja meg inkább a dinamikus szabályok létrehozását.

Dinamikus szabályok

A dinamikus szabályok konkrét DAX-függvényeket használnak, amelyek környezeti értékeket adnak vissza (az állandókkal szemben). A környezeti értékek három konkrét DAX-függvényből lesznek visszaadva:

  • U Standard kiadás RNAME vagy U Standard kiadás RPRINCIPALNAME – Szöveges értékként adja vissza a Power BI által hitelesített felhasználót.

  • CUSTOMDATA – A kapcsolati sztring átadott CustomData tulajdonságot adja vissza. A nem Power BI jelentéskészítő eszközök, amelyek egy kapcsolati sztring keresztül csatlakoznak az adathalmazhoz, beállíthatják ezt a tulajdonságot, például a Microsoft Excelt.

Feljegyzés

Vegye figyelembe, hogy az U Standard kiadás RNAME függvény tartomány\felhasználónév formátumban adja vissza a felhasználót a Power BI Desktopban való használatkor. A Power BI szolgáltatás azonban a felhasználó egyszerű felhasználóneve (UPN) formátumát adja vissza, példáulusername@adventureworks.com. Másik lehetőségként használhatja az U Standard kiadás RPRINCIPALNAME függvényt, amely mindig az egyszerű felhasználónév formátumában adja vissza a felhasználót.

Fontolja meg a módosított modelltervet, amely most már tartalmazza a (rejtett) AppUser táblát. Az AppUser tábla minden sora egy felhasználónevet és egy régiót ír le. A Régió táblával létesített modellkapcsolat szűrőket propagálja az AppUser táblából.

Image shows a revised model diagram that now includes the AppUser table. This table has two columns: Region and User Name.

Az AppUser táblára alkalmazott alábbi szabály korlátozza a hitelesített felhasználó régióihoz való adathozzáférést.


'AppUser'[UserName] = USERPRINCIPALNAME()

A dinamikus szabályok definiálása egyszerű és hatékony, ha a modelltáblák felhasználónév-értékeket tárolnak. Lehetővé teszik az adatvezérelt RLS-kialakítás kikényszerítését. Ha például az értékesítőket hozzáadják vagy eltávolítják az AppUser táblából (vagy különböző régiókhoz vannak rendelve), ez a tervezési módszer egyszerűen működik.

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

Szerepkörök létrehozásakor fontos tesztelni őket, hogy a megfelelő szűrőket alkalmazzák. A Power BI Desktopban létrehozott adatmodellek esetében a Nézet mint függvény lehetővé teszi a jelentés megtekintését különböző szerepkörök kényszerítésekor, valamint a különböző felhasználónévértékek átadásakor.

Screenshot shows the Power B I Desktop Modeling ribbon. The “View as” command is highlighted.

Szerepkör-leképezések beállítása

A szerepkör-leképezéseket a Power BI-tartalmakhoz hozzáférő felhasználók előtt kell beállítani. A szerepkör-leképezés magában foglalja a Microsoft Entra biztonsági objektumok szerepkörökhöz való hozzárendelését. A biztonsági objektumok lehetnek felhasználói fiókok vagy biztonsági csoportok.

Tipp.

Ha lehetséges, ajánlott a szerepkörök biztonsági csoportokhoz való leképezése. Így kevesebb leképezés lesz, és delegálhatja a csoporttagság-kezelést a hálózati rendszergazdáknak.

A Power BI Desktop által kifejlesztett modellek esetében a szerepkör-leképezés általában a Power BI szolgáltatás történik. Az Azure Analysis Services vagy az SQL Server Analysis Services-modellek esetében a szerepkör-leképezés általában az SSMS-ben történik.

Az RLS beállításával kapcsolatos további információkért lásd:

Egyszeri bejelentkezés (SSO) használata DirectQuery-forrásokhoz

Ha az adatmodell DirectQuery-táblákkal rendelkezik, és adatforrásuk támogatja az egyszeri bejelentkezést, az adatforrás kikényszerítheti az adatengedélyeket. Így az adatbázis kikényszeríti az RLS-t, és a Power BI-adathalmazok és -jelentések tiszteletben tartják az adatforrás biztonságát.

Vegye figyelembe, hogy az Adventure Works rendelkezik egy Azure SQL Database-adatbázissal az értékesítési műveleteikhez, amely ugyanabban a bérlőben található, mint a Power BI. Az adatbázis kikényszeríti az RLS-t a különböző adatbázistáblák soraihoz való hozzáférés szabályozásához. Létrehozhat egy DirectQuery-modellt, amely szerepkörök nélkül csatlakozik ehhez az adatbázishoz, és közzéteheti a Power BI szolgáltatás. Amikor beállítja az adatforrás hitelesítő adatait a Power BI szolgáltatás, engedélyezi az egyszeri bejelentkezést. Amikor a jelentésfelhasználók megnyitják a Power BI-jelentéseket, a Power BI átadja az identitásukat az adatforrásnak. Az adatforrás ezután kikényszeríti az RLS-t a jelentésfelhasználó identitása alapján.

Screenshot shows the data source credentials window with the S O option enabled.

Az Azure SQL Database RLS-ről további információt a sorszintű biztonság című témakörben talál.

Feljegyzés

Az SSO-hitelesítéssel rendelkező adatforrásból származó DirectQuery-táblákra hivatkozó számított táblák és számított oszlopok nem támogatottak a Power BI szolgáltatás.

Az egyszeri bejelentkezést támogató adatforrásokkal kapcsolatos további információkért lásd : Egyszeri bejelentkezés (SSO) DirectQuery-források esetén.