共有メールボックスから身に覚えのないメールが送信された時に、メッセージ追跡、監査ログ、代理送信権限、サインインをどう確認するかを整理。削除や権限変更の前に残す証跡、封じ込め、影響範囲、エスカレーション条件まで情シス・SaaS管理者向けに解説します。
この記事の目次 12項目から選ぶ
冒頭要約
問い合わせ窓口、経理、採用、サポートなどの共有メールボックスから、担当者全員が「送っていない」と答えるメールが見つかった場合、表示名や送信済みフォルダーだけで原因を決めてはいけません。正当な代理送信、送信元の選択ミス、業務アプリの自動送信、権限設定ミス、不正アクセスなど、複数の可能性があります。
まず、送受信者、送信時刻とタイムゾーン、件名、Message-ID、配送結果、メールボックス監査ログ、送信権限、直前の権限変更を記録します。その後、操作主体と配送経路を切り分け、疑わしいセッション・権限・連携アプリを組織の手順に沿って制限します。
この記事では、情シス、SaaS管理者、CSIRTがそのまま使える確認チェックリスト、初動対応、記録テンプレート、危険度の判断基準を整理します。現時点で公開されているMicrosoft、Google、NISTの公式情報を基準にし、攻撃再現や悪用手順は扱いません。
送信済みメール、監査ログ、メッセージ追跡結果、権限一覧を保全する前に削除や一斉変更を行うと、誰が、いつ、どの経路で送ったかを説明しにくくなります。業務停止が必要な緊急時も、取得できる証跡と実施時刻を先に記録してください。
共有メールボックスの「身に覚えのない送信」とは
共有メールボックスは、複数の担当者が同じ窓口アドレスを扱うための仕組みです。Microsoft 365では、適切な権限を持つ利用者が共有メールボックスとして送信する「Send As」と、利用者名を示して代理送信する「Send on Behalf」を利用できます。閲覧のための権限と送信のための権限は、同じとは限りません。
そのため、「共有メールボックス名で届いた」という事実だけでは、共有アカウントへの直接ログイン、担当者による代理送信、業務アプリ、メールフロールール、なりすましのどれかを断定できません。次の4つを分けて確認します。
| 確認軸 | 分かること | 主な確認材料 |
|---|---|---|
| 配送 | メール基盤が対象メールを受け付け、どこへ配送したか | メッセージ追跡、Email Log Search、Message-ID |
| 操作 | 所有者、代理人、管理者のどの区分で送信操作が記録されたか | メールボックス監査、SaaS監査ログ |
| 権限 | 誰が閲覧・送信・代理送信できたか | メールボックス委任、グループ所属、変更履歴 |
| 認証 | 疑わしい主体のサインインやセッションがあったか | IdP・SaaSのサインインログ、MFA、端末、セッション |
メッセージ追跡は配送の事実を確認する機能であり、それだけで人間の操作主体を特定するものではありません。反対に、監査ログだけを見ても、外部受信者へ最終的に配送されたかまでは分からない場合があります。両方を同じ時刻で突き合わせることが重要です。
読者別の影響
| 読者 | 想定される影響 | 最初に担うこと |
|---|---|---|
| 一般社員・窓口担当 | 取引先への誤連絡、情報送信、担当者へのなりすまし | 追加送信や削除をせず、発見時刻と心当たりを報告する |
| 情シス | アカウント侵害、権限設定ミス、メール基盤の不正利用 | 配送、監査、権限、認証の時系列を作る |
| SaaS管理者 | 代理送信権限、グループ所属、連携アプリ、管理者変更 | 現在値と変更履歴を保全し、正当な承認と照合する |
| 開発者・業務アプリ担当 | チケット、CRM、通知処理の誤設定やシークレット悪用 | ジョブ実行履歴、変更履歴、利用資格情報を確認する |
| CSIRT・SOC | BEC、情報漏えい、継続アクセス、対外説明 | 影響範囲、封じ込め、証跡、報告判断を統括する |
特に、振込先変更、請求、人事情報、パスワード再設定、MFA、個人情報、顧客データが含まれる場合は、内容の機密性と受信者の範囲を理由に優先度を上げます。共有窓口は利用者が多いため、「全員に確認したが心当たりがない」という申告だけで終えず、ログで裏付けます。
まず確認すること：初動チェックリスト
1. 発見時点の情報を固定する
- 共有メールボックスのアドレスと表示名を記録した
- 外部・内部の受信者、件名、送信時刻、タイムゾーンを記録した
- Message-ID、ヘッダー、添付ファイル名、本文中のURL有無を安全な保管先へ記録した
- 発見者、発見経路、送信済みフォルダー上の表示有無を記録した
- 誰が「心当たりなし」と回答したか、確認時刻とともに記録した
メール原本やヘッダーの扱いに迷う場合は、メールヘッダーの見方とブラウザ内だけで動くメールヘッダー解析ツールを参照してください。機密情報を含むヘッダーを、承認されていない外部サービスへ貼り付けないことが重要です。
2. 配送の事実を確認する
- メッセージ追跡または製品のメールログで対象メールを確認した
- 受信、拒否、遅延、隔離、配信などの最終状態を記録した
- 実際の送信者・受信者、配送時刻、適用された処理を確認した
- 同じMessage-ID、件名、時間帯の類似メールがないか確認した
- メールフロールールや業務連携による正当な自動送信か確認した
製品ごとに検索可能期間、必要権限、記録項目が異なります。Microsoft 365ではメッセージ追跡、Google WorkspaceではEmail Log Searchなど、契約中サービスの正規管理画面を使用します。
3. 操作主体と権限を確認する
- 送信、Send As、Send on Behalfに相当する監査イベントを確認した
- イベントの時刻、主体、権限区分、対象メールボックスを記録した
- Full Access、Send As、Send on Behalfなど現在の権限を一覧化した
- 権限を直接付与された利用者と、グループ経由の利用者を分けた
- 直前の権限追加、グループ加入、管理者操作、委託先変更を確認した
- 権限の所有者、承認記録、期限、業務上の必要性を確認した
Microsoft Learnでは、共有メールボックスを含む監査でOwner、Delegate、Adminを区別し、Send、SendAs、SendOnBehalfなどを監査対象として説明しています。ただし、監査設定のカスタマイズ、ライセンス、保持期間、バイパス設定などにより利用できる記録は変わります。「ログがない」ことを「操作がなかった」ことと同一視しないでください。
4. 認証と継続アクセスを確認する
- 監査ログに出た利用者やアプリのサインイン履歴を確認した
- 不審な端末、IP、国・地域、MFAイベント、セッションがないか確認した
- パスワード変更、MFA再登録、アカウント回復情報の変更を確認した
- OAuthアプリ、業務アプリ、サービスアカウントのメール送信権限を確認した
- 不審なメール転送ルールや受信トレイルールがないか確認した
共有メールボックス自体だけでなく、実際に操作した可能性がある代理人、管理者、アプリの認証状態を確認します。SaaS権限棚卸しチェックリストを併用すると、メール以外の継続アクセスも見落としにくくなります。
5. 影響範囲を確認する
- 同じ送信元から送られた件数と受信者を確認した
- 添付、本文、リンクに含まれる情報を機密区分で整理した
- 金銭、個人情報、認証情報、契約、顧客対応が関係するか確認した
- 外部受信者がメールを開いた、返信した、支払い・入力をした可能性を確認した
- 取引先への連絡、法務・個人情報保護担当への相談が必要か判断した
初動対応：やること
1. 証跡を保全し、調査の基準時刻を決める
発見時刻、最初に確認できた送信時刻、タイムゾーンを記録し、メール原本、メッセージ追跡結果、監査ログ、権限一覧、権限変更履歴を組織の保管先へ保存します。スクリーンショットだけに頼らず、可能であれば管理機能から出力した記録も保全します。
インシデント時の証拠保全に沿って、取得者、取得時刻、取得元、ファイル名、保管先を残すと、後から判断経緯を説明しやすくなります。
2. 疑わしい主体を限定して封じ込める
不審な操作主体や権限が絞れたら、組織の承認手順に従い、対象利用者・セッション・アプリ・送信権限を一時的に制限します。共有メールボックスを全面停止すると顧客対応や障害連絡まで止まる可能性があるため、影響を確認しながら、疑わしい経路を優先して封じ込めます。
操作主体が絞れず、送信が継続している、金銭や機密情報に関係する、高権限アカウントが関係する場合は、停止範囲をCSIRTや責任者へエスカレーションします。
3. アカウント・セッション・連携を保護する
疑わしい利用者について、セッション失効、資格情報の変更、MFA再確認、端末確認を進めます。連携アプリが関係する場合は、アプリの所有者、スコープ、資格情報、実行履歴を確認し、必要な範囲で停止・ローテーションします。
権限を削除しただけで、すでに成立したセッションや別の連携経路が消えるとは限りません。認証と認可の違いを意識し、「誰として接続したか」と「何を許可されていたか」を分けて確認します。
4. 受信者への追加被害を抑える
不審メールが外部へ配送され、URL、添付、振込、認証、個人情報の要求が含まれる場合は、法務・広報・業務責任者と連携し、受信者への連絡要否を判断します。連絡は、疑わしいメールへの返信ではなく、既知の電話番号や公式窓口など別経路で行います。
フィッシングやなりすましの可能性がある場合は、フィッシング報告テンプレートで送信内容と受信者の操作有無を整理します。情報漏えいの可能性がある場合は、漏えい疑い初動テンプレートへ引き継ぎます。
5. 復旧条件と監視期間を決める
原因となった権限、アプリ、認証、ルールを修正した後、正当な担当者だけが必要な操作を行えることを確認します。共有メールボックスの所有者、送信権限の承認者、棚卸し期限、監査ログの確認担当を明確にし、一定期間は同種の送信、権限変更、サインインを重点的に確認します。
やってはいけないこと
- 送信済みメールや監査記録を削除してから、原因調査を始める。
- 全担当者の権限を理由なく一斉解除し、顧客窓口や障害連絡を止める。
- 表示名やFromだけを見て、内部担当者または外部攻撃者の行為と断定する。
- 不審メールへ返信したり、同じ宛先へテスト送信したりして到達確認する。
- Full Accessがある人は全員送信できる、または送信権限がなければ閲覧できないと決めつける。
- パスワード変更だけで、セッション、MFA、アプリ、転送ルール、委任権限を確認しない。
- メール本文、受信者一覧、監査ログを承認されていない外部チャットや解析サービスへ貼り付ける。
「早く戻す」ことと「証跡を消す」ことは同じではありません。業務継続が必要な場合も、取得できる記録、変更者、変更時刻、判断理由を残してから復旧へ進みます。
記録すべきこと：初動記録テンプレート
発見日時・タイムゾーン:
発見者・発見経路:
共有メールボックス:
件名・Message-ID:
送信日時・配送結果:
内部受信者・外部受信者:
添付・URL・要求内容:
監査イベント:
操作主体・権限区分:
現在の送信権限:
直近の権限変更:
関連するサインイン・MFA・端末:
関連するアプリ・自動処理:
本人・担当者への確認結果:
影響があり得る情報:
実施した封じ込め:
業務への影響:
受信者への連絡判断:
残っている未確認事項:
次回確認日時・担当者:
エスカレーション先:不明な項目は推測で埋めず、「未確認」と記録します。確認済みの事実、推定、担当者の申告を分けると、後続担当者が同じ調査を繰り返さずに済みます。
判断基準：危険度とエスカレーション条件
| 危険度 | 条件 | 推奨する判断 |
|---|---|---|
| 高 | 送信が継続中、操作主体が不明、不審なサインインや権限追加がある | CSIRTへ直ちに上げ、証跡保全と疑わしい経路の封じ込めを並行する |
| 高 | 振込先変更、認証要求、個人情報、顧客データ、機密添付が外部へ送られた | BEC・情報漏えい疑いとして、法務・業務責任者・対外対応を含めて判断する |
| 高 | 管理者、経理、人事、役員、サポート窓口など影響の大きい権限が関係する | 対象アカウントだけでなく、同じ権限グループと類似送信も確認する |
| 中 | 正当な担当者の送信だが、承認外の宛先・内容・時間帯だった | 誤送信・運用逸脱として影響を確認し、権限と承認フローを見直す |
| 中 | 業務アプリの送信だが、所有者、変更記録、期限が不明 | 一時制限を検討し、アプリ所有者と正当性を確認する |
| 低 | 操作主体、承認、配送、内容がすべて説明でき、影響がない | 調査記録を残し、再発防止や棚卸しの要否を判断する |
次のいずれかに当てはまる場合は、担当者だけで完結させずにエスカレーションします。
- 操作主体をログで確認できない、または監査設定・保持期間が不明
- 外部受信者が添付を開いた、リンクを押した、返信・支払い・入力をした可能性がある
- 権限追加、MFA変更、不審なサインイン、転送ルールが同じ時間帯にある
- 個人情報、認証情報、決済、契約、顧客対応、法令・契約上の報告が関係する
- 共有メールボックスを止めると重要業務に影響し、封じ込め範囲を担当者だけで決められない
よくある誤解
「送信済みフォルダーにないから、社内からは送られていない」
送信方法、クライアント、アプリ、権限、保存設定によって見え方は異なります。送信済みフォルダーだけで結論を出さず、メッセージ追跡、監査ログ、ヘッダーを突き合わせます。
「メッセージ追跡を見れば、誰が送ったか分かる」
メッセージ追跡は、メール基盤がメッセージをどう処理したかを確認する機能です。人やアプリの操作主体を判断するには、メールボックス監査、IdPログ、アプリ実行履歴、権限情報も必要です。
「Full Accessがあれば送信できる」
Microsoft 365では、共有メールボックスを開くためのFull Accessと、共有メールボックスとして送るSend As・Send on Behalfは別の権限です。製品ごとの権限モデルを確認し、表示名だけで判断しないでください。
「権限を削除すればインシデントは終了」
権限削除は封じ込めの一部です。既存セッション、MFA、業務アプリ、転送ルール、受信者への影響、同種の送信が残っていないかを確認してからクローズします。
「担当者全員に心当たりがなければ侵害」
侵害の可能性はありますが、送信元の選択ミス、退職・異動後の権限残り、業務アプリ、管理者操作も候補です。申告は重要な材料ですが、ログと承認記録で裏付けます。
関連用語・関連ページ
- 用語: 共有メールボックス / メールボックス監査 / メッセージ追跡 / メールボックス委任 / Chain of Custody
- チェックリスト: フィッシング確認チェックリスト / SaaS権限棚卸しチェックリスト
- プレイブック: フィッシング報告テンプレート / 漏えい疑い初動テンプレート
- 比較: 認証と認可の違い
- 関連記事: 不審なメール転送ルールの初動対応 / メールヘッダーの見方 / インシデント時の証拠保全 / セキュリティログの読み方
- 学習・演習: インシデントレスポンス入門 / メールヘッダー分析入門 / メール・業務端末防御クイズ
公式情報・参考情報
- Microsoft Learn: Manage mailbox auditing
- Microsoft Learn: Message trace in the Exchange admin center in Exchange Online
- Microsoft Learn: About shared mailboxes in Microsoft 365
- Google Workspace Admin Help: Find messages with Email Log Search
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations
まとめ
共有メールボックスから身に覚えのない送信があった場合は、送信済みフォルダーやFrom表示だけで原因を断定せず、配送、操作、権限、認証を同じ時系列で確認します。最初に残すべきものは、Message-ID、配送結果、監査ログ、権限一覧、権限変更、サインイン、担当者の申告です。
不審な操作主体が確認できたら、証跡を保全したうえで、疑わしいセッション・権限・アプリを限定して封じ込めます。外部受信者、金銭、個人情報、認証情報が関係する場合は、メール運用の問題に閉じず、CSIRT、法務、業務責任者へ早めにエスカレーションしてください。
