Power BI での行レベルのセキュリティ (RLS)

行レベル セキュリティ (RLS) は、特定のユーザーのデータ アクセスを制限します。 フィルターは行レベルでデータを制限し、ロール内でフィルターを定義します。 Power BI サービスでは、ワークスペースにアクセスできるユーザーがそのワークスペース内のセマンティック モデルにアクセスすることができます。 RLS では、ビューアーのアクセス許可を持つユーザーのデータ アクセスのみが制限されます。 管理者、メンバー、共同作成者には適用されません。

RLS を実装するには、次の高度なワークフローに従います。

1. DAX フィルター式を使用してPower BI Desktop でロールとルールを定義します。
2. Publishセマンティック モデルをPower BI サービスに報告します。
3. メンバーをPower BI サービスのロールに追加します。
4. ロールとしてテスト機能を使用して検証し、データ フィルター処理が期待どおりに動作することを確認します。

インポートされたセマンティック モデルの RLS は、Power BI Desktop またはPower BI サービスで構成できます。 SQL Server などの DirectQuery を使用しているセマンティック モデルに RLS を構成することもできます。 Analysis Services または Azure Analysis Services のライブ接続では、Power BI ではなく、モデルに行レベル セキュリティを構成します。 このセキュリティ オプションは、ライブ接続セマンティック モデルには表示されません。

Power BI Desktop 内でロールとルールを定義する

Power BI Desktop 内でロールとルールを定義できます。 このエディターでは、デフォルトのドロップダウン インターフェイスと DAX インターフェイスの使用を切り替えることができます。 Power BI に発行すると、ロールの定義も発行されます。

セキュリティ ロールを定義するには:

1. Power BI Desktop レポートにデータをインポートするか、DirectQuery 接続を構成します。

   注

   Analysis Services ライブ接続の場合、Power BI Desktop 内でロールを定義することはできません。 Analysis Services モデル内で定義する必要があります。

2. [モデリング] タブ で 、[ ロールの管理] を選択します。

3. [ロールの管理] ウィンドウで、[新規] を選択して新しいロールを作成します。

4. [ロール] でロールの名前を指定し、Enter キーを選択します。

   注

   たとえば、London,ParisRole のように、コンマを使ってロールを定義することはできません。

5. [テーブルの選択] で、行レベルのセキュリティ フィルターを適用するテーブルを選びます。

6. [データのフィルター選択] で、デフォルトのエディターを使ってロールを定義します。 作成された式は、true または false の値を返します。

   注

   デフォルトのエディターを使って、Power BI でサポートされているすべての行レベルのセキュリティ フィルターを定義できるわけではありません。 制限事項には、username () や userprincipalname() などの動的ルールを含む DAX を使用してのみ定義できる式が含まれます。 これらのフィルターを使ってロールを定義するには、DAX エディターを使用するように切り替えてください。

7. 必要に応じて、[ DAX エディターに切り替える ] を選択して、DAX エディターを使用してロールを定義するように切り替えます。 DAX 式は true または false の値を返します。 (例: [Entity ID] = “Value”)。 DAX エディターには、数式のオートコンプリート (Intellisense) が含まれています。 式ボックスの上にあるチェックマークを選択して式を検証し、式ボックスの上にある [X] ボタンをクリックして変更を元に戻すことができます。

   注

   この式では username() を 使用できます。 username() には Power BI Desktop 内の DOMAIN\username の形式があることに注意してください。 Power BI サービスと Power BI Report Server 内では、それはユーザーのユーザー プリンシパル名 (UPN) の形式になります。 さらに、この式ボックスでは、通常はセミコロン区切り文字を使用するロケール (フランス語やドイツ語など) を使用している場合でも、DAX 関数の引数をコンマで区切ります。

8. デフォルトのエディターに戻すには、[デフォルトのエディターに切り替え] を選択します。 いずれかのエディター インターフェイスで行ったすべての変更は、可能であればインターフェイスを切り替えても保持されます。 既定のエディターで定義できない DAX エディターを使用してロールを定義すると、既定のエディターに切り替えようとすると、エディターを切り替えると一部の情報が失われる可能性があることを示す警告が表示されます。 この情報を保持するには、[キャンセル] を選択し、DAX エディターのみでこのロールを編集し続けるようにします。

   注

   この式ボックスでは、通常はセミコロン区切り文字を使用するロケール (フランス語やドイツ語など) を使用している場合でも、DAX 関数の引数をコンマで区切ります。

9. [保存] を選択します。

Power BI Desktop 内でロールにユーザーを割り当てることはできません。 その割り当ては、Power BI サービスで行います。 power BI Desktop 内で動的セキュリティを有効にするには、 username() または userprincipalname() DAX 関数を使用し、適切なリレーションシップを構成します。

一般的な DAX フィルター パターン

次の例は、RLS ロールを定義するときに使用できる一般的な DAX フィルター式を示しています。

• 静的 RLS — データを固定値に制限します。

  [Region] = "West"
  

• UPN を使用した動的 RLS — サインインしているユーザーの電子メール アドレスに基づいてデータを制限します。

  [UserEmail] = USERPRINCIPALNAME()
  

• ユーザー名を持つ動的 RLS — ユーザーのドメインとユーザー名に基づいてデータを制限します。

  [UserDomain] = USERNAME()
  

• CUSTOMDATA を使用した動的 RLS — 埋め込みアプリケーションから渡されるカスタム文字列に基づいてデータを制限します。

  [AppRole] = CUSTOMDATA()
  

  注

  CUSTOMDATA() は、主に、アプリケーションが Power BI REST API を介してカスタムの有効な ID 文字列を渡す埋め込みシナリオで使用されます。

動的 RLS は最も一般的な方法です。これは、データ モデル内のユーザー マッピング テーブルに基づいて、1 つのロール定義でユーザーごとに異なる方法でデータをフィルター処理できるためです。

双方向のクロスフィルター処理

デフォルトでは、リレーションシップが一方向と双方向のいずれに設定されているかに関係なく、行レベルのセキュリティ フィルターで一方向のフィルターが使用されます。

行レベルのセキュリティで双方向のクロス フィルターを手動で有効にすることができます。その場合は、リレーションシップを選択して、 [両方向にセキュリティ フィルターを適用する] チェック ボックスをオンにします。 サーバー レベルで、動的な行レベルのセキュリティも実装した場合 (行レベルのセキュリティはユーザー名またはログイン ID に基づく) は、このオプションをオンにします。 テーブルが複数の双方向リレーションシップに含まれる場合、これらのリレーションシップの 1 つに対してのみこのオプションを選択できます。

詳細については、「Power BI での DirectQuery を使用する双方向のクロス フィルタリング」と「表形式の BI セマンティック モデルの保護」の技術記事を参照してください。

モデルのセキュリティの管理

セマンティック モデルのセキュリティを管理するには、Fabric でセマンティック モデルを保存したワークスペースを開き、次の手順を実行します。

1. Fabric で、セマンティック モデルの [その他のオプション ] メニューを選択します。 セマンティック モデル名をポイントすると、このメニューが表示されます。

   

2. [セキュリティ] を選択します。

   

[セキュリティ] を選択すると、移動先のロール レベルのセキュリティ ページで、作成したロールにメンバーを追加できます。 共同作成者以上のワークスペース ロールを持つユーザーには、[セキュリティ] オプションが表示され、ユーザーをロールに割り当てることができます。 シナリオによっては、セマンティック モデルの所有権またはビルドアクセス許可も必要になる場合があります。

ロール メンバーシップを管理する

メンバーの追加

Power BI サービスでは、ユーザーまたはセキュリティ グループのメール アドレスまたは名前を入力することにより、ロールにメンバーを追加できます。 Power BI で作成されたグループを追加することはできません。 組織外部のメンバーを追加できます。 RLS が外部 B2B ゲスト ユーザーと連携する方法のガイダンスについては、「 外部 (B2B ゲスト) ユーザーの考慮事項」を参照してください。

次のグループを使用して、行レベル セキュリティを設定できます。

• 配布グループ
• メールが有効なグループ
• Microsoft Entra セキュリティ グループ

ロールの一部であるメンバーの数は、ロール名の横または [メンバー] の横にあるかっこ内の番号で確認できます。

メンバーの削除

メンバーを削除するには、メンバー名の横の [X] を選択します。

Power BI サービス内でのロールの検証

ロールをテストすることで、定義したロールがPower BI サービスで正しく動作することを検証できます。

1. ロールの横にあるその他のオプション (...) を選択します。
2. テストとしての役割を選択してください。

レポートが読み込まれたら、次のことを確認します。

• レポートには、ロールで定義されているフィルター式に一致するデータ行のみが表示されます。
• ビジュアル、テーブル、グラフには、完全なデータセットではなく、フィルター処理されたデータが反映されます。
• 動的 RLS を使用する場合、データは、 ヘッダーとして表示される [今すぐ表示 ] に表示される ID に対応します。

ページ ヘッダーには、適用されているロールが表示されます。 次の表示として を選択することで、他の役割や役割の組み合わせ、または特定の人物をテストできます。 ここで、テスト対象の個人またはロールに関連する重要なアクセス許可の詳細を確認できます。 アクセス許可が RLS とどのように連携するかの詳細については、「RLS ユーザー エクスペリエンス」を参照してください。

ページ ヘッダーで [表示] を選択して、セマンティック モデルに接続されている他のレポートをテストします。 テストできるのは、セマンティック モデルと同じワークスペースにあるレポートのみです。

通常の表示に戻るには、 [行レベルのセキュリティに戻る] を選択します。

username() または userprincipalname() DAX 関数の使用

データセット内で DAX 関数 username() または userprincipalname() を利用できます。 Power BI Desktop の式の中で使用することができます。 モデルを発行するときに、Power BI サービス内で使用されます。

Power BI Desktop 内で、username() は DOMAIN\User の形式でユーザーを返し、userprincipalname() は user@contoso.com の形式でユーザーを返します。

Power BI サービス内で、username() と userprincipalname() は両方とも、ユーザーのユーザー プリンシパル名 (UPN) を返します。 これはメール アドレスに似ています。

Power BI での RLS とワークスペースの使用

Power BI Desktop のレポートを Power BI サービスのワークスペースに発行する場合、そのワークスペースで閲覧者ロールに割り当てられているメンバーに、RLS のロールが適用されます。 閲覧者にセマンティック モデルのビルド アクセス許可が与えられている場合でも、RLS が適用されます。 たとえば、ビルド アクセス許可が与えられているビューアーが [Excel で分析] を使用する場合、データの表示は RLS によって制限されます。 管理者、メンバー、または共同作成者に割り当てられたワークスペース メンバーにはセマンティック モデルの編集アクセス許可があるため、RLS は適用されません。 RLS をワークスペース内のユーザーに適用する場合は、そのユーザーに閲覧者ロールのみを割り当てることができます。 詳細については、ワークスペースでのロールに関する記事を参照してください。

外部 (B2B ゲスト) ユーザーに関する考慮事項

Microsoft Entra B2B を介して外部ユーザーとPower BIコンテンツを共有する場合は、RLS がゲスト ユーザー ID とどのように対話するかを理解することが重要です。

B2BゲストのためのUPN解決

外部 B2B ゲスト ユーザーがPower BI レポートにアクセスすると、通常、USERPRINCIPALNAME() DAX 関数は電子メールのような識別子 (たとえば、user@partner.com) を返します。 一部の構成では、 #EXT# 形式 ( user_partner.com#EXT#@yourtenant.onmicrosoft.com など) でゲスト UPN が返されることがあります。

この区別は、動的 RLS にとって重要です。 ユーザー マッピング テーブルに、 USERPRINCIPALNAME() が返す形式とは異なる識別子の形式が格納されている場合、フィルター式が一致せず、ゲスト ユーザーにデータや正しくないデータが表示されない可能性があります。

B2B ゲストの USERNAME() 動作

USERNAME() DAX 関数は、ユーザーの domain\username 識別子を返します。 B2B ゲスト ユーザーの場合、この関数は通常、ドメイン\ユーザー名形式ではなく、ゲストのホーム テナント UPN (たとえば、 user@partner.com) を返します。 USERNAME()とUSERPRINCIPALNAME()は B2B ゲストに対して同じ値を返すことが多いため、ほとんどの実装では一貫性のためにUSERPRINCIPALNAME()を使用します。

[UserEmail] = USERPRINCIPALNAME()

UserEmail列には、内部ユーザーと外部ユーザーの両方のuser@partner.comなどの電子メール アドレスが含まれています。

トラブルシューティング: 外部ゲストにデータが表示されない

B2B ゲスト ユーザーに空のレポートが表示されたり、"データなし" メッセージが表示された場合は、次の手順に従います。

1. 返された UPN 形式を確認 する - USERPRINCIPALNAME() を使用してテスト メジャーを作成し、カード ビジュアルに表示します。 ゲスト ユーザーにレポートを表示して、返された実際の値を確認させます。
2. ユーザー マッピング テーブルを確認 する - マッピング テーブルに、そのゲストに対して返される USERPRINCIPALNAME() と正確に一致する値を持つ行が含まれていることを確認します。
3. 大文字と小文字の区別を確認する - DAX 文字列比較では既定では大文字と小文字が区別されませんが、データ ソースで大文字と小文字が区別される値が導入されていないことを確認します。
4. テナント間アクセス設定の確認 - 組織が cross-tenant アクセス ポリシー を使用している場合、Power BIに表示される UPN 形式に影響する可能性があります。
5. 実際のゲスト ユーザーによるテスト - ロールとしてのテスト 機能では、独自の ID が使用されます。 常に、実際の外部ゲスト アカウントを使用して検証します。 Power BI コンテンツを外部ユーザーと共有する方法の詳細については、「Distribute Power BI コンテンツを、Microsoft Entra B2B を使用して外部ゲスト ユーザーに提供する方法に関するページを参照してください。

考慮事項と制限事項

クラウド モデルの行レベル セキュリティにおける現在の制限事項を次に示します。

• Power BI サービスでロールおよびルールを以前に定義している場合、Power BI Desktop 内で再作成する必要があります。
• RLS は、Power BI Desktop を使用して作成されたセマンティック モデルにのみ定義できます。 Excel で作成されたセマンティック モデルに対して RLS を有効にするには、最初にファイルを Power BI Desktop (PBIX) ファイルに変換する必要があります。 詳細情報。
• サービス プリンシパルを RLS ロールに追加することはできません。 そのため、RLS は、サービス プリンシパルを最終的で有効な ID として使うアプリには適用されません。
• Import と DirectQuery 接続のみサポートされます。 Analysis Services へのライブ接続は、オンプレミス モデルで処理されます。
• RLS を有効にすると、DAX クエリとメジャーで USERELATIONSHIP() 関数を使用すると、予期しないエラーが発生する可能性があります。 この問題を回避するには、USERELATIONSHIP() を回避するように DAX 式を再設計し、代わりにモデル レベルのリレーションシップやその他の DAX パターンを使用します。
• [ロールとしてテスト] と [ロールとして表示] 機能は、シングル サインオン (SSO) が有効になっている DirectQuery モデルでは機能しません。
• [ロールとしてテスト] 機能と [ロールとしての表示] 機能は、セマンティック モデル ワークスペースからのレポートのみを表示します。
• [ロールとしてテスト]/[ロールとして表示] 機能は、改ページ対応レポートでは機能しません。

Power BI レポートで RLS が構成された行を参照する場合、削除されたか存在しないフィールドの場合と同じメッセージが表示されることに注意してください。 このようなユーザーにとっては、レポートが壊れているように見えます。

FAQ

質問: 以前に、Power BI サービスでデータセットのロールおよびルールを作成している場合はどうなりますか? 何もしなくてもそれらは動作しますか?
回答: いいえ。視覚エフェクトは正しくレンダリングされません。 Power BI Desktop 内でロールおよびルールを再作成し、Power BI サービスに発行する必要があります。

質問: Analysis Services データ ソースにこれらのロールを作成できますか。
回答: Power BI Desktop にデータをインポートした場合はできます。 ライブ接続を使用している場合、Power BI サービス内で RLS を構成することはできません。 RLS は、オンプレミスの Analysis Services モデルで定義します。

質問: RLS を使って、ユーザーがアクセスできる列またはメジャーを制限できますか。
回答: いいえ。ユーザーは、特定のデータ行にアクセスできる場合は、その行のすべてのデータ列を見ることができます。 列および列のメタデータへのアクセスを制限するには、オブジェクト レベルのセキュリティの使用をご検討ください。

質問: RLS を使って、詳細なデータは表示されないようにしながら、ビジュアルの集計データにはアクセスできるようにすることができますか。
回答: いいえ。個々のデータ行は保護されますが、ユーザーは常に詳細データまたは集計データを見ることができます。

質問: データ ソースにセキュリティ ロールが既に定義されています (SQL Server のロールや SAP BW のロールなど)。 これらのロールと RLS の関係はどのようなものですか?
回答: 答えは、データをインポートしているか、DirectQuery を使用しているかによって変わります。 Power BI データセットにデータをインポートしている場合、データ ソースのセキュリティ ロールは使用されません。 この場合、Power BI でつながるユーザーにセキュリティ規則を適用するには、RLS を定義する必要があります。 DirectQuery を使用している場合、データ ソースのセキュリティ ロールが使用されます。 ユーザーがレポートを開くと、Power BI から基礎データ ソースにクエリが送信され、ユーザーの資格情報に基づいてデータにセキュリティ規則が適用されます。

質問: ユーザーは複数のロールに属することができますか?
回答: ユーザーは複数のロールに属することができ、ロールは追加式です。 たとえば、ユーザーが "Sales" ロールと "Marketing" の両方のロールに属している場合、これらの両方のロールのデータを表示できます。

関連するコンテンツ

• Power BI Desktop の行レベルのセキュリティを使用してデータ アクセスを制限する
• Power BI 実装計画: レポート コンシューマーのセキュリティ計画
• ISV 向けの RLS for Embedded シナリオ
• Microsoft Entra B2B を使用して、Power BI コンテンツを外部ゲストユーザーに配布する

質問？ Power BI コミュニティで質問してみてください。ご提案の場合は、 Power BI を改善するためのアイデアをお寄せください