Zabezpečení na úrovni řádků s využitím Power BI

Zabezpečení na úrovni řádků (RLS) omezuje přístup k datům pro konkrétní uživatele Power BI sémantického modelu. Filtry omezují data na úrovni řádků a definujete filtry v rámci rolí. V služba Power BI mají uživatelé s přístupem k pracovnímu prostoru přístup k sémantickým modelům v daném pracovním prostoru. Zabezpečení na úrovni řádků omezuje přístup k datům pouze pro uživatele s oprávněním Viewer. Nevztahuje se na role správce, člena nebo přispěvatele pracovního prostoru.

Pokud chcete implementovat RLS (zabezpečení na úrovni řádků), postupujte podle tohoto pracovního postupu vysoké úrovně:

  1. Definujte role a pravidla v Power BI Desktop pomocí výrazů filtru DAX.
  2. Publish sémantický model a sestavu do služby Power BI.
  3. Přidejte členy k rolím ve službě Power BI.
  4. Pomocí funkce Test jako roleověřte, že filtrování dat funguje podle očekávání.

Zabezpečení na úrovni řádků můžete nakonfigurovat pro importované sémantické modely v Power BI Desktopu nebo Power BI službě. Zabezpečení na úrovni řádků můžete nakonfigurovat také u sémantických modelů, které používají DirectQuery, například SQL Server. Pro živá připojení Analysis Services nebo Azure Analysis Services nakonfigurujete zabezpečení na úrovni řádků v modelu, ne v Power BI. U sémantických modelů živého připojení se možnost zabezpečení nezobrazuje.

Poznámka:

Tento článek se konkrétně zabývá RLS pro sémantické modely Power BI. Zabezpečení dat v jiných položkách Microsoft Fabric najdete v tématu Zabezpečení v Microsoft Fabric.

Poznámka:

U sémantických modelů Direct Lake v Microsoft Fabric je podporováno RLS (zabezpečení na úrovni řádků). Pokud se však dotaz DAX vrátí do režimu DirectQuery kvůli nepodporovaným funkcím, RLS filtry stále platí, ale mohou se změnit charakteristiky výkonu. Monitorujte chování řešení dotazů při selhání v aplikaci metriky kapacity Fabric.

Definování rolí a pravidel v Power BI Desktopu

V Power BI Desktopu můžete definovat role a pravidla. V tomto editoru můžete přepínat mezi výchozím rozevíracím rozhraním a rozhraním DAX. Při publikování do Power BI publikujete také definice rolí.

Definování rolí zabezpečení:

  1. Importujte data do sestavy v Power BI Desktop nebo nakonfigurujte připojení DirectQuery.

    Poznámka:

    V Power BI Desktopu nemůžete definovat role pro přímá připojení Analysis Services. Musíte to udělat v rámci modelu Analysis Services.

  2. Na kartě Modelování vyberte Spravovat role.

  3. V okně Spravovat role vyberte Nový a vytvořte novou roli.

  4. V části Role zadejte název role a vyberte Enter.

    Poznámka:

    Roli nemůžete definovat čárkou, například London,ParisRole.

  5. V části Vybrat tabulky vyberte tabulku, u které chcete použít filtr zabezpečení na úrovni řádků.

  6. V části Filtrovat data definujte role pomocí výchozího editoru. Výrazy, které byly vytvořeny, vrátí hodnotu "true" nebo "false". Filtr DAX vyhodnocuje hodnotu TRUE/FALSE pro každý řádek. Pouze řádky, které vracejí hodnotu PRAVDA, jsou viditelné vše ostatní je zcela odebráno.

    Poznámka:

    Ne všechny filtry zabezpečení na úrovni řádků podporované v Power BI je možné definovat pomocí výchozího editoru. Omezení zahrnují výrazy, které dnes lze definovat pouze pomocí jazyka DAX, včetně dynamických pravidel, jako jsou username() nebo userprincipalname(). Pokud chcete definovat role pomocí těchto filtrů, použijte editor DAX.

  7. Volitelně vyberte Přepnout do editoru DAX a přepněte na použití editoru DAX a definujte svou roli. Výrazy jazyka DAX vracejí hodnotu "true" nebo "false". Například: [Entity ID] = “Value”. Editor DAX obsahuje automatické dokončování vzorců (intellisense). K ověření výrazu můžete použít zaškrtávací políčko nad polem výrazu. Tlačítko X nad polem výrazu můžete použít ke vrácení změn zpět.

    Poznámka:

    V tomto výrazu můžete použít uživatelské jméno(). Mějte na paměti, že uživatelské_jméno() má formát DOMAIN\username v Power BI Desktopu. Ve službě Power BI a na Server sestav Power BIu je to ve formátu hlavního názvu uživatele (UPN). V tomto poli výrazu navíc používejte čárky k oddělení argumentů funkce DAX i v případě, že používáte národní prostředí, které obvykle používá oddělovače středníků, například francouzštinu nebo němčinu.

  8. Výběrem možnosti Přepnout do výchozího editoru můžete přepnout zpět do výchozího editoru. Všechny změny provedené v obou rozhraních editoru se zachovají při přepínání rozhraní, pokud je to možné. Při definování role pomocí editoru DAX, který nelze definovat ve výchozím editoru, pokud se pokusíte přepnout na výchozí editor, zobrazí se výzva s upozorněním, že přepínání editorů může způsobit ztrátu některých informací. Chcete-li tyto informace zachovat, vyberte Zrušit a pokračujte pouze v úpravách této role v editoru DAX.

    Poznámka:

    V tomto poli výrazu oddělte argumenty funkce DAX čárkami, i když používáte národní prostředí, které obvykle používá oddělovače středníků, například francouzštinu nebo němčinu.

  9. Zvolte Uložit.

V Power BI Desktopu nemůžete přiřadit uživatele k roli. Přiřadíte je ve službě Power BI. Dynamické zabezpečení v Power BI Desktopu můžete povolit tak, že použijete funkce DAX username() nebo userprincipalname() a nakonfigurujete správné relace.

Běžné vzory filtrů DAX pro role RLS

Následující příklady ukazují běžné filtrační výrazy DAX, které můžete použít při definování rolí zabezpečení na úrovni řádků (RLS) v aplikaci Power BI Desktop:

  • Statické RLS – Omezuje data na pevnou hodnotu:

    [Region] = "West"

  • Dynamické RLS s UPN – omezuje data podle e-mailové adresy přihlášeného uživatele:

    [UserEmail] = USERPRINCIPALNAME()

  • Dynamické RLS s uživatelským jménem – Omezuje data na základě uživatelské domény a jména:

    [UserDomain] = USERNAME()

  • Dynamické zabezpečení na úrovni řádků s funkcí CUSTOMDATA – Omezuje data na základě vlastního řetězce předaného z vložené aplikace:

    [AppRole] = CUSTOMDATA()

    Poznámka:

    CUSTOMDATA() se primárně používá ve vložených scénářích, ve kterých aplikace předává vlastní efektivní řetězec identity prostřednictvím rozhraní POWER BI REST API.

Dynamické RLS je nejběžnější přístup, protože umožňuje, aby jediná definice role filtrovala data u každého uživatele jinak na základě tabulky mapování uživatelů ve vašem datovém modelu.

Příklad: Filtrování Power BI prodejních dat podle oblasti

Předpokládejme, že máte Sales tabulku se sloupci Region, Producta Amount. Chcete omezit uživatele přiřazené k roli „West“ tak, aby viděli pouze řádky, kde je oblast „West“.

Do pole filtru DAX pro roli West zadejte následující výraz:

[Region] = "West"

Před filtrováním (všechna data):

Oblast Product Částka
Západ Widget A 500
Východ Widget B 300
Západ Widget C 450
Jih Widget A 200
Východ Widget C 375

Po filtrování (zobrazení pro uživatele role West):

Oblast Product Částka
Západ Widget A 500
Západ Widget C 450

Výraz DAX funguje jako filtr řádků, který vyhodnocuje každý řádek v tabulce. Uživatelům přiřazeným k dané roli se zobrazí pouze řádky, kde se sloupec Region rovná hodnotě „West“.

Tip

Pomocí funkce Zobrazit jako roli (popsané v části Ověření role ve službě Power BI) ověřte, že filtr před publikováním sestavy vrací očekávané řádky.

Obousměrné křížové filtrování s RLS

Ve výchozím nastavení používá filtrování zabezpečení na úrovni řádků jednosměrné filtry bez ohledu na to, jestli jsou relace nastaveny na jeden směr nebo obousměrný.

Obousměrné křížové filtrování s zabezpečením na úrovni řádků můžete povolit ručně tak, že vyberete relaci a zaškrtnete políčko Použít filtr zabezpečení v obou směrech . Tuto možnost vyberte, pokud jste na úrovni serveru také implementovali dynamické zabezpečení na úrovni řádků, kde zabezpečení na úrovni řádků vychází z uživatelského jména nebo přihlašovacího ID. Pokud se tabulka účastní více obousměrných relací, můžete tuto možnost vybrat jenom pro jednu z těchto relací.

Caution

Povolení obousměrného filtrování zabezpečení může negativně ovlivnit výkon dotazů, zejména v modelech s mnoha relacemi nebo velkými datovými sadami. Před nasazením do produkčního prostředí důkladně otestujte.

Další informace najdete v tématu Obousměrné křížové filtrování pomocí DirectQuery v Power BI a technického článku Zabezpečení tabulkového sémantického modelu BI.

Snímek obrazovky s nastavením relace modelu pro použití filtru zabezpečení v obou směrech.

Správa zabezpečení v sémantickém modelu

Pokud chcete spravovat zabezpečení v sémantickém modelu, otevřete pracovní prostor, do kterého jste uložili sémantický model v Microsoft Fabric, a proveďte následující kroky:

  1. V Microsoft Fabric vyberte nabídku Další možnosti pro sémantický model. Tato nabídka se zobrazí, když najedete myší na název sémantického modelu.

    Snímek obrazovky s nabídkou Další možnosti v navigační nabídce

  2. Vyberte Zabezpečení.

    Snímek obrazovky s nabídkou Další možnosti a vybranou možností Zabezpečení

Zabezpečení vás přenese na stránku zabezpečení Row-Level, kde přidáte členy do vytvořené role. Uživatelé s rolí Přispěvatel pracovního prostoru nebo vyšší uvidí možnost Zabezpečení a můžou přiřadit uživatele k roli. V závislosti na scénáři může být vyžadováno také sémantické vlastnictví modelu nebo oprávnění k sestavení .

Poznámka:

Zabezpečení můžete spravovat pouze u sémantických modelů, které už mají role zabezpečení na úrovni řádků definované v Power BI Desktopu nebo při úpravách datového modelu v služba Power BI. Pokud váš sémantický model ještě nemá definované role, nemůžete v služba Power BI spravovat zabezpečení.

Správa členství v rolích RLS v služba Power BI

Přidat členy do role RLS

Ve službě Power BI můžete přidat člena do role zabezpečení na úrovni řádků (RLS) zadáním e-mailové adresy nebo jména uživatele či názvu skupiny zabezpečení. Skupiny vytvořené v Power BI se nedají přidat. Do vaší organizace můžete přidat externí členy. Pokyny k tomu, jak funguje zabezpečení na úrovni řádků (RLS) s externími uživateli typu host B2B, najdete v tématu Úvahy pro externí uživatele typu host (B2B guest).

K nastavení zabezpečení na úrovni řádků můžete použít následující Microsoft Entra ID a skupiny s podporou e-mailu:

Important

Skupiny Microsoftu 365 nejsou podporovány a nelze je přidat do žádných rolí zabezpečení na úrovni řádků (RLS). Podporovány jsou pouze ty typy skupin, které jsou uvedeny výše, pro členství v rolích RLS.

Snímek obrazovky znázorňující, jak přidat člena

Počet členů je součástí role podle čísla v závorkách vedle názvu role nebo vedle členů.

Snímek obrazovky zobrazující členy v roli

Odebrání členů z role RLS

Členy můžete odebrat výběrem symbolu X vedle jejich jména.

Snímek obrazovky znázorňující, jak odebrat člena

Ověření role v rámci služba Power BI

Pomocí testování role můžete ověřit, že role RLS, kterou jste definovali, funguje správně v služba Power BI.

  1. Vyberte Další možnosti (...) vedle role.
  2. Vyberte Test jako roli.

Snímek obrazovky možnosti

Poznámka:

Řídicí panely nejsou k dispozici k testování pomocí volby Test jako role. Pokud existuje, budete přesměrováni na sestavu publikovanou z Power BI Desktopu s tímto sémantickým modelem.

Po načtení sestavy ověřte následující:

  • Sestava zobrazí pouze řádky dat, které odpovídají výrazu filtru definovanému v roli.
  • Vizuály, tabulky a grafy odrážejí filtrovaná data, nikoli úplnou datovou sadu.
  • Pokud používáte dynamické zabezpečení na úrovni řádků, data odpovídají identitě zobrazené v záhlaví Nyní je zobrazeno jako.

V záhlaví stránky se zobrazí použitá role. Otestujte jiné role, kombinaci rolí nebo konkrétní osobu výběrem možnosti Nyní zobrazit jako. Tady vidíte důležité podrobnosti o oprávněních týkajících se testovaného jednotlivce nebo role. Další informace o způsobu, jakým oprávnění interagují se zabezpečením na úrovni řádků (RLS), najdete v tématu Uživatelské prostředí RLS.

Snímek obrazovky s zobrazením rozevíracího seznamu pro konkrétní osobu

Otestujte další sestavy připojené k sémantickému modelu tak, že v záhlaví stránky vyberete Zobrazení. Můžete testovat pouze sestavy, které se nacházejí ve stejném pracovním prostoru jako váš sémantický model.

Snímek obrazovky z náhledu pro výběr jiné sestavy k otestování

Pokud se chcete vrátit k normálnímu zobrazení, vyberte Zpět na zabezpečení na úrovni řádků.

Poznámka:

Funkce Test jako role nefunguje u sémantických modelů DirectQuery s povoleným jednotným přihlašováním (SSO). Kromě toho nelze ve funkci Test as role ověřit všechny aspekty sestavy, včetně vizualizací Q&A, vizualizací rychlých přehledů a .

Tip

Pokud Test jako role nezobrazuje očekávané výsledky, zkuste následující:

  • Ověřte, zda je syntaxe výrazu filtru DAX správná a zda odkazy směřují na správné názvy sloupců.
  • Ujistěte se, že jste vybrali správnou roli k otestování.
  • U dynamického RLS potvrďte, že tabulka mapování uživatelů obsahuje odpovídající hodnoty pro USERPRINCIPALNAME() nebo USERNAME().
  • V případě sémantických modelů DirectQuery s povoleným jednotným přihlašováním se testovat jako role nepodporuje. Místo toho se přihlaste jako skutečný uživatel role čtenáře a ověřte filtrování dat.

Použití funkcí DAX username() nebo userprincipalname()

Můžete využít výhod funkcí DAX username() nebo userprincipalname() v rámci datové sady. Můžete je použít ve výrazech v Power BI Desktopu. Když model publikujete, použije se v rámci služba Power BI.

V Power BI Desktopu vrátí uživatelské jméno() uživatele ve formátu DOMAIN\User a userprincipalname() vrátí uživatele ve formátu user@contoso.com.

V rámci služby Power BI budou funkce username() a userprincipalname() obě vracet uživatelské jméno (UPN) uživatele. Vypadá to podobně jako e-mailová adresa.

Použití RLS s pracovními prostory v Power BI

Pokud publikujete sestavu z aplikace Power BI Desktop do pracovního prostoru ve službě Power BI, role RLS se vztahují na členy přiřazené k roli Prohlížeč v pracovním prostoru. I když jsou uživatelům s rolí Prohlížející udělena oprávnění Build k sémantickému modelu, RLS se stále uplatňuje. Pokud například uživatelé s oprávněním Build používají funkci Analyzovat v Excelu, jejich zobrazení dat je omezeno zabezpečením na úrovni řádků. Členové pracovního prostoru, kterým byly přiřazeny role správce, člena nebo přispěvatele, mají oprávnění k úpravám sémantického modelu, a proto se na ně zabezpečení na úrovni řádků (RLS) nevztahuje. Pokud chcete, aby zabezpečení na úrovni řádků platilo pro lidi v pracovním prostoru, můžete jim přiřadit jenom roli čtenáře. Další informace najdete o rolích v pracovních prostorech.

Důležité informace pro externí uživatele (host B2B)

Pokud sdílíte obsah Power BI s externími uživateli prostřednictvím Microsoft Entra B2B, mějte na paměti následující skutečnosti týkající se RLS.

Zabezpečovací skupiny Microsoft Entra s externími členy

Skupiny zabezpečení Microsoft Entra, které obsahují externí hostující uživatele B2B, nemusí při použití pro členství v rolích RLS fungovat podle očekávání. V některých konfiguracích — zejména když má externí uživatel účet typu hosta (nikoli účet typu člena) — služba Power BI při vynucování filtrů zabezpečení na úrovni řádků nesprávně vyhodnocuje členství hosta ve skupině.

Doporučené náhradní řešení: Místo přidávání externích uživatelů do rolí RLS prostřednictvím skupin zabezpečení Microsoft Entra je přidejte přímo do role pomocí jejich e-mailové adresy. E-mailová adresa je přiřazena k B2B účtu uživatele. Tím se zajistí, že jejich identita bude při použití filtrů zabezpečení na úrovni řádků správně přiřazena. Další informace najdete v tématu Správa členství v roli RLS v služba Power BI.

U organizací s mnoha externími uživateli zvažte použití dynamického zabezpečení na úrovni řádků s USERPRINCIPALNAME() místo členství v rolích na základě skupin. Tento přístup vyhodnocuje identitu jednotlivých uživatelů jednotlivě a zcela se vyhne problému s řešením členství ve skupině.

Important

Pokud aktuálně používáte skupiny zabezpečení Microsoft Entra pro členství v rolích RLS a tyto skupiny zahrnují hostované uživatele B2B, ověřte, že tito uživatelé vidí správně filtrovaná data. Pokud ne, přidejte externí uživatele přímo do role RLS podle e-mailové adresy.

Poznámka:

Přesný rozsah tohoto omezení se může lišit v závislosti na konfiguraci Microsoft Entra ID a typu použité pozvánky hosta B2B. Než se budete při externím přístupu spoléhat na RLS založené na skupinách, vždy testujte pomocí skutečných uživatelských účtů hosta.

Pokud problém přetrvává i po použití zástupného řešení, další diagnostické kroky najdete v tématu Řešení potíží: Externí host B2B nevidí žádná data v sestavě Power BI.

Překlad UPN pro hosty B2B v RLS Power BI

Když externí uživatel typu host B2B přistupuje k sestavě Power BI, funkce USERPRINCIPALNAME() DAX obvykle vrátí identifikátor podobný e-mailu (například user@partner.com). V některých konfiguracích může vracet UPN hosta #EXT# ve formátu (například user_partner.com#EXT#@yourtenant.onmicrosoft.com).

Toto rozlišení je důležité pro dynamické zabezpečení na úrovni řádků. Pokud tabulka mapování uživatelů ukládá jiný formát identifikátoru než jaký vrátí USERPRINCIPALNAME(), výraz filtru nebude odpovídat a uživatel typu host nemusí vidět žádná data nebo nesprávná data.

Chování uživatele USERNAME() u hostů B2B v Power BI RLS

Funkce USERNAME() DAX vrátí identifikátor uživatele domain\username . U hostujících uživatelů B2B vrací USERNAME() často identifikátor typu UPN podobný formátu USERPRINCIPALNAME() v závislosti na konfiguraci (například user@partner.com) namísto formátu domain\username. Vzhledem k tomu, že USERNAME() a USERPRINCIPALNAME() často vrací stejnou hodnotu pro hosty B2B, většina implementací se používá USERPRINCIPALNAME() pro konzistenci.

Tip

Pokud vaše stávající dynamické RLS používá USERNAME(), před externím sdílením obsahu ověřte, jakou hodnotu vrací hostujícím uživatelům ve vašem prostředí. Kontrolu můžete provést přidáním vizuálu karty zobrazujícího USERNAME() v testovací sestavě.

Doporučený přístup: Uložte a konzistentně používejte stejný formát identifikátoru v tabulce mapování uživatelů jako hodnotu vrácenou USERPRINCIPALNAME(). Ve většině případů použití e-mailových adres zjednodušuje správu:

[UserEmail] = USERPRINCIPALNAME()

Ve sloupci UserEmail se nacházejí e-mailové adresy, jako je user@partner.com, a to jak pro interní, tak externí uživatele.

Poznámka:

Hodnota vrácená uživatelem USERPRINCIPALNAME() je přihlašovací identifikátor uživatele (UPN), nikoli nutně jeho e-mailová adresa. U většiny uživatelů jsou stejné, ale můžou se lišit (například když je e-mail uživatele alias). Při vytváření tabulky mapování uživatelů použijte hodnotu vrácenou USERPRINCIPALNAME() místo atributu mail z Microsoft Entra ID.

Important

Pokud používáte dynamické RLS s USERPRINCIPALNAME(), vždy testujte se skutečnými externími hostujícími uživateli. Funkce Test jako role používá vaši vlastní identitu a nezobrazí problémy s řešením hlavního názvu uživatele (UPN) u externích uživatelů.

Poznámka:

Chování při vyřešení hlavního názvu uživatele (UPN) u B2B hostů se může lišit v závislosti na konfiguraci Microsoft Entra ID, jako jsou nastavení přístupu mezi tenanty a typ hostujícího uživatele. Vždy ověřte chování ve vašem konkrétním prostředí.

Řešení potíží: Externí host B2B nevidí v sestavě Power BI žádná data

Pokud se uživateli typu host B2B zobrazí prázdná sestava nebo se zobrazí zpráva "žádná data", postupujte takto:

  1. Ověřte vrácený formát UPN — Vytvořte testovací měřítko pomocí USERPRINCIPALNAME() a zobrazte ho ve vizuálu typu karta. Požádejte hostujícího uživatele, aby si prohlédl sestavu, a uviděl tak skutečnou hodnotu, která byla vrácena.
  2. Zkontrolujte tabulku mapování uživatelů – Ověřte, že tabulka mapování obsahuje řádek s hodnotou, která přesně odpovídá tomu, co USERPRINCIPALNAME() se vrátí pro daného hosta.
  3. Zkontrolujte citlivost na malá a velká písmena – porovnání řetězců DAX ve výchozím nastavení nerozlišují malá a velká písmena, ale ověřte, že váš zdroj dat nezanesl hodnoty citlivé na malá a velká písmena.
  4. Zkontrolujte nastavení přístupu mezi tenanty — Pokud vaše organizace používá zásady přístupu mezi tenanty, mohou ovlivnit, který formát názvu User Principal Name (UPN) se službě Power BI předává.
  5. Testujte pomocí skutečného hostujícího uživatele — Funkce Testovat jako role používá vaši vlastní identitu. Vždy ověřte pomocí skutečného externího účtu hosta.
  6. Ověřte přiřazení role — Pokud hostující uživatel vidí více dat, než se očekává, ověřte, že je přiřazen k roli RLS. Uživatelé, kteří nejsou přiřazeni k žádné roli RLS, obvykle nevidí žádná data (prázdné výsledky), protože je vynucováno zabezpečení na úrovni řádků (RLS), ale není použita žádná odpovídající role. Filtr DAX vyhodnocuje hodnotu TRUE/FALSE pro každý řádek. Viditelné jsou pouze řádky, které vracejí hodnotu TRUE. Všechno ostatní je zcela odebráno.

Další informace o sdílení obsahu Power BI s externími uživateli najdete v tématu Distribute Power BI obsahu externím uživatelům typu host s Microsoft Entra B2B.

Úvahy a omezení

Aktuální omezení zabezpečení na úrovni řádků v cloudových modelech najdete tady:

  • Pokud jste dříve definovali role a pravidla v služba Power BI, musíte je v Power BI Desktopu znovu vytvořit.
  • Zabezpečení na úrovni řádků (RLS) můžete definovat jenom u sémantických modelů vytvořených v Power BI Desktopu. Pokud chcete povolit zabezpečení na úrovni řádků pro sémantické modely vytvořené v Excelu, musíte nejprve převést soubory na soubory Power BI Desktopu (PBIX). Další informace.
  • Služební principály nelze přidat do role RLS. Zabezpečení na úrovni řádků (RLS) se proto nepoužije pro aplikace, které jako konečnou efektivní identitu používají služební principál.
  • Podporují se jenom připojení Import a DirectQuery. Živá připojení ke službě Analysis Services se zpracovávají v místním modelu.
  • Pokud je povolené Row-Level Security (RLS), může použití funkce USERELATIONSHIP() v DAX dotazech a výpočtech způsobit neočekávané chyby. Chcete-li tento problém vyřešit, přepracujte výrazy DAX tak, abyste se vyhnuli používání USERELATIONSHIP() a místo toho použijte relace na úrovni modelu nebo jiné vzory DAX.
  • Funkce Testovat jako roli nebo Zobrazit jako roli nefunguje u modelů DirectQuery s povoleným jednotným přihlášením (SSO).
  • Funkce Testování jako role nebo Zobrazení jako role zobrazuje pouze sestavy z pracovního prostoru sémantických modelů.
  • Funkce Test jako role nebo Zobrazení jako role nefunguje pro stránkované zprávy.
  • Identita založená na tokenech funguje pouze pro modely DirectQuery v kapacitě připojené ke službě Azure SQL Database, která je nakonfigurovaná tak, aby umožňovala ověřování Microsoft Entra. Další informace najdete v tématu Vložení sestavy s identitou založenou na tokenu.
  • Parametr IdentityBlob je přístupový token OAuth 2.0 pro Azure SQL a podporuje se pouze u datových sad s připojením DirectQuery k Azure SQL. Samotný mechanismus je specifický pro Azure SQL: objekt blob is přístupový token Microsoft Entra omezený na https://database.windows.net/.default. Pro ostatní zdroje dat v App-owns-data embeddingu neexistuje žádný obdobný mechanismus předávání tokenů. Další informace najdete v referenčních informacích k rozhraní REST API pro GenerateToken.

Aspekty a omezení dynamického RLS

Pokud používáte dynamické zabezpečení na úrovni řádků (RLS) s funkcemi DAX, jako je USERPRINCIPALNAME(), USERNAME()nebo CUSTOMDATA(), mějte na paměti následující aspekty.

Scénáře B2B mezi tenanty

Ve scénářích B2B vrátí USERPRINCIPALNAME() identitu určenou službou Power BI, která se může lišit podle konfigurace tenanta. Může se zobrazit buď takto:

  • E-mailová adresa externího uživatele (user@partner.com) nebo
  • Vyřešená hodnota tenanta, například user_partner.com#EXT#@tenant.onmicrosoft.com

Přesný formát není zaručený a musí se ověřit ve vašem prostředí.

Pokud vaše tabulka mapování uživatelů ukládá identifikátory v jiném formátu, než v jakém je USERPRINCIPALNAME() vrací pro hostující uživatele, výraz filtru RLS nebude odpovídat a hostující uživatel neuvidí žádná data nebo uvidí nesprávná data. Vždy ověřte přesnou hodnotu vrácenou prvkem USERPRINCIPALNAME() pro externí uživatele ve svém prostředí.

Tip

Vytvořte testovací míru pomocí USERPRINCIPALNAME() a zobrazte ji ve vizuálu karty. Požádejte externí uživatele typu host, aby sestavu zobrazili a potvrdili, že vrácená hodnota odpovídá vaší tabulce mapování uživatelů. Tento jednoduchý test může zabránit hodinám ladění neodpovídajících hodnot identit.

Testování jako omezení rolí pomocí dynamického zabezpečení na úrovni řádků

Funkce Test jako role ve službě Power BI používá při vyhodnocování dynamických výrazů RLS vaši vlastní identitu. To znamená, že USERPRINCIPALNAME() vrátí váš UPN, nikoli UPN uživatele, kterého se pokoušíte simulovat. Test as role nelze použít k zobrazení toho, co by viděl konkrétní hostovaný uživatel B2B nebo instanční objekt služby.

Test jako role simuluje členství v rolích, ale plně nereplikuje kontext ověřování jiného uživatele, zejména pro hosty B2B nebo vložené scénáře.

Pokud chcete ověřit dynamické RLS pro externí uživatele, přihlaste se jako skutečný hostovaný uživatel a zobrazte sestavu přímo. Toto je jediný způsob, jak ověřit, že USERPRINCIPALNAME() vrací očekávanou hodnotu a že filtry zabezpečení na úrovni řádků (RLS) jsou pro daného uživatele správně nastavené.

Vložené scénáře s instančními objekty služby

Když je sestava přístupná prostřednictvím vložené aplikace, která se ověřuje pomocí instančního objektu, USERPRINCIPALNAME() a USERNAME() vrátí ID aplikace instančního objektu nebo prázdný řetězec, nikoli identitu koncového uživatele.

Tyto funkce nevracejí identitu koncového uživatele, a proto je nelze použít pro filtrování podle jednotlivých uživatelů ve scénářích vkládání pomocí instančního objektu služby. To znamená, že dynamické filtry RLS založené na těchto funkcích nebudou ve scénářích vložení filtrovat data pro jednotlivé uživatele.

Pokud chcete použít zabezpečení na úrovni řádků pro jednotlivé uživatele ve vložených scénářích, použijte funkci efektivní identita rozhraní POWER BI REST API. EffectiveIdentity Při generování tokenu pro vložení předejte objekt s příslušnými uživatelskými jmény a rolemi. Pokud vaše pravidla RLS používají CUSTOMDATA(), předejte řetězec vlastních dat pomocí EffectiveIdentity.CustomData.

Další informace najdete v tématu RLS pro vložené scénáře pro nezávislé výrobce softwaru.

Important

Při vkládání pomocí instančního objektu služby vždy testujte skutečné tokeny pro vložení, které obsahují EffectiveIdentity, aby se ověřilo, že se filtry RLS používají správně. Funkce Test jako role v služba Power BI nesimuluje vložené toky ověřování.

Mějte na paměti, že pokud sestava Power BI odkazuje na řádek s nakonfigurovaným RLS, se zobrazí stejná zpráva jako pro odstraněné nebo neexistující pole. Některým uživatelům to připadá, že je sestava nefunkční.

časté otázky

Otázka: Co když jsem v služba Power BI vytvořil(a) dříve vytvořené role a pravidla pro datovou sadu? Pořád pracují, když nic neudělám?
Odpověď: Ne, vizuály se nevykreslují správně. Musíte znovu vytvořit role a pravidla v Power BI Desktopu a pak je publikovat do služba Power BI.

Otázka: Můžu pro zdroje dat Analysis Services vytvořit tyto role?
Odpověď: Ano, pokud jste data naimportovali do Power BI Desktopu. Pokud používáte živé připojení, nemůžete v rámci služby Power BI nakonfigurovat zabezpečení na úrovni řádků. RLS definujete v místním modelu Analysis Services.

Otázka: Můžu pomocí RLS omezit sloupce nebo míry přístupné svými uživateli?
Odpověď: Ne, pokud má uživatel přístup k určitému řádku dat, může zobrazit všechny sloupce dat pro daný řádek. Pokud chcete omezit přístup ke sloupcům a metadatům sloupců, zvažte použití zabezpečení na úrovni objektů.

Otázka: Umožňuje RLS skrýt podrobná data, ale udělit přístup k datům souhrnným ve vizuálech?
Odpověď: Ne, zabezpečíte jednotlivé řádky dat, ale uživatelé můžou vždy zobrazit podrobnosti nebo souhrnná data.

Otázka: Zdroj dat už má definované role zabezpečení (například role SQL Serveru nebo role SAP BW). Jaký je vztah mezi těmito rolemi a RLS (zabezpečením na úrovni řádků)?
Odpověď: Odpověď závisí na tom, jestli importujete data nebo používáte DirectQuery. Pokud importujete data do datové sady Power BI, role zabezpečení ve zdroji dat se nepoužívají. V takovém případě byste měli definovat RLS (zabezpečení na úrovni řádků) a vynutit pravidla zabezpečení pro uživatele, kteří se připojují do Power BI. Pokud používáte DirectQuery, použijí se role zabezpečení ve zdroji dat. Když uživatel otevře sestavu, Power BI odešle dotaz do podkladového zdroje dat, který použije pravidla zabezpečení na data na základě přihlašovacích údajů uživatele.

Otázka: Může uživatel patřit do více než jedné role?
Odpověď: Uživatel může patřit k více rolím a role se sčítají. Pokud například uživatel patří do rolí Prodej i Marketing, uvidí data pro obě tyto role.

Související obsah

Otázky? Zkuste se zeptat komunity Power BI na návrhy? Přispívání nápadů ke zlepšení Power BI

  • Last updated on