Útmutató a sorszintű biztonsághoz (RLS) a Power BI DesktopbanRow-level security (RLS) guidance in Power BI Desktop

Ez a cikk a Power BI Desktopot használó adatmodellezőknek szól.This article targets you as a data modeler working with Power BI Desktop. A sorszintű biztonság (RLS) adatmodellekben történő kényszerítésének ajánlott tervezési eljárásait ismerteti.It describes good design practices for enforcing row-levels security (RLS) in your data models.

Fontos megérteni, hogy az RLS-szűrők táblasorokat szűrnek.It's important to understand RLS filters table rows. Nem konfigurálhatók úgy, hogy korlátozzák a modellobjektumokhoz való hozzáférést, beleértve a táblákat, oszlopokat vagy mértékeket.They can't be configured to restrict access to model objects, including tables, columns, or measures.

Megjegyzés

Ez a cikk nem taglalja az RLS-t vagy annak beállítását.This article doesn't describe RLS or how to set it up. További információért lásd: Az adathozzáférés korlátozása sorszintű biztonsággal (RLS) a Power BI Desktopban.For more information, see Restrict data access with row-level security (RLS) for Power BI Desktop.

Emellett nem fedi le az RLS kényszerítését a külső üzemeltetésű modellekkel való élő kapcsolatokon az Azure Analysis Services vagy az SQL Server Analysis Services használatával.Also, it doesn't cover enforcing RLS in live connections to external-hosted models with Azure Analysis Services or SQL Server Analysis Services. Ezekben az esetekben az RLS kényszerítését az Analysis Services végzi.In these cases, RLS is enforced by Analysis Services. Ha a Power BI egyszeri bejelentkezés (SSO) használatával csatlakozik, az Analysis Services kényszeríti az RLS-t (kivéve, ha a fiók rendszergazdai jogosultságokkal rendelkezik).When Power BI connects using single-sign on (SSO), Analysis Services will enforce RLS (unless the account has admin privileges).

Szerepkörök létrehozásaCreate roles

Több szerepkör is létrehozható.It's possible to create multiple roles. Amikor azt mérlegeli, hogy egy adott jelentésfelhasználónak milyen engedélyekre van szüksége, törekedjen arra, hogy egyetlen olyan szerepkört hozzon létre, amely az összes szükséges engedélyt biztosítja ahelyett, hogy a jelentésfelhasználóhoz több szerepkört társítana.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. Erre azért van szükség, mert a jelentésfelhasználók több szerepkörhöz is hozzárendelhetők közvetlenül a felhasználói fiókjukon vagy közvetve egy biztonsági csoport tagságán keresztül.It's because a report user could map to multiple roles, either directly by using their user account or indirectly by security group membership. Több szerepkör-hozzárendelés váratlan eredményekkel járhat.Multiple role mappings can result in unexpected outcomes.

Ha egy jelentésfelhasználó több szerepkörhöz van hozzárendelve, az RLS-szűrők összeadódnak.When a report user is assigned to multiple roles, RLS filters become additive. Ez azt jelenti, hogy a jelentésfelhasználók a tábla különböző szűrők által biztosított összes sorához hozzáférnek.It means report users can see table rows that represent the union of those filters. Mi több, bizonyos helyzetekben nem lehet garantálni, hogy egy jelentésfelhasználó nem lát sorokat a táblában.What's more, in some scenarios it's not possible to guarantee that a report user doesn't see rows in a table. Tehát az SQL Server adatbázis-objektumokra (és más engedélymodellekre) vonatkozó engedélyeitől eltérően a „ha egyszer megtagadva, akkor véglegesen megtagadva” elv nem érvényes.So, unlike permissions applied to SQL Server database objects (and other permission models), the "once denied always denied" principle doesn't apply.

Vegyünk egy modellt két szerepkörrel: A Feldolgozók nevű első szerepkör a következő szabálykifejezésen keresztül korlátozza a hozzáférést a tábla összes Bérszámfejtés típusú sorához: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()

Megjegyzés

Egy szabály a tábla egy sorát sem jeleníti meg, ha a kifejezés értéke hamis.A rule will return no table rows when its expression evaluates to false.

A Vezetők nevű második szerepkör a következő szabálykifejezésen keresztül hozzáférést biztosít a tábla összes Bérszámfejtés típusú sorához:Yet, a second role, named Managers, allows access to all Payroll table rows by using the following rule expression:

TRUE()

Legyen körültekintő: Ha a jelentésfelhasználó mindkét szerepkörhöz társítva van, akkor a tábla összes Bérszámfejtés típusú sorát látni fogja.Take care: Should a report user map to both roles, they'll see all Payroll table rows.

RLS-optimalizálásOptimize RLS

Az RLS automatikusan szűrőket alkalmaz minden DAX-lekérdezésre, és ezek a szűrők negatív hatással lehetnek a lekérdezési teljesítményre.RLS works by automatically applying filters to every DAX query, and these filters may have a negative impact on query performance. Emiatt az RLS hatékonysága a megfelelő modellkialakításon alapul.So, efficient RLS comes down to good model design. Fontos, hogy kövesse a modelltervezési útmutatót, amelyet a következő cikkekben talál:It's important to follow model design guidance, as discussed in the following articles:

Általánosságban elmondható, hogy az RLS-szűrőket hatékonyabb ténytáblák helyett dimenziótáblákon kényszeríteni.In general, it's often more efficient to enforce RLS filters on dimension-type tables, and not fact-type tables. Emellett a jól megtervezett kapcsolatok segítségével biztosítható, hogy az RLS-szűrők más modelltáblákba is propagálhatók.And, rely on well-designed relationships to ensure RLS filters propagate to other model tables. Ezért ne használja a LOOKUPVALUE DAX-függvényt, ha modellkapcsolatokon keresztül is elérheti ugyanazt az eredményt.So, avoid using the LOOKUPVALUE DAX function when model relationships could achieve the same result.

Amikor RLS-szűrők vannak DirectQuery-táblákon kényszerítve, és vannak kapcsolatok más DirectQuery-táblákhoz, ügyeljen arra, hogy optimalizálja a forrásadatbázist.Whenever RLS filters are enforced on DirectQuery tables and there are relationships to other DirectQuery tables, be sure to optimize the source database. Ez magában foglalhatja a megfelelő indexek kialakítását vagy a megőrzött számított oszlopok használatát is.It can involve designing appropriate indexes or using persisted computed columns. További információért lásd: Útmutató a Power BI Desktopbeli DirectQuery-modellekhez.For more information, see DirectQuery model guidance in Power BI Desktop.

Az RLS hatásának méréseMeasure RLS impact

Az RLS-szűrők teljesítményre gyakorolt hatásának mérése a Power BI Desktop Teljesítményelemző eszközének használatával lehetséges.It's possible to measure the performance impact of RLS filters in Power BI Desktop by using Performance Analyzer. Először határozza meg a jelentés vizualizációlekérdezésének időtartamát, amikor az RLS nincs kényszerítve.First, determine report visual query durations when RLS isn't enforced. Ezután használja a Modellezés menüszalaglapon található Megtekintés mint parancsot az RLS kényszerítéséhez, és határozza meg a lekérdezések időtartamát az összehasonlításhoz.Then, use the View As command on the Modeling ribbon tab to enforce RLS and determine and compare query durations.

Szerepkör-hozzárendelések konfigurálásaConfigure role mappings

A Power BI-ban történő közzétételt követően meg kell feleltetni a tagokat az adathalmaz-szerepköreikkel.Once published to Power BI, you must map members to dataset roles. Csak az adathalmazok tulajdonosai vagy a munkaterület-adminisztrátorok adhatnak hozzá tagokat a szerepkörökhöz.Only dataset owners or workspace admins can add members to roles. További információért lásd: Sorszintű biztonság (RLS) a Power BI-ban (az adatmodell biztonságának kezelése).For more information, see Row-level security (RLS) with Power BI (Manage security on your model).

Tagok lehetnek felhasználói fiókok vagy biztonsági csoportok.Members can be user accounts or security groups. Amikor csak lehetséges, azt javasoljuk, hogy a biztonsági csoportokat rendelje adathalmaz-szerepkörökhöz.Whenever possible, we recommend you map security groups to dataset roles. Ez magában foglalja a biztonsági csoportok tagságának kezelését az Azure Active Directoryban.It involves managing security group memberships in Azure Active Directory. Előfordulhat, hogy delegálja a feladatot a hálózati rendszergazdáknak.Possibly, it delegates the task to your network administrators.

Szerepkörök ellenőrzéseValidate roles

Tesztelje az egyes szerepköröket, és győződjön meg arról, hogy megfelelően szűrik a modellt.Test each role to ensure it filters the model correctly. Ezt egyszerűen végrehajthatja a Modellezés menüszalaglapon található Megtekintés mint parancs használatával.It's easily done by using the View As command on the Modeling ribbon tab.

Ha a modellben a USERNAME DAX-függvényt használó dinamikus szabályok vannak, a várt és váratlan értékeket egyaránt ellenőrizze.When the model has dynamic rules using the USERNAME DAX function, be sure to test for expected and unexpected values. Power BI-tartalom beágyazásakor – különösen az Alkalmazás tulajdonában lévő adatok típusú forgatókönyv esetén – az alkalmazáslogika bármilyen értéket érvényes identitás-felhasználónévként adhat át.When embedding Power BI content—specifically using the App owns data scenario—app logic can pass any value as an effective identity user name. Amikor csak lehetséges, gondoskodjon arról, hogy a véletlenül vagy rosszindulatú céllal megadott értékek szűrői ne adjanak vissza sorokat.Whenever possible, ensure accidental or malicious values result in filters that return no rows.

Vegyünk egy példát a Power BI Embedded használatával, ahol az alkalmazás érvényes felhasználónévként továbbítja a felhasználó munkakörét: Ez lehet „Vezető” vagy „Feldolgozó”.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". A vezetők láthatják az összes sort, ezzel szemben a feldolgozók csak azokat a sorokat láthatják, amelyeknél a Típus oszlop értéke „Belső”.Managers can see all rows, but workers can only see rows where the Type column value is "Internal".

A következő szabálykifejezés van definiálva:The following rule expression is defined:

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

Ezzel a szabálykifejezéssel az a probléma, hogy a „Feldolgozó” szerepkört leszámítva bármilyen értékre visszaadja a tábla összes sorát.The problem with this rule expression is that all values, except "Worker", return all table rows. Tehát a véletlenül hibásan megadott értékek, például a „Feldolgozó” akaratlanul visszaadják a tábla összes sorát.So, an accidental value, like "Wrker", unintentionally returns all table rows. Ezért biztonságosabb egy olyan kifejezést írni, amely minden egyes várt értékre tesztel.Therefore, it's safer to write an expression that tests for each expected value. A következő továbbfejlesztett szabálykifejezésben a nem várt értékek azt eredményezik, hogy a tábla nem ad vissza sorokat.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()
    )
)

Részleges RLS kialakításaDesign partial RLS

Előfordulhat, hogy a számításoknak olyan értékekre van szükségük, amelyeket az RLS-szűrők nem korlátoznak.Sometimes, calculations need values that aren't constrained by RLS filters. Előfordulhat például, hogy egy jelentésnek meg kell jelenítenie a jelentésfelhasználónak az értékesítési régiója által elért bevétel arányát az összes bevételhez képest.For example, a report may need to display a ratio of revenue earned for the report user's sales region over all revenue earned.

Habár egy DAX-kifejezés nem bírálhatja felül az RLS-t – valójában nem is tudja megállapítani, hogy az RLS kényszerítve van-e –, egy összegző modelltáblát használhat.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. Az összegző modelltábla használható az „összes régió” bevételének lekérésére, mivel nem korlátozzák az RLS-szűrők.The summary model table is queried to retrieve revenue for "all regions" and it's not constrained by any RLS filters.

Lássuk, hogyan valósítható meg ez a kialakítási követelmény.Let's see how you could implement this design requirement. Először vizsgáljuk meg a következő modelltervet:First, consider the following model design:

Megjelenik a modelldiagram képe. A terv a következő bekezdésekben olvasható.

A modell négy táblából áll:The model comprises four tables:

  • A Salesperson tábla egy sort tárol értékesítőnként.The Salesperson table stores one row per salesperson. Magában foglalja az EmailAddress oszlopot, amely az egyes üzletkötők e-mail-címét tárolja.It includes the EmailAddress column, which stores the email address for each salesperson. Ez a tábla rejtett.This table is hidden.
  • A Sales tábla rendelésenként egy sort tartalmaz.The Sales table stores one row per order. Magában foglalja a Revenue % All Region mértéket, amely a jelentésfelhasználó régiója és az összes régió által elért bevétel arányának visszaadására szolgál.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.
  • A Date tábla dátumonként egy sort tárol, és lehetővé teszi a szűrést és csoportosítási év és hónap alapján.The Date table stores one row per date and allows filtering and grouping year and month.
  • A SalesRevenueSummary egy számított tábla.The SalesRevenueSummary is a calculated table. Az egyes rendelési dátumokra vonatkozó teljes bevételt tárolja.It stores total revenue for each order date. Ez a tábla rejtett.This table is hidden.

A következő kifejezés definiálja a SalesRevenueSummary számított táblát:The following expression defines the SalesRevenueSummary calculated table:

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

Megjegyzés

Egy aggregációs tábla segítségével is elérhető ugyanaz a kialakítási követelmény.An aggregation table could achieve the same design requirement.

A következő RLS-szabály lesz alkalmazva a Salesperson táblára:The following RLS rule is applied to the Salesperson table:

[EmailAddress] = USERNAME()

A három modellkapcsolatot a következő táblázat ismerteti:Each of the three model relationships is described in the following table:

KapcsolatRelationship LeírásDescription
Folyamatábra 1. lezárója Több-a-többhöz kapcsolat van a Salesperson és a Sales táblák között.There's a many-to-many relationship between the Salesperson and Sales tables. Az RLS-szabály a rejtett Salesperson tábla EmailAddress oszlopát szűri a USERNAME DAX-függvény használatával.The RLS rule filters the EmailAddress column of the hidden Salesperson table by using the USERNAME DAX function. A Region oszlop értéke (a jelentésfelhasználó esetében) a Sales táblára terjed ki.The Region column value (for the report user) propagates to the Sales table.
Folyamatábra 2. lezárója A Date és a Sales tábla között egy-a-többhöz típusú kapcsolatok vannak.There's a one-to-many relationships between the Date and Sales tables.
Folyamatábra 3. lezárója A Date és az SalesRevenueSummary tábla között egy-a-többhöz típusú kapcsolatok vannak.There's a one-to-many relationships between the Date and SalesRevenueSummary tables.

A következő kifejezés az Összes régió bevételi aránya mértéket definiálja:The following expression defines the Revenue % All Region measure:

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

Megjegyzés

Ügyeljen rá, hogy elkerülje a bizalmas adatok felfedését.Take care to avoid disclosing sensitive facts. Ha ebben a példában csak két régió található, akkor a jelentésfelhasználók kiszámíthatják a másik régió bevételét.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.

Az RLS használatának mellőzéseAvoid using RLS

Az RLS-t akkor használja, amikor tényleg érdemes.Avoid using RLS, whenever it makes sense to do so. Ha csak kis számú, egyszerű RLS-szabályra van szüksége, amelyek statikus szűrőket alkalmaznak, érdemes inkább több adathalmazt közzétenni.If you have only a small number of simplistic RLS rules that apply static filters, consider publishing multiple datasets instead. Az adathalmazok egyike sem határoz meg szerepköröket, mert az egyes adathalmazok egy adott jelentésfelhasználói célközönségre vonatkozó adatokat tartalmaznak, amelyekre ugyanazok az adatengedélyek vonatkoznak.None of the datasets define roles because each dataset contains data for a specific report user audience, which has the same data permissions. Ezután hozzon létre célközönségenként egy munkaterületet, és rendeljen hozzáférési engedélyeket a munkaterülethez vagy alkalmazáshoz.Then, create one workspace per audience and assign access permissions to the workspace or app.

Például egy vállalat, amely mindössze két értékesítési régiót tartalmaz, úgy dönt, hogy az egyes értékesítési régiókhoz külön adathalmazokat tesz közzé különböző munkaterületekre.For example, a company that has just two sales regions decides to publish a dataset for each sales region to different workspaces. Az adathalmazok nem kényszerítik az RLS-t.The datasets don't enforce RLS. Azonban lekérdezési paramétereket használnak a forrásadatok szűrésére.They do, however, use query parameters to filter source data. Így ugyanaz a modell minden munkaterületen közzé van téve, mindössze eltérő adathalmaz-paraméterekkel.This way, the same model is published to each workspace—they just have different dataset parameter values. Az értékesítők csak az egyik munkaterülethez (vagy közzétett alkalmazáshoz) kapnak hozzáférést.Salespeople are assigned access to just one of the workspaces (or published apps).

Az RLS használatának mellőzése számos előnnyel jár:There are several advantages associated with avoiding RLS:

  • A lekérdezési teljesítmény növelése: A kevesebb szűrőnek köszönhetően jobb teljesítményt érhet el.Improved query performance: It can result in improved performance due to fewer filters.
  • Kisebb modellek: Bár több modellel jár, azok összességében kisebbek lesznek.Smaller models: While it results in more models, they are smaller in size. A kisebb modellek javítják a lekérdezési és adatfrissítési rugalmasságot, különösen akkor, ha az üzemeltetési kapacitás erőforrásait terhelés éri.Smaller models can improve query and data refresh responsiveness, especially if the hosting capacity experiences pressure on resources. Emellett könnyebb a modellek méretét a kapacitási méretkorlát alatt tartani.Also, it's easier to keep model sizes beneath size limits imposed by your capacity. Végül pedig könnyebb kiegyensúlyozni a számítási feladatokat a különböző kapacitások között, mert munkaterületeket hozhat létre – vagy áthelyezhet munkaterületeket – különböző kapacitásokra.Lastly, it's easier to balance workloads across different capacities, because you can create workspaces on—or move workspaces to—different capacities.
  • További funkciók: Használhatók a Power BI olyan funkciói, például a Webes közzététel, amelyek nem kompatibilisek az RLS-sel.Additional features: Power BI features that don't work with RLS, like Publish to web, can be used.

Azonban nem csak előnyei vannak az RLS használatának mellőzésének:However, there are disadvantages associated with avoiding RLS:

  • Több munkaterület: Az egyes jelentésfelhasználói célközönségekhez egy-egy munkaterületre van szükség.Multiple workspaces: One workspace is required for each report user audience. Ha az alkalmazások közzé vannak téve, az azt is jelenti, hogy jelentésfelhasználói célközönségenként egy-egy alkalmazásra van szükség.If apps are published, it also means there's one app per report user audience.
  • Duplikált tartalom: A jelentéseket és irányítópultokat minden munkaterületen létre kell hozni.Duplication of content: Reports and dashboards must be created in each workspace. A beállítás és karbantartás több erőfeszítést és időt igényel.It requires additional effort and time to set up and maintain.
  • Magas jogosultsággal rendelkező felhasználók: A magas jogosultságú felhasználók, akik több jelentésfelhasználói célközönségéhez tartoznak, nem láthatják az adatok összevont nézetét.High privilege users: High privilege users, who belong to multiple report user audiences, can't see a consolidated view of the data. Több jelentést kell megnyitniuk (különböző munkaterületekről vagy alkalmazásokból).They'll need to open multiple reports (from different workspaces or apps).

Az RLS hibaelhárításaTroubleshoot RLS

Ha az RLS nem várt eredményeket ad vissza, ellenőrizze a következőket:If RLS produces unexpected results, check for the following issues:

  • Helytelen kapcsolatok léteznek a modelltáblák között az oszlop-hozzárendelések és a szűrési irányok tekintetében.Incorrect relationships exist between model tables, in terms of column mappings and filter directions.
  • A Biztonsági szűrő alkalmazása mindkét irányban kapcsolattulajdonság nincs megfelelően beállítva.The Apply security filter in both directions relationship property isn't correctly set. További információ: Útmutatás kétirányú kapcsolatokhoz.For more information, see Bi-directional relationship guidance.
  • A táblák nem tartalmaznak adatokat.Tables contain no data.
  • Helytelen értékek vannak betöltve a táblákba.Incorrect values are loaded into tables.
  • A felhasználó több szerepkörhöz van hozzárendelve.The user is mapped to multiple roles.
  • A modell aggregációs táblákat tartalmaz, és az RLS-szabályok nem szűrik konzisztensen az aggregációkat és a részleteket.The model includes aggregation tables, and RLS rules don't consistently filter aggregations and details. További információ: Aggregációk használata a Power BI Desktopban (RLS az aggregációk használatához).For more information, see Use aggregations in Power BI Desktop (RLS for aggregations).

Ha egy adott felhasználó nem lát semmilyen adatot, annak az oka az lehet, hogy az UPN nincs tárolva, vagy helytelenül van megadva.When a specific user can't see any data, it could be because their UPN isn't stored or it's entered incorrectly. Ez hirtelen történik, mert a felhasználói fiók megváltozott a névváltozás miatt.It can happen abruptly because their user account has changed as the result of a name change.

Tipp

Tesztelési célból adjon hozzá egy mértéket, amely a USERNAME DAX-függvényt adja vissza.For testing purposes, add a measure that returns the USERNAME DAX function. A következőhöz hasonló nevet adhat neki: „Ki vagyok én”.You might name it something like "Who Am I". Ezután adja hozzá a mértéket egy jelentésben található kártyavizualizációhoz, és tegye közzé a Power BI-ban.Then, add the measure to a card visual in a report and publish it to Power BI.

Ha egy adott felhasználó láthatja az összes adatot, lehetséges, hogy közvetlenül a munkaterületen éri el a jelentéseket, és ő az adathalmaz tulajdonosa.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. A rendszer csak akkor kényszeríti az RLS-t, ha:RLS is only enforced when:

  • A jelentést egy alkalmazásban nyitják meg.The report is opened in an app.
  • A jelentés egy munkaterületen van megnyitva, és a felhasználóhoz a Megtekintő szerepkör van hozzárendelve.The report is opened in a workspace, and the user is mapped to the Viewer role.

Következő lépésekNext steps

Ezzel a cikkel kapcsolatosan a következő forrásanyagokban talál további információt:For more information related to this article, check out the following resources: