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 の値を返します。 DAX フィルターは、各行に対して TRUE/FALSE を評価します。 TRUE を返す行のみが表示されます。それ以外はすべて完全に削除されます。

   注

   デフォルトのエディターを使って、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()
  

• USERNAME ΓÇö を使用した動的 RLS では、ユーザーのドメインとユーザー名に基づいてデータが制限されます。

  [UserDomain] = USERNAME()
  

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

  [AppRole] = CUSTOMDATA()
  

  注

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

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

例: 地域別の売上データのフィルター処理

列Sales、Region、およびProductを含むAmount テーブルがあるとします。 "West" ロールに割り当てられているユーザーを制限して、リージョンが "West" の行のみを表示するようにする必要があります。

"West" ロールの DAX フィルター フィールドに、次の式を入力します。

[Region] = "West"

フィルター処理の前 (すべてのデータ):

フィルター処理後 ("West" ロール ユーザーの表示):

DAX 式は、テーブル内の各行を評価する行フィルターとして機能します。 Region列が "West" と等しい行のみが、そのロールに割り当てられているユーザーに表示されます。

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

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

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

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

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

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

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

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

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

   

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

   

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

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

メンバーの追加

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

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

• 配布グループ
• メールが有効なグループ
• Microsoft Entra セキュリティ グループ ΓÇö セキュリティ グループに外部 B2B ゲスト ユーザーが含まれている場合は、「外部 (B2B ゲスト) ユーザーの既知の制限事項」を参照してください。

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

メンバーの削除

メンバーを削除するには、メンバー名の横の [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 に関する次の考慮事項に注意してください。

外部メンバーを含む Entra セキュリティ グループ

外部 B2B ゲスト ユーザーを含むセキュリティ グループMicrosoft Entra、RLS ロール メンバーシップに使用すると、期待どおりに動作しない可能性があります。 一部の構成 (特に外部ユーザーが (メンバー型アカウントではなく) ゲストタイプのアカウントを持っている場合)、RLS フィルターを適用するときにゲストのグループ メンバーシップがPower BI サービスによって正しく評価されない場合があります。

推奨される回避策: Entra セキュリティ グループを使用して外部ユーザーを RLS ロールに追加する代わりに、メール アドレスで直接ロールに追加します。 電子メール アドレスは、ユーザーの B2B アカウントに紐付けられます。 これにより、RLS フィルターが適用されるときに ID が正しく一致することが保証されます。 詳細については、「 ロール メンバーシップの管理」を参照してください。

外部ユーザーが多い組織の場合は、グループベースのロール メンバーシップではなく、 USERPRINCIPALNAME() で動的 RLS を使用することを検討してください。 この方法では、各ユーザーの ID を個別に評価し、グループ メンバーシップ解決の問題を完全に回避します。

外部ユーザーとコンテンツを共有する方法の詳細については、「Distribute Microsoft Entra B2B を使用して外部ゲスト ユーザーにコンテンツをPower BIする」を参照してください。

回避策を適用した後も問題が解決しない場合は、「 トラブルシューティング: 外部ゲストにデータが表示されない 」を参照して、追加の診断手順を確認してください。

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 ゲスト ユーザーの場合、この関数は通常、ドメイン\ユーザー名形式ではなく構成 ( user@partner.com など) に応じて、USERPRINCIPALNAME() のような UPN のような識別子を返します。 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 が使用されます。 常に、実際の外部ゲスト アカウントを使用して検証します。
6. ロールの割り当てを確認 する — ゲスト ユーザーに予想以上 の データが表示される場合は、RLS ロールに割り当てられていることを確認します。 RLS ロールに割り当てられていないユーザーには、RLS は適用されますが、一致するロールは適用されないため、通常、データは表示されません (空の結果)。 DAX フィルターは、各行に対して TRUE/FALSE を評価します。 TRUE を返す行のみが表示されます。 それ以外はすべて完全に削除されます。

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 モデルでは機能しません。
• [ロールとしてテスト] 機能と [ロールとしての表示] 機能は、セマンティック モデル ワークスペースからのレポートのみを表示します。
• [ロールとしてテスト]/[ロールとして表示] 機能は、改ページ対応レポートでは機能しません。
• トークンベース ID が動作するのは、Microsoft Entra 認証を許可するように構成された Azure SQL Database に接続されている容量上の DirectQuery モデルに対してのみです。 詳細については、「トークンベースの ID を使用したレポートの埋め込み」を参照してください。
• "IdentityBlob" パラメーターは、Azure SQLの OAuth 2.0 アクセス トークンであり、Azure SQLへの DirectQuery 接続を持つデータセットでのみサポートされます。 メカニズム自体は Azure SQL 固有です: その blob はhttps://database.windows.net/.default をスコープとする Microsoft Entra アクセス トークンです。 アプリ所有データ埋め込みでは、他のデータ ソースに対して同等のトークン渡しメカニズムはありません。 詳細については、 GenerateToken の REST API リファレンスを参照してください。

動的 RLS に関する考慮事項と制限事項

USERPRINCIPALNAME()、USERNAME()、CUSTOMDATA()などの DAX 関数で動的行レベル セキュリティ (RLS) を使用する場合は、次の考慮事項に注意してください。

B2B テナント間シナリオ

B2B シナリオでは、USERPRINCIPALNAME() は、Power BI サービスによって解決された ID を返します。これはテナントの構成によって異なる場合があります。 次のように表示できます。

• 外部ユーザーの電子メール アドレス (user@partner.com)、または
• テナント解決値 (user_partner.com#EXT#@tenant.onmicrosoft.com など)

正確な形式は保証されていないため、環境内で検証する必要があります。

ユーザー マッピング テーブルに、ゲスト ユーザーに対して返される USERPRINCIPALNAME() とは異なる形式の識別子が格納されている場合、RLS フィルター式は一致せず、ゲストにはデータや正しくないデータが表示されません。 環境内の外部ユーザーの USERPRINCIPALNAME() によって返される正確な値を常に確認します。

動的 RLS を使用してロールの制限としてテストする

Power BI サービスの ロールとしてのテスト 機能は、動的 RLS 式を評価するときに独自の ID を使用します。 つまり、USERPRINCIPALNAME() は、シミュレートしようとしているユーザーの UPN ではなく、あなたの UPN を返すということです。 ロールとしてテストを使用して、特定の B2B ゲスト ユーザーまたはサービス プリンシパルに表示される内容を確認することはできません。

ロールとしてテスト ではロールへの所属はシミュレートされますが、特に B2B ゲストや埋め込みシナリオでは、別のユーザーの認証コンテキストを完全には再現できません。

外部ユーザーの動的 RLS を検証するには、実際のゲスト ユーザーとしてサインインし、レポートを直接表示します。 これは、 USERPRINCIPALNAME() が期待される値を返し、RLS フィルターがそのユーザーに対して正しく一致することを確認する唯一の方法です。

サービス プリンシパルを使用した埋め込みシナリオ

レポートが、サービス プリンシパルで認証する埋め込みアプリケーションを通じてアクセスされた場合、USERPRINCIPALNAME() と USERNAME() は、エンド ユーザーの ID ではなく、サービス プリンシパルのアプリケーション ID または空の文字列を返します。

これらの関数ではエンド ユーザー ID が返されないため、サービス プリンシパル埋め込みシナリオでのユーザーごとのフィルター処理には使用できません。 つまり、これらの関数に基づく動的 RLS フィルターは、埋め込みシナリオではユーザーごとのデータをフィルター処理しません。

埋め込みシナリオでユーザーごとの RLS を適用するには、Power BI REST API の effective identity 機能を使用します。 埋め込みトークンを生成するときに、適切なユーザー名とロールを持つ EffectiveIdentity オブジェクトを渡します。 RLS ルールで CUSTOMDATA()を使用する場合は、 EffectiveIdentity.CustomDataを介してカスタム データ文字列を渡します。

詳細については、 ISV の埋め込みシナリオの RLS を参照してください。

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 を改善するためのアイデアをお寄せください