Sprievodný materiál k zabezpečeniu na úrovni riadkov v aplikácii Power BI Desktop

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).

Vytvorenie rolí

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 .

Optimalizácia zabezpečenia na úrovni riadkov

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:

• Vysvetlenie hviezdicovej schémy a jej dôležitosti pre Power BI
• Všetky články so sprievodnými materiálmi k vzťahom v dokumentácii so sprievodnými materiálmi k službe Power BI

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.

Meranie vplyvu zabezpečenia na úrovni riadkov

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.

Konfigurácia priradení k rolám

Po publikovaní v službe Power BI musíte priradiť členov k sémantickým modelom (predtým známym ako množina údajov). 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. Zahŕňa spravovanie členskupín zabezpečenia v službe Microsoft Entra ID (predtým známe ako Azure Active Directory). Tým sa táto úloha pravdepodobne deleguje na vašich správcov siete.

Overenie rolí

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()
    )
)

Návrh čiastočného zabezpečenia na úrovni riadkov

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:

• Tabuľka Salesperson ukladá jeden riadok na predajcu. Obsahuje stĺpec EmailAddress , v ktorom je uložená e-mailová adresa každého predajcu. Táto tabuľka je skrytá.
• Tabuľka Sales ukladá jeden riadok na objednávku. Obsahuje mierku Revenue % All Region (Výnos v % celá oblasť ), ktorá je navrhnutá tak, aby vrátila pomer výnosov získaných z oblasti používateľa zostavy k výnosom získaným všetkými oblasťami.
• Tabuľka Date ukladá jeden riadok na dátum a umožňuje filtrovanie a zoskupovanie roka a mesiaca.
• SalesRevenueSummary je vypočítaná tabuľka. Ukladá celkové výnosy za každý dátum objednávky. Táto tabuľka je skrytá.

Nasledujúci výraz definuje vypočítavanú tabuľku SalesRevenueSummary :

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

Poznámka

Rovnakú požiadavku na návrh by splnila agregačná tabuľka .

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.

Kedy sa vyhnúť používaniu zabezpečenia na úrovni riadkov

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:

• Vylepšený výkon dotazov: Výsledkom môže byť zvýšenie výkonu v dôsledku menšieho počtu filtrov.
• Menšie modely: hoci je výsledkom viac modelov, tieto modely sú menšie. Menšie modely môžu zlepšiť odozvu dotazu a obnovenia údajov, a to najmä vtedy, ak sa hostiteľská kapacita nachádza pod tlakom na zdroje. Je tiež jednoduchšie udržiavať veľkosti modelov pod limitmi veľkosti, ktoré ukladá vaša kapacita. A nakoniec je jednoduchšie vyrovnávať vyťaženia v rámci rôznych kapacít, pretože môžete vytvárať pracovné priestory v rôznych kapacitách alebo ich medzi ktorými presúvať.
• Ďalšie funkcie: je možné používať funkcie služby Power BI, ktoré nefungujú so zabezpečením na úrovni riadkov, ako je napríklad publikovanie na webe.

Nepoužívanie zabezpečenia na úrovni riadkov má však aj nevýhody:

• Viaceré pracovné priestory: pre každú skupinu používateľov zostáv sa vyžaduje jeden pracovný priestor. Ak sú publikované aplikácie, znamená to tiež, že na každú skupinu používateľov zostáv je k dispozícii jedna aplikácia.
• Duplicita obsahu: Zostavy a tabule je potrebné vytvoriť v každom pracovnom priestore. To si vyžaduje viac úsilia a času na nastavenie a údržbu.
• Používatelia s vysokými oprávneniami: používatelia s vysokými oprávneniami, ktorí patria do viacerých skupín používateľov zostáv, nemajú k dispozícii konsolidovaný pohľad na údaje. Musia si otvoriť viacero zostáv (z rôznych pracovných priestorov alebo aplikácií).

Riešenie problémov so zabezpečením na úrovni riadkov

Ak zabezpečenie na úrovni riadkov poskytuje neočakávané výsledky, skontrolujte nasledujúce problémy:

• Medzi tabuľkami modelu existujú nesprávne vzťahy z hľadiska priradení stĺpcov a smerov filtrov. Majte na pamäti, že filtre zabezpečenia na úrovni riadkov sa šíria len prostredníctvom aktívnych vzťahov.
• Vlastnosť vzťahu Použiť filtre zabezpečenia v oboch smeroch nie je správne nastavená. Ďalšie informácie nájdete v téme Pokyny na dvojsmerné vzťahy.
• Tabuľky neobsahujú žiadne údaje.
• Do tabuliek sa načítajú nesprávne hodnoty.
• Používateľ je priradený k viacerým rolám.
• Model zahŕňa agregačné tabuľky a pravidlá zabezpečenia na úrovni riadkov nefiltrujú konzistentne agregácie a podrobnosti. Ďalšie informácie nájdete v téme Použitie agregácií v aplikácii Power BI Desktop (RLS pre agregácie).

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.

Prepitné

Na testovacie účely pridajte mierku, ktorá vráti funkciu jazyka DAX USERNAME . Môžete 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.

Súvisiaci obsah

Ďalšie informácie súvisiace s týmto článkom nájdete v nasledujúcich zdrojoch:

• Zabezpečenie na úrovni riadkov (RLS) v Power BI
• Obmedzenie prístupu k údajom so zabezpečením na úrovni riadkov (RLS) pre Power BI Desktop
• Vzťahy modelov v aplikácii Power BI Desktop
• Plánovanie implementácie služby Power BI: Plánovanie zabezpečenia spotrebiteľov zostáv
• Máte nejaké otázky? Skúste sa spýtať Komunita Power BI
• Návrhy? Prispejte nápadmi na zlepšenie služby Power BI