Udalosti
Pridajte sa k nám vo Vegas FabCon
31. 3., 23 - 2. 4., 23
Konečná udalosť pod vedením komunity služby Microsoft Fabric, Power BI, SQL a AI. Marec 31 až Apríl 2, 2025.
Zaregistrujte saTento prehliadač už nie je podporovaný.
Inovujte na Microsoft Edge a využívajte najnovšie funkcie, aktualizácie zabezpečenia a technickú podporu.
Tento článok je určený pre modelárov údajových pracujúcich s aplikáciou Power BI Desktop. Popisuje vhodné postupy návrhu na vynucovanie zabezpečenia na úrovni riadkov v dátových modeloch.
Je dôležité pochopiť, že zabezpečenie na úrovni riadkov filtruje riadky tabuľky. Nemôžu byť nakonfigurované tak, aby obmedzovali prístup k objektom modelu vrátane tabuliek, stĺpcov alebo mierok.
Poznámka
Tento článok nepopisuje zabezpečenie na úrovni riadkov ani to, ako ho nastaviť. Ďalšie informácie nájdete v téme Obmedzenie prístupu k údajom so zabezpečením na úrovni riadkov (RLS) pre Power BI Desktop.
Nezaoberá sa ani vynucovaním zabezpečenia na úrovni riadkov v dynamických pripojeniach k modelom umiestneným v externom hostiteľskom systéme so službou Azure Analysis Services alebo SQL Server Analysis Services. V týchto prípadoch zabezpečenie na úrovni riadkov vynucuje Analysis Services. Keď sa Power BI pripojí pomocou jediného prihlásenia (SSO), Analysis Services vynúti zabezpečenie na úrovni riadkov (pokiaľ konto nemá oprávnenia správcu).
Je možné vytvoriť viacero rolí. Keď uvažujete o potrebách povolení pre jedného používateľa zostavy, snažte sa vytvoriť jednu rolu, ktorá udelí všetky tieto povolenia, namiesto návrhu, v ktorom bude používateľ zostavy členom viacerých rolí. Dôvodom je, že používateľ zostavy by mohol byť priradený k viacerým rolám, a to buď priamo pomocou svojho používateľského konta, alebo nepriamo na základe členstva v skupine zabezpečenia. Priradenia k viacerým rolám môžu viesť k neočakávaným výsledkom.
Keď je používateľ zostavy priradený k viacerým rolám, filtre zabezpečenia na úrovni riadkov sa stávajú súčtami. To znamená, že používatelia zostavy môžu zobraziť riadky tabuľky, ktoré predstavujú zjednotenie týchto filtrov. V niektorých scenároch navyše nie je možné zaručiť, že používateľovi zostavy sa nezobrazujú riadky v tabuľke. Na rozdiel od povolení použitých na objekty databázy SQL Servera (a iných modelov povolení) teda neplatí zásada "zamietnuté raz, zamietnuté vždy".
Predstavte si model s dvomi rolami: Prvá rola s názvom Pracovníci obmedzuje prístup ku všetkým riadkom tabuľky Payroll pomocou nasledujúceho výrazu pravidla:
FALSE()
Poznámka
Pravidlo nevráti žiadne riadky tabuľky, keď sa jeho výraz vyhodnotí ako FALSE
.
Napriek tomu druhá rola s názvom Managers povoľuje prístup ku všetkým riadkom tabuľky Payroll pomocou nasledujúceho výrazu pravidla:
TRUE()
Pozor: Ak je používateľ zostavy priradený k obom rolám, zobrazia sa mu všetky riadky tabuľky Payroll .
Zabezpečenie na úrovni riadkov funguje tak, že automaticky použije filtre na každý dotaz DAX, a tieto filtre môžu mať negatívny vplyv na výkon dotazov. Efektívne zabezpečenie na úrovni riadkov preto pripadá na dobrý návrh modelu. Je dôležité riadiť sa pokynmi pre návrh modelu popísané v nasledujúcich článkoch:
Vo všeobecnosti je často efektívnejšie vynútiť filtre zabezpečenia na úrovni riadkov na tabuľky dimenzií a nie na tabuľky faktov. A zároveň sa spoľahnúť na vhodne navrhnuté vzťahy, ktoré zaistia rozšírenie filtrov zabezpečenia na úrovni riadkov do ostatných tabuliek modelu. Filtre zabezpečenia na úrovni riadkov sa šíria iba prostredníctvom aktívnych vzťahov. Preto sa vyhýbajte použitiu funkcie jazyka DAX LOOKUPVALUE , keď by mohli rovnaký výsledok dosiahnuť modelové vzťahy.
Nezabudnite optimalizovať zdrojovú databázu vždy, keď sa vynucujú filtre zabezpečenia na úrovni riadkov na tabuľky DirectQuery a existujú vzťahy na iné tabuľky DirectQuery. Jeho súčasťou môže byť navrhnutie vhodných indexov alebo použitie trvalých vypočítaných stĺpcov. Ďalšie informácie nájdete v téme Sprievodný materiál k modelu DirectQuery v Aplikácii Power BI Desktop.
Pomocou Analyzátor výkonu je možné merať vplyv filtrov zabezpečenia na úrovni riadkov na výkon v aplikácii Power BI Desktop. Najprv určte trvania dotazov vizuálu zostavy, keď sa zabezpečenie na úrovni riadkov nevynucuje. Potom použite príkaz Zobraziť ako na karte Modelovanie na páse s nástrojmi na vynútenie zabezpečenia na úrovni riadkov a zistite a porovnajte trvania dotazov.
Po publikovaní v službe Power BI musíte priradiť členov k sémantickým rolám modelu. Pridávať členov k rolám môžu len sémantickí vlastníci modelu alebo správcovia pracovného priestoru. Ďalšie informácie nájdete v téme Zabezpečenie na úrovni riadkov (RLS) v Power BI (v časti Spravovanie zabezpečenia v modeli).
Členmi môžu byť používateľské kontá, skupiny zabezpečenia, distribučné skupiny alebo skupiny s podporou e-mailu. Vždy, keď je to možné, odporúčame k sémantickým rolám modelu priradiť skupiny zabezpečenia. Tento proces zahŕňa spravovanie členskej skupiny zabezpečenia v službe Microsoft Entra ID. Tým sa táto úloha pravdepodobne deleguje na vašich správcov siete.
Otestujte každú rolu a ubezpečte sa, že správne filtruje model. Dá sa to jednoducho vykonať pomocou príkazu Zobraziť ako na karte Modelovanie na páse s nástrojmi.
Ak model obsahuje dynamické pravidlá používajúce funkciu jazyka DAX USERNAME , nezabudnite otestovať očakávané a neočakávané hodnoty. Pri vkladaní obsahu služby Power BI – konkrétne s použitím scenára Vloženie obsahu pre zákazníkov – môže logika aplikácie odovzdať ľubovoľnú hodnotu ako meno používateľa s efektívnou identitou. Vždy, keď je to možné, zabezpečte, aby v prípade náhodných alebo škodlivých hodnôt boli výsledkom filtre, ktoré nevrátia žiadne riadky.
Zoberme si príklad použitia služby Power BI Embedded, v ktorom aplikácia odovzdáva rolu pracovnej pozície používateľa ako efektívne meno používateľa: je to buď "Manager" (Manažér) alebo "Worker". Manažéri môžu zobraziť všetky riadky, ale pracovníci môžu zobraziť iba riadky, v ktorých má stĺpec Type hodnotu "Internal".
Je definovaný nasledujúci výraz pravidla:
IF(
USERNAME() = "Worker",
[Type] = "Internal",
TRUE()
)
Problém s týmto výrazom pravidla spočíva v tom, že všetky hodnoty okrem hodnoty "Worker" vrátia všetky riadky tabuľky. Takže náhodná hodnota, napríklad "Wrker", neúmyselne vráti všetky riadky tabuľky. Preto je bezpečnejšie napísať výraz, ktorý testuje každú očakávanú hodnotu. V nasledujúcom vylepšenom výraze pravidla spôsobí neočakávaná hodnota v tabuľke žiadne riadky.
IF(
USERNAME() = "Worker",
[Type] = "Internal",
IF(
USERNAME() = "Manager",
TRUE(),
FALSE()
)
)
Výpočty niekedy potrebujú hodnoty, ktoré nie sú obmedzené filtrami zabezpečenia na úrovni riadkov. Zostava môže napríklad potrebovať zobraziť pomer medzi výnosmi získanými v rámci oblasti predaja používateľa zostavy a všetkými získanými výnosmi.
Hoci výraz DAX nemôže prepísať zabezpečenie na úrovni riadkov – v skutočnosti ani nedokáže určiť, že zabezpečenie na úrovni riadkov sa vynucuje – môžete použiť súhrnnú tabuľku modelu. Súhrnná modelová tabuľka bude dotazovaná na načítanie výnosov pre všetky oblasti a nie je obmedzená žiadnymi filtrami zabezpečenia na úrovni riadkov.
Pozrime sa, ako by ste mohli implementovať túto požiadavku na návrh. Najprv zvážte nasledujúci návrh modelu:
Model sa skladá zo štyroch tabuliek:
Nasledujúci výraz definuje vypočítavanú tabuľku SalesRevenueSummary :
SalesRevenueSummary =
SUMMARIZECOLUMNS(
Sales[OrderDate],
"RevenueAllRegion", SUM(Sales[Revenue])
)
Poznámka
Na tabuľku Salesperson sa použije nasledujúce pravidlo zabezpečenia na úrovni riadkov:
[EmailAddress] = USERNAME()
V nasledujúcej tabuľke sú popísané tri jednotlivé modelové vzťahy:
Vzťah | Description |
---|---|
Medzi tabuľkami Salesperson a Sales existuje vzťah typu many-to-many. Pravidlo zabezpečenia na úrovni riadkov filtruje stĺpec EmailAddress skrytej tabuľky Salesperson pomocou funkcie jazyka DAX USERNAME . Hodnota stĺpca Region (pre používateľa zostavy) sa rozšíri do tabuľky Sales . | |
Medzi tabuľkami Date a Sales existuje vzťah one-to-many. | |
Existuje vzťah one-to-many medzi tabuľkami Date a SalesRevenueSummary . |
Nasledujúci výraz definuje mierku Revenue % All Region :
Revenue % All Region =
DIVIDE(
SUM(Sales[Revenue]),
SUM(SalesRevenueSummary[RevenueAllRegion])
)
Poznámka
Dbajte, aby ste nezverejnili citlivé fakty. Ak by v tomto príklade existovali len dve oblasti, používateľ zostavy by mohol vypočítať výnosy v rámci druhej oblasti.
Niekedy je vhodné vyhnúť sa používaniu zabezpečenia na úrovni riadkov. Ak máte len niekoľko zjednodušených pravidiel zabezpečenia na úrovni riadkov, ktoré používajú statické filtre, namiesto toho zvážte publikovanie viacerých sémantických modelov. Žiadna zo sémantických modelov nedefinuje roly, pretože každý sémantický model obsahuje údaje pre konkrétnu skupinu používateľov zostáv, ktorá má rovnaké povolenia pre údaje. Potom vytvorte jeden pracovný priestor na každú skupinu používateľov a priraďte k pracovnému priestoru alebo aplikácii povolenia na prístup.
Napríklad spoločnosť, ktorá má len dve oblasti predaja, sa rozhodne publikovať sémantický model pre každú oblasť predaja v rôznych pracovných priestoroch. Sémantické modely nevynucujú zabezpečenie na úrovni riadkov. Používajú však parametre dotazu na filtrovanie zdrojových údajov. Týmto spôsobom sa v každom pracovnom priestore publikuje rovnaký model – líšia sa len rôznymi hodnotami parametrov sémantického modelu. Predajcovia majú priradený prístup len k jednému z pracovných priestorov (alebo publikovaných aplikácií).
Nepoužívanie zabezpečenia na úrovni riadkov má niekoľko výhod:
Nepoužívanie zabezpečenia na úrovni riadkov má však aj nevýhody:
Ak zabezpečenie na úrovni riadkov poskytuje neočakávané výsledky, skontrolujte nasledujúce problémy:
Ak konkrétny používateľ nemôže zobraziť žiadne údaje, môže to byť spôsobené tým, že jeho hlavné meno používateľa nie je uložené alebo je zadané nesprávne. Môže k tomu dôjsť náhle, pretože jeho používateľské konto sa zmenilo z dôvodu zmeny mena.
Tip
Na testovacie účely pridajte mierku, ktorá vráti funkciu jazyka DAX USERNAME . Možno ho nazvite "Kto som". Potom mieru pridajte na vizuál karty v zostave a publikujte ju v službe Power BI.
Tvorcovia a spotrebitelia s povolením iba na čítanie v sémantickom modeli budú môcť zobraziť len údaje, ktoré im môžu zobrazovať (na základe priradenia rolí zabezpečenia na úrovni riadkov).
Keď používateľ zobrazí zostavu v pracovnom priestore alebo aplikácii, zabezpečenie na úrovni riadkov sa môže, ale nemusí vynútiť v závislosti od jeho povolení pre sémantický model. Z tohto dôvodu je mimoriadne dôležité, aby používatelia a tvorcovia obsahu mali povolenie na čítanie iba v prípade základného sémantického modelu, keď je potrebné vynútiť zabezpečenie na úrovni riadkov. Podrobnosti o pravidlách povolení, ktoré určujú, či sa zabezpečenie na úrovni riadkov vynucuje, nájdete v článku Plánovanie zabezpečenia spotrebiteľa zostavy.
Ďalšie informácie súvisiace s týmto článkom nájdete v nasledujúcich zdrojoch:
Udalosti
Pridajte sa k nám vo Vegas FabCon
31. 3., 23 - 2. 4., 23
Konečná udalosť pod vedením komunity služby Microsoft Fabric, Power BI, SQL a AI. Marec 31 až Apríl 2, 2025.
Zaregistrujte saŠkolenie
Modul
Implementácia zabezpečenia na úrovni riadkov - Training
Zabezpečenie na úrovni riadkov (RLS) umožňuje vytvoriť jednu alebo viac zostáv, ktoré sa zacielia na údaje pre konkrétneho používateľa. V tomto module sa dozviete, ako implementovať zabezpečenie na úrovni riadkov pomocou statickej alebo dynamickej metódy a tiež ako služba Microsoft Power BI zjednodušuje testovanie zabezpečenia na úrovni riadkov v službách Power BI Desktop a služba Power BI.
Certifikácia
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.