Power Pagesポータルのセキュリティ強化：テーブルアクセス許可とスコープの詳細解説

By Mirko Peters · 2026-08-11

ポッドキャストブログへようこそ。Microsoft Power Platform上で顧客向けWebアプリケーションを構築する際、セキュリティは後回しにできません。Power Pagesは、Dataverseに直接接続された堅牢な外部ポータルを素早く公開できる優れたツールです。しかし、大きな力には大きな責任が伴います。特に、組織の機密データが誤って一般公開されたり、組織の境界を越えて漏えいしたりしないようにする責任です。

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

ポッドキャストブログへようこそ。Microsoft Power Platform上で顧客向けWebアプリケーションを構築する際、セキュリティは後回しにできません。Power Pagesは、Dataverseに直接接続された堅牢な外部ポータルを素早く公開できる優れたツールです。しかし、大きな力には大きな責任が伴います。特に、組織の機密データが誤って一般公開されたり、組織の境界を越えて漏えいしたりしないようにする責任です。

今回の投稿では、最近のエピソードで取り上げたセキュリティのアーキテクチャの中核概念を詳しく掘り下げます。まだお聴きでない場合は、Build Customer Portals with Power Pages and Dataverseのエピソードをぜひご覧ください。環境のセットアップ、外部IDの処理、最初のポータルソリューションのデプロイまでを一通り解説しています。

Power Pagesのセキュリティの仕組みを詳しく見ていきましょう。まずは、データの境界を計画する方法と、テーブルアクセス許可を使いこなす方法から始めます。

Power Pagesセキュリティの概要

Power Pagesサイトを初めて作成すると、プラットフォームは柔軟で高度にカスタマイズ可能なキャンバスを提供します。しかし、そのキャンバスの下には、Microsoft Dataverse環境への直接のパイプラインがあります。セキュリティ構成を誤ると、保護されていないエンドポイントや適切にスコープされていないリストビューを通じて、データベース内のすべてのレコードが公開される可能性があります。

Power Pagesのセキュリティは、多層防御の戦略に基づいています。外側の層には、Azure AD B2C、ローカルアカウント、外部IDプロバイダーなどの認証メカニズムがあり、ユーザーが本人であることを証明します。内側の層には、Webロールと Dataverseテーブルアクセス許可があります。これらのアクセス許可により、認証済みのIDが閲覧、作成、更新、削除できる内容が厳密に決まります。ここを正しく設定できるかどうかが、安全なエンタープライズポータルと、いつ大規模な情報漏えいが起きてもおかしくない状態との分かれ目になります。

データの境界とテーブルアクセス許可の計画

Power Pages Studioでボタンを一つでも押す前に、ホワイトボードを用意し、データの境界を丁寧に洗い出す必要があります。これは、ポータルプロジェクトのライフサイクル全体の中で、おそらく最も重要な15分間です。

まず、外部ユーザーに公開する予定のDataverseテーブルを網羅的に一覧化します。テーブルごとに、必要最小限のCRUD操作を明確に定義してください。顧客が本当に請求書を削除する必要があるでしょうか。それとも、読み取りと追加の権限だけで十分でしょうか。操作を定義したら、各テーブルの行スコープを決定します。

• 連絡先スコープ: ユーザーは、自身の連絡先レコードに直接関連付けられたレコードのみを操作できます。
• アカウントスコープ: ユーザーは、所属する会社、つまりアカウント全体に関連付けられたレコードを操作できます。
• グローバルスコープ: ユーザーは、テーブル全体のすべてのレコードを閲覧できます(通常は、公開されたナレッジベースの記事やメタデータ向けに使用されます)。

早い段階でこれらの境界を定義しておくことで、開発環境で何かを構成する前に、最小特権の原則に基づく基準を確立できます。

連絡先スコープとアカウントスコープの違い

Power Pagesを初めて扱う作成者が最も混乱しやすい点の一つが、連絡先スコープとアカウントスコープの違いを理解することです。適切でないスコープを選ぶと、関連する会社データが表示されなくなり、ユーザー体験が完全に損なわれるか、逆に機密データが権限のない人に意図せず公開されてしまう可能性があります。

連絡先スコープは、個人向けのコンシューマー型ポータルを想定して設計されています。ユーザーがログインしてサポートチケットを送信した場合、連絡先スコープのアクセス許可により、そのユーザーを主要な連絡先または作成者として明示的に指定しているケースのみを閲覧できます。同じ会社の別のユーザーがログインしても、同僚の個人的なサポートチケットは表示されません。

一方、アカウント スコープは、B2B ポータルのアーキテクチャ向けに設計されています。B2B のシナリオでは、アカウント マネージャーや購買担当の責任者が、取引先の親アカウントに紐づくすべてのケース、注文、請求書を参照できることが望ましいでしょう。テーブル アクセス許可にアカウント スコープを割り当てると、ポータルはログイン中のユーザーの連絡先レコードに紐づく親アカウントを評価し、その組織に属するすべての関連子レコードを表示します。Dataverse でこの関係を正しくマッピングすることが、B2B を成功させるうえで極めて重要です。

Web ロールの定義と「認証済みユーザー」の落とし穴の回避

Web ロールは、認証済みユーザーと Dataverse のテーブル アクセス許可をつなぐ役割を果たします。Power Pages には既定で「認証済みユーザー」というロールが含まれています。ここで、多くの管理者が危険なセキュリティの罠に陥ります。

既定では、ポータルへのログインに成功したユーザーは全員、自動的に認証済みユーザー ロールに割り当てられます。このロールに広範なテーブル アクセス許可、さらに悪いことにグローバル スコープのアクセス許可を設定すると、サイトに登録するすべてのユーザーが、その広すぎる権限を即座に継承してしまいます。これは重大なセキュリティ上のアンチパターンです。

代わりに、想定するユーザーのペルソナに合わせて、カスタムかつ粒度の細かい Web ロールを作成してください。例えば次のようになります。

• CustomerUser: ケースや注文などの業務テーブルに対して連絡先スコープを割り当てます。ユーザーは自分のやり取りを追跡できます。
• AccountManager: アカウント スコープを割り当て、指定された組織のリーダーが会社全体の資産を参照できるようにします。
• KnowledgeBaseViewer: グローバルに割り当てますが、公開されているサポート記事に対する読み取り専用の操作のみに厳密に制限します。

不要な既定のアクセス権は必ず削除し、組織内の関係に基づいて、目的別に作成されたロールがユーザーに明示的に割り当てられているようにしてください。

フィールド レベルの表示の強化と個人情報(PII)の保護

テーブル スコープによる行レベルのアクセス制御は、対策の半分にすぎません。個々の行や一覧に表示されるデータの内容にも十分注意する必要があります。電話番号、自宅住所、金融情報、社内の従業員メモなどの個人を特定できる情報(PII)が公開されると、GDPR や CCPA への違反といった重大なコンプライアンス問題につながるおそれがあります。

Power Pages でリストや基本的なフォームを作成する際は、ビューから機密性の高い列を必ず取り除いてください。フロントエンドのフォーム レイアウトで項目を非表示にしても、アクセス許可が広すぎれば、基盤となる Web API から内容を確認または取得できてしまいます。「PublicView」のような、安全で無害化された列だけを含む、専用の強化されたビューを活用してください。どうしても列をテーブルに残す必要がある場合は、Dataverse の列レベル セキュリティを実装して、データベース エンジンのレベルでアクセスを完全に制限することを検討してください。

ポータルのアクセス許可に対するペネトレーション テスト

セキュリティ モデルが機能していると単純に思い込んではいけません。実際に証明する必要があります。ポータル ソリューションをテスト環境や本番環境に展開する前に、テーブル アクセス許可とルーティング ロジックに対して、厳密なペネトレーション テストを実施してください。

定義したそれぞれの Web ロールについて、テスト用のユーザー アカウントを設定します。標準的な CustomerUser としてログインし、別の連絡先またはアカウントに属するデータの表示を試みてください。ブラウザーのアドレス バーで レコード ID を書き換え、直接 URL の操作や GUID の改ざんを試し、サーバーが不正なリクエストを正しくブロックするかを確認します。さらに、診断ログと監査ログを確認し、権限昇格の試みに対して適切な 403 Forbidden の応答が返されていることを検証してください。

まとめとベスト プラクティス

Power Pages ポータルを保護するには、綿密な計画、最小権限の原則の厳格な遵守、そして Dataverse のテーブル アクセス許可とスコープについての十分な理解が欠かせません。認証済みユーザー ロールのような危険な既定値から離れ、テーブル アクセスを連絡先またはアカウントのレベルに慎重にスコープし、フィールド レベルの表示を強化することで、高機能かつ非常に安全な顧客ポータルを構築できます。

この トピック を さらに深く 学び、外部 ID の設定、ソリューション アーキテクチャの設計、本番稼働の準備までを含む エンドツーエンドの実装ガイド を確認するには、関連する ポッドキャスト エピソード Build Customer Portals with Power Pages and Dataverse をぜひお聴きください。ご覧いただきありがとうございます。Microsoft Power Platform を使いこなすための 専門的な ヒント も引き続きお届けしますので、ぜひご期待ください。