Microsoft 365 Copilotを安全に導入するには、MFAを有効化するだけでは不十分です。Microsoftが示した2層のZero Trustリスクモデルでは、リスクを「誰がCopilotへアクセスできるか」と「認証後にCopilotがどのデータへ到達できるか」に分けて評価します。
結論として、今回の情報は緊急パッチや新しい設定項目の追加を告知するものではありません。Microsoft 365 Copilotの導入状況を点検するためのリスク評価モデルです。ただし、Copilotを導入済み、または利用者を拡大する予定の組織は、IDとデバイスだけでなく、SharePointやOneDriveの過剰共有、秘密度ラベル、DLP、コネクタ、監査ログまで確認する必要があります。(TECHCOMMUNITY.MICROSOFT.COM)
特に優先すべきなのは、次の3点です。
- MFA、条件付きアクセス、デバイス準拠性に抜けがないか
- Copilot利用者が不要なSharePoint、OneDrive、Teamsデータへアクセスできないか
- Copilotの操作と参照リソースを監査し、異常を検知できるか
Microsoft 365 Copilotの2層Zero Trustリスクモデルとは
2026年7月9日時点で公開・更新が確認できるMicrosoftの公式情報では、Microsoft 365 Copilotのリスクが次の2層に整理されています。
| 層 | 評価する内容 | 主な管理領域 | 対象リスク |
|---|---|---|---|
| Layer 1 | 誰がMicrosoft 365 Copilotへアクセスできるか | ID、サインイン、デバイス、モバイルアプリ、ライセンス | R1～R6 |
| Layer 2 | 認証後にCopilotがどの情報へ到達できるか | アプリ、データ、権限、DLP、コネクタ、監査、特権アクセス | R7～R13 |
Layer 1が「入口の安全性」、Layer 2が「入口を通過した後の到達範囲」です。
たとえば、MFAと条件付きアクセスを適切に設定していても、利用者が過去のプロジェクトサイトや機密資料へ不要な権限を持っていれば、Layer 2のリスクは残ります。反対に、データ権限を整理していても、退職者アカウントや未管理端末からCopilotへアクセスできれば、Layer 1が弱い状態です。
なお、この2層モデルは、Microsoftが従来示している「データ保護」「IDとアクセス」「アプリ保護」「デバイス管理」「脅威保護」「Teamsの安全な共同作業」「データに対するユーザー権限」という7つの保護レイヤーを置き換えるものではありません。既存のZero Trust施策を、Copilot特有の露出経路に沿って優先順位付けするための整理方法と考えるのが適切です。MicrosoftはZero Trustの基本原則として、明示的な検証、最小権限、侵害を前提とした設計を挙げています。(Microsoft Learn)
Copilotは新しい権限を与えないが、既存権限の影響を増幅する
Microsoft 365 Copilotは、利用者がアクセスを許可されているMicrosoft 365データだけを参照します。Copilotが独自にSharePointやOneDriveのアクセス権を追加するわけではありません。(Microsoft Learn)
ただし、「新しい権限を作らない」ことと「情報漏えいリスクが増えない」ことは同じではありません。
通常であれば、利用者が古いSharePointサイトから機密情報を見つけるには、サイトの存在を知り、フォルダーをたどり、複数のファイルを開く必要があります。Copilotを利用すると、既存権限の範囲内で情報を検索し、複数の資料から要点をまとめられます。
つまり、Copilotが増幅するのは権限そのものではなく、次の能力です。
- 情報を発見する速度
- 複数の情報を関連付ける能力
- 大量の文書を短時間で要約する能力
- 分散した機密情報を一つの回答へ集約する能力
そのため、従来は表面化しにくかった過剰共有や権限の放置が、Copilot導入後に大きなリスクとして現れる可能性があります。Microsoftも、過剰共有または管理不十分なコンテンツがCopilotの結果とリスクに影響すると説明しています。(Microsoft Learn)
Layer 1で確認する6つのアクセスリスク
Layer 1では、Microsoft 365 Copilotを利用できる人物、端末、アプリの信頼性を確認します。以下はMicrosoftが示した英語のリスク名を、管理者向けに日本語化したものです。(TECHCOMMUNITY.MICROSOFT.COM)
| ID | リスク | 想定される問題 | 管理者の確認点 |
|---|---|---|---|
| R1 | 管理されていないIDによるアクセス | 共有アカウント、休眠アカウント、退職者アカウント、侵害されたアカウントからCopilotを利用される | アカウントのライフサイクル、共有IDの有無、退職・異動時の無効化 |
| R2 | MFAが弱い、または未適用 | パスワード漏えいだけでCopilotと組織データへ到達される | 全利用者と管理者へのMFA適用、レガシー認証の遮断 |
| R3 | 未管理・非準拠デバイス | セキュリティ基準を満たさない端末からCopilotを利用される | Intune登録、準拠ポリシー、端末リスク、条件付きアクセス |
| R4 | 役割で絞り込まない広範なライセンス付与 | 利用目的やデータ保護状況を確認せず、部門全体へライセンスが拡大する | パイロットグループ、グループベースライセンス、利用目的と責任者 |
| R5 | サインイン時のリアルタイムリスク評価不足 | 不審な場所や侵害の兆候があるサインインを、そのまま許可する | ユーザーリスク、サインインリスク、リスクベースの条件付きアクセス |
| R6 | モバイルデバイスのアプリ保護ギャップ | 個人端末上でCopilotの生成内容を未承認アプリへコピーされる | Intuneアプリ保護ポリシー、コピー・保存・共有の制御 |
R4のライセンス管理を軽視しない
Microsoft 365 Copilotのライセンス付与は、単なる契約管理ではありません。誰にCopilotを利用させるかを決めるセキュリティ制御でもあります。
「営業部全員」「本社勤務者全員」といった単位で一括付与すると、過剰な権限を持つ利用者や、未管理端末を使う利用者まで対象に含まれる可能性があります。
最初は、次の条件を満たす利用者に限定するのが現実的です。
- 業務上の利用目的が明確である
- MFAと条件付きアクセスが適用されている
- 利用端末が管理対象またはアプリ保護対象である
- 利用者がアクセスできる主要サイトを確認済みである
- インシデント時の連絡先と責任者が決まっている
Microsoftも、必要な保護策を導入していない場合は、Copilotライセンスを割り当てる前に保護策を試験導入するよう案内しています。(Microsoft Learn)
Layer 2で確認する7つのデータ露出リスク
Layer 2では、正規の利用者が認証された後、Copilotがどのデータや外部サービスへ到達できるかを確認します。(TECHCOMMUNITY.MICROSOFT.COM)
| ID | リスク | 想定される問題 | 管理者の確認点 |
|---|---|---|---|
| R7 | SharePoint／OneDriveコンテンツの過剰共有 | 全社グループや大規模グループに共有された情報がCopilotの回答へ含まれる | 「全員」相当の共有、匿名リンク、古い共有リンク、外部共有 |
| R8 | 秘密度ラベルの適用漏れ | 機密情報を識別できず、暗号化や利用制限を適用できない | ラベル体系、公開ポリシー、既存データへの適用状況 |
| R9 | 過大なユーザー権限 | 異動前の権限や一時プロジェクトの権限が残り、不要な情報まで参照できる | グループ所属、サイト権限、アクセスレビュー、個別共有 |
| R10 | Copilot生成物をDLPで保護できていない | 複数資料から集約した機密情報が、回答、要約、下書きとして持ち出される | Copilot／エージェント向けDLP、出力先、例外設定 |
| R11 | プラグイン／コネクタによる到達範囲の拡大 | Microsoft 365外のデータや業務システムへ接続範囲が広がる | コネクタの権限、データ範囲、所有者、承認・廃止手続き |
| R12 | 監査・可視性の不足 | 誰が何を参照したか追跡できず、調査や検知が遅れる | Purview Audit、参照リソース、保持期間、SIEM連携 |
| R13 | 特権ユーザーによるデータ露出の増幅 | 広範な権限を持つ管理者や責任者のアカウント侵害時に影響が拡大する | PIM、Just-In-Timeアクセス、管理用アカウントの分離 |
R7とR9は似ているが、確認対象が異なる
R7はコンテンツ側の共有範囲に関するリスクです。たとえば、SharePointサイトが大規模なグループへ公開されている状態が該当します。
R9は利用者側の権限に関するリスクです。たとえば、異動した従業員に以前の部署の権限が残っている状態が該当します。
安全性を高めるには、両側から確認する必要があります。
- サイトから見て、誰がアクセスできるか
- 利用者から見て、どのサイトへアクセスできるか
サイト単位の共有設定だけを修正しても、個別共有やグループ所属が残っていれば過大な権限は解消されません。
Microsoft 365 Copilotで保護対象になるもの
2層モデルを実務へ落とし込む際は、保護対象を「文書」だけに限定しないことが重要です。
| 保護対象 | 主なリスク | 主な対策 |
|---|---|---|
| ユーザーID | アカウント侵害、退職者利用、共有ID | MFA、条件付きアクセス、IDライフサイクル管理 |
| 管理者・特権ID | 広範なデータへの到達、設定改変 | PIM、JIT、管理用アカウント分離 |
| PC・スマートフォン | 未管理端末、コピー、ローカル保存 | Intune準拠ポリシー、アプリ保護ポリシー |
| SharePoint・OneDrive | 過剰共有、古いサイト、不要な権限 | データアクセスガバナンス、アクセスレビュー |
| Teams・Exchangeの情報 | 会話、添付ファイル、メールの機密情報 | 秘密度ラベル、DLP、保持ポリシー |
| Copilotのプロンプトと応答 | 機密情報の入力、回答への集約 | 監査、DLP、保持、調査権限の制限 |
| Copilotが生成した文書 | 機密内容の再利用や外部共有 | ラベル継承、DLP、アプリ保護 |
| エージェント・コネクタ | 外部データや業務システムへの到達 | 承認制、最小権限、所有者・期限管理 |
| 監査証跡 | 調査不能、証拠不足 | Purview Audit、保持、定期レビュー |
Microsoftは、Copilotとエージェントの導入に伴うリスクを、データセキュリティ、AIセキュリティ、コンプライアンスとプライバシーの観点から管理するよう案内しています。(Microsoft Learn)
管理者が優先して確認すべき設定
IDとサインインを先に固める
最初にMicrosoft Entra IDの設定を確認します。データ側の対策を進めても、侵害されたアカウントから正規利用者としてアクセスされれば、Copilotを使って情報を探索される可能性があるためです。
最低限、次の項目を確認します。
- 管理者だけでなく、Copilot利用者全員にMFAを要求している
- レガシー認証を遮断している
- 条件付きアクセスポリシーの対象にMicrosoft 365サービスが含まれている
- 緊急用アカウントを除外する場合、利用手順と監視方法を定めている
- 退職者、休眠アカウント、共有アカウントを定期的に確認している
- 利用可能なライセンスがある場合、サインインリスクとユーザーリスクを評価している
MicrosoftのZero Trustガイドでも、全利用者へのMFA、管理者へのMFA、レガシー認証の遮断が基本対策として示されています。より高度な環境では、リスクベースの条件付きアクセスやアクセスレビューも検討対象です。(Microsoft Learn)
未管理端末とBYODの利用経路を確認する
PCをIntuneで管理していても、スマートフォンの利用経路が残っている場合があります。特にBYODを許可している組織では、端末をMDMへ登録していないからといって、無条件にCopilotを利用させるべきではありません。
Intuneのアプリ保護ポリシーを使うと、管理対象アプリ内の組織データについて、コピー、貼り付け、保存、共有先などを制御できます。Microsoftは、未管理端末であってもアプリ内の組織データを保護し、Copilotの生成内容が未承認アプリへコピーされる範囲を制限できると説明しています。(Microsoft Learn)
確認時は、「端末が登録されているか」だけでなく、次の利用経路を実際にテストします。
- 個人スマートフォンのMicrosoft 365アプリ
- モバイルブラウザー
- OutlookやTeamsから開くCopilot
- Copilotの回答を個人用アプリへコピーする操作
- ローカルストレージや個人クラウドへの保存
SharePointとOneDriveの過剰共有を可視化する
Copilot導入前に、すべての文書を完全に整理するのは現実的ではありません。まず影響の大きい共有から優先的に修正します。
確認対象になりやすいのは、次のサイトです。
- 全社または大規模グループに公開されている
- 外部共有や匿名リンクが多い
- サイト所有者が退職している
- 長期間更新されていない
- 人事、法務、財務、研究開発などの機密情報を含む
- 一時プロジェクト終了後もアクセス権が残っている
- メンバー数が業務上の想定より多い
Microsoftは、データアクセスガバナンスレポートによる過剰共有の特定や、サイト所有者へのアクセスレビューを案内しています。修正に時間がかかる場合は、Restricted Content DiscoveryやRestricted Access Controlを使い、利用者、Copilot、エージェントによる到達を一時的に制限できます。これらは権限整理の代替ではなく、修正中の露出を抑えるための手段です。(Microsoft Learn)
秘密度ラベルは「付ける」だけで終わらせない
秘密度ラベルは、文書の分類名を表示するだけの機能ではありません。暗号化、アクセス制限、外部共有制御などの保護設定と組み合わせて使う必要があります。
実務では、次の順序で設計します。
- 機密区分を「公開」「社内限定」「機密」「極秘」などに整理する
- 各区分で許可する共有先と操作を決める
- 秘密度ラベルへ保護設定を割り当てる
- Word、Excel、PowerPoint、Outlook、SharePoint、OneDriveで検証する
- 既存データへ段階的に適用する
- Copilotとエージェントでの処理結果を確認する
既定ラベルやラベル必須化は適用範囲を広げるうえで有効ですが、利用者教育や分類ルールが不十分なまま強制すると、誤ったラベルが増える可能性があります。Microsoftも、包括的なトレーニングなどがない状態では不正確なラベル付けにつながり得ると注意しています。(Microsoft Learn)
DLPは入力元と生成物の両方を確認する
Microsoft 365 CopilotのDLPでは、機密ファイルをCopilotやエージェントの処理対象から除外する対策に加え、生成された回答や文書の扱いも考える必要があります。
たとえば、個別の資料には顧客名、売上、契約条件が分散していても、Copilotがそれらを一つの回答へまとめると、生成物自体の機密性が高くなります。
DLPの設計では、次の点を確認します。
- Copilotとエージェントが処理できないラベルや情報種別
- 生成内容を貼り付けられるアプリ
- 外部送信、共有、印刷、ダウンロードの制御
- 業務上必要な例外と承認手続き
- 誤検知が発生した際の問い合わせ先
- ポリシー変更後のテスト方法
Microsoftの現在の案内では、Copilotやエージェントに特定の機密ファイルを処理させないDLPなど、一部の高度な制御は上位ライセンスを前提としています。利用できる機能は契約プランや展開状況によって異なるため、管理センターと最新のライセンス条件を確認してください。(Microsoft Learn)
DLPを設定しても、過大なアクセス権が自動的に解消されるわけではありません。権限の最小化を先に進め、DLPを追加の防御層として使うことが重要です。
エージェントとコネクタを台帳化する
Copilotの到達範囲は、エージェント、プラグイン、コネクタを追加すると広がります。Microsoft 365内の情報だけを確認していても、CRM、ファイル共有、チケット管理、社内データベースなどへ接続していれば、Layer 2の評価範囲に含める必要があります。
少なくとも、次の情報を台帳で管理します。
| 管理項目 | 記録する内容 |
|---|---|
| 名称 | エージェント、プラグイン、コネクタの名称 |
| 所有者 | 業務責任者と技術責任者 |
| 利用目的 | どの業務を支援するのか |
| 接続先 | Microsoft 365内外のシステム |
| 権限 | 読み取り、書き込み、実行など |
| データ範囲 | 参照できるサイト、テーブル、フォルダー |
| 対象利用者 | 利用を許可するグループ |
| 承認日・期限 | 導入日、次回レビュー日、終了予定日 |
| 廃止方法 | 接続解除、資格情報削除、データ処理停止の手順 |
「信頼できるベンダーの製品だから許可する」のではなく、実際に要求される権限とデータ範囲を確認します。使われていないコネクタや所有者不明のエージェントは、停止または再承認の対象です。
管理ダッシュボードで現在地を確認する
Microsoft 365管理センターでは、英語UIの場合、Copilot > Overview > SecurityからCopilotのセキュリティダッシュボードを確認できます。表示にはGlobal Reader、変更にはAI Administratorの役割が必要とされています。グローバル管理者を日常的な確認作業へ使うのではなく、必要最小限の役割を割り当てるのが適切です。(Microsoft Learn)
Microsoftは、AIリスクを確認するために次の2種類のダッシュボードを案内しています。
| ダッシュボード | 主な用途 |
|---|---|
| Microsoft 365管理センターのCopilotセキュリティダッシュボード | Microsoft 365 Copilotの過剰共有、DLP、データ保護、コンプライアンス |
| Microsoft Security Dashboard for AI | Entra、Defender、Purviewを横断した組織全体のAIリスク |
Microsoft Security Dashboard for AIは、2026年7月時点の公式情報ではプレビューとして案内されており、機能や対象範囲が変更される可能性があります。(Microsoft Learn)
Microsoft Purviewでは、DSPM for AIから監査の有効化状況を確認し、Microsoft 365 Copilot向けの画面で、過剰共有、データ保護、利用状況を確認できます。公式手順では、PurviewポータルのSolutions > DSPM for AIから監査状態を確認する流れが案内されています。管理画面の名称や配置は更新される場合があるため、見つからない場合はPurview内で「DSPM for AI」または「Audit」を検索してください。(Microsoft Learn)
監査ログと検知はどう変わるのか
Microsoft Purview Auditが組織で有効になっていれば、CopilotやAIアプリに関する利用者操作と管理者操作はAudit Standardの一部として自動的に記録されます。Copilot対応のためだけに、個別の監査機能を追加設定する必要はありません。ただし、監査自体が有効か、必要な保持期間を確保できているか、担当者が検索できるかは別途確認が必要です。(Microsoft Learn)
Copilotの監査レコードには、利用者、日時、利用場所に加え、回答生成時に参照したファイル、サイト、メールなどのリソース情報が含まれます。AccessedResourcesには、リソースID、サイトURL、名称、種類、秘密度ラベルIDなどが記録される場合があります。(Microsoft Learn)
これにより、調査時に「何を質問したか」だけでなく、「どの情報が回答生成に使われたか」を追跡しやすくなります。
検知ルールに組み込みたいシナリオ
| 検知シナリオ | 懸念されるリスク | 初動対応 |
|---|---|---|
| 高リスクのサインイン後にCopilotが利用された | 侵害アカウントによる情報探索 | セッション無効化、本人確認、参照リソース調査 |
| 短時間に多数のサイトや機密資料が参照された | 大量収集、内部不正、資格情報侵害 | 利用者の業務確認、アクセス範囲の一時制限 |
| 特権ユーザーが広範な機密情報を参照した | R13による影響範囲の拡大 | 特権セッション、PIM履歴、参照ファイルを確認 |
| 新しいコネクタやプラグインが追加された | 未承認データ接続 | 所有者、権限、接続先、承認記録を確認 |
| DLPまたはInsider RiskのアラートとCopilot利用が重なった | 機密情報の持ち出し | プロンプト、応答、参照リソース、出力先を調査 |
| 未管理モバイル端末から利用された | コピーや個人アプリへの保存 | 条件付きアクセスとアプリ保護ポリシーを確認 |
これらは組織独自の検知ルール例です。取得できる属性、リアルタイム性、SIEM連携、アラート機能は、利用サービスとライセンスによって異なります。
DSPM for AIでは、Copilotやエージェントの総インタラクション数、機密情報を含むインタラクション、秘密度ラベル、潜在的に危険なAI利用などを確認できます。Activity Explorerでプロンプトと応答を表示するには、Microsoft Purviewの所定の閲覧権限が必要です。(Microsoft Learn)
プロンプトや応答には、個人情報、顧客情報、社内相談などが含まれる可能性があります。調査担当者へ無制限に閲覧権限を与えず、利用目的、承認手続き、操作記録、保持期間を定めることが重要です。
自社に対応が必要か判断する基準
今回の情報を受けて、すべての組織が直ちに設定変更しなければならないわけではありません。次の基準で対応の緊急度を判断できます。
| 現在の状態 | 対応判断 | 最初に行うこと |
|---|---|---|
| Copilotを多数の利用者へ展開済みで、MFAや条件付きアクセスに例外が多い | 最優先で対応 | 対象者、例外、未管理端末の利用経路を特定する |
| ID対策は完了しているが、SharePointの過剰共有状況が不明 | 拡大前に対応 | 過剰共有レポートと高機密サイトの権限を確認する |
| 少人数のパイロットで、監査も有効になっている | 限定運用を続けながら改善 | Layer 2の未確認項目を記録し、拡大条件を決める |
| Copilotは未導入だが、近くライセンスを付与する予定 | 緊急変更は不要だが事前対応が必要 | 導入対象者のMFA、端末、主要サイト権限を点検する |
| エージェントや外部コネクタを利用している | Layer 2の再評価が必要 | 接続先、権限、所有者、利用期限を台帳化する |
| 管理者や経営層がCopilotを利用している | 特権アクセス対策を優先 | PIM、JIT、管理用アカウント分離、監査を確認する |
| 13項目すべてについて設定と証跡を提示できる | 緊急の変更は不要 | 定期レビューと新規利用者追加時の再評価を続ける |
Copilotをまだ導入していない場合でも、過剰共有、休眠アカウント、過大な権限はMicrosoft 365全体のリスクです。今回のモデルを、Copilot導入準備だけでなく、既存テナントの権限整理に利用できます。
対応は4段階で進める
最優先はアクセス経路の遮断
最初に、Layer 1の抜けを解消します。
- Copilotのライセンス保有者を一覧化する
- MFAと条件付きアクセスの適用状況を確認する
- 退職者、休眠、共有アカウントを特定する
- 未管理端末とモバイルアプリの利用条件を確認する
- パイロットグループ外へのライセンス付与を止める
完了条件は、対象利用者全員について、ID、サインイン、端末の保護状況を説明できることです。
次にデータ到達範囲を縮小する
Layer 2では、影響の大きいデータから修正します。
- 全社共有や大規模グループ共有を抽出する
- 高機密サイトの所有者とメンバーを確認する
- 異動者や終了プロジェクトの権限を削除する
- 所有者不在のサイトを再割り当てする
- 修正中のサイトは検索・アクセス制限を検討する
- 秘密度ラベルと保護設定を段階的に適用する
すべてのサイトを一度に整理するのではなく、機密度、共有範囲、利用者数を基準に優先順位を付けます。
生成物と拡張機能を制御する
続いて、Copilotが作る情報と、Copilotから接続する外部サービスを管理します。
- Copilotとエージェント向けDLPを検討する
- 生成文書のラベル継承をテストする
- モバイルからのコピーや保存を確認する
- コネクタとエージェントを承認制にする
- 特権利用者の常時権限を減らす
最後に監査を運用へ落とし込む
監査ログを有効にしただけでは、異常を発見できません。
- 実際にCopilotを利用し、監査レコードを検索する
- 参照リソースが確認できるかテストする
- 調査担当者の役割と閲覧権限を決める
- 重大アラートの通知先を設定する
- ID、DLP、Insider Risk、Copilot監査を関連付ける
- インシデント時の停止、調査、復旧手順を文書化する
「ログがあるはず」ではなく、テスト操作を実施して検索できることを確認する必要があります。
よくある失敗と回避方法
| 失敗しやすい判断 | 問題点 | 回避方法 |
|---|---|---|
| Copilotは既存権限に従うので安全だと考える | 既存の過剰共有と不要な権限がそのまま利用される | 権限の正しさと情報探索能力の増幅を分けて評価する |
| ライセンスを先に配り、後からデータを整理する | 未確認の利用者とデータ範囲が急速に広がる | パイロットグループと拡大条件を設定する |
| DLPだけで情報漏えいを防ごうとする | 過大なアクセス権やコネクタ権限は残る | 権限整理、ラベル、DLPを多層で組み合わせる |
| PCだけを管理してモバイルを確認しない | BYODから生成内容を持ち出される可能性がある | Intuneアプリ保護ポリシーと実機テストを行う |
| 秘密度ラベルの名称だけを作る | 暗号化や共有制御が伴わず、保護効果が限定される | ラベルごとの保護動作と利用ルールを定義する |
| 監査を有効にしただけで完了とする | 異常が起きても誰も確認せず、調査手順もない | 定期レビュー、検知ルール、インシデント手順を整備する |
| 調査担当者全員にプロンプト閲覧権限を与える | プライバシーや内部情報への新たなアクセスリスクが生じる | Just-In-Time付与、承認、操作記録を導入する |
Microsoft 365 CopilotのZero Trust対応チェックリスト
- [ ] Copilotのライセンス保有者を一覧化した
- [ ] エージェント、プラグイン、コネクタを一覧化した
- [ ] Copilot利用者全員にMFAが適用されている
- [ ] 条件付きアクセスの対象と例外を確認した
- [ ] 退職者、休眠、共有アカウントを確認した
- [ ] 未管理端末とモバイルアプリの利用条件を確認した
- [ ] SharePointとOneDriveの過剰共有を確認した
- [ ] 異動者や終了プロジェクトの権限を見直した
- [ ] 高機密情報へ秘密度ラベルと保護設定を適用した
- [ ] Copilotおよびエージェント向けDLPの要否を判断した
- [ ] 特権利用者にPIMやJITアクセスを適用した
- [ ] Microsoft Purview Auditが有効になっている
- [ ] Copilotの監査レコードを実際に検索できた
- [ ] プロンプトと応答を閲覧できる担当者を限定した
- [ ] インシデント発生時の停止・調査・復旧手順を定めた
- [ ] 利用者追加時とコネクタ追加時の再評価手順を定めた
まず「誰が使えるか」と「何が見えるか」を分けて確認する
Microsoft 365 Copilotの2層Zero Trustリスクモデルが示しているのは、強固な認証だけでも、データ保護だけでも不十分だということです。
Layer 1では、ID、MFA、条件付きアクセス、端末、モバイルアプリ、ライセンス付与を確認します。Layer 2では、SharePointとOneDriveの共有、ユーザー権限、秘密度ラベル、DLP、コネクタ、監査、特権アクセスを確認します。
最初に行うべき作業は、Copilot利用者の一覧化、条件付きアクセスの適用確認、過剰共有サイトの抽出、Purview Auditの検索テストです。この4点で現状を可視化したうえで、未確認項目が残っている間はライセンスやエージェントの対象拡大を抑えます。
「設定したか」ではなく、「対象者全員へ適用され、監査証跡で確認できるか」を完了基準にすることが、Microsoft 365 CopilotをZero Trustで運用するための重要なポイントです。
コメント