Power BI と Microsoft Fabric における動的行レベル セキュリティの実装：アーキテクチャ、DAX パターン、エンタープライズ級のガバナンス

By Mirko Peters · 2025-11-21 · Updated 2025-11-26

Power BI と Microsoft Fabric で動的行レベル セキュリティを実装し、ユーザーのデータアクセスを制御するとともに、コンプライアンスを確保し、組織の変化に対応します。

Automatically translated with AI from the original post. Read the English original

動的行レベル セキュリティは、変化し続けるシステムとして捉えてください。組織とともに成長し、変わっていきます。データモデルの設計、DAX 式、ユーザー ID、ガバナンスが、Power BI と Microsoft Fabric でセキュリティがどのように動作するかを決めます。正しく設定すれば、特定のデータを誰が閲覧できるかを選べるようになります。

重要なポイント

• 動的行レベル セキュリティは、会社のニーズに合わせて変化させられます。各ユーザーの ID を確認し、特定のデータを誰が閲覧できるかを選択できます。

• クラウドでセキュリティを確保するには、USERPRINCIPALNAME() を使用します。この関数により、ユーザーは自分のデータだけを閲覧できます。情報を安全に保つ助けになります。

• セキュリティ設定とユーザー グループを定期的に確認してください。閲覧すべきでないデータが見られてしまうことを防ぎます。データを安全に保つ助けになります。

• ユーザーのアクセス許可を管理するセキュリティ テーブルを明確に設計してください。会社が拡大しても、誰が何を閲覧できるかを制御しやすくなります。

• クラウドで実際のユーザーを使い、セキュリティ ルールをテストしてください。データが安全であることを確認でき、ユーザーは許可された内容だけを閲覧できるようになります。

行レベル セキュリティ システムの見直し

モデル主導のシステムとしてのセキュリティ

行レベル セキュリティは、分析プラットフォームのさまざまな要素をつなぐシステムです。データモデルを作成する時点で、データセキュリティの構築が始まります。テーブルの設定、テーブル同士の接続、ロールの定義によって、ユーザーに見えるデータが変わります。会社が成長したり新しいチームが加わったりした場合は、セキュリティ ルールを更新する必要があります。行レベル セキュリティは一度設定して終わりにするものではありません。ビジネスの変化や新たなニーズに合わせて変わっていくものです。

ヒント：データモデルを定期的に確認してください。適切なモデルはセキュリティの管理を容易にし、ミスの回避にも役立ちます。

モデルには明確なリレーションシップと専用のセキュリティ テーブルを持たせるべきです。これにより、特定のデータを閲覧できるユーザーを制御し、機密データを保護できます。動的行レベル セキュリティでは、ユーザーが閲覧できる内容を Fabric 内のグループや役割に対応づけられます。そのため、会社の体制が変わったときもアクセス許可をすばやく変更できます。

静的と動的の行レベル セキュリティの比較

データセキュリティの設定方法には、大きく分けて静的と動的の 2 種類があります。静的セキュリティは、あらかじめ決めたルールを使います。グループごとにロールとフィルターを作成します。小規模なチームや、アクセス権がほとんど変わらない場合に適しています。動的行レベル セキュリティは、サインインしているユーザーとマッピング テーブルを使います。ユーザーを確認し、閲覧できるデータをすぐに切り替えます。ユーザーが多く、ルールが頻繁に変わる大企業に適しています。

違いを示した表は次のとおりです：

動的行レベル セキュリティは、アクセスを制御する方法が豊富です。USERPRINCIPALNAME() やマッピング テーブルを使い、ユーザーを適切なデータに対応づけます。静的セキュリティは簡単ですが、会社の規模が拡大したり大きく変わったりすると、うまく機能しなくなります。

• 静的な行レベル セキュリティは、あらかじめ決めたルールでデータを制限します。

• 動的な行レベル セキュリティは、ユーザーの身元に基づいて閲覧できる内容を変えます。

• 動的セキュリティは、ルールの多い大企業に最適です。

データを安全に保つため、自社のニーズに最も合う方法を選んでください。適切な計画と堅牢なモデルにより、機密データを保護し、分析環境を安全に保てます。

Fabric における動的行レベル セキュリティのパターン

DAX関数: USERPRINCIPALNAME() と USERNAME() の違い

Fabric では ID の仕組みを理解することが重要です。行レベル セキュリティの設定に使う主な関数は 2 つあります。USERPRINCIPALNAME() と USERNAME() です。どちらもレポートを閲覧しているユーザーを判別します。USERPRINCIPALNAME() は、クラウド上のユーザーのメール アドレスを返します。USERNAME() は主に Power BI Desktop で、ローカル アカウント名を返すことが多いです。クラウドで USERNAME() を使うと正しく動作しない可能性があり、その結果データの安全性が低下するおそれがあります。

ヒント: Fabric で動的な行レベル セキュリティを設定する場合は、必ず USERPRINCIPALNAME() を使用してください。この関数はユーザーのクラウド メール アドレスと照合するため、データを安全に保てます。

誤った関数を使用すると、本来表示すべきではないデータがユーザーに見えてしまう可能性があります。デスクトップだけでなく、クラウドでセキュリティをテストする必要があります。

安全な DAX パターンとアンチパターン

データを安全に保つには、動的な行レベル セキュリティに適した DAX パターンが必要です。最適な方法は、マッピング テーブルと動的ルールを使用することです。これにより、誰が何を見られるかを制御できます。

• 行フィルターを使うと、ユーザーが参照できる範囲を制限できます。リージョン、部門、アカウントごとにデータをブロックできます。

• 列マスクを使うと、ユーザーに応じて データを非表示にしたり、値を変更したりできます。

優れた DAX パターンでは、ルックアップを使ってユーザーとそのグループを照合します。多くのグループを持つ企業に適しています。次に良い例を示します。

Organizations[Id] = LOOKUPVALUE(
    AspNetUsers[OrganizationId],
    AspNetUsers[Email],
    USERPRINCIPALNAME()
)

このパターンでは、ユーザーのメール アドレスを確認し、そのグループを特定します。これを使うと、適切なデータだけを表示できます。この方法は、単純にメール アドレスを照合するだけの方法より優れています。企業の規模が拡大しても有効に機能し、データを安全に保てます。

注: ユーザーの変更や組織の拡大に伴って破綻する可能性があるため、メール アドレスをハードコードしたり、アクセス制御に計算列を使用したりしないでください。

データ漏えいを引き起こす可能性のある、望ましくないパターンがあります。

• クラウドで USERNAME() を使用する。

• ユーザーのメール アドレスやドメインをハードコードする。

• セキュリティ ロジックを計算列に配置する。

常に動的ルールとマッピング テーブルを使用してください。これにより、データ モデルがシンプルに保たれ、データも安全に保てます。

階層と PATH() 関数

管理者、チーム、部門ごとにセキュリティが必要な場合があります。そのような場合に階層が役立ちます。DAX の PATH() 関数を使うと、親子関係を構築できます。これを使えば、各レベルで誰が何を見られるかを制御できます。

たとえば、従業員 ID と上司の ID を含むテーブルを作成できます。PATH() は、各従業員から上司までの連鎖を構築します。その後、DAX を使用して各レベルのデータをフィルターできます。

PATH(Employee[EmployeeID], Employee[ManagerID])

この関数は、大企業向けの動的な行レベル セキュリティの設定に役立ちます。マネージャーは自分のチームのデータを参照でき、一般の従業員が必要以上の情報を見ることも防げます。

ヒント: 階層のセキュリティには PATH() を使用してください。これによりデータ モデルの柔軟性が高まり、データも安全に保てます。

行フィルター、列マスク、階層関数を組み合わせて使用できます。これにより、機密データを保護しつつ、組織の拡大に合わせてアクセスを制御できます。

ロールとリレーションシップの設計

セキュリティ テーブルの設計

動的な行レベル セキュリティには、セキュリティ テーブルを作成する必要があります。このテーブルは、どのユーザーがどのデータを参照できるかを示します。ユーザーのメール アドレス、グループ、アクセス レベルの列を用意してください。この構成により、組織の拡大に伴ってもデータを安全に保てます。
ロールを作成する際は、厳格なロールと広範なロールを分けて管理してください。あるロールですべてのデータが参照できると、行レベル セキュリティを設定した他のロールが正しく機能しない可能性があります。データを安全に保つため、ロール同士が競合しないようにする必要があります。

• ユーザーとアクセス許可の列が明確なセキュリティ テーブルを作成してください。

• ロールは重複しないように分けて管理し、問題の発生を防いでください。

• 変更に対応できるよう、セキュリティ テーブルを定期的に確認してください。

データ モデルのリレーションシップ

データ モデルの構築方法によって、アクセスの制御方法が変わります。テーブル間には単方向のリンクを使用してください。これによりモデルがシンプルになり、エラーを防げます。
事実テーブルにアクセス許可を配置するよりも、専用のセキュリティ テーブルを使用するほうが適切です。セキュリティ テーブルを部門や地域などの他のテーブルにリンクできます。これにより、ユーザーやグループごとにデータをフィルターできます。

ヒント: ブリッジ テーブルを使ってユーザーとデータを結び付けてください。これにより動的な行レベル セキュリティが機能し、データも安全に保てます。

ロールの粒度: 小さいロールと大きいロール

ロールの詳細度をどの程度にするかを決める必要があります。ロールを細かく設定するほど、きめ細かな制御が可能になります。ジョブやグループ単位でアクセスを付与できます。大きなロールは多くのユーザーを対象にできますが、状況が変わったときにリスクになることがあります。
各ロールを誰が持っているかを頻繁に確認してください。これによりデータを安全に保ち、必要に応じて変更できます。
制御性を高め、更新を容易にするには、小さなロールを選んでください。大きなロールは単純なグループには適している場合もありますが、大企業では問題を引き起こす可能性があります。

Fabric でのユーザーとグループの割り当て

Azure AD グループと個別ユーザー

Fabric では、ユーザーを Azure AD グループに追加することでアクセスを付与します。これにより、多数のユーザーのデータをまとめて制御できます。ユーザーを1人ずつ追加するより、グループを使うほうが安全です。グループを使うと、システムの管理にかかる手間が減ります。チームの構成が変わったときも、グループを素早く更新できます。グループをロールに関連付けると、データモデリングが容易になります。行レベルセキュリティのルールも、明確でシンプルな状態を保てます。

ヒント: アクセス制御には Azure AD グループを使用してください。ミスを減らし、時間を節約できます。

重複するグループとシャドウアクセス

重複するグループには注意が必要です。ユーザーが複数のグループに所属していることがあり、本来見るべきではないデータが見えてしまう場合があります。シャドウアクセスとは、この問題によってユーザーが余分なデータを見られてしまう状態です。これを防ぐには、グループの一覧を頻繁に確認してください。テーブルを使って、各グループに所属するユーザーを把握するのも有効です。適切なデータモデリングを行えば、問題を早期に発見できます。不要になったグループからはユーザーを削除し、データを安全に保ちましょう。

注: シャドウアクセスにより、非公開のデータが表示される可能性があります。グループの重複を解消して、システムを安全に保ちましょう。

定期的なアクセスレビュー

定期的にアクセスレビューを計画してください。各グループの所属者を定期的に確認し、グループの所有者に、誰がアクセス権を持つべきかを確認してもらいます。これにより、会社の成長に合わせて動的な行レベルセキュリティが機能し続けます。これらの確認には Fabric のツールを活用してください。古いユーザーを削除すると、データがより安全になります。分析システムをクリーンで安全な状態に保つことにもつながります。アクセスレビューを、ビジネスインテリジェンス業務の通常の一部にしてください。

• すべてのグループを確認する日程を決めてください。

• Fabric のツールを使って、グループの確認を行ってください。

• 各グループの所属者を確認するよう、所有者に依頼してください。

警告: 定期的なレビューにより、問題を引き起こす前に設定ミスを発見できます。

ID の解決: Desktop と Fabric の違い

ID 関数とクラウドの違い

Power BI Desktop と Microsoft Fabric では ID の仕組みが異なることを理解しておくことが重要です。Power BI Desktop では、USERNAME() は通常コンピューター名を返します。Microsoft Fabric では、USERPRINCIPALNAME() がクラウドのメールアドレスを返します。この違いはデータを保護するうえで重要です。クラウドで USERNAME() を使うと、本来見るべきではない人にデータが見えてしまう可能性があります。クラウドのレポートでは、必ず USERPRINCIPALNAME() を使用してください。これによりデータが保護され、会社の ID システムとも整合します。

ヒント: 行レベルセキュリティのルールはクラウドでテストしてください。Desktop でのテストでは、実際のユーザーのアクセス権は確認できません。

データセットの所有者とテナント設定

データセットの所有者を把握しておく必要があります。所有者は更新設定を変更でき、誰がデータを見られるかに影響します。所有者を変更すると、非公開データを閲覧できる人が変わってしまう可能性があります。テナント設定も重要です。これらの設定により、社内で ID がどのように扱われるかが決まります。レポートを公開する前にテナント設定を確認してください。データモデルが社内のセキュリティルールに沿っていることを確認しましょう。

行レベルセキュリティ漏えいの一般的な原因

クラウドでテストしないと、行レベルセキュリティを適切に管理できなくなる可能性があります。ユーザーが本来より多くのデータを閲覧してしまうことがあります。これは、誤った ID 関数を使用した場合や、グループのメンバーシップの更新を忘れた場合に起こり得ます。セキュリティテーブルを確認せずにデータモデルを変更した場合も、漏えいが発生することがあります。変更後は必ずデータセキュリティの設定を見直してください。クラウドでのテストと定期的な監査により、問題を早期に発見しましょう。

警告: データセキュリティの漏えいにより、非公開の情報が表示される可能性があります。組織を守るため、設定を頻繁に確認してください。

テスト、監査、ガバナンス

クラウドベースの行レベルセキュリティのテスト

クラウドでの行レベルセキュリティのテストは必ず行ってください。実際のユーザーに対してデータが安全に保たれているかを確認するためです。Desktop の「表示ユーザー」ツールはプレビューにすぎず、Microsoft Fabric でルールがどのように機能するかは示しません。レポートを公開したら、実際のユーザーとグループを使ってテストしてください。そうすることで、各ユーザーが閲覧できる内容を確認できます。テスト用アカウントを使い、ユーザーが自分のデータだけを見られているかを検証しましょう。ロールを変更したり、モデルを更新したりするたびに、必ず再度テストしてください。クラウドでのテストは、ビジネスに被害が出る前に問題を見つけるのに役立ちます。

ヒント: Desktop だけでなく、必ず実際のユーザーを使ってクラウドでテストしてください。これにより、データセキュリティを強固に保てます。

監査とレビューのための自動化

Fabric で監査とレビューを効率化するために、自動化を活用できます。自動化では、ワークスペースのアクセス許可、データフロー、秘密度ラベルをスケジュールに従って確認します。Microsoft Purview には、プラットフォーム全体のルールを追跡できるダッシュボードがあります。アクティビティ ログと管理 API を使えば、コンプライアンス上の問題を見つけられます。自動化により問題を早期に発見でき、時間の節約にもなります。監査担当者は、機密性の高い列が出どころからレポートに至るまでの全経路を確認できます。これにより、レビューはより迅速かつ正確になります。また、GDPR や HIPAA などの規制への準拠も、自動化によって容易かつ低コストで行えるようになります。

• アクセス許可とデータフローの自動チェックを設定します。

• ダッシュボードを使って、セキュリティルールの変更を監視します。

• アクティビティ ログを確認して、問題を素早く見つけます。

ドキュメント作成と変更管理

データセキュリティの仕組みを明確に保つには、適切な記録が欠かせません。セキュリティルール、グループの一覧、ロールの変更内容を文書化してください。モデルを変更したり新しいユーザーを追加したりしたときは、メモを更新します。明確な記録があれば、どのユーザーがどのデータを閲覧できるかを追跡しやすくなります。また、新しいチームメンバーがシステムを理解する助けにもなります。変更管理とは、更新を本番環境に反映する前に確認し、承認するプロセスのことです。これにより、会社の成長に合わせて行レベルセキュリティを安全に保てます。

注意: 記録は常に最新の状態に保ってください。これによりデータが保護され、問題にも迅速に対処できます。

行レベルセキュリティは、データと会社の成長に合わせて変化していくものと考えてください。堅牢な設定は、機密情報を安全に保つのに役立ちます。適切な DAX パターンを使い、ユーザー ID を適切に管理することで、データを保護できます。セキュリティを定期的に確認し、変更内容を記録しておくことで、問題を早期に発見できます。事前に計画しておけば、誰がデータを閲覧できるかを管理し、分析環境を安全に保てます。

• セキュリティ設定を定期的に確認してください。

• 変化に合わせてルールを更新し、データをより確実に保護してください。

• 常にプライバシーを最優先にしてください。

よくある質問

Power BI と Fabric における動的な行レベルセキュリティとは何ですか?

動的な行レベルセキュリティでは、レポートを閲覧しているユーザーに基づいてデータへのアクセスを制御できます。DAX 関数とマッピング テーブルを使い、ユーザーに適切なデータを割り当てます。

USERNAME() ではなく USERPRINCIPALNAME() を使うべき理由は何ですか?

USERPRINCIPALNAME() はユーザーのクラウド上のメール アドレスを返します。Power BI や Fabric では、この方法が最も適しています。USERNAME() はローカルの名前を返す場合があり、クラウドではセキュリティ上の問題を引き起こすことがあります。

Azure AD グループはセキュリティにどのように役立ちますか?

Azure AD グループを使うと、多数のユーザーのアクセスをまとめて管理できます。ユーザーをグループに追加し、ロールを割り当てます。これにより、セキュリティ設定がより簡単かつ安全になります。

セキュリティ テーブルとは何ですか、またなぜ必要なのですか?

セキュリティ テーブルは、ユーザー、グループ、アクセス許可を一覧にしたものです。特定のデータを誰が閲覧できるかを制御するために使います。会社が成長しても、データを安全に保つのに役立ちます。

クラウドでの行レベルセキュリティは、どのくらいの頻度でテストすべきですか?

ロール、グループ、データ モデルを変更するたびに、行レベルセキュリティをテストしてください。クラウドでのテストにより、実際のユーザーが閲覧できる内容を確認でき、問題を早期に発見できます。