Power BI モデル データへのアクセスを制限する

  • 14 分

データ モデリングツールとして、1 つ以上のロールを作成して RLS を設定します。 ロールはモデル内で一意の名前を持ち、通常は 1 つ以上のルールを含みます。 ルールは、データ分析式 (DAX) フィルター式を使用してモデル テーブルにフィルターを適用します。

注

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

ヒント

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

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

また、SQL Server Management Studio (SSMS) を使用するか、 表形式エディターなどのサード パーティ製ツールを使用してロールを作成および管理することもできます。

RLS がデータへのアクセスを制限する方法について理解を深めるために、次のアニメーション画像をご覧ください。

アニメーション化された図は、それぞれ特定の国/地域データにアクセスできる 2 人のユーザーに対して行レベルのセキュリティがどのように機能するかを示しています。

スター スキーマの設計原則を適用する

スター スキーマの設計原則を適用して、ディメンション テーブルとファクト テーブルを構成するモデルを生成することをお勧めします。 ディメンション テーブルをフィルター処理するルールを適用するように Power BI を設定するのが一般的です。 これにより、モデル リレーションシップ は、これらのフィルターをファクト テーブルに効率的に伝達できます。

次の図は、Adventure Works 売上分析データ モデルのモデル図です。 Sales という名前の 1 つのファクト テーブルで構成されるスター スキーマ設計を示します。 その他のテーブルは、日付、販売区域、顧客、リセラー、注文、製品、および販売員による販売メジャーの分析をサポートするディメンション テーブルです。 すべてのテーブルを接続するモデル リレーションシップに注目してください。 これらのリレーションシップは、フィルターを (直接または間接的に) Sales テーブルに伝達します。

前の段落で説明したように、テーブルとリレーションシップを構成する Power BI Desktop モデルの図を示すスクリーンショット。

このモデル設計では、このユニットで紹介する例がサポートされています。

ルールを定義する

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

ヒント

行コンテキストの詳細については、「Power BI Desktop モデルに計算テーブルと計算列を追加する」モジュールを参照してください。 このモジュールではモデル計算の追加方法について説明されていますが、行コンテキストに関するユニットが含まれています。

静的または動的のいずれかのルールを定義できます。

静的ルール

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

データ アクセスを中西部の売上に制限する リージョン テーブルに適用される次の規則を検討してください。


'Region'[Region] = "Midwest"

次の手順では、Power BI で規則がどのように適用されるかについて説明します。 次のことが行われます。

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

  2. モデル リレーションシップを使用して Region テーブル フィルターを State テーブルに伝達し、14 行が表示されます（中西部地域は14の州から構成されます）。

  3. モデル リレーションシップを使用して 、State テーブル フィルターを Sales テーブルに伝達します。その結果、何千もの表示行 (中西部リージョンに属する州の売上ファクト) が表示されます。

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


FALSE()

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

静的ルールの定義は簡単で効果的です。 米国のリージョンが 6 つしかない Adventure Works の場合と同様に、少数のリージョンのみを作成する必要がある場合は、それらを使用することを検討してください。 ただし、欠点に注意してください。静的ルールの設定には、作成と設定に大きな労力が必要になる場合があります。 また、新しいリージョンがオンボードされたときに、データセットを更新して再発行する必要もあります。

設定するルールが多数あり、今後新しいルールを追加する予定がある場合は、代わりに動的ルールを作成することを検討してください。

動的ルール

動的ルールでは、(定数ではなく) 環境値を返す特定の 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 テーブルを含む変更されたモデル図を示しています。このテーブルには、Region と User Name という 2 つの列があります。

AppUser テーブルに適用される次の規則は、認証済みユーザーのリージョンへのデータ アクセスを制限します。


'AppUser'[UserName] = USERPRINCIPALNAME()

動的ルールの定義は、モデル テーブルにユーザー名の値が格納されている場合に簡単で効果的です。 これにより、データドリブン RLS 設計を適用できます。 たとえば、 AppUser テーブルに営業担当者を追加または削除する (または異なるリージョンに割り当てられている) 場合、この設計アプローチは機能します。

ロールを検証する

ロールを作成するときは、ロールをテストして、正しいフィルターが適用されていることを確認することが重要です。 Power BI Desktop で作成されたデータ モデルには、さまざまなロールが適用され、さまざまなユーザー名の値が渡されたときにレポートを表示できる View as 関数があります。

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 には、Power BI と同じテナントに存在する販売操作用の Azure SQL Database があるとします。 データベースは、RLS を適用して、さまざまなデータベース テーブル内の行へのアクセスを制御します。 ロールなしでこのデータベースに接続し、Power BI サービスに発行する DirectQuery モデルを作成できます。 Power BI サービスでデータ ソースの資格情報を設定すると、 SSO が有効になります。 レポート コンシューマーが Power BI レポートを開くと、Power BI は自分の ID をデータ ソースに渡します。 データ ソースは、レポート コンシューマーの ID に基づいて RLS を適用します。

S O オプションが有効になっているデータ ソース資格情報ウィンドウを示すスクリーンショット。

Azure SQL Database RLS の詳細については、「 行レベルのセキュリティ」を参照してください。

注

SSO 認証を使用してデータ ソースから DirectQuery テーブルを参照する計算テーブルと計算列は、Power BI サービスではサポートされていません。

SSO をサポートするデータ ソースの詳細については、 DirectQuery ソースのシングル サインオン (SSO) に関するページを参照してください。