Microsoft 365 Copilotのアクセスリスク対策としてMicrosoftが示した要点は、Copilot専用の新しい防御機能を追加することではなく、Microsoft EntraのConditional AccessとMicrosoft Intuneのデバイス・アプリ保護を、Copilot利用者へ確実に適用することです。
2026年7月9日時点で公開・確認されたMicrosoft FastTrackの公式情報では、「誰が、どのID・デバイス・アプリからMicrosoft 365 Copilotへアクセスできるか」を左右する6つのリスクが整理されています。公開内容は、テナント設定を自動的に変更するアップデートではありません。既存のZero Trustコントロールを、Copilotの展開範囲に合わせて設計・検証するための実装ガイドと捉えるのが適切です。(TECHCOMMUNITY.MICROSOFT.COM)
そのため、次のいずれかに該当する組織は対応が必要です。
- Microsoft 365 Copilotのライセンスを部門単位や個別操作で広く割り当てている
- MFAが一部のユーザーにしか適用されていない
- レガシー認証を許可している
- 管理外デバイスや非準拠デバイスからMicrosoft 365へアクセスできる
- 個人スマートフォンでIntuneアプリ保護ポリシーを使用していない
- サインインリスクやユーザーリスクをConditional Accessで評価していない
一方、すでにこれらの対策を導入している場合も、ポリシーの対象範囲、除外アカウント、ライセンス割り当て、監査ログを再確認する必要があります。なお、今回のIdentity・Device対策だけでは、SharePointやOneDriveの過剰なアクセス権、機密情報のラベル付け不足、Copilotコネクタのガバナンスといった「認証後にCopilotが何へアクセスできるか」という問題は解決しません。
Microsoft 365 CopilotのアクセスリスクをZero Trustに対応づけた公式情報とは
Microsoftは今回、Microsoft 365 Copilotに関するリスクを、Zero TrustのIdentityとEndpointsの観点から整理しました。公式記事では、Copilotへアクセスできるユーザーやデバイスを決める領域を「Layer 1」と位置づけ、R1からR6までの6つのリスクを示しています。(TECHCOMMUNITY.MICROSOFT.COM)
これは「Copilotのセキュリティ設定」という単独の管理項目を追加する話ではありません。実際には、次の既存サービスを組み合わせてアクセス可否を判断します。
| サービス | 主な役割 |
|---|---|
| Microsoft 365 Copilot | 保護対象となるAIサービス |
| Microsoft Entra | ID管理、MFA、Conditional Access、サインインリスク評価 |
| Microsoft Intune | デバイスコンプライアンス、アプリ保護ポリシー |
| Microsoft Defender for Endpoint | 端末の脅威レベルやデバイスリスクの検出 |
| Microsoft Purview | Copilot操作、参照リソース、管理者操作の監査 |
MicrosoftのZero Trustガイダンスでは、「明示的に検証する」「最小権限を使用する」「侵害を前提とする」という原則に沿って、ID、アプリ、デバイス、データなど複数の保護層を構成するよう案内されています。Copilotを導入する前、または利用者を拡大する前に、これらの保護をパイロット展開しておくことが推奨されています。(Microsoft Learn)
Layer 1とLayer 2を分けて考える
Microsoft 365 Copilotのリスク対策では、「アクセスできる人」と「アクセス後に参照できるデータ」を分けることが重要です。
| 区分 | 管理する内容 | 主な対策 |
|---|---|---|
| Layer 1 | 誰が、どのデバイス・アプリからCopilotへアクセスできるか | MFA、Conditional Access、デバイスコンプライアンス、アプリ保護、ライセンス範囲 |
| Layer 2 | 認証後のCopilotが、どのデータへアクセスできるか | SharePoint・Teams・OneDriveの権限、秘密度ラベル、DLP、コネクタ管理、アクセスレビュー |
Copilotが回答に使用するのは、そのユーザーがすでにアクセスを許可されているデータです。したがって、ユーザーのSharePointやTeamsの権限が過剰なら、強固なMFAと準拠デバイスを使用していても、Copilotが必要以上の情報を参照できる可能性は残ります。(Microsoft Learn)
今回のIdentity・Device対策は、アカウントの乗っ取りや危険な端末からのアクセスを防ぐものです。データの過剰共有対策は、別の作業として並行して進める必要があります。
今回のZero Trustコントロールが保護する範囲
IdentityとDeviceのコントロールによって軽減できるのは、主に次のアクセス経路です。
| 保護対象 | 想定される問題 | 対応するコントロール |
|---|---|---|
| ユーザーアカウント | 退職者、休眠アカウント、侵害されたIDの利用 | Entra ID Governance、Lifecycle Workflows、アクセスレビュー |
| 認証処理 | パスワードだけの認証、MFAの未適用、レガシー認証 | MFA、認証強度、レガシー認証のブロック |
| Windows・macOSなどの端末 | 管理外端末、古いOS、侵害された端末 | Intuneコンプライアンスポリシー、Conditional Access |
| モバイルアプリ | 個人アプリへのコピー、保存、共有 | Intuneアプリ保護ポリシー |
| Copilot利用者 | ライセンスの無秩序な拡大 | グループベースのライセンス割り当て、アクセスレビュー |
| 危険なサインイン | 漏えい資格情報、匿名IP、通常と異なるアクセス | Entra ID Protection、リスクベースのConditional Access |
反対に、次の問題は今回のコントロールだけでは解決できません。
- SharePointサイトが全社員へ公開されている
- 古いプロジェクトのTeamsメンバーが削除されていない
- 機密文書へ秘密度ラベルが設定されていない
- DLPポリシーがCopilotの利用シナリオをカバーしていない
- Copilotエージェントやコネクタの接続先が適切に審査されていない
「準拠端末から正規ユーザーがアクセスしているため安全」と判断せず、データ権限の最小化も別レイヤーで確認することが重要です。
Microsoftが示した6つのアクセスリスクと対策
今回の公式情報で整理された6つのリスクは、次のとおりです。
| リスク | 内容 | 主な対策 | 優先度 |
|---|---|---|---|
| R1 | 管理されていないIDアクセス | IDライフサイクル管理、アカウント停止の自動化 | 高 |
| R2 | 弱い、または未適用のMFA | MFA、認証強度、レガシー認証のブロック | 最優先 |
| R3 | 管理外・非準拠デバイス | Intuneコンプライアンス、Conditional Access | 最優先 |
| R4 | 役割に基づかないライセンス拡大 | 審査済みグループへのライセンス割り当て | 高 |
| R5 | サインイン時のリアルタイムリスク評価不足 | Entra ID Protection、リスクベースポリシー | 高 |
| R6 | モバイル端末のアプリ保護不足 | Intuneアプリ保護ポリシー | 高 |
R1：管理されていないIDアクセス
退職者、異動者、契約終了後の外部スタッフなどのアカウントが残っていると、そのIDを通じてCopilotを利用される可能性があります。
例えば、委託先担当者の契約が終了しても、EntraアカウントとCopilotライセンス、Teamsメンバーシップが残っていれば、アカウント侵害時の影響範囲が広がります。Copilotライセンスだけを回収しても、Microsoft 365内のデータアクセス権が残っていれば十分とはいえません。
Microsoft Entra Lifecycle Workflowsでは、入社、異動、退職に対応するJoiner・Mover・Leaverの処理を自動化できます。利用できない契約の場合も、人事情報を起点としてアカウント停止、グループ削除、ライセンス回収を行う手順を明確にする必要があります。(TECHCOMMUNITY.MICROSOFT.COM)
実務では、次の完了条件を設定します。
- 退職・契約終了時にアカウントを停止する期限が決まっている
- 異動時に旧部署のグループとCopilot利用グループを再評価する
- 休眠アカウントを定期的に検出している
- ゲストアカウントに有効期限または定期レビューを設定している
- Copilotライセンスの回収とデータ権限の削除を別々に確認している
R2：弱い、または未適用の多要素認証
パスワードだけでMicrosoft 365へアクセスできる状態では、資格情報の漏えいがそのままCopilotへのアクセスにつながります。また、レガシー認証を許可していると、最新のMFAやデバイス状態を評価できない経路が残る可能性があります。
Microsoftは、管理者と一般ユーザーへのMFA適用、レガシー認証のブロックを基本的なConditional Accessポリシーとして案内しています。ポリシーの対象には、Microsoft 365 Servicesと関連するSaaSアプリを含める必要があります。(TECHCOMMUNITY.MICROSOFT.COM)
最低限、次の状態を目指します。
- 管理者を含む全利用者へMFAを要求する
- 特権管理者にはフィッシング耐性のある認証方法を優先する
- レガシー認証をブロックする
- MFA除外には責任者、理由、有効期限を設定する
- 緊急アクセスアカウントは通常利用せず、利用状況を監視する
Copilotだけを対象にしたポリシーを作り、Microsoft 365の基盤サービスを対象外にすると、想定したアクセス制御にならない場合があります。CopilotはMicrosoft 365内の複数サービスと連携するため、Microsoft 365 Servicesまたは必要な関連リソース全体を対象にした設計が必要です。
R3：管理外または非準拠デバイス
MFAを通過した正規ユーザーであっても、マルウェアに感染した端末や更新されていない端末からCopilotを利用すれば、生成結果や参照データが流出する可能性があります。
Intuneのデバイスコンプライアンスポリシーでは、最低OSバージョン、ルート化・脱獄の有無、暗号化、脅威レベルなどを条件として端末を評価できます。評価結果をEntra Conditional Accessへ渡すことで、非準拠端末からのアクセスをブロックできます。(Microsoft Learn)
特に確認したいのが、Intuneの「コンプライアンスポリシーが割り当てられていないデバイス」の扱いです。既定値のままでは、ポリシー未割り当て端末が準拠と判断される構成があります。Conditional Accessと組み合わせる場合、Microsoftはポリシー未割り当て端末を非準拠として扱う設定を案内しています。(Microsoft Learn)
設定時は、次の順番を守ります。
- Windows、macOS、iOS、Androidなど、使用するプラットフォームごとにコンプライアンスポリシーを作成する
- パイロットユーザーへ割り当てる
- 少なくとも1台が準拠状態になることを確認する
- Conditional Accessをレポート専用モードで作成する
- サインインログで影響を確認する
- 対象を段階的に広げてポリシーを有効化する
Intune側のポリシーがない状態で「準拠デバイスを要求する」Conditional Accessを有効化すると、管理者を含むユーザーがアクセスできなくなるおそれがあります。Microsoftも、先にコンプライアンスポリシーを作成し、準拠端末を確保するよう注意しています。(Microsoft Learn)
R4：役割に基づかないCopilotライセンスの拡大
Copilotライセンスの割り当ては、単なる費用管理ではありません。Copilotを利用して既存データへアクセスできるユーザーを増やす、セキュリティスコープの変更でもあります。
Microsoftは、部門や所在地だけを条件にライセンスを広く付与するのではなく、名前と目的が明確で、セキュリティ審査済みのパイロットグループへグループベースで割り当てる方法を示しています。また、グループメンバーが引き続き適切かをアクセスレビューで確認することも挙げています。(TECHCOMMUNITY.MICROSOFT.COM)
Copilot利用グループへ追加する条件は、少なくとも次のように明文化します。
- 業務上の利用目的がある
- 上長またはデータオーナーの承認を得ている
- MFA登録が完了している
- 管理端末、準拠端末、または保護されたモバイルアプリを使用できる
- Copilot利用時の情報管理ルールを受講している
- 利用終了時の削除条件が決まっている
「営業部だから全員」「本社勤務だから全員」という割り当てでは、端末準備やデータ権限の確認が追いつかない場合があります。パイロット時は利用目的と保護状態を基準にし、本番展開後も直接割り当てされた例外ライセンスを定期的に洗い出すことが重要です。
R5：サインイン時のリアルタイムリスク評価不足
固定的なMFAポリシーだけでは、資格情報の漏えいや通常と異なるサインインを、その時点のリスクに応じて制御できません。
Microsoft Entra ID Protectionを利用できる環境では、ユーザーリスクとサインインリスクをConditional Accessの条件にできます。Microsoftのガイダンスでは、中または高リスクのサインインにMFAを要求し、高リスクユーザーには安全なパスワード変更などの修復処理を要求する構成が示されています。リスクベースのConditional Accessには、原則としてMicrosoft Entra ID P2相当のライセンスが必要です。(TECHCOMMUNITY.MICROSOFT.COM)
導入後は、ポリシーを作るだけでなく、次の運用を整えます。
- リスク検出をセキュリティ担当者が確認できる
- ユーザーが安全に自己修復できる条件を定義している
- 高リスク判定を放置しない運用期限がある
- 誤検知時の確認・解除手順がある
- Copilot利用者と特権管理者を優先的に監視する
R6：モバイル端末のアプリ保護ギャップ
個人所有のiPhoneやAndroid端末をMDMへ登録しない運用でも、Microsoft 365 CopilotやOfficeアプリを使用する可能性があります。この場合、デバイス全体を管理できなくても、業務アプリ内のデータを保護する必要があります。
Intune App Protection Policyは、管理対象アプリ内の組織データと個人データの間に境界を作ります。Copilotの生成結果を未承認アプリへコピーする、個人領域へ保存するといった操作を制限できます。端末をIntuneへ完全登録していない場合にも適用できる点が重要です。(Microsoft Learn)
Conditional Accessでは、対応するiOS・Androidアプリに「アプリ保護ポリシーを必須にする」条件を設定できます。ただし、先にIntune側のアプリ保護ポリシーを作成・割り当てておかないと、対象ユーザーが管理ポータルを含むリソースへアクセスできなくなる可能性があります。(Microsoft Learn)
また、2026年6月30日をもって、Conditional Accessの「承認済みクライアントアプリを必須にする」コントロールは読み取り専用になりました。既存の有効なポリシーは引き続き適用されますが、新しいポリシーでは「アプリ保護ポリシーを必須にする」を使用する必要があります。古いコントロールだけに依存している組織は、移行状況を確認してください。(Microsoft Learn)
管理者が優先して実施する設定手順
すべてのポリシーを一度に有効化すると、業務停止や管理者ロックアウトにつながります。次の順番で進めると、アクセスリスクと展開リスクの両方を抑えられます。
| 手順 | 実施内容 | 完了の判断基準 |
|---|---|---|
| 1 | Copilot利用者とライセンス割り当て方法を棚卸しする | 利用者、所属グループ、直接割り当て、承認者が一覧化されている |
| 2 | 緊急アクセス・サービスアカウントを整理する | 除外理由と監視方法が決まり、通常ユーザーと分離されている |
| 3 | IDライフサイクルを整備する | 退職・異動・休眠アカウントの処理期限が定義されている |
| 4 | MFAとレガシー認証ブロックを適用する | 対象外ユーザーが把握され、例外に期限がある |
| 5 | Intuneのコンプライアンスとアプリ保護を先に作成する | パイロット端末・アプリが準拠または保護済みと表示される |
| 6 | Conditional Accessをレポート専用で展開する | 想定外のブロック対象と未適用ユーザーを説明できる |
| 7 | 段階的に有効化して監査を継続する | サインイン、端末、アプリ、Copilot操作を追跡できる |
Conditional Accessの構成例
ポリシーを1つに詰め込みすぎると、どの条件でアクセスが失敗したのか分かりにくくなります。実務では、目的ごとに分けたうえで、命名規則を統一すると管理しやすくなります。
| ポリシー例 | 対象 | 主な制御 |
|---|---|---|
| CA01-Block-LegacyAuth | 原則として全ユーザー | レガシー認証をブロック |
| CA02-Require-MFA | 原則として全ユーザー | MFAまたは必要な認証強度を要求 |
| CA03-Require-CompliantDevice | 管理端末を使うパイロットグループ | 準拠デバイスを要求 |
| CA04-Require-APP-Mobile | iOS・Android利用者 | Intuneアプリ保護ポリシーを要求 |
| CA05-Risk-Based-Access | リスク評価対象ユーザー | サインイン・ユーザーリスクに応じて追加認証や修復を要求 |
これはそのまま全組織へ適用する設定値ではありません。対象リソース、ゲスト、緊急アクセスアカウント、業務用サービスアカウント、端末プラットフォームを確認したうえで調整してください。
「すべて必須」と「いずれか必須」を間違えない
Conditional Accessで複数の許可コントロールを選択した場合、次の2種類の評価方法があります。
- 選択したすべてのコントロールを必須にする
- 選択したコントロールのいずれか1つを必須にする
例えば、MFAと準拠デバイスの両方を要求したいのに「いずれか1つ」を選ぶと、MFAだけ、または準拠デバイスだけでアクセスできる構成になります。既定ではすべてのコントロールが必要ですが、既存ポリシーを複製・編集した場合も設定を確認してください。(Microsoft Learn)
レポート専用モードから段階的に有効化する
レポート専用モードでは、Conditional Accessの条件を評価しながら、原則としてアクセスをブロックせずに結果をサインインログへ記録できます。結果は、成功、失敗、ユーザー操作が必要、未適用などに分類されます。(Microsoft Learn)
確認する項目は次のとおりです。
- 本来対象になるユーザーへポリシーが適用されているか
- 意図しない除外グループがないか
- 利用中のアプリや端末が大量に失敗判定されていないか
- MFA登録が完了していないユーザーが何人いるか
- 非準拠となった原因をIntune側で説明できるか
- サービスアカウントや同期アカウントへ影響しないか
注意点として、準拠デバイスを要求するポリシーは、レポート専用モードでもmacOS、iOS、Androidでデバイス証明書の選択を求める場合があります。「レポート専用なら利用者には何も見えない」とは限りません。(Microsoft Learn)
What Ifだけで判断しない
Microsoft EntraのWhat Ifツールでは、ユーザー、対象リソース、端末プラットフォーム、クライアントアプリなどを指定し、どのConditional Accessポリシーが適用されるかをシミュレーションできます。
ただし、What Ifツールはサービス間の依存関係を評価しません。例えば、Teamsを対象にテストしても、依存先であるExchange Onlineへ適用されるポリシーの影響までは結果に含まれません。What Ifの結果だけで有効化せず、実際のサインインログとパイロットユーザーの動作確認を組み合わせてください。(Microsoft Learn)
監査・検知への影響
今回の公式情報が公開されたことで、Copilot専用の統合アラートが自動的に追加されるわけではありません。実務上の変化は、Entra、Intune、Purviewに分散している既存ログを、Copilot利用者を軸に関連づけて確認する必要性が高まる点です。
| 確認したい内容 | 主な確認先 | 確認できる情報 |
|---|---|---|
| 誰がアクセスしたか | Entraサインインログ | ユーザー、時刻、アプリ、IP、リスク、Conditional Access結果 |
| どのポリシーが作用したか | Conditional Access詳細 | 有効、レポート専用、適用、未適用、成功、失敗 |
| 端末が安全だったか | Intuneデバイスコンプライアンス | 準拠状態、非準拠となった設定、OS、最終チェックイン |
| モバイルアプリが保護されていたか | Intuneアプリ保護状態 | ユーザー、アプリ、管理方式、ポリシー、最終同期、保護状態 |
| Copilotが何を参照したか | Microsoft Purview Audit | 利用者、時刻、ホストアプリ、参照ファイル・サイト、ラベル、処理結果 |
Entraサインインログでポリシーの適用結果を確認する
Entraのサインインログでは、個別のサインインに対して、どのConditional Accessポリシーが適用されたかを確認できます。レポート専用ポリシーについても、条件を満たしたか、コントロールを満たせなかったか、対象外だったかが記録されます。(Microsoft Learn)
「Copilotへアクセスできた」という結果だけでなく、次の点を確認します。
- MFAは今回のサインインで満たされたのか
- 既存トークンのMFA情報で通過したのか
- デバイス情報が取得できているか
- ポリシー除外によってアクセスできたのか
- リスク条件が評価されたか
- 別のポリシーとの組み合わせで許可・拒否されたか
Intuneでデバイスとアプリの保護状態を確認する
デバイスコンプライアンスでは、端末が準拠・非準拠となった理由を設定単位で確認します。単に「非準拠端末が100台ある」と集計するだけではなく、OS更新不足、暗号化、脅威レベル、ポリシー未割り当てなど、原因別に対応担当を決める必要があります。(Microsoft Learn)
アプリ保護については、Intune管理センターの「Apps」「Monitor」「App protection status」から、ユーザー、アプリ、管理方式、ポリシー名、最終同期時刻、保護状態などを確認できます。個人端末からの利用が多い組織では、Copilot利用グループに含まれるユーザーが「Protected」の状態になっているかを重点的に確認します。(Microsoft Learn)
Purview AuditでCopilotの参照リソースを追跡する
監査が有効なテナントでは、Microsoft CopilotやAIアプリに関するユーザー操作と管理者操作がAudit Standardへ自動記録されます。Copilot監査のために、追加の専用設定を行う必要はありません。(Microsoft Learn)
監査レコードには、次のような情報が含まれます。
- Copilotを利用したユーザー
- 利用日時とホストアプリ
- Copilotが参照したファイル、メール、サイトなど
- 参照リソースの秘密度ラベルID
- 読み取り、作成、変更などの操作
- ポリシーによって制限された場合の情報
- 処理の成功・失敗
- 参照リソースでクロスプロンプトインジェクションが検出されたか
インシデント調査では、Purview Auditだけを見るのではなく、同じユーザーと時間帯のEntraサインインログを確認し、さらにIntuneで端末・アプリの状態を調べます。これにより、「誰が」「どの認証条件で」「どの端末から」「どのデータをCopilot経由で参照したか」を段階的に追跡できます。(Microsoft Learn)
自社で対応が必要かを判断するチェックリスト
次の項目のうち、1つでも「いいえ」または「不明」がある場合は、設定または調査が必要です。
| 確認項目 | いいえ・不明の場合の対応 |
|---|---|
| Copilot利用者を一覧化できる | ライセンス利用者と割り当て方法を出力する |
| 直接割り当てされたライセンスを把握している | グループベースへ集約し、例外を記録する |
| 全利用者へMFAが適用されている | Conditional Accessの対象と除外を見直す |
| レガシー認証をブロックしている | 利用状況を確認後、段階的にブロックする |
| 管理端末にはコンプライアンスポリシーがある | プラットフォーム別にIntuneポリシーを作成する |
| 管理外モバイルにはアプリ保護がある | APPを作成し、対応アプリへ割り当てる |
| P2環境ではリスクベースポリシーがある | ユーザー・サインインリスクを条件に追加する |
| 緊急アクセスアカウントを保護・監視している | 通常利用から分離し、除外と監視を設定する |
| レポート専用ポリシーを定期的に確認している | サインインログで失敗・未適用を分析する |
| Copilot操作をPurview Auditで検索できる | 監査の有効状態、権限、保持要件を確認する |
特に、MFA、レガシー認証、非準拠デバイス、モバイルのアプリ保護、ライセンス範囲の5項目は優先度が高い対策です。
設定時に失敗しやすいポイント
Intuneを準備する前にConditional Accessを有効化する
コンプライアンスポリシーやアプリ保護ポリシーを割り当てる前にアクセス条件を強制すると、利用者だけでなく管理者もブロックされる可能性があります。
必ずIntune側の状態を先に完成させ、パイロットユーザーで準拠・保護済みになることを確認してください。
Copilotだけを対象リソースにすればよいと考える
Microsoft 365 Copilotは、Microsoft 365内の複数サービスやデータへアクセスします。特定のCopilot画面だけを想定したポリシーでは、Teams、Exchange Online、SharePointなどの依存関係を見落とす可能性があります。
Microsoft 365 Servicesまたは関連リソース全体を対象にし、実際のサインインログで適用範囲を確認する必要があります。
MFAか準拠デバイスの「どちらか一方」で許可してしまう
複数の許可コントロールを「いずれか必須」にすると、意図したZero Trust要件より弱い条件になります。MFAと準拠デバイスの両方を要求する設計なら、「すべて必須」を選択します。
緊急アクセスアカウントを用意せず全ユーザーへ適用する
Conditional Accessの設定ミスで全管理者がロックアウトされると、ポリシーを修正できません。Microsoftは、緊急アクセスアカウントを除外し、サービスアカウントや同期アカウントも通常ユーザーとは別に扱うよう案内しています。(Microsoft Learn)
ただし、除外したアカウントを日常的に使用してはいけません。強固な認証、資格情報の安全な保管、サインイン時の通知など、別の監視が必要です。
レポート専用モードのまま放置する
レポート専用ポリシーは、原則としてアクセスをブロックしません。失敗結果が大量に出ていても、担当者がログを確認しなければリスクは残ったままです。
開始日、評価期間、対象ユーザー、合格条件、有効化予定日を変更管理へ記録してください。
Identity・Device対策だけでCopilotのデータ問題も解決したと考える
今回の対策で確認できるのは、主にアクセス主体とアクセス経路です。過剰なSharePoint権限、古いTeamsメンバー、秘密度ラベル、DLP、コネクタ、エージェントの権限は別途確認しなければなりません。
Layer 1の対策完了を、Copilot全体のセキュリティ対策完了と扱わないことが重要です。
まずはCopilot利用者とアクセス条件を1つの一覧にする
最初に実施すべき作業は、Microsoft 365 Copilotのライセンス利用者を一覧化し、各ユーザーの保護状態を横並びで確認することです。
一覧には、次の列を用意します。
- ユーザー名
- 部署・利用目的
- ライセンス割り当て方法
- 所属するCopilot利用グループ
- MFA登録・適用状態
- レガシー認証の利用有無
- 主な利用端末
- Intuneコンプライアンス状態
- モバイルアプリ保護状態
- サインインリスクポリシーの対象
- 例外理由と有効期限
- 承認者・対応担当者
空欄や「不明」となった箇所が、そのまま優先対応項目です。
Microsoft 365 Copilotのアクセスリスク対策では、ライセンス付与、ID、認証、デバイス、モバイルアプリを別々に管理してはいけません。Copilot利用者を起点として、Microsoft EntraのConditional AccessとMicrosoft Intuneの保護状態を結びつけ、レポート専用モードで影響を確認してから段階的に強制します。
そのうえで、Purview Auditとサインインログ、Intuneレポートを横断して追跡できる状態を作り、SharePointやTeamsの権限・データ保護をLayer 2の対策として並行して進めることが、今回の公式情報を実務へ反映する最も確実な進め方です。
コメント