ログ管理の基本。何を・どこまで・どれだけ残すか

インシデントが起きてから「あのログを取っていなかった」と気づく。これがログ管理で最もよくある失敗です。攻撃の侵入経路を追おうとして認証ログが上書きされていた、不正な通信を確認しようとしてプロキシのログが3日分しか残っていなかった、複数の機器の記録を突き合わせようとして時刻がずれていて順序が分からなかった。どれも事故が起きた後では取り返しがつきません。ログ管理は、平時に地味な投資をしておくことで、有事に初めて価値が出る仕組みです。

一方で、何でもかつ無期限に残せばよいというものでもありません。ログには容量・コスト・個人情報・運用負荷といった制約があり、闇雲に増やすと肝心なときに必要なログが埋もれます。重要なのは「何を・どこまで・どれだけ残すか」を、自組織のリスクと目的に照らして意図的に決めることです。

この記事では、ログ管理の4つの柱、すなわち取得対象の選定、保管期間の設計、改ざん対策、そして相関分析を、原理から噛み砕いて整理します。特定の製品の設定手順ではなく、どんな環境にも応用できる判断基準の作り方に焦点を当てます。

早見表: ログ管理の4つの柱と判断軸#

まず全体像を整理します。各柱で「何を基準に決めるか」を押さえると、個別の製品選定や設定に振り回されずに済みます。

この4つは独立ではなく連鎖します。取得していないログは分析できず、改ざんされたログは証拠にならず、時刻がずれたログは相関できません。どこか一つが欠けると全体の価値が落ちる点を意識してください。

取得対象をどう選ぶか#

ログ管理の出発点は「取れるものを全部取る」ではなく「目的から逆算して必要なものを決める」ことです。NIST SP 800-92「Guide to Computer Security Log Management」も、ログ管理を組織全体の計画として捉え、目的に応じて生成・収集・保管・分析を設計する考え方を示しています。目的は大きく次の4つに整理できます。

• 検知: 攻撃や異常をできるだけ早く気づくため
• 調査（フォレンジック）: インシデント発生後に経緯と影響範囲を追跡するため
• 監査: 誰が何をしたかの説明責任を果たすため
• 法令・契約遵守: 規制やガイドライン、取引先との契約で求められるため

この目的に照らすと、優先して取得すべきログの当たりがつきます。一般に価値が高いのは、認証・認可の記録（ログイン成否、権限変更、管理者操作）、ネットワーク境界の通信記録（プロキシ、ファイアウォール、DNS）、エンドポイントのプロセス実行や永続化の記録、そしてクラウドやIDプロバイダの監査ログです。JPCERT/CCの資料「高度サイバー攻撃への対処におけるログの活用と分析方法」でも、攻撃の各段階でどの機器にどのような痕跡が残るかという観点から、採取すべきログ項目が整理されています。

ここで誤解しやすいのが「アプリケーションのアクセスログさえあれば調査できる」という思い込みです。Webアクセスログだけでは、攻撃者がサーバ内でどのコマンドを実行したか、どのアカウントに横展開したかは分かりません。攻撃は複数のレイヤをまたいで進むため、ネットワーク・OS・アプリケーション・認証基盤の各層からバランスよく取得することが、後の相関分析を成立させる前提になります。攻撃者の振る舞いを段階で捉える枠組みとしては

保管期間をどう決めるか#

「どれだけ残すか」は、感覚ではなく根拠から決めます。判断軸は主に3つです。

1つ目は法令・規制・契約です。たとえば決済カード業界のセキュリティ基準であるPCI DSSは、監査ログを最低1年間保管し、直近3か月分はすぐに分析可能な状態で維持することを求めています。業種によっては、より長い保存が法令や業界ガイドラインで定められている場合があります。自組織に適用される要件を最初に棚卸ししてください。

2つ目は、想定する調査の遡及範囲です。標的型攻撃では、侵入から発覚まで数か月以上が経過する例も珍しくありません。発覚時点から逆算して侵入の起点まで追える期間のログがなければ、初期侵入の経路は永遠に分からないままになります。「気づくまでにどれくらいかかりうるか」を見積もり、それを上回る保管期間を確保するのが調査目的の基本です。

3つ目はコストと運用です。すべてのログを高速に検索できる状態で長期保管するのは高コストです。そこで実務では、保管を階層に分けるのが定石です。

改ざん・消去への対策#

ログを語るとき見落とされがちなのが、ログ自体が攻撃対象になるという事実です。攻撃者は侵入の痕跡を消すため、侵害した機器上のログを削除・改ざんしようとします。MITRE ATT&CKでも「Indicator Removal」のようにログを消去・改ざんする手口が体系化されています。したがって、ログを生成元の機器の中だけに置いておくのは、もっとも壊れやすい構成です。

対策の核は次の3点です。

相関分析と時刻同期#

単独のログは断片でしかありません。価値が生まれるのは、複数の機器のログを突き合わせ、攻撃者の一連の動きを時系列で再構成できたときです。これが相関分析です。たとえば「境界で不審なIPからの接続」「直後に特定アカウントの認証成功」「その数分後に管理者権限の付与」「さらに別サーバへのログイン」とつながって初めて、侵入から横展開までの物語が見えます。

この相関分析を成立させる絶対条件が時刻同期です。各機器の時計がずれていると、イベントの前後関係が崩れ、因果が再構成できません。NTP（Network Time Protocol）などで組織全体の時刻を信頼できる基準に合わせ、ログのタイムスタンプはタイムゾーンを明示した形式（UTCまたはオフセット付き）で記録するのが原則です。「ログはあるのに順序が分からない」という事態は、時刻同期の不備が原因であることが非常に多いです。

ログの生成・収集・保管・分析を組織全体の計画として捉える考え方と、時刻同期や標準化の重要性は、NIST SP 800-92「Guide to Computer Security Log Management」で体系的に整理されています。IPAによる日本語翻訳版も参照できます。

相関のもう一つの前提が正規化です。機器ごとにログの書式やフィールド名（送信元IP、ユーザ名、イベント種別など）はばらばらです。これらを共通のスキーマに揃えてはじめて、横断的な検索や相関ルールが書けます。SIEMの主要な役割の一つは、この正規化と時刻の整合、そして相関ルールによる検知の自動化です。ただしツールを入れれば自動で相関が効くわけではなく、何と何を結びつけたいのかという検知シナリオを人が設計する必要があります。

ここで実務上の注意点があります。相関ルールは作って終わりではなく、誤検知（フォールスポジティブ）と検知漏れ（フォールスネガティブ）のバランスを継続的に調整する運用が要ります。ルールを厳しくしすぎればアラート疲れを招き、緩めれば見逃します。自組織の正常な振る舞いを把握したうえで、優先度の高いシナリオから少しずつ精度を上げるのが現実的です。

よくある質問#

まとめ#

ログ管理は、平時の地味な投資が有事に効く仕組みです。取れるものを全部取るのではなく、検知・調査・監査・法令という目的から取得対象を逆算し、法令と調査範囲とコストから保管期間に根拠を持たせ、集約と追記専用と完全性検証で改ざんに備え、時刻同期と正規化を前提に相関分析で全体像を描く。この4つの柱を意図的に設計しておくことが、インシデント発生時に「あのログを取っていなかった」という後悔を防ぎます。

攻撃者の振る舞いを戦術と技術で整理し、どの段階のログが手薄かを点検する枠組みとしては、