Microsoft 365 / セキュリティアラートの確認と初動対応

Microsoft 365 セキュリティアラートを受け取った場合、重大度だけを見てすぐに閉じず、発生時刻、検出源、影響を受けたユーザー・デバイス・メール、関連アラートを確認する必要があります。同じインシデントの複数のアラートが1つのインシデントとしてまとめられることがあるため、個別のアラートとインシデント全体を合わせて確認してください。

アラートとインシデントの違い

アラートは特定の疑わしい活動を検出した記録です。インシデントは関連するアラートと証拠をまとめて攻撃の流れを把握するための単位です。Microsoft の Defender インシデント調査ガイド は、アラート、活動、資産、証拠を合わせて確認するよう説明しています。使用可能な画面と自動調査機能は、組織の製品およびライセンスによって異なります。

調査画面と権限の準備

Microsoft Defender ポータルで インシデントおよびアラート → アラートを開きます。セキュリティ閲覧者などの読み取り権限などで閲覧できても、アカウントのブロック・デバイスの隔離などの対応作業まで実行できるわけではありません。組織の Defender 権限モデル、担当範囲、製品ライセンスをまず確認し、調査担当者と対応担当者を決めてください。

2026年10月の Microsoft 文書では、新しい インシデントケース(プレビュー)と既存の調査画面が共に案内されます。新画面を使用する組織は Cases → Incident でケースを開き、関連するアラート・資産・証拠・活動を確認できます。メニューが異なってもログがないわけではありません。インシデントケース調査文書で、現在使用している画面と権限を照合してください。

初めて対応する際に確認する順序

  1. Microsoft Defender ポータルのインシデントまたはアラート一覧を開きます。チームで担当者を決め、同一インシデントを重複処理しないようにインシデント番号を記録します。
  2. 重大度と検出時刻、影響を受けたアカウント・メール・デバイスを確認します。アラートのタイトルだけで実際の侵害を確定しません。
  1. インシデントの詳細で関連するアラート、活動の時系列記録、証拠と自動対処の結果を確認します。アラート調査ドキュメントでステータスと分類の意味を確認します。
  2. 実際の脅威可能性が高く、被害が進行中の場合は、組織のインシデント対応手順に従って担当者に直ちに通知し、影響範囲と承認済みの隔離・遮断措置を決定します。追跡に必要な証拠をまず保全します。
  3. 原因と対処を記録し、同じ活動が他のユーザーや機器にもあるか確認します。対処後、アラートが再度発生しないか監視します。

インシデント記録に残す根拠と調査の順序

アラート名だけでなく、アラート・インシデントID、検出製品、最初・直近の活動時刻およびタイムゾーン、対象ユーザー・機器・メール識別情報を記録します。名前が同じファイルや似たアカウントを混同しないように実際のオブジェクトを照合してください。悪意のあるURLや添付ファイルを確認するために、通常業務用PCで直接開かないでください。

時系列で「メール受信 → リンク関連のアラート → ログイン → 資料へのアクセス」のように確認されたイベントをつなげます。すべて発生したと推定せず、既存の証拠とまだ不明な事実を区別してください。例えば、ユーザーがクリックを否認しても関連ログを確認し、クリック記録だけでパスワード漏洩を断定してはいけません。

同じ送信者・ファイル・URLに関連する他のユーザーのアラートがあるかも調査します。1つのアカウントのアラートを閉じても、別のアカウントで同じ行為が続く場合があるためです。資料は承認されたインシデント管理の場所に保管し、メールの原文・ユーザー情報・アクセス記録を公開チャンネルに貼り付けません。

フィッシングアラートを受けた場合の判断例

確認された状況 優先的に確認・対応すること
メッセージは隔離され、ユーザーには届かない 隔離結果と他の受信者への配送状況を確認。検出・ブロックされた攻撃かどうかを区別
受信トレイに届いたが、ユーザーの行動は確認されていない メッセージ識別子と配送範囲を調査し、セキュリティ担当者が回収・ブロックの必要性を判断
ユーザーがリンクでパスワードを入力したことを確認 アカウント侵害の可能性として優先対応。承認された手順でアクセスのブロック・セッション・認証方法の点検などを実施
端末で悪意ある実行や継続する被害が確認 進行中の被害を防ぐ担当者に直ちに引き継ぎ、承認された隔離・対処の完了状況を確認します。

複数のサービスで対処が必要な場合があります。メール配信はメッセージ追跡、ログインと認証はEntraサインインログで続けて確認します。ユーザーのパスワードだけを変更するのではなく、疑わしい認証方法・転送ルール・アプリ権限を残さないように、関連担当者が調査範囲を決定する必要があります。

自動対処が表示されても、要求済み・待機中・失敗・完了を区別します。製品によっては自動調査や対応機能が提供されない場合があり、ポータルに対応ボタンが表示されているだけで作業が実行されたわけではありません。証拠保全と緊急遮断を併せて行う一方で、進行中の被害の遮断を不要に遅らせないようにします。

誤検知と思われる場合はすぐに無視してもよいですか?

いいえ。ポリシー変更や通常の運用作業によってアラートが発生したかどうか、証拠と担当者の説明を照合する必要があります。誤検知に分類した場合は、判断の根拠と範囲を残し、アラートルールを広く解除して実際の攻撃を見逃さないようにします。繰り返し同じ誤検知が発生したときのみ、狭い範囲での調整が適切か検討してください。

実際の脅威を阻止したアラートと、正常な作業が誤検知されたアラートも区別します。被害がないという理由だけで、すべてが誤検知ではありません。承認された試験・運用作業であれば、作業依頼・実行時刻・対象と証拠が一致しているか確認した上で、現在の画面の分類と決定項目に基づいて記録を残します。例外や抑制が必要な場合は、対象を絞り、有効期限・レビュー日程を設定してください。

最終確認

  • 影響を受けたアカウント・機器の現在の状態と追加アラートの有無
  • 実行した自動・手動対応と、元に戻す必要がある対応
  • ユーザー通知と社内インシデント記録の完了状況
  • ポリシー・教育・認証方法など再発防止作業の担当者

インシデント終了記録には、初期の症状、影響範囲、判断根拠、自動・手動対応の実際の結果と残っているフォローアップ作業を記載します。アラート状態を「解決済み」に変更するだけでは脅威が除去されたことにはなりません。アカウント・機器の保護が回復し、業務が正常化されたことを確認してから終了し、臨時ブロック解除やポリシー変更は、担当者が根拠を確認した上で承認された範囲内で元に戻します。