Power BI の行レベルのセキュリティ: マルチテナント データ アクセス

行レベル セキュリティ (RLS) は、各ユーザーがアクセスを許可されているデータのみを参照できるようにするメカニズムです。マルチテナントまたは複数部門の環境では、RLS はオプションではありません。RLS は、管理された分析プラットフォームと、発生を待っているデータ侵害との違いです。しかし、Microsoft 独自の使用状況テレメトリによると、Power BI Premium を利用している組織のうち運用データセットに RLS を実装しているのは 30% 未満であることがわかります。

その理由は、RLS が概念的に難しいからではありません。その理由は、実装の詳細が微妙であり、テスト プロセスが手動であり、RLS と他の Power BI 機能 (DirectQuery、複合モデル、埋め込み、集計) の間の相互作用により、チームの不意を突くようなエッジ ケースが発生するためです。このガイドでは、最も単純な静的ロールから Azure Active Directory 統合による複雑な動的セキュリティまで、RLS 実装のあらゆる側面を説明します。

---

重要なポイント

• Power BI の行レベルのセキュリティは、DAX 式を使用してモデル レベルでデータをフィルターし、ユーザーがレポートやビジュアルを変更してセキュリティをバイパスできないようにします。
• 静的 RLS はフィルター値をハードコードします (小規模で安定したユーザー グループに適しています)。一方、動的 RLS は USERNAME() や USERPRINCIPALNAME() などの DAX 関数を使用して、ログインしているユーザーに基づいて動的にフィルターします。
• RLS はインポート モードと DirectQuery モードでのみ機能します --- Analysis Services へのライブ接続 (独自の RLS がある) には適用されません
• オブジェクト レベルのセキュリティ (OLS) は、テーブルまたは列全体を非表示にし、ユーザーが特定のデータの存在さえ知らないシナリオで RLS を補完します。
• RLS をテストするには、Power BI Desktop およびサービスの "表示" 機能が必要です。各ロールの明示的なテストなしで RLS が機能すると想定しないでください。
• 埋め込みシナリオ (Power BI Embedded) の RLS では、埋め込みトークンで有効な ID を渡す必要があります。これが実装エラーの一般的な原因です。
• RLS のパフォーマンスへの影響は、適切に設計されたモデルでは通常 5% 未満ですが、DAX フィルターの作成が不十分だとパフォーマンスが 50% 以上低下する可能性があります。

---

行レベルのセキュリティについて理解する

RLS の機能

RLS は、Power BI データ モデル内の 1 つ以上のテーブルに DAX フィルター式を適用します。ユーザーがレポートを開くと、Power BI は RLS ルールを評価し、ユーザーが表示する権限を持たない行をサイレントにフィルターで除外します。ユーザーには通常のレポートが表示されます。つまり、自分の範囲外のデータは表示されないだけです。

重要なことに、RLS はレポート層ではなくデータ モデル層で動作します。これは次のことを意味します:

• ユーザーは同じデータセットに対して独自のレポートを作成して RLS をバイパスすることはできません
• RLS フィルターは関係を通じて伝播します (Dim_Region のフィルターは関係を通じて Fact_Sales を自動的にフィルターします)
• DAX メジャーは RLS コンテキストを尊重します (CALCULATE、SUMX、およびその他の関数はフィルターされたサブセットで動作します)
• Excel、CSV、または PowerPoint へのエクスポートでは、ユーザーが表示を許可されているデータのみがエクスポートされます

RLS と他のセキュリティ メカニズムの比較

RLS は、ユーザーがアクセスできるデータの特定の行を制御する唯一のメカニズムです。他のメカニズムは、ワークスペース、レポート、またはオブジェクト レベルでアクセスを制御します。

---

静的な行レベルのセキュリティ

静的 RLS は、ハードコードされたフィルター値を使用してユーザーをロールに割り当てます。これは最も単純な実装であり、少数の固定地域、部門、または事業単位のシナリオに適しています。

静的ロールの作成

Power BI Desktop の場合:

1.「モデリング」に移動し、「役割の管理」に移動します。 2. 「作成」をクリックして新しい役割を追加します 3. 役割に名前を付けます (例: 「北米販売」) 4. フィルタリングするテーブルを選択します (例: Dim_Region) 5. DAX フィルター式を作成します。

[Region] = "North America"

この式は、ユーザーに「北米販売」ロールが割り当てられている場合、Dim_Region に関連するすべてのテーブルには、地域が北米である行のみが表示されることを意味します。売上レポートを表示しているユーザーには、北米の売上のみが表示されます。 HR ダッシュボードを表示しているユーザー (地域ディメンションを通じて接続している場合) には、北米の従業員のみが表示されます。

複数の役割

異なるフィルターを使用して複数のロールを作成できます。

• EMEA 販売: [Region] = "EMEA"
• APAC 販売: [Region] = "APAC"
• グローバル エグゼクティブ: フィルターなし (すべてのデータを表示)

ユーザーは複数の役割に割り当てることができます。複数のロールに割り当てられている場合、フィルターは OR ロジックと結合します。ユーザーにはすべてのロールのデータが結合されたものが表示されます。たとえば、「北米販売」と「EMEA 販売」の両方に割り当てられたユーザーには、両方の地域のデータが表示されます。

静的 RLS の制限事項

静的 RLS は、次の場合に管理できなくなります。

• 10 ～ 15 を超える個別のフィルター値がある (15 以上のロールを作成して維持するのは面倒です)
• ユーザーとロールの割り当ては頻繁に変更されます (変更ごとに Power BI 管理者が必要です)
• フィルター ロジックは単純な等価性よりも複雑です (たとえば、マネージャーは自分のチームのデータと自分のデータを参照する必要があります)
• 数十の事業単位にまたがる数百のユーザーがいる

このようなシナリオでは、動的 RLS が解決策になります。

---

動的な行レベルのセキュリティ

動的 RLS は、実行時に評価される DAX 関数を使用してログイン ユーザーを特定し、適切なフィルターを適用します。 2 つの主要な機能は次のとおりです。

• USERNAME() — 現在のユーザーのドメイン\ユーザー名または UPN を返します。
• USERPRINCIPALNAME() — 現在のユーザーの電子メール/UPN を返します (クラウド展開に推奨)

動的 RLS のセットアップ

ステップ 1: セキュリティ マッピング テーブルを作成する

このテーブルは、ユーザーを承認されたデータ スコープにマップします。データ ソース (データベース)、SharePoint リスト、または Excel ファイルに保存できます。

このテーブルを Power BI モデルに SecurityMapping としてインポートします。

ステップ 2: RLS ロールを作成する

セキュリティ マッピング テーブルに DAX フィルターを使用して単一のロール (例: 「DynamicSecurity」) を作成します。

[UserEmail] = USERPRINCIPALNAME()
    || [UserEmail] = "ALL"

ステップ 3: 関係を作成する

SecurityMapping からディメンション テーブルへの関係を確立します。

• SecurityMapping[地域] から Dim_Region[地域]
• SecurityMapping[部門] から Dim_Department[部門]
• SecurityMapping[CompanyId] から Dim_Company[CompanyId]

これらの関係は、ディメンションからセキュリティ マッピング テーブルまで 1 対多である必要があります。そうでない場合は、双方向クロス フィルターを使用できます。ただし、双方向フィルターにはパフォーマンスへの影響があります。より良いアプローチでは、DAX 式で CROSSFILTER または TREATAS を使用します。

ステップ 4: 関係性のない代替案 (TREATAS アプローチ)

セキュリティ マッピング テーブルからリレーションシップを作成する代わりに、ファクト テーブルの RLS 式で TREATAS を直接使用できます。

VAR CurrentUser = USERPRINCIPALNAME()
VAR UserRegions =
    CALCULATETABLE(
        VALUES(SecurityMapping[Region]),
        SecurityMapping[UserEmail] = CurrentUser
            || SecurityMapping[UserEmail] = "ALL"
    )
RETURN
    [Region] IN UserRegions

このアプローチにより、追加の関係による複雑さが回避され、セキュリティ ロジックが自己完結型に保たれます。

マネージャー階層を使用した動的 RLS

一般的な要件は、マネージャーがレポート チェーン全体のデータを確認できることです。これには、従業員テーブルまたはユーザー テーブルに親子階層が必要です。

アプローチ 1: PATH 関数

ユーザー テーブルに ManagerId 列がある場合は、DAX の PATH 関数を使用します。

UserPath = PATH(Users[UserId], Users[ManagerId])

次に、RLS 式では次のようになります。

VAR CurrentUserId =
    LOOKUPVALUE(Users[UserId], Users[Email], USERPRINCIPALNAME())
RETURN
    PATHCONTAINS([UserPath], CurrentUserId)

この式は、現在のユーザー自身のデータと、その直属および間接的な部下に属するすべてのデータに対して TRUE を返します。

アプローチ 2: フラット化されたセキュリティ テーブル

ETL プロセスで階層を事前に計算し、各マネージャーがすべてのレポートのデータ スコープとともにリストされるフラットなセキュリティ マッピングを作成します。これにより、PATH 評価のオーバーヘッドが回避されるため、クエリ時のパフォーマンスが向上します。

---

オブジェクトレベルのセキュリティ (OLS)

オブジェクトレベルのセキュリティにより、テーブル全体または列全体がユーザーから隠されます。行をフィルタリングする RLS とは異なり、OLS ではテーブルや列が完全に非表示になります。フィールド リストには表示されず、非表示のフィールドを視覚的に参照するとエラーが表示されます。

OLS を使用する場合

• HR データセットの給与列を HR 以外のユーザーから非表示にする
• 収益のみを参照する必要がある営業チームからコスト関連のテーブルを非表示にする
• 集計データのみが必要なアナリストから顧客の PII (電子メール、電話番号、住所) を隠す
• 戦略的価格設定の列を一般ユーザーから非表示にする

OLS の構成

OLS は、Power BI Desktop UI ではなく、表形式エディター (外部ツール) または XMLA エンドポイントを通じて構成されます。

表形式エディタの場合:

1. 外部ツール リボンを使用してモデルを開きます
2. 制限したいテーブルまたは列に移動します。
3. [プロパティ] ペインで、各ロールの下の [テーブル権限] または [列権限] を見つけます。
4. 権限を「なし」に設定します（デフォルトは「読み取り」です）。

たとえば、「Sales」ロールから「Employees」テーブルの「Salary」列を非表示にするには、次のようにします。

• 役割: 営業
• 表: 従業員
• コラム: 給与
• 許可: なし

Sales ロールが割り当てられたユーザーには、フィールド リストに Salary 列が表示されず、DAX 計算で参照することもできません。

OLS の制限事項

• OLS には、XMLA エンドポイントが有効になっている Power BI Premium または Pro が必要です
• OLS は Power BI Desktop のネイティブ UI では構成できません
• OLS はメタデータ レベルのみです --- 行はフィルターされません
• メジャーが非表示の列を参照している場合、制限されたユーザーに対してメジャー自体がエラーになります

---

DirectQuery を使用した RLS

RLS は DirectQuery で動作しますが、動作は重要な点でインポート モードとは異なります。

仕組み

DirectQuery モードでは、Power BI は RLS DAX フィルターを SQL WHERE 句に変換し、データ ソースに送信します。データ ソースはフィルタリングを実行し、承認された行のみが返されます。

シングル サインオン (SSO) パススルー

Azure SQL や Azure Synapse などのデータベースに対して SSO で DirectQuery を使用する場合、Power BI はユーザーの ID をデータベースに渡します。データベースに独自の行レベルのセキュリティ (SQL Server の CREATE SECURITY POLICY など) がある場合、そのセキュリティは Power BI の RLS に加えて適用されます。

重要: SSO パススルーを有効にすると、データベースがセキュリティを処理するため、Power BI の RLS はバイパスされます。どちらかを選択する必要があります。

• Power BI RLS (DAX で定義、Power BI で管理)
• データベースレベルの RLS (SQL で定義、データベースで管理)
• 両方 (Power BI RLS とデータベース RLS が適用されます --- ユーザーには交差部分が表示されます)

パフォーマンスに関する考慮事項

DirectQuery の RLS フィルターは、すべてのクエリに WHERE 句を追加します。データベース内でフィルター列にインデックスが付けられていない場合、パフォーマンスが大幅に低下する可能性があります。次のことを確認してください。

• RLS フィルター列にはデータベース インデックスがあります
• DAX フィルター式は効率的な SQL に変換できるほど単純です
• Power BI Desktop の「パフォーマンス アナライザー」を使用してクエリ パフォーマンスをテストします。

---

Power BI Embedded の RLS

Power BI Embedded (カスタム アプリケーションへのレポートの埋め込み) には、エンド ユーザーが Power BI または Azure AD アカウントを持っていない可能性があるため、独自の RLS 要件があります。

アプリがデータを所有するシナリオ

「アプリがデータを所有する」埋め込みパターンでは、サービス プリンシパルまたはマスター アカウントが Power BI に対して認証し、アプリケーションは埋め込みトークンでユーザーの ID を渡します。

RLS を使用した埋め込みトークンの生成:

Power BI REST API を呼び出して埋め込みトークンを生成する場合は、identities パラメーターを含めます。

{
  "datasets": [
    {
      "id": "dataset-guid-here"
    }
  ],
  "reports": [
    {
      "id": "report-guid-here"
    }
  ],
  "identities": [
    {
      "username": "[email protected]",
      "roles": ["DynamicSecurity"],
      "datasets": ["dataset-guid-here"]
    }
  ]
}

username 値は、USERPRINCIPALNAME() が DAX 式で返す値です。 roles 配列は、適用する RLS ロールを指定します。ユーザー名として任意の文字列を渡すことができます。実際の Azure AD アカウントである必要はありません。

よくある埋め込みの間違い

間違い 1: 有効な ID を渡さない。 identities パラメーターを指定せずに埋め込みトークンを生成すると、埋め込みレポートにはすべてのデータが表示されます。これは、最も一般的な RLS 埋め込みエラーです。

間違い 2: ロールを渡しますが、ユーザー名は渡しません。 動的 RLS にはユーザー名が必要です。これがないと、USERPRINCIPALNAME() は空白を返し、DAX フィルターはどの行とも一致しません。レポートは空のように表示されます。

間違い 3: サービス プリンシパルの ID を使用する。 サービス プリンシパルはワークスペース管理者であり、RLS をバイパスします。エンド ユーザーの ID を明示的に渡す必要があります。

間違い 4: 動的 RLS の埋め込みトークンでロールをハードコーディングする。 動的 RLS を単一のロール (「DynamicSecurity」など) で使用する場合は、常にそのロール名を渡します。ユーザーごとに個別のロールを作成しないでください。これは、動的 RLS の目的を無効にします。

---

行レベルのセキュリティのテスト

ロールとして表示 (Power BI Desktop)

Power BI Desktop で、[モデリング]、[表示方法] の順に移動します。

1. テストするロールを選択します
2. 必要に応じて、動的 RLS をテストするためのユーザー名を入力します (これは USERPRINCIPALNAME() 値をシミュレートします)。
3. 「OK」をクリックします。

レポートには、指定されたロールを持つ指定されたユーザーであるかのようにデータが表示されます。確認:

• KPI カードには、正しくフィルター処理された合計が表示されます
• テーブルにはユーザーのスコープ内の行のみが表示されます
• グラフにはフィルタリングされたデータが反映されます
• ビジュアル間のクロスフィルタリングは RLS 境界を尊重します
• ドリルスルー ページは RLS コンテキストを維持します

表示形式 (Power BI サービス)

Power BI サービスで、データセット設定を開き、[セキュリティ] を選択します。 「ロールとしてテスト」を選択し、ユーザー名を入力することで、ロールを直接テストできます。

自動テストのチェックリスト

次のシナリオでテスト マトリックスを作成します。

---

RLS のパフォーマンスの最適化

影響を測定する

RLS を実装する前後に、Power BI Desktop のパフォーマンス アナライザーを使用してクエリ時間を測定します。 [パフォーマンス アナライザー] ウィンドウを開き、記録を開始し、レポートを操作して、RLS を使用した場合と使用しない場合の DAX クエリ時間を比較します。

適切に設計された RLS 実装では、追加されるオーバーヘッドは 5% 未満です。 10% を超える低下が見られる場合は、DAX フィルター式を調査してください。

最適化手法

フィルター式は単純にしてください。 理想的な RLS 式は単一列の比較です。

[Region] = USERPRINCIPALNAME()

RLS フィルター自体で複数の CALCULATE、FILTER、または LOOKUPVALUE 呼び出しを含む複雑な式を避けてください。

テキスト比較の代わりに整数キーを使用します。 [CompanyId] = 1 でのフィルタリングは [CompanyName] = "ECOSIRE Private Limited" より高速です。ユーザーの電子メールをセキュリティ マッピング テーブルの整数キーにマッピングします。

RLS フィルターを使用してテーブルの数を最小限に抑えます。 RLS をディメンション テーブルに適用し、リレーションシップの伝播でファクト テーブルを処理します。 RLS を大きなファクト テーブルに直接適用すると、Power BI はファクト テーブルのすべての行でフィルターを評価することになります。

可能な場合は事前に集計します。 ユーザーが概要レベルのデータのみを必要とする場合は、ETL 中にセキュリティ フィルターが適用された事前に集計されたテーブルを作成することを検討してください。これにより、Power BI がクエリ時にフィルターする必要があるデータの量が減少します。

双方向クロスフィルターは避けてください。 双方向の関係はクエリの複雑さを増大させ、RLS と競合する可能性があります。一方向のリレーションシップ (ディメンションからファクトへ) を使用し、ディメンション側で RLS を適用します。

---

よくある落とし穴と解決策

落とし穴 1: RLS はワークスペース管理者には適用されない

ワークスペース管理者と編集権限を持つメンバーは RLS をバイパスします。彼らは常にすべてのデータを参照します。これは仕様です --- 管理者はワークスペースを管理するために完全なアクセス権を必要とします。

解決策: RLS の対象となるビジネス ユーザーには「閲覧者」ロールを使用してください。管理者/メンバー/共同作成者の役割のみを BI チームに付与します。

落とし穴 2: ALL() RLS フィルターの削除

DAX ALL() 関数は、RLS フィルターを含むすべてのフィルターをテーブルから削除します。メジャーが RLS フィルター処理されたテーブルで ALL() を使用する場合、ユーザーに表示すべきではないデータが公開される可能性があります。

-- DANGEROUS: This measure ignores RLS on Dim_Region
Total Global Sales =
CALCULATE(SUM(Fact_Sales[Revenue]), ALL(Dim_Region))

解決策: スライサー/ビジュアル フィルターを削除して RLS フィルターを保持したい場合は、ALL() の代わりに ALLSELECTED() を使用します。

-- SAFE: This measure preserves RLS filters
Total Sales for Context =
CALCULATE(SUM(Fact_Sales[Revenue]), ALLSELECTED(Dim_Region))

落とし穴 3: RLS をオーバーライドする CALCULATE

明示的なフィルター引数を指定した CALCULATE は、特定のシナリオ、特に REMOVEFILTERS で RLS をオーバーライドできます。

-- DANGEROUS: REMOVEFILTERS is equivalent to ALL
Total Revenue All Regions =
CALCULATE(SUM(Fact_Sales[Revenue]), REMOVEFILTERS(Dim_Region[Region]))

解決策: ALL、REMOVEFILTERS、および ALLEXCEPT の使用状況について、すべての DAX メジャーを監査します。 RLS フィルター処理された列を参照していないことを確認してください。

落とし穴 4: 複合モデルと RLS

複合モデル (インポートと DirectQuery の混合) では、RLS をインポート テーブルと DirectQuery テーブルに対して個別に定義する必要があります。 1 つの RLS ロールに両方のフィルターを含めることができますが、動作は異なります。

• テーブルのインポート: RLS フィルターは Power BI エンジンによって評価されます
• DirectQuery テーブル: RLS フィルターは SQL に変換され、ソースに送信されます。

DirectQuery ソースが RLS フィルターで使用される DAX 関数をサポートしていない場合、クエリは失敗します。

落とし穴 5: RLS を無視したページ分割されたレポート

Power BI ページ分割されたレポート (レポート ビルダーで作成) は、データ ソースに直接接続する場合、データセット RLS をバイパスできます。 RLS を強制するには、ページ分割されたレポートが (データベースに直接接続するのではなく) Power BI データセットを介して接続する必要があり、ユーザーには RLS ロールが割り当てられている必要があります。

---

エンタープライズ RLS アーキテクチャ パターン

大規模な組織の場合、ECOSIRE は標準化された RLS アーキテクチャを推奨 します。

セキュリティ層の設計

1. 中央データベースに保存された セキュリティ マッピング テーブル (Azure SQL または SharePoint リスト)
2. USERPRINCIPALNAME() を使用した「DynamicSecurity」という名前の 単一の RLS ロール
3. Azure AD グループ同期。グループ メンバーシップに基づいてセキュリティ マッピング テーブルに自動的に入力します。
4. 事前にフラット化された親子テーブルを使用した 階層サポート
5. 監査証跡のログ記録 (Power BI アクティビティ ログと REST API 経由) どのユーザーがどのデータにアクセスしたか

ガバナンスプロセス

1. データ スチュワードはセキュリティ マッピング テーブルを保守します。
2. 変更は、変更管理プロセスを通じてレビューおよび承認されます。
3. 月次監査により、Power BI RLS の割り当てが人事記録システムと比較されます。
4. 四半期ごとのペネトレーションテストで RLS の有効性を検証

このアーキテクチャは、単一ポイントのセキュリティ管理を維持しながら、数百のデータセットにわたる数千のユーザーに拡張できます。

---

よくある質問

RLS は Power BI の無料ライセンスで動作しますか?

いいえ。RLS では、RLS で保護されたレポートを使用するすべてのユーザーに対して Power BI Pro または Premium Per User ライセンスが必要です。無料ライセンスのユーザーは、Premium 容量のワークスペース内のコンテンツにのみアクセスできます。その場合でも、RLS ロールを割り当てるには Pro または PPU ライセンスが必要です。 Power BI Embedded シナリオでは、エンド ユーザーは Power BI ライセンスを必要としません。RLS は埋め込みトークンを通じて適用されます。

個々のユーザーではなく Azure AD グループに基づいて RLS を実装できますか?

直接ではありません。 Power BI の RLS は、USERPRINCIPALNAME() に対して DAX 式を評価し、個々のユーザーの電子メールを返します。ただし、Azure AD グループをデータ スコープにマップするセキュリティ マッピング テーブルを作成し、Microsoft Graph API または Azure AD グループ メンバーシップ同期を使用してそれにデータを取り込むことができます。 DAX 式は引き続きユーザーの電子メールによってフィルター処理しますが、セキュリティ マッピング テーブルはグループとデータのマッピングを提供します。

ユーザーが RLS ロールに割り当てられていない場合はどうなりますか?

RLS がデータセットに定義されており、ユーザーがどのロールにも割り当てられていない場合、ユーザーにはデータが表示されません。レポートは読み込まれますが、すべてのビジュアルが空白またはゼロで表示されます。これは安全な既定値です --- Power BI は、明示的に許可されない限りアクセスしないものとみなされます。ただし、ワークスペース管理者と編集権限を持つメンバーは RLS をバイパスし、ロールの割り当てに関係なく常にすべてのデータを表示します。

RLS はリアルタイム ダッシュボードのデータをフィルタリングできますか?

はい。 RLS は、インポート モードと DirectQuery モードの両方で動作します。 DirectQuery モードでは、RLS フィルターは SQL WHERE 句に変換され、クエリごとにデータベースに送信されるため、フィルター処理はリアルタイムで行われます。インポート モードでは、ユーザーがレポートを開いたときにフィルタリングがメモリ内で適用されます。どちらのモードでも同じセキュリティ保証が提供されます。ユーザーには承認されたデータのみが表示されます。

RLS を通じて誰がどのデータにアクセスしたかを監査するにはどうすればよいですか?

Power BI は、Microsoft 365 管理センターと Power BI REST API を通じてアクティビティ ログを提供します。これらのログには、レポート ビュー、データセットの更新、およびユーザーの ID を含むエクスポート操作が記録されます。ただし、ログには、ユーザーがどの特定の行を表示したかは記録されません。詳細なデータ アクセス監査の場合は、データベース レベルの監査 (PostgreSQL pgaudit や Azure SQL 監査など) を有効にして、RLS フィルターが適用された DirectQuery によって生成された実際のクエリをログに記録します。