Microsoft Security Copilotの認証で最初に押さえるべき結論は、Security Copilotのロールを付与しただけでは、Microsoft Sentinel、Intune、Defender XDR、Purviewなどのデータにアクセスできないという点です。Security CopilotはOn-Behalf-Of（OBO）認証を使い、ログイン中のユーザー本人の権限に基づいて、アクティブなMicrosoftプラグイン経由でセキュリティ関連データへアクセスします。つまり管理者は、「Security Copilotを使える権限」と「各プラグインのデータを読める権限」を分けて確認する必要があります。(Microsoft Learn)
2026年6月上旬に更新されたMicrosoft Learnの公式情報で特に重要なのは、Security Copilot RBAC、Microsoft Entra RBAC、Azure RBAC、各サービス固有のRBACが別物として扱われる点です。展開時は、所有者・共同作成者の割り当てだけでなく、Sentinel、Intune、Defender XDR、Purviewなど接続先サービス側のロール、ライセンス、条件付きアクセス、共有セッションの扱いまで確認する必要があります。(Microsoft Learn)
Microsoft Security Copilotの認証は「OBO認証」が前提
Microsoft Security Copilotの認証は、On-Behalf-Of認証、つまりOBO認証を前提に設計されています。OBO認証では、Security Copilotが独自に強い権限でデータを取りに行くのではなく、プロンプトを実行したユーザーのIDと権限を使って、プラグインや接続先サービスへアクセスします。MicrosoftのZero Trustガイダンスでも、Security CopilotはOAuth 2.0のOBO認証を使い、ユーザーのIDと権限をリクエストチェーンに渡すことで、本来アクセスできないリソースへの権限昇格を防ぐ考え方が示されています。(Microsoft Learn)
実務では、次の3層を分けて見ると理解しやすくなります。
| 確認する層 | 役割 | 不足していると起きること |
|---|---|---|
| Security Copilotロール | Security Copilotプラットフォームへのアクセス、セッション作成、設定管理などを制御 | Copilot画面やセッション作成にアクセスできない |
| Microsoft Entra / Azure RBAC | Microsoft製品群やAzureリソースへのアクセスを制御 | Sentinelワークスペース、SCU、Azureリソースにアクセスできない |
| 各プラグイン・各サービスの権限 | Sentinel、Intune、Defender XDR、Purviewなどのデータアクセスを制御 | Copilotは使えるが、対象データを使った回答が生成できない |
重要なのは、Security Copilotの「共同作成者」になっても、組織のセキュリティデータを自動的に閲覧できるわけではないことです。たとえば、SOCアナリストにCopilot共同作成者ロールを付与しても、Microsoft Sentinelのインシデントを扱うにはMicrosoft Sentinel Readerなど、対象ワークスペースに対する適切なAzure RBACロールが必要です。Intuneのデバイスやポリシーを扱う場合も、Intune側の適切なロールが求められます。(Microsoft Learn)
管理者が押さえるべき変更点と確認ポイント
今回の公式情報で管理者が特に確認すべきポイントは、Security Copilotの導入を「Copilotの利用許可」だけで終わらせないことです。認証と権限は複数レイヤーに分かれており、どこか1つでも不足していると、利用者は「Copilotは開けるのに期待した回答が出ない」「特定のプラグインだけ使えない」といった状態になります。
| 確認ポイント | 管理者が見るべき理由 |
|---|---|
| Security Copilot RBACとMicrosoft Entraロールは別物 | Copilot内のロールは、Security Copilot機能へのアクセスを制御するもので、EntraやAzure上のデータアクセス権そのものではない |
| 所有者と共同作成者の設計 | 所有者は設定や権限、プラグイン可用性、容量管理などに関わるため、人数と範囲を絞る必要がある |
| Everyoneグループの扱い | 既存環境では広い共同作成者アクセスが残っている場合があり、推奨ロールやセキュリティグループへの置き換えを検討する必要がある |
| 各プラグインのロールとライセンス | Copilot側の権限だけでは、Sentinel、Intune、Defender XDR、Purviewなどのデータを利用できない |
| 共有セッションの扱い | 共有された結果の閲覧時には、生成時と同じプラグインデータアクセスが再評価されないケースがあるため、情報共有ルールが必要 |
Security Copilotには「所有者」と「共同作成者」の2つの基本ロールがあります。これらはMicrosoft Entra IDロールではなく、Security Copilotプラットフォームの機能アクセスを制御するためのロールです。また、所有者の誤削除を防ぐため、Security Copilotは常に2人の所有者を保持する設計になっています。(Microsoft Learn)
特に既存環境では、Everyoneグループが共同作成者アクセスに割り当てられている可能性があります。Microsoftの公式情報では、新しいSecurity Copilotインスタンスでは推奨されるMicrosoft Securityロールが既定とされ、既存顧客はEveryoneグループの割り当てを継続できる一方、削除後は再割り当てできないと説明されています。広範なアクセスを見直す際は、いきなり削除するのではなく、代替となるロール割り当て可能なグループとテストユーザーを準備してから移行するのが安全です。(Microsoft Learn)
影響範囲はSecurity Copilot単体ではなく接続先サービスまで及ぶ
Microsoft Security Copilotの認証変更・整理で影響を受けるのは、Copilotポータルにアクセスするユーザーだけではありません。プラグインを通じて利用するMicrosoftセキュリティ製品、埋め込みエクスペリエンス、共有セッション、MSSPなどのマルチテナント運用まで確認範囲に含める必要があります。
| 対象 | 確認すべき内容 | 実務上の注意点 |
|---|---|---|
| SOCアナリスト | Copilot共同作成者ロール、SentinelやDefender XDRの閲覧権限 | Copilotに入れても、各サービスの権限がなければ調査データを使えない |
| ID管理者 | Entra関連の権限、条件付きアクセス、PIMの利用状況 | Copilot利用のためだけに強い管理者ロールを常時付与しない |
| Intune管理者 | Intune RBAC、デバイス・ポリシー・セキュリティ態勢へのアクセス | Intune埋め込み体験ではIntuneのコンテキストに依存する |
| Purview担当者 | Purviewロール、コンプライアンス関連データへのアクセス | Purviewの推奨ロールで足りる範囲と、別サービスで追加権限が必要な範囲を分ける |
| MSSP・複数テナント運用 | B2B/ゲスト、GDAP、Azure Lighthouse | サインイン元テナントとSecurity Copilotがプロビジョニングされたテナントが異なるケースを事前検証する |
| プラグイン管理者・開発者 | プレインストール済みプラグイン、カスタムプラグイン、認証方式 | 歯車アイコンやセットアップボタンがあるプラグインはユーザーごとの構成が必要 |
Microsoftは、Security Copilotがユーザーの持つアクセス権を超えないこと、各Microsoftプラグインにはサービスとデータにアクセスするための独自のロール要件があることを明記しています。したがって、展開前の権限レビューでは「誰がCopilotを使えるか」ではなく、「誰がCopilot経由でどのセキュリティデータを扱えるか」まで棚卸しする必要があります。(Microsoft Learn)
Security Copilotロール設計の基本
Security Copilotのロール設計では、所有者を最小限にし、日常的な利用者には共同作成者を割り当てるのが基本です。ただし、共同作成者であってもセッション作成やプロンプトブック実行など、業務に直結する操作が可能です。ロール付与の単位は、個人ではなくセキュリティグループを使うと管理しやすくなります。Microsoftも、個別ユーザーではなくセキュリティグループでSecurity Copilotロールを割り当てることを推奨しています。(Microsoft Learn)
所有者に向いているユーザー
所有者は、Security Copilot全体の設定、アクセス許可、プラグインの可用性、データ共有やフィードバック設定、容量管理、使用状況ダッシュボードなどに関わります。次のようなユーザーに限定するのが現実的です。
- Security Copilotの運用責任者
- セキュリティ基盤全体を管理する管理者
- Microsoft Entra、Defender、Sentinel、Purviewなどの権限設計を理解している担当者
- 監査・コンプライアンス要件を踏まえて設定変更できる担当者
所有者を増やしすぎると、プラグインの公開、共有設定、データ利用設定などの変更経路が増えます。緊急時の継続性を確保しつつ、通常運用では最小人数に絞るのが安全です。
共同作成者に向いているユーザー
共同作成者は、Security Copilotを使ってセッションを作成し、調査、要約、プロンプトブック実行などを行う利用者向けです。SOCアナリスト、脅威ハンター、インシデント対応担当者、IntuneやDefenderを日常的に使う運用担当者が該当します。
ただし、共同作成者ロールは「Copilotを使う入口」です。Sentinelのインシデント、Intuneのデバイス情報、Defender XDRのアラート、Purviewのコンプライアンスデータを扱うには、それぞれのサービス側のロールとライセンスを確認する必要があります。
管理者が確認すべき設定
Security Copilotのロール割り当て
Security Copilotのロール割り当ては、Security Copilot設定内で行います。公式手順では、ホームメニューから「Role assignment」を開き、「Add members」でユーザーまたはグループを選択し、Copilot ownerまたはCopilot contributorを割り当てます。(Microsoft Learn)
展開時は、次の順序で進めると失敗しにくくなります。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 事前確認 | 既存の所有者、共同作成者、Everyoneグループの有無を確認 | 誰がCopilotに入れるかをまず可視化する |
| グループ設計 | 所有者用、共同作成者用、パイロット用のセキュリティグループを作成 | 個人付与を避け、異動・退職・委託先変更に対応しやすくする |
| パイロット割り当て | 少人数に共同作成者を付与 | 各プラグインの回答可否を検証する |
| サービス権限確認 | Sentinel、Intune、Defender XDR、Purviewなどの権限を確認 | Copilot上のエラーや空回答を、権限不足として切り分けられるようにする |
| 本番展開 | 推奨ロールまたはカスタムグループで段階展開 | Everyone依存を避け、最小権限を維持する |
Microsoft EntraとAzure RBACの確認
Microsoft Entra RBACは、Microsoft製品群やセキュリティデータを含むサービスへのアクセスを制御します。一方、Azure RBACは、SCUを含むリソースグループ、Microsoft Sentinelが有効なワークスペースなど、Azureリソースへのアクセスを制御します。Security Copilot RBACとは管理場所も意味も異なるため、混同しないことが重要です。(Microsoft Learn)
よくある失敗は、Copilotでデータが見えない問題を解決するために、安易にSecurity AdministratorやGlobal Administratorのような強いロールを付けることです。公式情報でも、Security AdministratorロールはCopilotや一部プラグイン機能へのアクセスを継承するものの、Copilotアクセスのためだけに割り当てるべきではなく、代わりにセキュリティグループを作成して適切なCopilotロールに追加する考え方が示されています。(Microsoft Learn)
条件付きアクセスとデバイス保護
Security Copilotは、セキュリティ担当者や管理者の強い権限を前提に使われることが多いため、条件付きアクセスとデバイス保護は必須レベルで検討すべきです。MicrosoftのZero Trustガイダンスでは、管理者やSecOps担当者のアカウントに対して、IDとアクセスの保護、最小権限、管理されたデバイス、脅威保護、サードパーティ製品への安全なアクセスを重ねる考え方が示されています。(Microsoft Learn)
実務では、少なくとも次の観点を確認します。
| 確認項目 | 推奨される対応 |
|---|---|
| MFA | 管理者・SecOps担当者には多要素認証を必須化する |
| デバイス準拠 | Intune管理下の準拠済みデバイスからのアクセスを優先する |
| レガシー認証 | モダン認証に対応しないクライアントをブロックする |
| リスクベース制御 | 高リスクユーザーや高リスクセッションに追加制御をかける |
| セキュリティ製品側の条件付きアクセス | OBO認証で接続されるEntra、Intune、Purview、Defender XDRなどもポリシー対象として確認する |
Security Copilot単体にだけ目を向けるのではなく、OBO認証で実際にデータアクセスが発生するセキュリティツール側にも条件付きアクセスを適用することが重要です。(Microsoft Learn)
共有セッションで注意すべき情報漏えいリスク
Security Copilotの共有セッションは便利ですが、権限設計上は注意が必要です。公式情報では、セッションリンクを共有または表示するための要件はCopilot共同作成者ロールであり、共有セッションの閲覧時には、応答生成時に使われたプラグインサービスやデータへの同じアクセス権は評価されないと説明されています。共有セッションには、セッション内のすべてのプロンプトと応答が含まれ、読み取り専用で、同じテナント内のCopilotアクセス権を持つユーザーに共有できます。(Microsoft Learn)
これは、Intuneデータにアクセスできるユーザーが生成した結果を共有した場合、受信者がIntuneへのアクセス権を持たなくても、共有されたセッション結果を見られる可能性があることを意味します。運用ルールとして、インシデント名、デバイス名、ユーザー名、IPアドレス、脆弱性情報、調査メモなどが含まれるセッションは、共有前に内容を確認するプロセスを設けるべきです。
共有セッションの運用では、次のルールを明文化しておくと安全です。
| ルール | 目的 |
|---|---|
| インシデント対応中のセッションは原則共有しない | 調査中の攻撃情報や対応方針の漏えいを防ぐ |
| 共有前にプロンプトと回答を確認する | 不要な個人情報、端末情報、脆弱性情報が含まれていないか確認する |
| 共有先をチーム単位で限定する | 必要な担当者だけに閲覧範囲を絞る |
| 共有セッションの扱いを教育する | 「リンクを渡せば安全に共有できる」という誤解を防ぐ |
マルチテナントとMSSP運用で確認すること
複数テナントを持つ組織やMSSPが関与する環境では、サインイン元テナントとSecurity Copilotがプロビジョニングされたテナントが一致しない場合があります。Microsoftの公式情報では、Security CopilotはB2B・ゲストアカウントによるテナント切り替え、Partner Center経由のGDAP、Azure Lighthouseによるアクセスモデルをサポートすると説明されています。ただし、スタンドアロンポータルでのテナント切り替えは、B2Bコラボレーションアカウントまたはゲストアカウントが前提です。(Microsoft Learn)
展開前に確認すべきことは、次の3点です。
- 外部ユーザーが対象テナントに外部メンバーまたはゲストとして存在しているか
- Security Copilotロールだけでなく、目的のMicrosoftプラグインに必要なロールも割り当てられているか
- テナント切り替え後に、期待したプラグインとデータにアクセスできるか
MSSP向けの運用では、「ポータルに入れる」ことと「顧客テナントのセキュリティデータを調査できる」ことを分けて受け入れテストする必要があります。
プレインストール済みプラグインと開発者が見るべき認証ポイント
Microsoft SentinelやAzure AI Searchなどのプレインストール済みプラグインには、追加のセットアップが必要な場合があります。公式情報では、歯車アイコンまたは「Set up」ボタンがあるプラグインはユーザーごとに構成され、プラグインにアクセスできるユーザーは自分用のセットアップを行う必要があると説明されています。また、Webサイトプラグインは匿名認証でコンテンツにアクセスします。(Microsoft Learn)
プラグイン担当者や開発者は、次の点を確認してください。
| 確認項目 | 具体的に見ること |
|---|---|
| 認証方式 | ユーザーごとのセットアップが必要か、匿名認証か、外部サービスの認証が必要か |
| 権限の前提 | プラグインがどのサービスのどのデータにアクセスするか |
| エラー時の切り分け | Copilotロール不足、サービス側RBAC不足、ライセンス不足、プラグイン未設定を分けて確認できるか |
| 共有時の情報範囲 | プラグイン結果が共有セッションに含まれた場合のリスク |
| カスタムプラグイン公開 | テナント全体に影響する公開権限を所有者に限定できているか |
開発者視点では、「Copilotが便利に答えられるか」だけでなく、「誰の権限で、どのデータを、どの範囲まで回答に含めるか」を設計段階で明確にすることが重要です。OBO認証を前提に、ユーザーごとの最小権限を崩さないプロンプト、プラグイン、運用ルールを用意しましょう。
移行・展開時の実務チェックリスト
Security Copilotの認証まわりは、既存のID管理、Azure RBAC、Microsoft Defender、Sentinel、Intune、Purviewの運用にまたがります。いきなり全社展開するより、少人数のパイロットから始め、各プラグインで「期待したデータにアクセスできるか」「余計なデータまで見えていないか」を確認するのが現実的です。
| フェーズ | 確認すること | 完了の目安 |
|---|---|---|
| 棚卸し | Security Copilot所有者、共同作成者、Everyone割り当て、既存の管理者ロールを確認 | 誰がCopilotにアクセスできるか一覧化できている |
| 権限設計 | 所有者用・共同作成者用・パイロット用のセキュリティグループを作る | 個人単位ではなくグループ単位で管理できる |
| サービス別確認 | Sentinel、Intune、Defender XDR、Purviewなどの必要ロールを整理 | 利用者ごとに必要なデータアクセスが説明できる |
| パイロット | 少人数でプロンプト、プラグイン、共有セッションを検証 | 期待する回答と権限制御が一致している |
| 条件付きアクセス | MFA、準拠デバイス、リスクベース制御、対象アプリを確認 | 管理者・SecOps向けのアクセス制御が適用されている |
| 本番展開 | 推奨ロールまたはカスタムグループで段階的に追加 | Everyone依存を避け、必要なユーザーだけに展開できている |
| 運用監査 | ロール変更、共有セッション、プラグイン追加、所有者変更を定期確認 | 権限が肥大化していないことを定期的に確認できる |
よくあるつまずきと対処法
Copilot共同作成者なのにSentinelの情報が出ない
原因は、Security Copilotロールはあるが、Microsoft SentinelワークスペースへのAzure RBACが不足している可能性があります。Microsoft Sentinel Readerなど、業務に必要な最小権限が対象ワークスペースに付与されているか確認します。
とりあえずSecurity Administratorを付与してしまう
短期的には問題が解消するように見えても、最小権限の原則から外れます。Copilotアクセスのためだけに強いMicrosoft Entraロールを付けるのではなく、Security Copilotロールはセキュリティグループで管理し、データアクセスは各サービス側の最小権限で付与します。
Everyoneグループをすぐ削除して混乱する
Everyoneグループが残っている既存環境では、削除後に再割り当てできない点に注意が必要です。削除前に、推奨されるMicrosoft Securityロールまたは独自のロール割り当て可能なグループへ移行し、パイロットユーザーで動作確認してから切り替えます。
共有セッションを通常のチャット共有の感覚で使う
共有セッションには、プロンプトと回答が含まれます。生成時に使われたプラグインデータへのアクセス権が閲覧時に同じ形で評価されないため、共有前の確認ルールを設ける必要があります。
MSSPユーザーがテナントを切り替えられない
スタンドアロンポータルのテナント切り替えは、B2Bコラボレーションアカウントまたはゲストアカウントが前提です。対象テナント側の外部アカウント、Security Copilotロール、各プラグインの必要ロールを順番に確認します。
管理者が次に取るべき行動
Microsoft Security Copilotの認証を安全に運用するには、まず現在の権限状態を可視化することが重要です。最初に確認すべきなのは、Security Copilot所有者、共同作成者、Everyoneグループの有無、利用予定プラグインごとのサービス権限です。そのうえで、パイロットグループを作り、Sentinel、Intune、Defender XDR、Purviewなど実際に使うデータソースで回答可否を確認してください。
展開の判断基準はシンプルです。利用者がSecurity Copilotにアクセスでき、必要なプラグインのデータだけを扱え、共有セッションや条件付きアクセスのルールが運用に組み込まれている状態になってから本番展開します。Security Copilotは権限を増やすツールではなく、既存の権限設計を可視化しやすくするツールです。導入を機に、Microsoft Entra、Azure RBAC、サービス固有RBAC、条件付きアクセスをまとめて見直しましょう。
コメント