データ損失防止（DLP）ポリシー
データ損失防止 (DLP) は、Microsoft Power Platform エコシステム内でデータ セキュリティとコンプライアンスを維持する上で重要な要素です。
ガードレールとして機能するデータ ポリシーを作成して、ユーザーが意図せずに組織データを公開するリスクを低減することができます。 Power Apps、Power Automate、そして Microsoft Copilot Studio のコア コンポーネントは、コネクタを使用してデータを列挙、入力、プッシュ、プルすることです。 管理センター のデータ ポリシー を使用すると、管理者はさまざまな方法でこれらのコネクタへのアクセスを制御し、組織内のリスクを軽減できます。 Power Platform
この概要では、コネクタに関連する高レベルの概念と、ポリシーの設定時またはポリシーの変更時に考慮すべきいくつかの重要な考慮事項について説明します。
コネクタ
コネクタは、最も基本的なレベルでは、RESTful なアプリケーション プログラミング インターフェイス (API とも呼ばれます) の厳密に型指定された表現です。 例えば、Power Platform API は、Power Platform 管理センターの機能に関連するいくつかの操作を提供します。
ラッピングの際には Power Platform API をコネクタに組み込むことで、作成者や市民開発者がローコード アプリ、ワークフロー、チャットボットで API を利用しやすくなります。 例えば、Power Platform for Admins V2 コネクタは、Power Platform API では、「レコメンデーションを取得」アクションをフローにドラッグ アンド ドロップするだけです。
この記事で紹介されているコネクタにはいくつかの種類があり、それぞれにデータ ポリシー内での機能があります。
認証済みのコネクタ
認定コネクタとは、セキュリティ、信頼性、コンプライアンスに関する Microsoftの標準を満たしていることを確認するために、厳格なテストと認定プロセスを経たコネクタを指します。 これらのコネクタは、データの整合性とセキュリティを維持しながら、他の Microsoft サービスや外部サービスと統合するための信頼性の高い手段をユーザーに提供します。
認定コネクタの詳細については、認定資格提出ガイドラインを参照してください。
カスタム コネクタ
カスタム コネクタを使用すると、作成者は独自のコネクタを作成して、認定コネクタの標準セットでカバーされていない外部システムまたはサービスと統合できます。 カスタム コネクタは柔軟性とカスタマイズ オプションを提供しますが、データ ポリシーに準拠し、データ セキュリティが損なわれないように慎重に検討する必要があります。
カスタム コネクタの作成と管理の詳細について説明します。
仮想コネクタ
仮想コネクタは、管理者が制御するためにデータ ポリシーに表示されるコネクタですが、RESTful API に基づいていません。 仮想コネクタの急増は、データ ポリシーが Power Platform で最も人気のあるガバナンス制御の 1 つであることに起因しています こうしたタイプの「オン/オフ」機能は、環境グループ内のルールとしてさらに多く登場することが予想されます。
Microsoft Copilot Studio 管理用にいくつかの仮想コネクタが提供されています。 これらのコネクタにより、Copilot とチャットボットのさまざまな機能をオフにできるようになります。
仮想コネクタと、Microsoft Copilot Studio のデータ損失防止におけるその役割について説明します。
つながり
作成者がアプリまたはフローを構築し、データに接続する必要がある場合は、上記のコネクタ タイプのいずれかを使用できます。 コネクタが最初にアプリに追加されると、その特定のコネクタでサポートされている認証プロトコルを使用して接続が確立されます。 これらの接続は保存された資格情報を表し、アプリまたはフローをホストしている環境内に保存されます。 コネクタ認証の詳細については、データソースへの接続と認証を参照してください。
設計時とランタイムの比較
管理者がコネクタ全体またはコネクタの特定のアクションへのアクセスを制限することを選択した場合、作成者のエクスペリエンスと、以前に作成されたアプリ、フロー、チャットボットの実行の両方に影響があります。
作成者エクスペリエンス (多くの場合、デザイン時 エクスペリエンスとも呼ばれます) では、作成者が操作できるコネクタが制限されます。 データ ポリシーによって MSN Weather コネクタの使用がブロックされている場合、作成者はこれを利用するフローまたはアプリを保存できず、代わりにコネクタがポリシーによってブロックされているというエラー メッセージが表示されます。
毎日午前 3 時など、事前に定義されたスケジュールでアプリが実行されたり、フローが実行されたりするエクスペリエンスは、多くの場合、ランタイム エクスペリエンスと呼ばれます。 先ほどの例を続けると、以下で説明するバックグラウンド プロセスによって接続が非アクティブ化された場合、結果として、アプリまたはフローは、MSN Weather 接続が切断され、解決が必要であるというエラー メッセージを表示します。 作成者が接続を更新して修正しようとすると、デザイン時のエクスペリエンスで、コネクタがポリシーによってブロックされているというエラーが発生します。
ポリシー変更のプロセス
新しいデータ ポリシーが作成されるか、既存のポリシーが更新されると、サービスの Power Platform エコシステム内で特定のプロセスがトリガーされ、顧客のテナントにあるリソース セット全体にそれらのポリシーを適用するのに役立ちます。 このプロセスでは、以下の手順に従います。
- データ ポリシー構成は顧客管理レベルで保存されます。
- 構成は、顧客テナント内の各環境にカスケードされます。
- 各環境のリソース (アプリ、フロー、チャットボットなど) は、更新されたポリシー構成を定期的にチェックします。
- 構成の変更が検出されると、各アプリ、フロー、チャットボットが評価され、ポリシーに違反していないかどうかが確認されます。
- 違反が発生した場合、アプリ、フロー、またはチャットボットは 一時停止 または 隔離 状態になり、動作できなくなります。
- 接続がスキャンされます。 ポリシーによってコネクタ全体がブロックされると、接続は動作できないように 無効 状態に設定されます。
- 実行中であり、非アクティブな接続を使用しようとするリソースは、実行時に失敗します。
重要
ランタイムの適用は接続の状態に依存します。 まだ非アクティブ化されていないか、まだスキャンされていない場合は、実行時にエラーなしで接続を実行できます。
待機時間に関する考慮事項
データ ポリシーを効果的に実装するのにかかる時間は、環境の量と環境内のリソースに基づいて顧客ごとに異なります。 顧客が使用するアプリ、フロー、チャットボットの数が多いほど、ポリシーの変更が完全に有効になるまでの時間が長くなります。 最も極端なケースでは、完全な施行までの待ち時間は 24 時間です。 ほとんどの場合、1 時間以内です。