Power BI モデル データへのアクセスを制限する
データ モデラーは、1 つ以上のロールを作成して RLS をセットアップします。 ロールはモデル内で一意の名前を持ち、通常は 1 つ以上のルールを含みます。 ルールは、Data Analysis Expressions (DAX) フィルター式を使用して、モデル テーブルにフィルターを適用します。
注意
既定で、データ モデルにはロールがありません。 ロールのないデータ モデルは、ユーザー (データ モデルを照会する権限を持っている) がすべてのモデル データにアクセスできることを意味します。
ヒント
ルールを含まないロールを定義することができます。 この場合は、ロールが、すべてのモデル テーブルのすべての行へのアクセスを提供します。 このロールの設定は、すべてのデータの表示を許可されている管理者ユーザーに適しています。
ロールの作成、検証、管理は、Power BI Desktop で行うことができます。 Azure Analysis Services モデルまたは SQL Server Analysis Services モデルでは、SQL Server Data Tools (SSDT) を使用してロールを作成、検証、管理することができます。
また、SQL Server Management Studio (SSMS) を使用するか、Tabular Editor などのサードパーティ製ツールを使用することによって、ロールを作成して管理することもできます。
RLS がデータへのアクセスを制限する方法に関する理解を深めるには、次のアニメーション画像をご覧ください。
スター スキーマの設計原則を適用する
スター スキーマの設計原則を適用して、ディメンションとファクトの各テーブルを構成するモデルを生成することをお勧めします。 ディメンション テーブルをフィルター処理する規則を適用するように Power BI を設定するのが一般的です。こうすることで、モデル リレーションシップによって、そのフィルターがファクト テーブルに効率的に伝達されます。
次の図は、Adventure Works の売上分析データ モデルのモデル図です。 Sales という名前の 1 つのファクト テーブルで構成されるスター スキーマ設計が示されています。 他のテーブルは、日付、販売区域、顧客、リセラー、注文、製品、および営業担当者別の販売施策の分析をサポートするディメンション テーブルです。 すべてのテーブルを接続するモデル リレーションシップに注目してください。 これらのリレーションシップは、フィルターを (直接的または間接的に) Sales テーブルに反映します。
このモデル設計は、このユニットで示される例をサポートしています。
ルールを定義する
ルール式は、行コンテキスト内で評価されます。 行コンテキストは、その行の列値を使用して各行の式が評価されることを意味します。 式が TRUE を返した場合は、ユーザーがその行を "確認" できます。
ヒント
行コンテキストの詳細については、「Power BI Desktop モデルに計算テーブルと計算列を追加する」モジュールを参照してください。 このモジュールではモデル計算の追加方法について説明されていますが、行コンテキストに関するユニットが含まれています。
静的なまたは動的なルールを定義できます。
静的ルール
静的ルールでは、定数を参照する DAX 式が使用されます。
Midwest の売上へのデータ アクセスを制限する Region テーブルに適用される次のルールについて考えてみましょう。
'Region'[Region] = "Midwest"
次の手順では、Power BI がルールを適用する方法について説明します。 それでは次のことが行われます。
Region テーブルをフィルター処理し、表示される行を 1 行にします (Midwest の場合)。
モデル リレーションシップを使用して、Region テーブル フィルターを State テーブルに反映し、表示される行を 14 つにします (Midwest 地域は 14 つの州で構成されます)。
モデル リレーションシップを使用して、State テーブル フィルターを Sales テーブルに反映し、表示される行を数千にします (Midwest 地域に属している州の売上ファクト)。
作成可能な最も簡単な静的ルールは、すべてのテーブル行へのアクセスを制限します。 Sales Details テーブルに適用される次のルールについて考えてみましょう (モデル図には示されていません)。
FALSE()
このルールにより、ユーザーはどのテーブル データにもアクセスできなくなります。 これは、営業担当者が ( Sales テーブルから) 集計された売上結果は表示できるが、注文レベルの詳細は表示できない場合に役に立つ可能性があります。
静的ルールの定義はシンプルで効果的です。 Adventure Works の地域が 6 つしかない場合と同様に、一部のみを作成する必要がある場合は、それらの使用を検討してください。 ただし、デメリットに注意してください。静的ルールの設定には、作成と設定に多大な労力が必要になる場合があります。 また、新しい地域がオンボードされたときは、データセットを更新して再発行する必要もあります。
設定するルールが多数存在し、今後新しいルールの追加が予想される場合は、代わりに動的ルールを作成することを検討してください。
動的ルール
動的ルールでは、(定数ではなく) 環境値を返す特定の DAX 関数が使用されます。 環境値は、次の 3 つの特定の DAX 関数から返されます。
USERNAME または USERPRINCIPALNAME – Power BI の認証済みユーザーをテキスト値として返します。
CUSTOMDATA - 接続文字列で渡された CustomData プロパティを返します。 接続文字列を使用してデータセットに接続する Power BI 以外のレポート ツールでは、このプロパティを設定できます (Microsoft Excel など)。
注意
USERNAME 関数は、Power BI Desktop で使用されたときは DOMAIN\username の形式でユーザーを返すことに注意してください。 ただし、Power BI サービスで使用されたときは、ユーザーのユーザー プリンシパル名 (UPN) の形式 (username@adventureworks.com など) が返されます。 また、必ずユーザー プリンシパル名の形式でユーザーを返す USERPRINCIPALNAME 関数を使用することもできます。
(非表示の) AppUser テーブルを含むように修正されたモデル設計を検討してください。 AppUser テーブルの各行には、ユーザー名と地域が入力されます。 Region テーブルへのモデル リレーションシップには、AppUser テーブルからのフィルターが反映されます。
AppUser テーブルに適用される次のルールは、認証されたユーザーの地域へのデータ アクセスを制限します。
'AppUser'[UserName] = USERPRINCIPALNAME()
動的ルールの定義は、モデル テーブルにユーザー名の値が保存されている場合にシンプルで効果的です。 これにより、データ駆動型 RLS 設計を適用できます。 たとえば、営業担当者が AppUser テーブルに対して追加または削除される (または別々のリージョンに割り当てられる) 場合は、この設計アプローチが適しています。
ロールを検証する
ロールを作成する場合は、ロールをテストして、正しいフィルターが適用されていることを確認することが重要です。 Power BI Desktop で作成されたデータ モデルの場合は、複数のロールが適用され、複数のユーザー名の値が渡されたときにレポートを表示できるようにする [表示方法] 機能があります。
ロール マッピングをセットアップする
ユーザーが Power BI コンテンツにアクセスする前に、ロール マッピングを設定する必要があります。 ロール マッピングには、Microsoft Entra セキュリティ オブジェクトのロールへの割り当てが含まれます。 セキュリティ オブジェクトは、ユーザー アカウントまたはセキュリティ グループにすることができます。
ヒント
可能であれば、ロールをセキュリティ グループにマップすることをお勧めします。 そうすることで、マッピングの数が少なくなり、グループ メンバーシップの管理をネットワーク管理者に任せることができます。
Power BI Desktop 開発モデルの場合は、ロール マッピングが、通常、Power BI サービスで実行されます。 Azure Analysis Services モデルまたは SQL Server Analysis Services モデルの場合は、ロール マッピングが、通常、SSMS で実行されます。
RLS のセットアップの詳細については、以下を参照してください。
DirectQuery ソースにシングル サインオン (SSO) を使用する
データ モデルに DirectQuery テーブルがあり、そのデータ ソースが SSO をサポートしている場合は、データ ソースでデータ アクセス許可を適用できます。 これにより、データベースで RLS が適用され、Power BI のデータセットとレポートでデータ ソースのセキュリティが尊重されます。
たとえば、Adventure Works で、販売業務用の Azure SQL Database が Power BI と同じテナント内に存在しているとします。 このデータベースでは、RLS が適用され、さまざまなデータベース テーブル内の行へのアクセスが制御されています。 DirectQuery モデルを作成すると、ロールなしでこのデータベースに接続し、それを Power BI サービスに公開することができます。 Power BI サービスでデータ ソースの資格情報を設定する際に、SSO を有効にします。 レポート コンシューマーが Power BI レポート開くと、その ID が Power BI によってデータ ソースに渡されます。 その後、レポート コンシューマーの ID に基づいて、データ ソースで RLS が適用されます。
Azure SQL Database の RLS については、「行レベルのセキュリティ」を参照してください。
注意
計算テーブルおよび計算列で、SSO 認証を使用してデータ ソースから DirectQuery テーブルを参照することは、Power BI サービスではサポートされていません。
SSO をサポートするデータ ソースの詳細については、「DirectQuery ソースのシングル サインオン (SSO)」を参照してください。