前へ

次へ

行レベルのセキュリティをセットアップする

完了

データ モデル開発者は、1 つ以上の "ロール" を作成して RLS をセットアップします。 ロールはモデル内で一意の名前を持ち、通常は 1 つ以上のルールを含みます。 ルールは、Data Analysis Expressions (DAX) フィルター式を使用して、モデル テーブルにフィルターを適用します。

注意

既定で、データ モデルにはロールがありません。 ロールのないデータ モデルは、ユーザー (データ モデルを照会する権限を持っている) がすべてのモデル データにアクセスできることを意味します。

ヒント

ルールを含まないロールを定義することができます。 この場合は、ロールが、すべてのモデル テーブルのすべての行へのアクセスを提供します。 このロールの設定は、すべてのデータの表示を許可されている管理者ユーザーに適しています。

Microsoft Power BI Desktop で開発したモデルの場合、Power BI Desktop でロールを作成、検証、管理することができます。 Microsoft Azure Analysis Services モデルまたは SQL Server Analysis Services モデルでは、SQL Server Data Tools (SSDT) を使用してロールを作成、検証、管理することができます。

さらに、SQL Server Management Studio を使用するか、Tabular Editor などの外部ツールを使用して、ロールを作成および管理できます。

スター スキーマ デザイン プリンシパルを適用する

効果的な RLS ソリューションを実現するための最初のステップは、適切に設計されたモデルを開発することです。 スター スキーマ デザイン プリンシパルを適用して、ディメンション テーブルとファクト テーブルで構成されるモデルを生成することをお勧めします。 一般に、Power BI では、ディメンション テーブルをフィルター処理するためのルールが適用され、モデル リレーションシップによってそれらのフィルターがファクト テーブルに効率的に反映されます。

次の図は、Tailspin Toys 社の売上分析データ モデルの図です。 Sales という名前の単一のファクト テーブルを含むスター スキーマ設計を示しています。 他の 4 つのテーブルは、日付、状態、地域、および製品別の販売施策の分析をサポートするディメンション テーブルです。 モデル リレーションシップによって、すべてのテーブルが接続されています。 これらのリレーションシップは、フィルターを (直接的または間接的に) Sales テーブルに反映します。

このモデル設計は、このモジュールで示される例をサポートしています。

ルールを定義する

ルール式は、行コンテキスト内で評価されます。 行コンテキストは、その行の列値を使用して各行の式が評価されることを意味します。 式が TRUE を返した場合は、ユーザーがその行を "確認" できます。

ヒント

行コンテキストについて詳しくは、「Power BI Desktop モデルに計算テーブルと計算列を追加する」モジュールをご覧ください。 このモジュールではモデルの計算を追加するプロセスが説明されていますが、行コンテキストを紹介して説明するユニットも含まれています。

静的なまたは動的なルールを定義できます。

静的ルール

静的ルールでは、定数を参照する DAX 式が使用されます。

New England の売上へのデータ アクセスを制限する Region テーブルに適用される次のルールについて考えてみましょう。

'Region'[Region] = "New England"

次の手順では、ルールが適用される Power BI のプロセスについて説明します。

1. Region テーブルをフィルター処理し、表示される行を 1 行にします (New England の場合)。

2. モデル リレーションシップを使用して、Region テーブル フィルターを State テーブルに反映し、表示される行を 6 つにします (New Englan 地域には 6 つの州が含まれます)。

3. モデル リレーションシップを使用して、State テーブル フィルターを Sales テーブルに反映し、表示される行を数千にします (New England 地域に属している州の売上ファクト)。

作成可能な最も簡単な静的ルールは、すべてのテーブル行へのアクセスを制限します。 Sales Details テーブルに適用される次のルールについて考えてみましょう (モデル図には示されていません)。

FALSE()

このルールにより、ユーザーはテーブルのデータにアクセスできなくなります。 このルールは、営業担当者が (Sales テーブルから) 集計された売上結果は表示できるが、注文レベルの詳細は表示できない場合に役に立つ可能性があります。

静的ルールの定義はシンプルで効果的です。 地域が 6 つしかない Tailspin Toys の場合と同様に、一部のみを作成する必要がある場合は、静的ルールの使用を検討してください。 ただし、いくつかのデメリットに注意してください。静的ルールのセットアップには、作成とセットアップに多大な労力が必要になる場合があります。 また、静的ルールでは、新しい地域が追加されたときはデータセットを更新して再発行する必要もあります。

設定するルールが複数存在し、今後新しいルールを追加する予定の場合は、代わりに動的ルールを使用することを検討してください。

動的ルール

動的ルールでは、(定数ではなく) 環境値を返す特定の DAX 関数が使用されます。 環境値は、次の特定の DAX 関数から返されます。

• USERNAME または USERPRINCIPALNAME: "組織向け" シナリオを使用している場合は、これらの関数から認証されたユーザーに関するテキスト値が返されます。 "顧客向け" シナリオを使用している場合は、アプリで渡したテキスト値が返されます。

• CUSTOMDATA: "組織向け" シナリオを使用している場合は、この関数から接続文字列で渡された CustomData プロパティが返されます。 "顧客向け" シナリオを使用している場合は、アプリで渡したテキスト値が返されます。

注意

USERNAME 関数は、Power BI Desktop で使用されたときは、DOMAIN\username の形式でユーザーを返します。 一方、Power BI サービスで使用されたときは、ユーザー プリンシパル名 (UPN) の形式 (username@tailspintoys.com など) を返します。 また、常に UPN の形式でユーザーを返す USERPRINCIPALNAME 関数を使用することもできます。

(非表示の) AppUser テーブルを含むように修正されたモデル設計を検討してください。 AppUser テーブルの各行には、ユーザー名と地域が入力されます。 Region テーブルへのモデル リレーションシップには、AppUser テーブルからのフィルターが反映されます。

AppUser テーブルに適用される次のルールは、認証されたユーザーの地域へのデータ アクセスを制限します。

'AppUser'[UserName] = USERPRINCIPALNAME()

動的ルールの定義は、モデル テーブルにユーザー名の値が保存されている場合にシンプルで効果的です。 動的ルールを使うと、"データ駆動型" の RLS 設計を適用できます。 たとえば、営業担当者が AppUser テーブルに対して追加または削除される (または別々の地域に割り当てられる) 場合は、この設計アプローチが適しています。

重要

"顧客向け" シナリオを使用している場合は、USERNAME 関数と USERPRINCIPALNAME 関数が実際のユーザー名を返す必要はありません。 代わりに、アプリで特定のテキスト値を渡してモデルをフィルター処理できます。

ロールを検証する

ロールを作成するときは、ロールをテストし、正しいフィルターが適用されることを確認してください。 Power BI Desktop で作成されたデータ モデルの場合は、複数のロールが適用され、複数のユーザー名の値が渡されたときにレポートを表示できるようにする [表示方法] 機能があります。

ロール マッピングをセットアップする

ロール マッピングは、埋め込みシナリオによって異なる方法で実行されます。

"組織向け" シナリオを使用している場合は、ユーザーが Power BI のコンテンツにアクセスする前に、ロール マッピングを設定する必要があります。 ロール マッピングには、Microsoft Azure Active Director のセキュリティ オブジェクトをロールに割り当てます。 セキュリティ オブジェクトは、ユーザー アカウントまたはセキュリティ グループにすることができます。

ヒント

可能であれば、ロールをセキュリティ グループにマップすることをお勧めします。 そうすることで、マッピングの数が少なくなり、グループ メンバーシップの管理をネットワーク管理者に任せることができます。

Power BI Desktop 開発モデルの場合は、ロール マッピングが、通常、Power BI サービスで実行されます。 Azure Analysis Services モデルまたは SQL Server Analysis Services モデルの場合は、ロール マッピングが、通常、SQL Server Management Studio (SSMS) で実行されます。

"顧客向け" シナリオを使用している場合は、アプリによって実行時にロール マッピングが行われます。 アプリ ロジックが、RLS を適用するための 1 つ以上の実効 ID を設定します。 実効 ID の設定については、このモジュールで後ほど説明します。

RLS の設定について詳しくは、次の記事をご覧ください。

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

• Power BI Desktop での行レベルのセキュリティ (RLS) のガイダンス

続行