Power BI Desktop での行レベルのセキュリティ (RLS) のガイダンスRow-level security (RLS) guidance in Power BI Desktop

この記事は、Power BI Desktop を操作するデータ モデラーを対象としています。This article targets you as a data modeler working with Power BI Desktop. データ モデルで行レベルのセキュリティ (RLS) を適用するための適切な設計方法について説明します。It describes good design practices for enforcing row-levels security (RLS) in your data models.

RLS では "テーブルの行" のフィルター処理が行われるということを理解しておくことが重要です。It's important to understand RLS filters table rows. テーブル、列、メジャーなどのモデル オブジェクトへのアクセスを制限するように構成することはできません。They can't be configured to restrict access to model objects, including tables, columns, or measures.

注意

この記事では、RLS について、またはそれを設定する方法については説明しません。This article doesn't describe RLS or how to set it up. 詳細については、「Power BI Desktop の行レベルのセキュリティを使用してデータ アクセスを制限する」を参照してください。For more information, see Restrict data access with row-level security (RLS) for Power BI Desktop.

また、Azure Analysis Services または SQL Server Analysis Services によって外部でホストされているモデルへのライブ接続での RLS の適用についても説明しません。Also, it doesn't cover enforcing RLS in live connections to external-hosted models with Azure Analysis Services or SQL Server Analysis Services. これらの場合には、RLS は Analysis Services によって適用されます。In these cases, RLS is enforced by Analysis Services. Power BI がシングル サインオン (SSO) を使用して接続しているときは、Analysis Services によって RLS が適用されます (アカウントに管理者特権がない場合)。When Power BI connects using single-sign on (SSO), Analysis Services will enforce RLS (unless the account has admin privileges).

ロールを作成するCreate roles

複数のロールを作成することができます。It's possible to create multiple roles. 1 人のレポート ユーザーに必要なアクセス許可を検討する場合は、レポート ユーザーが複数のロールのメンバーになるように設計するのではなく、できる限りすべてのアクセス許可を付与する 1 つのロールを作成するようにします。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. これは、レポート ユーザーは、ユーザー アカウントを使用して直接、またはセキュリティ グループのメンバーシップによって間接的に、複数のロールにマップする可能性があるためです。It's because a report user could map to multiple roles, either directly by using their user account or indirectly by security group membership. 複数のロールにマッピングすると、予期しない結果になる可能性があります。Multiple role mappings can result in unexpected outcomes.

レポート ユーザーが複数のロールに割り当てられていると、RLS フィルターは加法的になります。When a report user is assigned to multiple roles, RLS filters become additive. つまり、レポート ユーザーは、それらのフィルターの和集合を表すテーブル行を見ることができます。It means report users can see table rows that represent the union of those filters. さらに、場合によっては、レポート ユーザーにテーブルの行が表示されないことを保証することができません。What's more, in some scenarios it's not possible to guarantee that a report user doesn't see rows in a table. したがって、SQL Server のデータベース オブジェクトに適用されるアクセス許可 (およびその他のアクセス許可モデル) とは異なり、"一度拒否したら常に拒否する" の原則は適用されません。So, unlike permissions applied to SQL Server database objects (and other permission models), the "once denied always denied" principle doesn't apply.

2 つのロールを持つモデルを考えてみます。Workers という名前の 1 つ目のロールでは、次のルール式を使用して、Payroll テーブルのすべての行に対するアクセスが制限されます。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()

注意

式が false と評価されると、ルールからテーブル行は返されません。A rule will return no table rows when its expression evaluates to false.

一方、Managers という名前の 2 つ目のロールでは、次のルール式を使用して、Payroll テーブルのすべての行に対するアクセスが許可されます。Yet, a second role, named Managers, allows access to all Payroll table rows by using the following rule expression:

TRUE()

注意してください。レポート ユーザーが両方のロールにマップされると、Salary テーブルのすべての行が表示されるようになります。Take care: Should a report user map to both roles, they'll see all Salary table rows.

RLS を最適化するOptimize RLS

RLS は、すべての DAX クエリにフィルターを自動的に適用することによって機能します。これらのフィルターは、クエリのパフォーマンスに悪影響を及ぼす可能性があります。RLS works by automatically applying filters to every DAX query, and these filters may have a negative impact on query performance. したがって、RLS が効率的であれば、適切なモデル設計になります。So, efficient RLS comes down to good model design. 次の記事で説明されているように、モデルの設計ガイダンスに従うことが重要です。It's important to follow model design guidance, as discussed in the following articles:

通常、ファクト型テーブルではなく、ディメンション型テーブルに RLS フィルターを適用する方が効率的です。In general, it's often more efficient to enforce RLS filters on dimension-type tables, and not fact-type tables. また、RLS フィルターが他のモデル テーブルに確実に反映されるためには、リレーションシップが適切に設計されている必要があります。And, rely on well-designed relationships to ensure RLS filters propagate to other model tables. そのため、モデルのリレーションシップで同じ結果になる可能性がある場合は、LOOKUPVALUE DAX 関数を使用しないようにします。So, avoid using the LOOKUPVALUE DAX function when model relationships could achieve the same result.

DirectQuery テーブルに対して RLS フィルターが適用されていて、他の DirectQuery テーブルに対するリレーションシップがある場合は常に、ソース データベースを最適化します。Whenever RLS filters are enforced on DirectQuery tables and there are relationships to other DirectQuery tables, be sure to optimize the source database. それには、適切なインデックスの設計や、保存される計算列の使用が含まれる場合があります。It can involve designing appropriate indexes or using persisted computed columns. 詳細については、「Power BI Desktop の DirectQuery モデルのガイダンス」を参照してください。For more information, see DirectQuery model guidance in Power BI Desktop.

RLS の影響を測定するMeasure RLS impact

パフォーマンス アナライザーを使用することにより、Power BI Desktop での RLS フィルターのパフォーマンスへの影響を測定できます。It's possible to measure the performance impact of RLS filters in Power BI Desktop by using Performance Analyzer. まず、RLS が適用されていない状態で、レポートの視覚化クエリの時間を確認します。First, determine report visual query durations when RLS isn't enforced. 次に、 [モデリング] リボン タブの [表示方法] コマンドを使用して RLS を適用し、クエリの時間を確認して比較します。Then, use the View As command on the Modeling ribbon tab to enforce RLS and determine and compare query durations.

ロールのマッピングを構成するConfigure role mappings

Power BI にパブリッシュした後は、メンバーをデータセットのロールにマップする必要があります。Once published to Power BI, you must map members to dataset roles. メンバーをロールに追加できるのは、データセット所有者またはワークスペース管理者だけです。Only dataset owners or workspace admins can add members to roles. 詳細については、「Power BI での行レベルのセキュリティ (RLS)」の「モデルのセキュリティの管理」を参照してください。For more information, see Row-level security (RLS) with Power BI (Manage security on your model).

メンバーにできるのは、ユーザー アカウントまたはセキュリティ グループです。Members can be user accounts or security groups. 可能な限り、セキュリティ グループをデータセットのロールにマップすることをお勧めします。Whenever possible, we recommend you map security groups to dataset roles. これには、Azure Active Directory でのセキュリティ グループ メンバーシップの管理が含まれます。It involves managing security group memberships in Azure Active Directory. 場合によっては、タスクをネットワーク管理者に委任します。Possibly, it delegates the task to your network administrators.

ロールを検証するValidate roles

各ロールをテストして、モデルが正しくフィルター処理されることを確認します。Test each role to ensure it filters the model correctly. これは、 [モデリング] リボン タブの [表示方法] コマンドを使用して簡単に行うことができます。It's easily done by using the View As command on the Modeling ribbon tab.

モデルに USERNAME DAX 関数を使用する動的なルールがある場合は、予期される値 "および予期されない" 値について必ずテストします。When the model has dynamic rules using the USERNAME DAX function, be sure to test for expected and unexpected values. Power BI コンテンツを埋め込む場合 (具体的にはアプリ所有データのシナリオ)、アプリのロジックで任意の値を有効な ID ユーザー名として渡すことができます。When embedding Power BI content—specifically using the App owns data scenario—app logic can pass any value as an effective identity user name. 可能な場合は常に、誤った値や悪意のある値に対しては行が返されないフィルターになるようにします。Whenever possible, ensure accidental or malicious values result in filters that return no rows.

Power BI Embedded を使用する例を考えます。アプリでは、ユーザーのジョブ ロールを有効なユーザー名として渡します: "Manager" または "Worker" のいずれかです。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". マネージャーはすべての行を表示できますが、ワーカーは Type 列の値が "Internal" である行しか表示できません。Managers can see all rows, but workers can only see rows where the Type column value is "Internal".

次のルール式が定義されています。The following rule expression is defined:

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

このルール式の問題点は、"Worker" を除くすべての値に対して "すべてのテーブル行" が返されることです。The problem with this rule expression is that all values, except "Worker", return all table rows. そのため、誤って "Wrker" などの値を指定すると、すべてのテーブル行が誤って返されます。So, an accidental value, like "Wrker", unintentionally returns all table rows. したがって、予想される値ごとにテストする式を記述する方が安全です。Therefore, it's safer to write an expression that tests for each expected value. 次の改善されたルール式では、予期しない値に対してはテーブルから行が返されません。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()
    )
)

部分的な RLS を設計するDesign partial RLS

場合によっては、RLS フィルターによって制約されない値が計算で必要になることがあります。Sometimes, calculations need values that aren't constrained by RLS filters. たとえば、レポートで、"全収益" に対するレポート ユーザーの販売地域での収益の比率を表示することが必要な場合があります。For example, a report may need to display a ratio of revenue earned for the report user's sales region over all revenue earned.

DAX 式で RLS をオーバーライドすることはできませんが (実際、RLS が適用されているかどうかを判断することさえできません)、概要モデル テーブルを使用できます。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. "すべての地域" の収益を取得するには、概要モデル テーブルのクエリを行い、RLS フィルターでは制約されません。The summary model table is queried to retrieve revenue for "all regions" and it's not constrained by any RLS filters.

この設計要件を実装する方法を見てみましょう。Let's see how you could implement this design requirement. まず、次のようなモデル設計を考えます。First, consider the following model design:

モデルの図が示されている。後の段落で説明されている。

モデルは、次の 4 つのテーブルで構成されます。The model comprises four tables:

  • Salesperson テーブルには、営業担当者ごとに 1 つの行が格納されます。The Salesperson table stores one row per salesperson. EmailAddress 列には、各営業担当者のメール アドレスが格納されます。It includes the EmailAddress column, which stores the email address for each salesperson. このテーブルは非表示です。This table is hidden.
  • Sales テーブルには、注文ごとに 1 つの行が格納されます。The Sales table stores one row per order. それには Revenue % All Region メジャーが含まれており、全地域の収益に対するレポート ユーザーの地域の収益の比率を返すように設計されています。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.
  • Date テーブルには、日付ごとに 1 つの行が格納され、年と月でのフィルター処理とグループ化が可能です。The Date table stores one row per date and allows filtering and grouping year and month.
  • SalesRevenueSummary は計算テーブルです。The SalesRevenueSummary is a calculated table. 注文日ごとの合計収益が格納されます。It stores total revenue for each order date. このテーブルは非表示です。This table is hidden.

次の式では、SalesRevenueSummary 計算テーブルが定義されています。The following expression defines the SalesRevenueSummary calculated table:

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

注意

集計テーブルでも、同じ設計要件を実現できます。An aggregation table could achieve the same design requirement.

Salesperson テーブルには、次の RLS ルールが適用されます。The following RLS rule is applied to the Salesperson table:

[EmailAddress] = USERNAME()

次の表では、3 つのモデル リレーションシップについて説明します。Each of the three model relationships is described in the following table:

リレーションシップRelationship DescriptionDescription
フローチャート ターミネータ 1。 Salesperson テーブルと Sales テーブルの間には、多対多のリレーションシップがあります。There's a many-to-many relationship between the Salesperson and Sales tables. RLS ルールにより、USERNAME DAX 関数を使用して、非表示の Salesperson テーブルの EmailAddress 列がフィルター処理されます。The RLS rule filters the EmailAddress column of the hidden Salesperson table by using the USERNAME DAX function. Region 列の (レポート ユーザーに対する) 値が、Sales テーブルに反映されます。The Region column value (for the report user) propagates to the Sales table.
フローチャート ターミネータ 2。 Date テーブルと Sales テーブルの間には、一対多のリレーションシップがあります。There's a one-to-many relationships between the Date and Sales tables.
フローチャート ターミネータ 3。 Date テーブルと SalesRevenueSummary テーブルの間には、一対多のリレーションシップがあります。There's a one-to-many relationships between the Date and SalesRevenueSummary tables.

次の式では、Revenue % All Region メジャーが定義されています。The following expression defines the Revenue % All Region measure:

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

注意

機密性のファクトが公開されないように注意してください。Take care to avoid disclosing sensitive facts. この例に地域が 2 つしかない場合、レポート ユーザーは他の地域の収益を計算することができます。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.

RLS の使用を避けるAvoid using RLS

そうすることに意味がある場合は常に、RLS を使用しないようにします。Avoid using RLS, whenever it makes sense to do so. 静的フィルターを適用する少数の非常に単純な RLS ルールしかない場合は、代わりに複数のデータセットを公開することを検討します。If you have only a small number of simplistic RLS rules that apply static filters, consider publishing multiple datasets instead. 各データセットには、同じデータ アクセス許可を持つ特定のレポート対象ユーザーのデータが含まれているため、どのデータセットにもロールは定義されていません。None of the datasets define roles because each dataset contains data for a specific report user audience, which has the same data permissions. そして、対象ユーザーごとに 1 つのワークスペースを作成し、ワークスペースまたはアプリにアクセス許可を割り当てます。Then, create one workspace per audience and assign access permissions to the workspace or app.

たとえば、販売地域が 2 つだけの会社では、"各販売地域に対する" データセットを異なるワークスペースに公開します。For example, a company that has just two sales regions decides to publish a dataset for each sales region to different workspaces. データセットでは RLS を適用しません。The datasets don't enforce RLS. ただし、クエリ パラメーターを使用して、ソース データのフィルター処理を行います。They do, however, use query parameters to filter source data. これにより、データセット パラメーターの値だけが異なる同じモデルが、各ワークスペースに対して公開されます。This way, the same model is published to each workspace—they just have different dataset parameter values. 営業担当者には、ワークスペース (または公開されたアプリ) の 1 つのみに対するアクセス権が割り当てられます。Salespeople are assigned access to just one of the workspaces (or published apps).

RLS を避けることにはいくつかの長所があります。There are several advantages associated with avoiding RLS:

  • クエリのパフォーマンスが向上する: フィルターが減るため、パフォーマンスが向上する可能性があります。Improved query performance: It can result in improved performance due to fewer filters.
  • モデルが小さくなる: モデルの数は多くなりますが、サイズは小さくなります。Smaller models: While it results in more models, they are smaller in size. モデルが小さいと、クエリとデータ更新の応答性が向上します。ホスティングのための容量によってリソースに負荷がかかっている場合は特にそうです。Smaller models can improve query and data refresh responsiveness, especially if the hosting capacity experiences pressure on resources. また、容量によって課せられるサイズ制限よりモデルのサイズを小さくしておくのも簡単です。Also, it's easier to keep model sizes beneath size limits imposed by your capacity. 最後に、異なる容量にワークスペースを作成したり、ワークスペースを移動したりできるため、異なる容量間でワークロードのバランスを取るのが簡単になります。Lastly, it's easier to balance workloads across different capacities, because you can create workspaces on—or move workspaces to—different capacities.
  • 機能が増える: Web への発行のような、RLS では動かない Power BI の機能を使用できます。Additional features: Power BI features that don't work with RLS, like Publish to web, can be used.

ただし、RLS を避けると短所もあります。However, there are disadvantages associated with avoiding RLS:

  • ワークスペースが複数になる: レポート対象ユーザーごとに 1 つのワークスペースが必要です。Multiple workspaces: One workspace is required for each report user audience. アプリが公開される場合は、レポート対象ユーザーごとに 1 つのアプリがあることも意味します。If apps are published, it also means there's one app per report user audience.
  • 内容が重複する: ワークスペースごとにレポートとダッシュボードを作成する必要があります。Duplication of content: Reports and dashboards must be created in each workspace. そのため、設定と保守に追加の作業と時間が必要です。It requires additional effort and time to set up and maintain.
  • 高い特権を持つユーザー: 複数のレポート対象ユーザーに属する高い特権を持つユーザーは、データの統合ビューを表示できません。High privilege users: High privilege users, who belong to multiple report user audiences, can't see a consolidated view of the data. 複数のレポートを開く必要があります (別のワークスペースまたはアプリから)。They'll need to open multiple reports (from different workspaces or apps).

RLS のトラブルシューティングTroubleshoot RLS

RLS で予期しない結果が発生する場合は、次の問題を調べます。If RLS produces unexpected results, check for the following issues:

  • モデル テーブルの間に、列マッピングとフィルターの方向に関して正しくないリレーションシップが存在します。Incorrect relationships exist between model tables, in terms of column mappings and filter directions.
  • [両方向にセキュリティ フィルターを適用する] リレーションシップ プロパティが、正しく設定されていません。The Apply security filter in both directions relationship property isn't correctly set. 詳細については、「双方向のリレーションシップのガイダンス」をご覧ください。For more information, see Bi-directional relationship guidance.
  • テーブルにデータが含まれていません。Tables contain no data.
  • テーブルに無効な値が読み込まれています。Incorrect values are loaded into tables.
  • ユーザーが複数のロールにマップされています。The user is mapped to multiple roles.
  • モデルに集計テーブルが含まれており、集計と詳細で RLS ルールによるフィルター処理が一致していません。The model includes aggregation tables, and RLS rules don't consistently filter aggregations and details. 詳細については、「Power BI Desktop で集計を使用する」の「集計の RLS」を参照してください。For more information, see Use aggregations in Power BI Desktop (RLS for aggregations).

特定のユーザーがデータを表示できない場合、UPN が格納されていないか、正しく入力されていない可能性があります。When a specific user can't see any data, it could be because their UPN isn't stored or it's entered incorrectly. 名前の変更の結果としてユーザー アカウントが変更されたため、突然発生する可能性があります。It can happen abruptly because their user account has changed as the result of a name change.

ヒント

テストするには、USERNAME DAX 関数を返すメジャーを追加します。For testing purposes, add a measure that returns the USERNAME DAX function. "Who Am I" のような名前を指定します。You might name it something like "Who Am I". 次に、レポートのカード視覚化にメジャーを追加し、Power BI に発行します。Then, add the measure to a card visual in a report and publish it to Power BI.

特定のユーザーがすべてのデータを表示できる場合は、ワークスペース内のレポートに直接アクセスしていて、データセットの所有者である可能性があります。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. RLS は、次の場合にのみ適用されます。RLS is only enforced when:

  • レポートがアプリで開かれています。The report is opened in an app.
  • レポートがワークスペースで開かれ、ユーザーがビューアー ロールにマップされています。The report is opened in a workspace, and the user is mapped to the Viewer role.

次の手順Next steps

この記事に関する詳細については、次のリソースを参照してください。For more information related to this article, check out the following resources: