Pokyny k zabezpečení na úrovni řádků (RLS) v Power BI Desktopu

Tento článek se zaměřuje na modelátora dat, který pracuje s Power BI Desktopem. Popisuje osvědčené postupy návrhu pro vynucování zabezpečení na úrovni řádků (RLS) v datových modelech.

Je důležité pochopit, že zabezpečení na úrovni řádků v tabulce filtruje. Není možné je nakonfigurovat tak, aby omezovaly přístup k objektům modelu, včetně tabulek, sloupců nebo měr.

Poznámka:

Tento článek nepopisuje zabezpečení na úrovni řádků ani jeho nastavení. Další informace najdete v tématu Omezení přístupu k datům pomocí zabezpečení na úrovni řádků (RLS) pro Power BI Desktop.

Nevztahuje se také na vynucování zabezpečení na úrovni řádků v živých připojeních k externím hostovaným modelům se službou Azure Analysis Services nebo Služba Analysis Services serveru SQL. V těchto případech služba Analysis Services vynucuje zabezpečení na úrovni řádků. Když se Power BI připojí pomocí jednotného přihlašování (SSO), služba Analysis Services vynutí zabezpečení na úrovni řádků (pokud účet nemá oprávnění správce).

Vytvoření rolí

Je možné vytvořit více rolí. Při zvažování potřeb oprávnění pro jednoho uživatele sestavy se snažte vytvořit jednu roli, která uděluje všechna tato oprávnění, místo návrhu, kde bude uživatel sestavy členem více rolí. Je to proto, že uživatel sestavy může namapovat na více rolí, a to buď přímo pomocí svého uživatelského účtu, nebo nepřímo prostřednictvím členství ve skupině zabezpečení. Více mapování rolí může vést k neočekávaným výsledkům.

Když je uživatel sestavy přiřazený k více rolím, filtry zabezpečení na úrovni řádků se stanou doplňkovými. To znamená, že uživatelé sestavy uvidí řádky tabulky, které představují sjednocení těchto filtrů. V některých scénářích navíc není možné zaručit, že uživatel sestavy neuvidí řádky v tabulce. Na rozdíl od oprávnění použitých u databázových objektů SQL Serveru (a jiných modelů oprávnění) se princip "jakmile odepře vždy odepřen" nepoužije.

Představte si model se dvěma rolemi: První role s názvem Pracovní procesy omezuje přístup ke všem řádkům tabulky Mzdy pomocí následujícího výrazu pravidla:

FALSE()

Poznámka:

Pravidlo nevrátí žádné řádky tabulky, když se jeho výraz vyhodnotí jako FALSE.

Druhá role s názvem Manažeři ale umožňuje přístup ke všem řádkům tabulky Mzdy pomocí následujícího výrazu pravidla:

TRUE()

Dbejte na to: Pokud se uživatel sestavy mapuje na obě role, uvidí všechny řádky tabulky Mzdy .

Optimalizace zabezpečení na úrovni řádků

Zabezpečení na úrovni řádků funguje tak, že automaticky použije filtry na každý dotaz DAX a tyto filtry můžou mít negativní dopad na výkon dotazů. Efektivní zabezpečení na úrovni řádků se tedy týká dobrého návrhu modelu. Je důležité postupovat podle pokynů k návrhu modelu, jak je popsáno v následujících článcích:

• Vysvětlení hvězdicového schématu a důležitosti pro Power BI
• Všechny články s pokyny k relacím, které najdete v dokumentaci k pokynům k Power BI

Obecně platí, že je efektivnější vynucovat filtry zabezpečení na úrovni řádků u tabulek dimenzí, nikoli tabulek faktů. A spoléháte na dobře navržené relace, abyste zajistili, že se filtry zabezpečení na úrovni řádků rozšíří do jiných tabulek modelu. Filtry zabezpečení na úrovni řádků se šíří pouze prostřednictvím aktivních relací. Proto nepoužívejte funkci DAX LOOKUPVALUE , pokud by relace modelu mohly dosáhnout stejného výsledku.

Vždy, když se filtry zabezpečení na úrovni řádků vynucují u tabulek DirectQuery a existují relace s jinými tabulkami DirectQuery, nezapomeňte zdrojová databáze optimalizovat. Může zahrnovat návrh vhodných indexů nebo použití trvalých počítaných sloupců. Další informace najdete v pokynech k modelu DirectQuery v Power BI Desktopu.

Měření dopadu zabezpečení na úrovni řádků

Pomocí Analyzátor výkonu je možné měřit dopad filtrů RLS na výkon v Power BI Desktopu. Nejprve určete dobu trvání dotazu vizuálu sestavy, pokud není vynuceno zabezpečení na úrovni řádků. Potom pomocí příkazu Zobrazit jako na kartě Modelování na pásu karet vynucujte zabezpečení na úrovni řádků a určete a porovnejte doby trvání dotazu.

Konfigurace mapování rolí

Po publikování do Power BI musíte členy mapovat na sémantické modely (dříve označované jako datové sady). Do rolí můžou přidávat členy pouze sémantické vlastníky modelu nebo správci pracovního prostoru. Další informace najdete v tématu Zabezpečení na úrovni řádků (RLS) pomocí Power BI (Správa zabezpečení v modelu).

Členy můžou být uživatelské účty, skupiny zabezpečení, distribuční skupiny nebo skupiny s podporou pošty. Kdykoli je to možné, doporučujeme namapovat skupiny zabezpečení na sémantické role modelu. Zahrnuje správu členství ve skupinách zabezpečení v Microsoft Entra ID (dříve označované jako Azure Active Directory). Pravděpodobně tento úkol deleguje na správce sítě.

Ověření rolí

Otestujte každou roli, abyste měli jistotu, že model správně filtruje. Snadno to uděláte pomocí příkazu Zobrazit jako na kartě Modelování na pásu karet.

Pokud má model dynamická pravidla pomocí funkce USERNAME DAX, nezapomeňte otestovat očekávané a neočekávané hodnoty. Při vkládání obsahu Power BI – konkrétně pomocí vložení pro váš scénář zákazníků – může logika aplikace předat libovolnou hodnotu jako efektivní uživatelské jméno identity. Pokud je to možné, zajistěte, aby náhodné nebo škodlivé hodnoty byly výsledkem filtrů, které nevracely žádné řádky.

Představte si příklad použití Power BI Embedded, kde aplikace předá roli úlohy uživatele jako efektivní uživatelské jméno: Jedná se o manažera nebo pracovního procesu. Správci můžou zobrazit všechny řádky, ale pracovníci uvidí jenom řádky, ve kterých je hodnota sloupce Typ interní.

Definuje se následující výraz pravidla:

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

Problém s tímto výrazem pravidla spočívá v tom, že všechny hodnoty s výjimkou "Worker" vrátí všechny řádky tabulky. Náhodná hodnota, například "Wrker", tedy neúmyslně vrátí všechny řádky tabulky. Proto je bezpečnější napsat výraz, který testuje každou očekávanou hodnotu. V následujícím vylepšeném výrazu pravidla má neočekávaná hodnota za následek, že tabulka nevrací žádné řádky.

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

Návrh částečného zabezpečení na úrovni řádků

Výpočty někdy potřebují hodnoty, které nejsou omezené filtry zabezpečení na úrovni řádků. Sestava může například potřebovat zobrazit poměr výnosů získaných pro prodejní oblast uživatele sestavy nad všemi získanými výnosy.

I když není možné, aby výraz DAX přepsal zabezpečení na úrovni řádků – ve skutečnosti ani nedokáže určit, že se zabezpečení na úrovni řádků vynucuje – můžete použít tabulku souhrnného modelu. Tabulka souhrnného modelu se dotazuje na načtení výnosů pro všechny oblasti a není omezena filtry zabezpečení na úrovni řádků.

Pojďme se podívat, jak byste mohli tento požadavek na návrh implementovat. Nejprve zvažte následující návrh modelu:

Model se skládá ze čtyř tabulek:

• Tabulka Salesperson ukládá jeden řádek na prodejce. Obsahuje sloupec EmailAddress , který ukládá e-mailovou adresu pro každého prodejce. Tato tabulka je skrytá.
• Tabulka Sales (Prodej) ukládá jeden řádek pro každou objednávku. Zahrnuje míru Revenue % All Region (Výnosy % všech oblastí ), která je navržená tak, aby vrátila poměr výnosů získaných oblastí uživatele sestavy oproti výnosům získaným všemi oblastmi.
• Tabulka Kalendářní data ukládá jeden řádek na datum a umožňuje filtrování a seskupování roků a měsíců.
• SalesRevenueSummary je počítaná tabulka. Ukládá celkové výnosy pro každé datum objednávky. Tato tabulka je skrytá.

Následující výraz definuje počítanou tabulku SalesRevenueSummary :

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

Poznámka:

Tabulka agregace by mohla dosáhnout stejného požadavku na návrh.

Pro tabulku Salesperson se použije následující pravidlo zabezpečení na úrovni řádků:

[EmailAddress] = USERNAME()

Každá ze tří relací modelu je popsaná v následující tabulce:

Vztah	Popis
	Mezi tabulkami Salesperson a Sales existuje relace M:N. Pravidlo RLS filtruje sloupec EmailAddress skryté tabulky Salesperson pomocí funkce USERNAME DAX. Hodnota sloupce Region (pro uživatele sestavy) se rozšíří do tabulky Sales (Sales ).
	Mezi tabulkami Date a Sales existuje relace 1:N.
	Mezi tabulkami Date a SalesRevenueSummary existuje relace 1:N.

Následující výraz definuje míru Revenue % All Region :

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

Poznámka:

Dbejte na to, abyste se vyhnuli zveřejnění citlivých faktů. Pokud v tomto příkladu existují jenom dvě oblasti, může uživatel sestavy vypočítat výnosy pro jinou oblast.

Kdy se vyhnout použití zabezpečení na úrovni řádků

Někdy je vhodné se vyhnout použití zabezpečení na úrovni řádků. Pokud máte jenom několik jednoduchých pravidel zabezpečení na úrovni řádků, která používají statické filtry, zvažte místo toho publikování více sémantických modelů. Žádný z sémantických modelů nedefinuje role, protože každý sémantický model obsahuje data pro konkrétní cílovou skupinu uživatelů sestavy, která má stejná oprávnění k datům. Pak vytvořte jeden pracovní prostor pro cílovou skupinu a přiřaďte přístupová oprávnění k pracovnímu prostoru nebo aplikaci.

Například společnost, která má jen dvě prodejní oblasti, se rozhodne publikovat sémantický model pro každou prodejní oblast do různých pracovních prostorů. Sémantické modely nevynucuje zabezpečení na úrovni řádků. K filtrování zdrojových dat však používají parametry dotazu. Tímto způsobem se stejný model publikuje do každého pracovního prostoru – mají jenom jiné sémantické hodnoty parametrů modelu. Prodejci mají přiřazený přístup jenom k jednomu z pracovních prostorů (nebo publikovaným aplikacím).

Existuje několik výhod spojených s vyloučením zabezpečení na úrovni řádků:

• Vylepšený výkon dotazů: Může vést k lepšímu výkonu kvůli menšímu počtu filtrů.
• Menší modely: Výsledkem je více modelů, ale jsou menší. Menší modely můžou zlepšit rychlost odezvy dotazů a aktualizace dat, zejména pokud kapacita hostování zatěžuje prostředky. Je také jednodušší zachovat velikosti modelů nižší než limity velikosti stanovené vaší kapacitou. Nakonec je jednodušší vyrovnávat úlohy napříč různými kapacitami, protože můžete vytvářet pracovní prostory v různých kapacitách nebo je přesouvat do různých kapacit.
• Další funkce: Je možné použít funkce Power BI, které nefungují s RLS, jako je publikování na webu.

Existují však nevýhody spojené s vyloučením zabezpečení na úrovni řádků:

• Více pracovních prostorů: Pro každou cílovou skupinu uživatelů sestavy se vyžaduje jeden pracovní prostor. Pokud jsou aplikace publikované, znamená to také, že pro každou cílovou skupinu uživatelů sestavy existuje jedna aplikace.
• Duplikace obsahu: Sestavy a řídicí panely musí být vytvořeny v každém pracovním prostoru. Vyžaduje větší úsilí a čas k nastavení a údržbě.
• Uživatelé s vysokými oprávněními: Uživatelé s vysokou úrovní oprávnění, kteří patří do více cílových skupin uživatelů sestav, nevidí konsolidované zobrazení dat. Budou muset otevřít více sestav (z různých pracovních prostorů nebo aplikací).

Řešení potíží se zabezpečením na úrovni řádků

Pokud zabezpečení na úrovni řádků generuje neočekávané výsledky, zkontrolujte následující problémy:

• Mezi tabulkami modelu existují nesprávné relace z hlediska mapování sloupců a směrů filtru. Mějte na paměti, že filtry zabezpečení na úrovni řádků se šíří pouze prostřednictvím aktivních relací.
• Filtr Použít zabezpečení v obou směrech relace není správně nastaven. Další informace najdete v tématu Pokyny k obousměrným relacím.
• Tabulky neobsahují žádná data.
• Do tabulek se načtou nesprávné hodnoty.
• Uživatel je namapován na více rolí.
• Model obsahuje tabulky agregace a pravidla zabezpečení na úrovni řádků nefiltrují agregace a podrobnosti konzistentně. Další informace najdete v tématu Použití agregací v Power BI Desktopu (RLS pro agregace).

Pokud konkrétní uživatel nevidí žádná data, může to být proto, že jeho hlavní jméno uživatele (UPN) není uložené nebo je zadané nesprávně. Může k tomu dojít náhle, protože se jeho uživatelský účet změnil v důsledku změny jména.

Tip

Pro účely testování přidejte míru, která vrátí funkci USERNAME DAX. Můžeš to pojmenovat třeba "Kdo Am I". Pak přidejte míru do vizuálu karty v sestavě a publikujte ji do Power BI.

Tvůrci a příjemci s oprávněním jen ke čtení v sémantickém modelu budou moct zobrazit jenom data, která mají povoleno zobrazit (na základě mapování role RLS).

Když uživatel zobrazí sestavu v pracovním prostoru nebo v aplikaci, může se zabezpečení na úrovni řádků v závislosti na jejich sémantických oprávněních modelu vynucovat. Z tohoto důvodu je důležité, aby uživatelé a tvůrci obsahu měli oprávnění ke čtení pouze pro základní sémantický model, když je nutné vynutit zabezpečení na úrovni řádků. Podrobnosti o pravidlechoprávněních

Související obsah

Další informace týkající se tohoto článku najdete v následujících zdrojích informací:

• Zabezpečení na úrovni řádků s využitím Power BI
• Omezení přístupu k datům pomocí zabezpečení na úrovni řádků (RLS) pro Power BI Desktop
• Relace modelu v Power BI Desktopu
• Plánování implementace Power BI: Sestava plánování zabezpečení uživatelů
• Otázky? Zkuste se zeptat Komunita Power BI
• Návrhy? Přispívání nápadů ke zlepšení Power BI