Power BI Desktop での行レベルのセキュリティ (RLS) のガイダンス
この記事は、Power BI Desktop を操作するデータ モデラーを対象としています。 データ モデルで行レベルのセキュリティ (RLS) を適用するための適切な設計方法について説明します。
RLS では "テーブルの行" のフィルター処理が行われるということを理解しておくことが重要です。 テーブル、列、メジャーなどのモデル オブジェクトへのアクセスを制限するように構成することはできません。
注意
この記事では、RLS について、またはそれを設定する方法については説明しません。 詳細については、「Power BI Desktop の行レベルのセキュリティを使用してデータ アクセスを制限する」を参照してください。
また、Azure Analysis Services または SQL Server Analysis Services によって外部でホストされているモデルへのライブ接続での RLS の適用についても説明しません。 これらの場合には、RLS は Analysis Services によって適用されます。 Power BI がシングル サインオン (SSO) を使用して接続しているときは、Analysis Services によって RLS が適用されます (アカウントに管理者特権がない場合)。
ロールを作成する
複数のロールを作成することができます。 1 人のレポート ユーザーに必要なアクセス許可を検討する場合は、レポート ユーザーが複数のロールのメンバーになるように設計するのではなく、できる限りすべてのアクセス許可を付与する 1 つのロールを作成するようにします。 これは、レポート ユーザーは、ユーザー アカウントを使用して直接、またはセキュリティ グループのメンバーシップによって間接的に、複数のロールにマップする可能性があるためです。 複数のロールにマッピングすると、予期しない結果になる可能性があります。
レポート ユーザーが複数のロールに割り当てられていると、RLS フィルターは加法的になります。 つまり、レポート ユーザーは、それらのフィルターの和集合を表すテーブル行を見ることができます。 さらに、場合によっては、レポート ユーザーにテーブルの行が表示されないことを保証することができません。 したがって、SQL Server のデータベース オブジェクトに適用されるアクセス許可 (およびその他のアクセス許可モデル) とは異なり、"一度拒否したら常に拒否する" の原則は適用されません。
2 つのロールを持つモデルを考えてみます。Workers という名前の 1 つ目のロールでは、次のルール式を使用して、Payroll テーブルのすべての行に対するアクセスが制限されます。
FALSE()
注意
式が FALSE と評価されると、ルールからテーブル行は返されません。
一方、Managers という名前の 2 つ目のロールでは、次のルール式を使用して、Payroll テーブルのすべての行に対するアクセスが許可されます。
TRUE()
注意してください。レポート ユーザーが両方のロールにマップされると、Payroll テーブルのすべての行が表示されるようになります。
RLS を最適化する
RLS は、すべての DAX クエリにフィルターを自動的に適用することによって機能します。これらのフィルターは、クエリのパフォーマンスに悪影響を及ぼす可能性があります。 したがって、RLS が効率的であれば、適切なモデル設計になります。 次の記事で説明されているように、モデルの設計ガイダンスに従うことが重要です。
- Power BI のスター スキーマおよび重要性について
- 「Power BI ガイダンスのドキュメント」に記載されているすべてのリレーションシップ ガイダンスの記事
通常、ファクト型テーブルではなく、ディメンション型テーブルに RLS フィルターを適用する方が効率的です。 また、RLS フィルターが他のモデル テーブルに確実に反映されるためには、リレーションシップが適切に設計されている必要があります。 RLS フィルターは、アクティブなリレーションシップを介してのみ伝達されます。 そのため、モデルのリレーションシップで同じ結果になる可能性がある場合は、LOOKUPVALUE DAX 関数を使用しないようにします。
DirectQuery テーブルに対して RLS フィルターが適用されていて、他の DirectQuery テーブルに対するリレーションシップがある場合は常に、ソース データベースを最適化します。 それには、適切なインデックスの設計や、保存される計算列の使用が含まれる場合があります。 詳細については、「Power BI Desktop の DirectQuery モデルのガイダンス」を参照してください。
RLS の影響を測定する
パフォーマンス アナライザーを使用することにより、Power BI Desktop での RLS フィルターのパフォーマンスへの影響を測定できます。 まず、RLS が適用されていない状態で、レポートの視覚化クエリの時間を確認します。 次に、 [モデリング] リボン タブの [表示方法] コマンドを使用して RLS を適用し、クエリの時間を確認して比較します。
ロールのマッピングを構成する
Power BI に発行したら、メンバーをセマンティック モデル ロールにマップする必要があります。 メンバーをロールに追加できるのは、セマンティック モデル所有者またはワークスペース管理者だけです。 詳細については、「Power BI での行レベルのセキュリティ (RLS)」の「モデルのセキュリティの管理」を参照してください。
メンバーには、ユーザー アカウント、セキュリティ グループ、配布グループ、またはメールが有効なグループがなることができます。 可能な限り、セキュリティ グループをセマンティック モデルのロールにマップすることをお勧めします。 これには、Microsoft Entra ID のセキュリティ グループ メンバーシップの管理が含まれます。 場合によっては、タスクをネットワーク管理者に委任します。
ロールを検証する
各ロールをテストして、モデルが正しくフィルター処理されることを確認します。 これは、 [モデリング] リボン タブの [表示方法] コマンドを使用して簡単に行うことができます。
モデルに USERNAME DAX 関数を使用する動的なルールがある場合は、予期される値 "および予期されない" 値について必ずテストします。 Power BI コンテンツを埋め込む場合 (具体的には「顧客向けに埋め込む」のシナリオを使用)、アプリのロジックで任意の値を有効な ID ユーザー名として渡すことができます。 可能な場合は常に、誤った値や悪意のある値に対しては行が返されないフィルターになるようにします。
Power BI Embedded を使用する例を考えます。アプリでは、ユーザーのジョブ ロールを有効なユーザー名として渡します: "Manager" または "Worker" のいずれかです。 マネージャーはすべての行を表示できますが、ワーカーは Type 列の値が "Internal" である行しか表示できません。
次のルール式が定義されています。
IF(
USERNAME() = "Worker",
[Type] = "Internal",
TRUE()
)
このルール式の問題点は、"Worker" を除くすべての値に対して "すべてのテーブル行" が返されることです。 そのため、誤って "Wrker" などの値を指定すると、すべてのテーブル行が誤って返されます。 したがって、予想される値ごとにテストする式を記述する方が安全です。 次の改善されたルール式では、予期しない値に対してはテーブルから行が返されません。
IF(
USERNAME() = "Worker",
[Type] = "Internal",
IF(
USERNAME() = "Manager",
TRUE(),
FALSE()
)
)
部分的な RLS を設計する
場合によっては、RLS フィルターによって制約されない値が計算で必要になることがあります。 たとえば、レポートで、"全収益" に対するレポート ユーザーの販売地域での収益の比率を表示することが必要な場合があります。
DAX 式で RLS をオーバーライドすることはできませんが (実際、RLS が適用されているかどうかを判断することさえできません)、概要モデル テーブルを使用できます。 "すべての地域" の収益を取得するには、概要モデル テーブルのクエリを行い、RLS フィルターでは制約されません。
この設計要件を実装する方法を見てみましょう。 まず、次のようなモデル設計を考えます。
モデルは、次の 4 つのテーブルで構成されます。
- Salesperson テーブルには、営業担当者ごとに 1 つの行が格納されます。 EmailAddress 列には、各営業担当者のメール アドレスが格納されます。 このテーブルは非表示です。
- Sales テーブルには、注文ごとに 1 つの行が格納されます。 それには Revenue % All Region メジャーが含まれており、全地域の収益に対するレポート ユーザーの地域の収益の比率を返すように設計されています。
- Date テーブルには、日付ごとに 1 つの行が格納され、年と月でのフィルター処理とグループ化が可能です。
- SalesRevenueSummary は計算テーブルです。 注文日ごとの合計収益が格納されます。 このテーブルは非表示です。
次の式では、SalesRevenueSummary 計算テーブルが定義されています。
SalesRevenueSummary =
SUMMARIZECOLUMNS(
Sales[OrderDate],
"RevenueAllRegion", SUM(Sales[Revenue])
)
注意
集計テーブルでも、同じ設計要件を実現できます。
Salesperson テーブルには、次の RLS ルールが適用されます。
[EmailAddress] = USERNAME()
次の表では、3 つのモデル リレーションシップについて説明します。
| リレーションシップ | Description |
|---|---|
 |
Salesperson テーブルと Sales テーブルの間には、多対多のリレーションシップがあります。 RLS ルールにより、USERNAME DAX 関数を使用して、非表示の Salesperson テーブルの EmailAddress 列がフィルター処理されます。 Region 列の (レポート ユーザーに対する) 値が、Sales テーブルに反映されます。 |
 |
Date テーブルと Sales テーブルの間には、一対多のリレーションシップがあります。 |
 |
Date テーブルと SalesRevenueSummary テーブルの間には、一対多のリレーションシップがあります。 |
次の式では、Revenue % All Region メジャーが定義されています。
Revenue % All Region =
DIVIDE(
SUM(Sales[Revenue]),
SUM(SalesRevenueSummary[RevenueAllRegion])
)
注意
機密性のファクトが公開されないように注意してください。 この例に地域が 2 つしかない場合、レポート ユーザーは他の地域の収益を計算することができます。
RLS の使用を避ける場合
場合によっては、RLS の使用を避けるのが理にかなっていることがあります。 静的フィルターを適用する少数の非常に単純な RLS ルールしかない場合は、代わりに複数のセマンティック モデルを公開することを検討します。 各セマンティック モデルには、同じデータ アクセス許可を持つ特定のレポート対象ユーザーのデータが含まれているため、どのセマンティック モデルにもロールは定義されていません。 そして、対象ユーザーごとに 1 つのワークスペースを作成し、ワークスペースまたはアプリにアクセス許可を割り当てます。
たとえば、販売地域が 2 つだけの会社では、"各販売地域に対する" セマンティック モデルを異なるワークスペースに公開します。 セマンティック モデルでは RLS は適用されません。 ただし、クエリ パラメーターを使用して、ソース データのフィルター処理を行います。 これにより、セマンティック モデル パラメーターの値だけが異なる同じモデルが、各ワークスペースに対して公開されます。 営業担当者には、ワークスペース (または公開されたアプリ) の 1 つのみに対するアクセス権が割り当てられます。
RLS を避けることにはいくつかの長所があります。
- クエリのパフォーマンスが向上する: フィルターが減るため、パフォーマンスが向上する可能性があります。
- モデルが小さくなる: モデルの数は多くなりますが、サイズは小さくなります。 モデルが小さいと、クエリとデータ更新の応答性が向上します。ホスティングのための容量によってリソースに負荷がかかっている場合は特にそうです。 また、容量によって課せられるサイズ制限よりモデルのサイズを小さくしておくのも簡単です。 最後に、異なる容量にワークスペースを作成したり、ワークスペースを移動したりできるため、異なる容量間でワークロードのバランスを取るのが簡単になります。
- 機能が増える:Web への発行のような、RLS では動かない Power BI の機能を使用できます。
ただし、RLS を避けると短所もあります。
- ワークスペースが複数になる: レポート対象ユーザーごとに 1 つのワークスペースが必要です。 アプリが公開される場合は、レポート対象ユーザーごとに 1 つのアプリがあることも意味します。
- 内容が重複する: ワークスペースごとにレポートとダッシュボードを作成する必要があります。 設定と保守にさらなる作業と時間が必要です。
- 高い特権を持つユーザー: 複数のレポート対象ユーザーに属する高い特権を持つユーザーは、データの統合ビューを表示できません。 複数のレポートを開く必要があります (別のワークスペースまたはアプリから)。
RLS のトラブルシューティング
RLS で予期しない結果が発生する場合は、次の問題を調べます。
- モデル テーブルの間に、列マッピングとフィルターの方向に関して正しくないリレーションシップが存在します。 RLS フィルターはアクティブなリレーションシップを介してのみ伝達されることに注意してください。
- [両方向にセキュリティ フィルターを適用する] リレーションシップ プロパティが、正しく設定されていません。 詳細については、「双方向のリレーションシップのガイダンス」をご覧ください。
- テーブルにデータが含まれていません。
- テーブルに無効な値が読み込まれています。
- ユーザーが複数のロールにマップされています。
- モデルに集計テーブルが含まれており、集計と詳細で RLS ルールによるフィルター処理が一致していません。 詳細については、「Power BI Desktop で集計を使用する」の「集計の RLS」を参照してください。
特定のユーザーがデータを表示できない場合、UPN が格納されていないか、正しく入力されていない可能性があります。 名前の変更の結果としてユーザー アカウントが変更されたため、突然発生する可能性があります。
ヒント
テストするには、USERNAME DAX 関数を返すメジャーを追加します。 "Who Am I" のような名前を指定します。 次に、レポートのカード視覚化にメジャーを追加し、Power BI に発行します。
セマンティック モデルに対して読み取り権限のみを持つ作成者とコンシューマーは、自分が閲覧を許可されているデータ (RLS ロール マッピングに基づく) のみを見ることができます。
ユーザーがワークスペースまたはアプリでレポートを閲覧するときに、セマンティック モデルのアクセス許可に応じて、RLS が適用される場合も適用されない場合もあります。 このような理由から、RLS を適用する必要があるときは、コンテンツ コンシューマーと作成者が、基になるセマンティック モデルに対する読み取りアクセス許可のみを持つようにすることが重要です。 RLS が適用されるかどうかを決定する権限ルールの詳細については、コンシューマー セキュリティ計画のレポートに関する記事を参照してください。
関連するコンテンツ
この記事に関する詳細については、次のリソースを参照してください。