Pokyny k zabezpečení na úrovni řádků (RLS) v Power BI DesktopuRow-level security (RLS) guidance in Power BI Desktop

Tento článek je určený pro modelátory dat, kteří pracují s Power BI Desktopem.This article targets you as a data modeler working with Power BI Desktop. Popisuje vhodné postupy návrhu pro vynucování zabezpečení na úrovni řádků (RLS) v datových modelech.It describes good design practices for enforcing row-levels security (RLS) in your data models.

Je důležité pochopit, že zabezpečení na úrovni řádků filtruje řádky tabulek.It's important to understand RLS filters table rows. Není možné ho nakonfigurovat tak, aby omezovalo přístup k objektům modelu včetně tabulek, sloupců a měr.They can't be configured to restrict access to model objects, including tables, columns, or measures.

Poznámka

Tento článek nepopisuje zabezpečení na úrovni řádků, ani jak ho nastavit.This article doesn't describe RLS or how to set it up. Další informace najdete v článku Omezení přístupu k datům pomocí zabezpečení na úrovni řádků (RLS) pro Power BI Desktop.For more information, see Restrict data access with row-level security (RLS) for Power BI Desktop.

Nevěnuje se ani vynucování zabezpečení na úrovni řádků v živých připojeních k externě hostovaným modelům pomocí služeb Azure Analysis Services nebo SQL Server Analysis Services.Also, it doesn't cover enforcing RLS in live connections to external-hosted models with Azure Analysis Services or SQL Server Analysis Services. V těchto případech je zabezpečení na úrovni řádků vynucováno službou Analysis Services.In these cases, RLS is enforced by Analysis Services. Když se Power BI připojí pomocí jednotného přihlašování, vynutí služba Analysis Services zabezpečení na úrovni řádků (pokud účet nemá oprávnění správce).When Power BI connects using single-sign on (SSO), Analysis Services will enforce RLS (unless the account has admin privileges).

Vytvoření rolíCreate roles

Je možné vytvořit více rolí.It's possible to create multiple roles. Pokud zvažujete potřebná oprávnění pro jednoho uživatele sestavy, snažte se vytvořit jedinou roli, která udělí všechna tato oprávnění, místo návrhu, ve kterém bude uživatel sestavy členem více rolí.When you're considering the permission needs for a single report user, strive to create a single role that grants all those permissions, instead of a design where a report user will be a member of multiple roles. Je to proto, že uživatel sestavy by mohl být mapován na více rolí, a to buď přímo pomocí vlastního uživatelského účtu, nebo nepřímo pomocí členství ve skupině zabezpečení.It's because a report user could map to multiple roles, either directly by using their user account or indirectly by security group membership. Mapování na více rolí může vést k neočekávaným výsledkům.Multiple role mappings can result in unexpected outcomes.

Když má uživatel sestavy přiřazeno více rolí, začnou se filtry zabezpečení na úrovni řádků přičítat.When a report user is assigned to multiple roles, RLS filters become additive. To znamená, že uživatelé sestavy můžou zobrazit řádky tabulky představující spojení těchto filtrů.It means report users can see table rows that represent the union of those filters. V některých scénářích navíc není možné zaručit, že uživatel sestavy neuvidí řádky v určité tabulce.What's more, in some scenarios it's not possible to guarantee that a report user doesn't see rows in a table. To znamená, že na rozdíl od oprávnění použitých u objektů databáze SQL Serveru (a dalších modelů oprávnění) neplatí zásada, že „jedno odepření znamená odepření vždy“.So, unlike permissions applied to SQL Server database objects (and other permission models), the "once denied always denied" principle doesn't apply.

Představte si model se dvěma rolemi: První role s názvem Workers (Pracovníci) omezuje přístup ke všem řádkům tabulky Payroll (Mzdy) pomocí následujícího výrazu pravidla:Consider a model with two roles: The first role, named Workers, restricts access to all Payroll table rows by using the following rule expression:

FALSE()

Poznámka

Pravidlo nevrátí žádné řádky tabulky, pokud je jeho výraz vyhodnocen jako false.A rule will return no table rows when its expression evaluates to false.

Druhá role s názvem Managers (Manažeři) však umožňuje přístup ke všem řádkům tabulky Payroll pomocí následujícího výrazu pravidla:Yet, a second role, named Managers, allows access to all Payroll table rows by using the following rule expression:

TRUE()

Tady je potřeba postupovat opatrně: Pokud by měl uživatel sestavy namapovány obě role, uvidí všechny řádky tabulky Salary (Plat).Take care: Should a report user map to both roles, they'll see all Salary table rows.

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

Zabezpečení na úrovni řádků funguje na principu automatického používání filtrů u každého dotazu v jazyce DAX. Tyto filtry můžou mít negativní dopad na výkon dotazů.RLS works by automatically applying filters to every DAX query, and these filters may have a negative impact on query performance. Efektivní zabezpečení na úrovni řádků proto závisí na dobrém návrhu modelu.So, efficient RLS comes down to good model design. Je důležité postupovat podle pokynů pro návrh modelů, jak je popsáno v následujících článcích:It's important to follow model design guidance, as discussed in the following articles:

Obecně je často efektivnější vynucovat filtry zabezpečení na úrovni řádků u tabulek dimenzí, a ne u tabulek faktů.In general, it's often more efficient to enforce RLS filters on dimension-type tables, and not fact-type tables. A spoléhat na dobře navržené relace, abyste zajistili, že se filtry zabezpečení na úrovni řádků budou šířit do ostatních tabulek modelu.And, rely on well-designed relationships to ensure RLS filters propagate to other model tables. Proto nepoužívejte funkci jazyka DAX LOOKUPVALUE, když by relace modelu mohly dosáhnout stejného výsledku.So, avoid using the LOOKUPVALUE DAX function when model relationships could achieve the same result.

Vždy, když jsou v tabulkách DirectQuery vynuceny filtry zabezpečení na úrovni řádků a existují relace s jinými tabulkami DirectQuery, musíte optimalizovat zdrojovou databázi.Whenever RLS filters are enforced on DirectQuery tables and there are relationships to other DirectQuery tables, be sure to optimize the source database. To může zahrnovat návrh odpovídajících indexů nebo používání trvalých počítaných sloupců.It can involve designing appropriate indexes or using persisted computed columns. Další informace najdete v článku Pokyny k modelu DirectQuery v Power BI Desktopu.For more information, see DirectQuery model guidance in Power BI Desktop.

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

V Power BI Desktopu je možné měřit dopad filtrů zabezpečení na úrovni řádků pomocí Analyzátoru výkonu.It's possible to measure the performance impact of RLS filters in Power BI Desktop by using Performance Analyzer. Nejprve určíte trvání dotazů ve vizuálech sestavy, když není vynuceno zabezpečení na úrovni řádků.First, determine report visual query durations when RLS isn't enforced. Pak použijete příkaz Zobrazit jako na pásu karet Modelování k vynucení zabezpečení na úrovni řádků a určení a porovnání trvání dotazů.Then, use the View As command on the Modeling ribbon tab to enforce RLS and determine and compare query durations.

Konfigurace mapování rolíConfigure role mappings

Po publikování do Power BI musíte namapovat členy na role datové sady.Once published to Power BI, you must map members to dataset roles. Do rolí můžou členy přidávat pouze vlastníci datové sady nebo správci pracovního prostoru.Only dataset owners or workspace admins can add members to roles. Další informace najdete v článku Zabezpečení na úrovni řádků (RLS) v Power BI (Správa zabezpečení na vašem modelu).For more information, see Row-level security (RLS) with Power BI (Manage security on your model).

Členy můžou být uživatelské účty nebo skupiny zabezpečení.Members can be user accounts or security groups. Kdykoli je to možné, doporučujeme, abyste na role datové sady mapovali skupiny zabezpečení.Whenever possible, we recommend you map security groups to dataset roles. To zahrnuje správu členství ve skupinách zabezpečení ve službě Azure Active Directory.It involves managing security group memberships in Azure Active Directory. Případně se tento úkol deleguje správcům vaší sítě.Possibly, it delegates the task to your network administrators.

Ověření rolíValidate roles

Otestujte všechny role, abyste se ujistili, že filtrují model správně.Test each role to ensure it filters the model correctly. To se dá snadno udělat pomocí příkazu Zobrazit jako na pásu karet Modelování.It's easily done by using the View As command on the Modeling ribbon tab.

Pokud model používá dynamická pravidla pomocí funkce jazyka DAX USERNAME, nezapomeňte otestovat očekávané a neočekávané hodnoty.When the model has dynamic rules using the USERNAME DAX function, be sure to test for expected and unexpected values. Při vkládání obsahu Power BI – konkrétně při použití scénáře Aplikace vlastní data – může logika aplikace předat libovolnou hodnotu jako efektivní uživatelské jméno identity.When embedding Power BI content—specifically using the App owns data scenario—app logic can pass any value as an effective identity user name. Kdykoli je to možné, zajistěte, aby výsledkem nechtěných nebo škodlivých hodnot byly filtry, které nevrací žádné řádky.Whenever possible, ensure accidental or malicious values result in filters that return no rows.

Příkladem může být použití Power BI Embedded, kde aplikace předává roli pracovní pozice uživatele jako efektivní uživatelské jméno: Je to buď „Manager“ (Manažer) nebo „Worker“ (Pracovník).Consider an example using Power BI embedded, where the app passes the user's job role as the effective user name: It's either "Manager" or "Worker". Manažeři uvidí všechny řádky, ale pracovníci uvidí jenom řádky, u kterých má sloupec Type (Typ) hodnotu „Internal“ (Interní).Managers can see all rows, but workers can only see rows where the Type column value is "Internal".

Je definován následující výraz pravidla:The following rule expression is defined:

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

Problém s tímto výrazem pravidla je, že všechny hodnoty s výjimkou hodnoty „Worker“ vrátí všechny řádky tabulky.The problem with this rule expression is that all values, except "Worker", return all table rows. Takže jakákoli náhodná hodnota, například „Wrker“, neúmyslně vrátí všechny řádky tabulky.So, an accidental value, like "Wrker", unintentionally returns all table rows. Proto je bezpečnější napsat výraz, který testuje každou očekávanou hodnotu.Therefore, it's safer to write an expression that tests for each expected value. V následujícím vylepšeném výrazu pravidla bude výsledkem neočekávané hodnoty to, že tabulka nevrátí žádné řádky.In the following improved rule expression, an unexpected value will result in the table returning no rows.

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

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

V některých případech výpočty potřebují hodnoty, které nejsou omezeny pomocí filtrů zabezpečení na úrovni řádků.Sometimes, calculations need values that aren't constrained by RLS filters. Sestava může například potřebovat zobrazit poměr tržeb získaných v prodejní oblasti uživatele sestavy a všech celkových tržeb.For example, a report may need to display a ratio of revenue earned for the report user's sales region over all revenue earned.

I když není možné, aby výraz v jazyce DAX přepsal zabezpečení na úrovni řádků – ve skutečnosti nemůže ani určit, že je zabezpečení na úrovni řádků vynuceno – můžete použít souhrnnou tabulku modelu.While it's not possible for a DAX expression to override RLS—in fact, it can't even determine that RLS is enforced—you can use a summary model table. Souhrnná tabulka modelu je dotazována, aby se získaly tržby za „všechny oblasti“, a není omezena žádnými filtry zabezpečení na úrovni řádků.The summary model table is queried to retrieve revenue for "all regions" and it's not constrained by any RLS filters.

Pojďme se podívat, jak byste mohli tento požadavek na návrh implementovat.Let's see how you could implement this design requirement. Nejprve zvažte následující návrh modelu:First, consider the following model design:

Je zobrazen obrázek s diagramem modelu. Je popsán v následujících odstavcích.

Model se skládá ze čtyř tabulek:The model comprises four tables:

  • Tabulka Salesperson (Prodejce) ukládá jeden řádek pro každého prodejce.The Salesperson table stores one row per salesperson. Zahrnuje sloupec EmailAddress (E-mailová adresa), ve kterém je uložena e-mailová adresa pro každého prodejce.It includes the EmailAddress column, which stores the email address for each salesperson. Tato tabulka je skrytá.This table is hidden.
  • Tabulka Sales (Prodeje) ukládá jeden řádek pro každou objednávku.The Sales table stores one row per order. Zahrnuje míru Revenue % All Region (Procento tržeb proti všem oblastem), která je navržena tak, aby vracela poměr tržeb dosažených v oblasti uživatele sestavy a tržeb dosažených všemi oblastmi.It includes the Revenue % All Region measure, which is designed to return a ratio of revenue earned by the report user's region over revenue earned by all regions.
  • Tabulka Date (Datum) ukládá jeden řádek pro každé datum a umožňuje filtrování a seskupování roků a měsíců.The Date table stores one row per date and allows filtering and grouping year and month.
  • Tabulka SalesRevenueSummary (Souhrn prodejních tržeb) je počítaná tabulka.The SalesRevenueSummary is a calculated table. Ukládá celkové tržby pro každé datum objednávky.It stores total revenue for each order date. Tato tabulka je skrytá.This table is hidden.

Následující výraz definuje počítanou tabulku SalesRevenueSummary:The following expression defines the SalesRevenueSummary calculated table:

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

Poznámka

Tabulka agregace by mohla dosáhnout stejného požadavku na návrh.An aggregation table could achieve the same design requirement.

Následující pravidlo zabezpečení na úrovni řádků se použije u tabulky Salesperson:The following RLS rule is applied to the Salesperson table:

[EmailAddress] = USERNAME()

Každá ze tří relací tohoto modelu je popsána v následující tabulce:Each of the three model relationships is described in the following table:

RelaceRelationship PopisDescription
Ukončení vývojového diagramu 1 Mezi tabulkami Salesperson a Sales je relace M:N.There's a many-to-many relationship between the Salesperson and Sales tables. Pravidlo zabezpečení na úrovni řádků filtruje sloupec EmailAddress skryté tabulky Salesperson pomocí funkce jazyka DAX USERNAME.The RLS rule filters the EmailAddress column of the hidden Salesperson table by using the USERNAME DAX function. Hodnota sloupce Region (Oblast) uživatele sestavy se šíří do tabulky Sales.The Region column value (for the report user) propagates to the Sales table.
Ukončení vývojového diagramu 2 Mezi tabulkami Date a Sales je relace 1:N.There's a one-to-many relationships between the Date and Sales tables.
Ukončení vývojového diagramu 3 Mezi tabulkami Date a SalesRevenueSummary je relace 1:N.There's a one-to-many relationships between the Date and SalesRevenueSummary tables.

Následující výraz definuje míru Revenue % All Region:The following expression defines the Revenue % All Region measure:

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

Poznámka

Dávejte pozor, abyste nezveřejnili citlivé údaje.Take care to avoid disclosing sensitive facts. Pokud by v tomto příkladu existovaly jenom dvě oblasti, pak by uživatel sestavy mohl vypočítat tržby druhé oblasti.If there are only two regions in this example, then it would be possible for a report user to calculate revenue for the other region.

Vyhněte se používání zabezpečení na úrovni řádkůAvoid using RLS

Vyhněte se používání zabezpečení na úrovni řádků, kdykoli to dává smysl.Avoid using RLS, whenever it makes sense to do so. Pokud máte jenom malý počet zjednodušených pravidel zabezpečení na úrovni řádků, která používají statické filtry, zvažte místo toho publikování více datových sad.If you have only a small number of simplistic RLS rules that apply static filters, consider publishing multiple datasets instead. Žádná z těchto datových sad nedefinuje role, protože každá datová sada obsahuje data pro konkrétní cílovou skupinu uživatelů sestavy, která má stejná oprávnění pro data.None of the datasets define roles because each dataset contains data for a specific report user audience, which has the same data permissions. Pak vytvořte jeden pracovní prostor pro každou cílovou skupinu a přiřaďte k tomuto pracovnímu prostoru nebo aplikaci přístupová oprávnění.Then, create one workspace per audience and assign access permissions to the workspace or app.

Například společnost, která má pouze dvě prodejní oblasti, se rozhodla publikovat datovou sadu pro každou prodejní oblast do různých pracovních prostorů.For example, a company that has just two sales regions decides to publish a dataset for each sales region to different workspaces. Tyto datové sady nevynucují zabezpečení na úrovni řádků.The datasets don't enforce RLS. Používají však parametry dotazu k filtrování zdrojových dat.They do, however, use query parameters to filter source data. Tímto způsobem je v každém pracovním prostoru publikován stejný model – liší se pouze hodnoty parametrů datové sady.This way, the same model is published to each workspace—they just have different dataset parameter values. Prodejcům se přiřadí přístup pouze k jednomu z pracovních prostorů (nebo publikovaných aplikací).Salespeople are assigned access to just one of the workspaces (or published apps).

Nepoužívání zabezpečení na úrovni řádků má několik výhod:There are several advantages associated with avoiding RLS:

  • Lepší výkon dotazů: Může to vést k lepšímu výkonu díky menšímu počtu filtrů.Improved query performance: It can result in improved performance due to fewer filters.
  • Menší modely: I když je výsledkem větší počet modelů, jsou tyto modely menší.Smaller models: While it results in more models, they are smaller in size. Menší modely můžou zlepšit odezvu u dotazů a aktualizací dat, zejména v případě, že hostující kapacita zaznamenává tlak na prostředky.Smaller models can improve query and data refresh responsiveness, especially if the hosting capacity experiences pressure on resources. Také je snazší udržovat velikosti modelů v rámci omezení velikosti, která jsou vynucená vaší kapacitou.Also, it's easier to keep model sizes beneath size limits imposed by your capacity. Nakonec je také snazší vyrovnávat zatížení mezi různými kapacitami, protože můžete vytvářet pracovní prostory v různých kapacitách nebo je do různých kapacit přesouvat.Lastly, it's easier to balance workloads across different capacities, because you can create workspaces on—or move workspaces to—different capacities.
  • Další funkce: Je možné používat funkce Power BI, které nefungují se zabezpečením na úrovni řádků, jako je Publikovat na webu.Additional features: Power BI features that don't work with RLS, like Publish to web, can be used.

Nepoužívání zabezpečení na úrovni řádků má však také nevýhody:However, there are disadvantages associated with avoiding RLS:

  • Více pracovních prostorů: Pro každou cílovou skupinu uživatelů je vyžadován jeden pracovní prostor.Multiple workspaces: One workspace is required for each report user audience. Pokud jsou publikovány aplikace, znamená to také, že existuje jedna aplikace pro každou cílovou skupinu uživatelů sestavy.If apps are published, it also means there's one app per report user audience.
  • Duplikování obsahu: V každém pracovním prostoru musí být vytvořeny sestavy a řídicí panely.Duplication of content: Reports and dashboards must be created in each workspace. To vyžaduje další úsilí a čas k nastavení a údržbě.It requires additional effort and time to set up and maintain.
  • Uživatelé s vysokými oprávněními: Uživatelé s vysokými oprávněními, kteří patří k více cílovým skupinám uživatelů sestavy, nemůžou zobrazit konsolidované zobrazení dat.High privilege users: High privilege users, who belong to multiple report user audiences, can't see a consolidated view of the data. Budou muset otevřít víc sestav (z různých pracovních prostorů nebo aplikací).They'll need to open multiple reports (from different workspaces or apps).

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

Pokud má zabezpečení na úrovni řádků za následek neočekávané výsledky, ověřte následující problémy:If RLS produces unexpected results, check for the following issues:

  • Mezi tabulkami modelů existují nesprávné relace, a to u mapování sloupců a směrů filtrů.Incorrect relationships exist between model tables, in terms of column mappings and filter directions.
  • Není správně nastavená vlastnost relace Použít filtr zabezpečení v obou směrech.The Apply security filter in both directions relationship property isn't correctly set. Další informace najdete v tématu Pokyny k obousměrné relaci.For more information, see Bi-directional relationship guidance.
  • Tabulky neobsahují žádná data.Tables contain no data.
  • Do tabulek jsou načteny nesprávné hodnoty.Incorrect values are loaded into tables.
  • Uživatel je mapován na více rolí.The user is mapped to multiple roles.
  • Model obsahuje tabulky agregací a pravidla zabezpečení na úrovni řádků nefiltrují konzistentně agregace a podrobnosti.The model includes aggregation tables, and RLS rules don't consistently filter aggregations and details. Další informace najdete v článku Používání agregací v Power BI Desktopu (Zabezpečení na úrovni řádků pro agregace).For more information, see Use aggregations in Power BI Desktop (RLS for aggregations).

Když určitý uživatel nevidí žádná data, může to být tím, že jeho hlavní název uživatele (UPN) není uložený nebo je nesprávně zadaný.When a specific user can't see any data, it could be because their UPN isn't stored or it's entered incorrectly. K tomu může dojít náhle, protože se jeho uživatelský účet změnil v důsledku změny jména.It can happen abruptly because their user account has changed as the result of a name change.

Tip

Pro účely testování přidejte míru, která vrací funkci jazyka DAX USERNAME.For testing purposes, add a measure that returns the USERNAME DAX function. Můžete ji pojmenovat například „Kdo jsem“.You might name it something like "Who Am I". Pak tuto míru přidejte do vizuálu karty v sestavě a publikujte ji do Power BI.Then, add the measure to a card visual in a report and publish it to Power BI.

Když určitý uživatel vidí všechna data, je možné, že přistupuje k sestavám přímo v pracovním prostoru a je vlastníkem datové sady.When a specific user can see all data, it's possible they're accessing reports directly in the workspace and they're the dataset owner. Zabezpečení na úrovni řádků se vynucuje jen v těchto případech:RLS is only enforced when:

  • Sestava je otevřena v aplikaci.The report is opened in an app.
  • Sestava je otevřena v pracovním prostoru a uživatel je mapován na roli Prohlížející.The report is opened in a workspace, and the user is mapped to the Viewer role.

Další krokyNext steps

Další informace související s tímto článkem najdete v následujících tématech:For more information related to this article, check out the following resources: