情報セキュリティ事故の証拠保全｜ログ・端末・受渡記録を壊さない方法
不審なアクセスや情報漏えいの疑いが見つかったとき、端末の再起動やログの整理を先に行うと、原因や影響範囲を調べる材料が失われることがあります。一方で、証拠を残すことだけを優先して被害の拡大を放置することもできません。担当者が必要とするのは、収集する対象と操作の影響を判断し、後から説明できる記録を残す手順です。
情報セキュリティ事故の証拠保全は、取得対象と権限を決め、消えやすさと調査価値を踏まえてデータを取得し、原本を保護したうえで取得・分析・受け渡しの履歴を残す運用です。保全の完了条件は、ファイルが保存されたことではなく、取得元と取得条件、保管先、受け渡し履歴を別の担当者が追跡できることです。
対象は企業の情報システム、セキュリティ、法務、内部監査の担当者です。事故対応全体の備えは主要なセキュリティインシデントと教訓も参考になります。ここでは調査資料の扱いに範囲を絞り、専門家による端末解析そのものと、担当者が整える管理手順を分けます。
本記事のポイント
- 証拠保全は、取得元・取得条件・保管先・受け渡し履歴を追跡できる状態まで整える運用です。
- 取得順は調査価値・消えやすさ・労力で判断し、封じ込めとの優先関係と操作の影響を記録します。
- 原本と分析用コピーを分け、ハッシュだけに頼らず、担当者・時刻・条件と受領確認を残します。
最初に決めるのは取得範囲・権限・優先順位
NIST SP 800-86の3.1.2節は、データ取得を「計画」「取得」「完全性の確認」に分け、優先順位を調査上の価値、揮発性、取得に必要な労力から判断しています。揮発性とは、電源断や時間経過、システムへの操作によって情報が失われやすい性質です。メモリだけでなく、保存容量を超えると上書きされるログにも注意が必要です。
この資料は2006年の技術ガイドです。現代のクラウド製品の操作画面や契約条件を説明するものではありません。2025年4月のNIST SP 800-61 Rev.3では、RS.AN-06とRS.AN-07で、調査中の行動記録と、事故データ・メタデータの完全性および由来を保護する考え方を示しています。以下の台帳と手順は、これらを実務に落とし込む運用例です。日本法上の証拠能力や、全企業共通の保存年限を保証するものではありません。
責任者はまず、事故番号、調査目的、対象システム、作業を許可する人、保全担当者を決めます。会社の管理端末でも、私物端末、個人アカウント、委託先の設備まで同じ権限で取得できるとは限りません。個人情報や契約上の制約を法務と確認し、対象期間と対象アカウントを絞ります。範囲を狭めた理由も残すと、後日の追加取得を判断しやすくなります。
| 取得候補 | 失われる要因 | 先に確認すること |
|---|---|---|
| メモリ・実行中プロセス・接続状態 | 電源断、再起動、時間経過、操作 | 専門担当者の対応可否、稼働中取得の影響、隔離との順序 |
| 端末・サーバーのログ | ローテーション、容量超過、自動削除 | 保存期間、現在の時刻、必要な前後期間、取得方法 |
| クラウド監査ログ | 契約ごとの保持期間、出力範囲の制限 | 取得権限、対象組織、期間、ページ分割、提供元への保全依頼 |
| ディスク・ファイル・バックアップ | 通常利用による書き込み、復元、削除 | 原本の隔離方法、複製方式、対象容量、完全性確認 |
「メモリを必ず最初に取る」と一律には決めません。重大な被害が進行している場合は、封じ込めを優先する判断が必要です。端末の電源を切るか、ネットワークを切り離すか、稼働状態を維持するかは、対応責任者と専門担当者が状況に応じて決めます。判断時刻、理由、失われ得る情報を記録し、一般担当者が思いつきで再起動やソフトの追加を行わないようにします。
証拠台帳にはデータの由来と扱った人を残す
受け渡しの連続した履歴はチェーン・オブ・カストディと呼ばれます。NIST SP 800-86は、証拠を扱った人、行った操作、時刻を記録し、使用していない間は安全な場所で保管し、分析には複製を使うことを示しています。ファイル名の一覧だけでは、どこから取得し、誰が変更したかを説明できません。
図の四段階は、計画だけ、保存だけで終わらせないための確認順です。取得前に対象を決め、取得中の操作を記録し、原本と作業用コピーを分け、外部へ渡す際にも同じ履歴を継続します。台帳には秘密の値そのものを転記せず、必要な人だけがアクセスできる保管先を記録します。
| 記録の区分 | 残す項目の例 | 確認できること |
|---|---|---|
| 対象と由来 | 事故番号、証拠番号、端末識別子、組織・サービス名、取得元 | 別の端末や組織のデータとの取り違えを防ぐ |
| 取得条件 | 担当者、開始・終了時刻、タイムゾーン、ツールと版、検索条件、失敗・欠落 | 取得手順と対象範囲を再確認できる |
| 完全性と保管 | ファイル名、容量、ハッシュ方式と値、原本・複製の区分、保管場所、権限 | 取得後に同じデータを扱っているかを照合できる |
| 受け渡しと終了 | 渡した人、受け取った人、日時、目的、対象、受領確認、保持・削除判断 | 保管責任の移動と処理の終了を追える |
時刻には、イベントが発生した時刻、システムが記録した時刻、担当者が取得した時刻があります。ログ内の時刻を上書きして揃えるのではなく、原データを残し、分析用の一覧に正規化した時刻と変換規則を別に持たせます。時計のずれを確認できた場合は、比較した基準時刻と差を記録します。ずれを確認できない情報は、その不確実性を残します。
ハッシュ値は、同じバイト列かどうかを確認する助けになります。たとえば組織で承認したSHA-256で取得ファイルと作業用コピーを照合する方法があります。ただし、ハッシュ一致だけで取得前の改ざんがなかったこと、取得範囲が完全なこと、法的に有効な証拠であることまでは証明できません。取得元、取得権限、条件、受け渡し記録と組み合わせて扱います。
取得から引き渡しまでの7手順
1．事故番号と保全担当者を決める
問い合わせやアラートを一つの事故番号にまとめ、判断責任者と保全担当者を明記します。電話やチャットの指示も、実施内容と時刻を対応記録へ移します。法務、外部調査会社、警察への相談が必要かを初期に判断し、相談前に現物を変更し過ぎないようにします。連絡できない場合の代行者も決めます。
2．消失期限と取得の優先順位を整理する
端末、認証基盤、クラウド、ネットワーク機器などの候補を列挙し、残りの保存期間と調査上の価値を記録します。保存期間が短い監査ログは、分析が終わるまで待たずに取得や保全依頼を検討します。サービスごとの実際の権限、保持期間、エクスポート条件を確認し、取得できない対象も「未取得」と理由付きで残します。
3．操作前の状態と取得条件を記録する
画面の状態、接続機器、端末識別子、現在時刻など、対象に応じた初期状態を記録します。ログの出力では、対象組織、ユーザー、検索期間、タイムゾーン、フィルター、ページ分割や出力上限を控えます。画面写真だけでは元のログ全体を代替できません。スクリーンショットと機械可読な出力は、目的を分けて保管します。
4．承認された方法で取得し、原本を保護する
専門性が必要な端末イメージやメモリの取得は、訓練された担当者へ依頼します。一般担当者が解析ツールを対象端末へ追加すると、ディスクや実行状態が変化する可能性があります。ファイルのコピー、ディスク全体のイメージ、クラウドのエクスポートは取得できる範囲が異なるため、実施方式を台帳に書きます。失敗や再試行も消さずに記録します。
5．完全性を確認し、分析用コピーを分ける
取得したファイルの容量とハッシュ値を記録し、複製後に照合します。取得した原本側は変更を制限し、検索・加工・時刻変換は作業用コピーで行います。稼働中システムのデータは刻々と変わるため、後から取り直した出力のハッシュ不一致を直ちに改ざんと判断しません。どの時点のどのファイル同士を比較したかを確認します。
6．保管権限と受領確認を揃える
証拠には顧客情報、認証情報、脆弱性の詳細が含まれ得ます。アクセスは必要な担当者へ限定し、読み取りや持ち出しの履歴を残します。外部調査会社へ渡す場合は、委託範囲、送信経路、暗号化、受領者、再提供の可否を確認します。受領側の容量・ハッシュ照合結果と受領時刻を記録して、送りっぱなしを防ぎます。
委託先が事故データを保持している場合は、SaaS委託先の事故通知条項に、保全依頼先や追加情報の提供手順があるかも確認します。連絡したことと、相手が対象範囲を保全したことは別なので、対象期間と実施結果の返答まで残します。
7．保持期限と終了条件を見直す
復旧した時点で証拠を自動削除しないようにします。訴訟や懲戒、契約、法令、組織の保持方針を法務や責任者と確認し、保全継続の必要性を判断します。NIST SP 800-61 Rev.3は、組織の証拠保全手順とデータ保持方針に従い、将来データを読むためのハードウェアやソフトウェアの費用も考慮するよう示しています。保持延長や廃棄の承認、複製の所在まで管理します。
記録があるのに調査できない失敗を防ぐ
よくある失敗は、担当者が「必要そうな行」だけを表計算へ貼り付け、元の出力を残していないことです。列の欠落、時刻の自動変換、長い識別子の表示変更が起きると、他のログとの照合が難しくなります。元のファイルを保持し、加工後の資料には元ファイルと処理条件を結び付けます。
同様に、出力ファイルがあるだけでは取得範囲の完全性を確認できません。対象期間、件数、ページ数、取得エラー、権限による非表示項目を確認します。取得できなかった時間帯は空白を埋めて推定せず、欠落として報告します。調査結果には、観測した事実と推測、未確認事項を分けて記載します。
受け渡し台帳を後から記憶でまとめる運用も避けます。担当交代時に、証拠番号、保管先、未取得対象、次の期限を照合する短い確認を入れると、保管責任が途切れにくくなります。台帳の記載漏れを補う場合は、追記した日時と根拠を残し、元の記録を黙って書き換えません。
よくある質問
不審な端末はすぐ電源を切りますか？
一律には決めません。電源断で失われる情報と被害拡大のリスクを比較し、対応責任者と専門担当者が隔離や電源操作を判断します。実施した操作、時刻、理由を残します。
ハッシュが一致すれば証拠として十分ですか？
十分とは限りません。ハッシュは比較したバイト列の同一性を確認する手段です。取得元、権限、条件、保管と受け渡し履歴、取得前の状態については別の記録が必要です。
クラウドのログにも原本はありますか？
利用者がサービス内部の原本を直接保持できるとは限りません。取得した出力を変更せず保存し、取得方法、対象組織、期間、フィルター、提供元の情報を記録します。必要なら提供元に保全を依頼します。
すべての事故で厳密なチェーン・オブ・カストディが必要ですか？
NIST SP 800-61 Rev.3は、すべての事故で正式な証拠取扱手続を行うとは限らないとしています。それでも、収集データと対応記録の完全性、由来、アクセス制限は維持し、正式手続の必要性は組織の方針と法務判断で決めます。
ログの保存期間は何年にすればよいですか？
事故証拠に共通の年数を一律には設定できません。法令、契約、訴訟・調査上の必要性、組織の保持方針を確認して決定し、保全継続中の自動削除を防ぎます。
担当者が途中で交代するときは何を確認しますか？
証拠番号ごとに保管場所、原本と複製、取得済み・未取得の範囲、次の期限を引き継ぎます。渡した人と受け取った人、日時、受領確認を台帳に残します。
関連ページと関連記事
事故の調査には、平時のログ設計も影響します。AI連携を含むシステムの追跡項目はAI監査ログのチェックリストで整理できます。標準の管理策を満たせない事情がある場合は、情報セキュリティ例外の承認・期限管理で代替統制と見直し期限を揃えます。
事故時の記録・権限・担当引き継ぎを業務フローとして整理したい場合は、ファネルAiに業務運用の整備を相談することで、現場が確認すべき項目と責任分担を具体化できます。
参考資料
- NIST SP 800-86：Guide to Integrating Forensic Techniques into Incident Response（2006年、3.1.2節、本文3-3〜3-4ページ）
- NIST SP 800-61 Rev.3：Incident Response Recommendations and Considerations for Cybersecurity Risk Management（2025年4月、RS.AN-06・RS.AN-07）。いずれも2026年9月9日に原文を確認。
