インシデント対応で証拠保全・ログ保全をどう進めるか。端末、SaaS、クラウド、メール、監査ログを失わない初動確認、やってはいけないこと、記録テンプレート、エスカレーション基準を整理します。
冒頭要約
インシデント時の証拠保全とは、あとから原因・影響範囲・報告要否を説明できるように、ログ、端末状態、SaaS監査ログ、メール原本、設定変更履歴を失わない形で残す初動対応です。
重要なのは「何かを消す前に、何を見たか、何を取得したか、誰が判断したか」を記録することです。端末初期化、ログ削除、アカウント停止、設定変更を急ぐと、必要な証跡を失う場合があります。
まずは攻撃再現や深い解析ではなく、対象、時刻、取得元、保持期限、変更した操作をそろえ、必要に応じてCSIRT・法務・SaaS管理者・委託先へ早めにエスカレーションします。
この記事は2026年7月7日時点で公開されているNIST、CISA、IETFの一次情報を参考に、防御・確認・初動判断のために整理しています。攻撃手順、PoC、悪用コード、探索クエリ、認証回避の具体手順は扱いません。法的証拠性が必要な案件では、自社規程、法務、外部専門家、関係当局の助言を優先してください。
読者別の影響
証拠保全はフォレンジック担当だけの作業ではありません。最初に異常を見つけるのは、ヘルプデスク、SaaS管理者、開発者、上長、利用者本人であることも多いため、立場ごとに「消さないもの」を分けると初動が安定します。
| 読者 | 影響 | 最初に残すもの |
|---|---|---|
| 個人・一般社員 | 不審メールを開いた、MFAを承認した、端末が不審な動きをした可能性がある | メール原本、受信時刻、クリック有無、画面表示、端末名 |
| 情シス・ヘルプデスク | 端末対応とアカウント保護を急ぐ一方で、ログや操作履歴を残す必要がある | 対象者、端末、IP、対応チケット、実施操作、時刻 |
| SaaS管理者 | 外部共有、権限変更、OAuth同意、監査ログの保持期限が判断に関係する | 監査ログ、管理者操作、共有リンク、連携アプリ、サインインログ |
| 開発者・DevOps | CI/CD、GitHub、クラウドキー、Webhook、依存関係のログが短期間で流れることがある | CIログ、secret scanning通知、リリース履歴、キー失効前の利用ログ |
| SOC・CSIRT | 原因、影響範囲、封じ込め、報告、再発防止を説明する必要がある | タイムライン、取得ログ一覧、Chain of Custody、未確認事項 |
証拠保全とは
証拠保全は、インシデント対応で使う証跡を「あとから説明できる状態」で残すことです。ここでいう証跡には、端末やサーバーの状態だけでなく、監査ログ、メール、SaaS管理画面の操作履歴、クラウドのAPIログ、チャットでの判断記録、委託先からの回答も含まれます。
似た言葉にフォレンジックがあります。フォレンジックは証拠を分析して事実関係を明らかにする活動で、証拠保全はその前提になる「失わない・改ざんを疑われにくい・扱った履歴を残す」活動です。証拠保全が弱いと、あとから高度な分析をしても、どのログが正しいのか、誰がいつ取得したのかを説明しにくくなります。
また、Chain of Custodyは、証拠の取得、保管、複製、引き渡し、分析、廃棄までの扱いを記録する考え方です。すべての小規模インシデントで厳密な法的手続きを行う必要はありませんが、顧客データ、個人情報、高権限アカウント、外部報告が関係する場合は、早い段階で記録粒度を上げる必要があります。
まず確認すること
最初の30分では、解析よりも「証跡を失う原因」を減らします。以下のチェックリストは、そのままチケットや初動メモに転記できます。
| 確認項目 | チェック | 記録例 |
|---|---|---|
| 1. 事象 | 何をきっかけにインシデント疑いになったか | EDRアラート, 不審メール報告, SaaS外部共有通知 |
| 2. 時刻 | JST/UTC、検知時刻、発生推定時刻、対応開始時刻を分けたか | 2026-07-07 09:12 JST 検知 |
| 3. 対象 | ユーザー、端末、サーバー、SaaS、リポジトリ、クラウドアカウントを特定したか | [email protected], device-023, GitHub org |
| 4. ログ取得元 | どのログを見たか、まだ見ていないログは何か | IdP sign-in, SaaS audit, EDR, proxy, DNS |
| 5. 保持期限 | そのログがいつ消えるか、エクスポートが必要か | SaaS監査ログは90日, CIログは14日 |
| 6. 変更操作 | 隔離、失効、削除、設定変更、再起動などを実施したか | 09:28 セッション失効, 09:35 端末隔離 |
| 7. 原本性 | 原本、エクスポート、スクリーンショット、コピーの区別を記録したか | CSV export, 管理画面スクショ, メール原本 |
| 8. 引き渡し | 誰が取得し、どこへ保管し、誰へ渡したか | 情シスAが取得、IRフォルダへ保存、CSIRTへ共有 |
| 9. 未確認事項 | 推測と事実を分け、まだ確認できていない項目を書いたか | データ持ち出しは未確認, 外部共有範囲確認中 |
| 10. 次の判断者 | CSIRT、法務、DPO、委託先、経営への連絡要否を決めたか | 顧客データ可能性あり、法務へ相談 |
すべてのログを無期限に残すことは、コストやプライバシーの面で現実的ではありません。NIST SP 800-92の考え方に沿って、対象ログ、保持期間、アクセス権、削除条件を運用として決めておくことが重要です。
初動対応
やること
- 事象、対象、時刻、検知元、対応担当者を1つのインシデントタイムラインにまとめる。
- EDR、IdP、SaaS、メール、DNS、プロキシ、クラウド、GitHub、CI/CDなど、関係するログの保持期限を確認する。
- 取得したログのファイル名、取得条件、タイムゾーン、エクスポート形式、保存場所、取得者を記録する。
- 端末隔離、セッション失効、キー失効、アカウント停止、外部共有停止など、証跡に影響する操作は「実施前後」を記録する。
- 顧客データ、個人情報、高権限アカウント、複数端末、委託先が関係する場合は、早い段階でCSIRT・法務・管理者に共有する。
やらないこと
- 不審ファイルやURLを業務端末で開いて確認しない。
- ログのエクスポート前に、端末初期化、アプリ削除、アカウント削除、共有リンク削除を急がない。
- チケットやチャットへ、Cookie、セッショントークン、APIキー、個人情報をそのまま貼らない。
- 公式情報やログで確認できない被害規模、攻撃者名、攻撃経路を断定しない。
- 自社の権限外のシステムに対して、探索的アクセス、スキャン、検証リクエストを行わない。
記録すべきこと
| 記録項目 | 書き方 |
|---|---|
| 観測事実 | 09:12 JST に [email protected] の不審サインイン成功をIdPログで確認 |
| 根拠ログ | IdP sign-in log, SaaS audit log, EDR alert, DNS log |
| 取得条件 | 対象ユーザー, 2026-07-07 08:00-10:00 JST, CSV export |
| 変更操作 | 09:28 セッション失効, 09:34 対象端末をEDRで隔離 |
| 未確認事項 | メールボックス閲覧範囲は確認中, 外部共有先は未確認 |
| 引き渡し | 情シスAが取得し、IR保管フォルダへ保存。CSIRT Bがレビュー |
判断基準
証拠保全の粒度は、すべてのアラートで同じにする必要はありません。業務影響と説明責任の大きさに応じて優先度を上げます。
| 優先度 | 条件 | 対応 |
|---|---|---|
| 高 | 管理者、経理、人事、GitHub owner、クラウド管理者など高権限アカウントが関係する | セッション失効や権限停止と並行して、監査ログ、操作履歴、対象データを保全する |
| 高 | 顧客データ、個人情報、機密情報、外部共有、ダウンロード、APIキー利用が関係する可能性がある | 法務、DPO、CSIRTへ早期共有し、取得ログと未確認事項を分けて記録する |
| 高 | 複数端末、複数ユーザー、委託先、VPN、クラウド、SaaSをまたいで発生している | タイムラインを統合し、ログの重複・欠落・タイムゾーン差を確認する |
| 中 | 単一端末や単一ユーザーだが、EDRアラート、不審メール、DNS/プロキシログが連動している | 端末隔離前後のログ、メール原本、認証ログ、利用者ヒアリングを残す |
| 低 | 誤検知や既知の正規通信として説明でき、影響範囲も限定的 | 判断根拠、確認したログ、再発時の確認条件をチケットに残す |
エスカレーションの目安は、「自分の権限だけで対応完了と説明できるか」です。ログ取得権限が足りない、保持期限が近い、SaaS管理者が別部署、外部報告の可能性がある、利用者への聞き取りが必要、といった条件がある場合は早めに巻き込みます。
よくある誤解
証拠保全は専門家が来てから始めればよい
専門家が必要な案件でも、最初の担当者が残す時刻、対象、操作記録が重要です。詳細なメモリ取得やフォレンジックイメージの作成は専門性が必要ですが、ログの保持期限確認、チケット記録、操作前後のメモは現場でも始められます。
先に消せば安全になる
危険なアカウントや共有を止めることは重要です。ただし、削除や初期化を急ぐと、原因調査に必要な証跡を失う場合があります。封じ込めと証拠保全は対立ではなく、順番と記録を決めて両立させるものです。
スクリーンショットがあれば十分
スクリーンショットは有用ですが、検索条件、対象期間、タイムゾーン、取得者、原本ログの有無が分からないと説明力が弱くなります。可能なら原本ログのエクスポート、監査ログの取得条件、保存先、ハッシュやアクセス制御も記録します。
小さなインシデントなら記録しなくてよい
小さく見えた事象が、あとで複数SaaSや委託先に広がることがあります。最低限、発見時刻、対象、確認ログ、実施操作、判断者、未確認事項を残しておくと、あとから調査を拡張しやすくなります。
関連用語・関連ページ
証拠保全の考え方は、ログの読み方、初動対応、SaaS権限、データ漏えい疑いの対応とセットで理解すると実務に落とし込みやすくなります。
- 用語を確認する: Evidence Preservation、Forensics、Chain of Custody、Audit Log、Log Retention
- 学習する: インシデント対応の基本、セキュリティログの読み方、DNSログの読み方
- 実務で使う: 漏えい疑い初動テンプレート、ランサムウェア初動対応テンプレート、SaaS権限棚卸しチェックリスト
- 練習する: ログイン失敗ログレビューCTF、アクセスログトリアージCTF
公式情報・参考情報
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
- NIST SP 800-92: Guide to Computer Security Log Management
- CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
- RFC 3227: Guidelines for Evidence Collection and Archiving
まとめ
インシデント時の証拠保全は、専門家だけが行う高度な作業ではありません。最初の担当者が、時刻、対象、ログ取得元、実施操作、未確認事項を残すだけでも、原因調査と報告判断の質は大きく変わります。
迷ったときは「消す前に記録する」「変更前後を残す」「事実と推測を分ける」「保持期限が近いログを優先する」の4点から始めてください。深い解析が必要な場合でも、初動で残した記録が後続のCSIRT、法務、外部専門家を助けます。
