時刻同期不備で追跡不能『ログ・証跡の運用崩れの話⑧』
ログは残っていた。
でも、時刻が機器ごとにズレていた。
それだけで、追跡は一気に難しくなる。
冒頭の一言要約
時刻が揃っていないログはつなげて読めない。同期不備は調査不能を生む。
症状（あるある）
・サーバ、FW、認証基盤でログ時刻がずれている
・同じ事象なのに前後関係が分からない
・機器によってタイムゾーン表記が違う
・障害調査で「どれが最初か」が判断できない
・SIEMに入れても時系列が崩れる
・監査で証跡を並べても説明が合わない
・インシデント報告書の時刻が機器ごとに食い違う
原因と仕組み（なぜ起きるか）
原因はシンプル。
時刻同期を「後回しの設定」にしていること。
現場ではこうなる。
・NTP設定を入れていない
・入れていても参照先がバラバラ
・一部機器だけ手動時刻設定のまま
・仮想基盤やクラウド側の時刻設定を見ていない
・タイムゾーン統一をしていない
その結果、同じ出来事でもログの並びが崩れる。
たとえば、認証失敗 → VPN接続 → FW遮断の順で起きたのに、時刻ズレのせいでFW遮断が最初に見えることがある。
これでは原因調査が遅れる。
不正アクセスの追跡でも、侵入経路や横展開の順番を誤る。
証跡として出しても、整合しないログは信用を落とす。
つまり問題は、ログが無いことではない。
時間軸が壊れていること。
図（テキスト図）
本来の流れ
10:00:01 認証失敗
10:00:03 VPN接続試行
10:00:05 FWで遮断
実際のログ
Server 10:00:01 認証失敗
VPN 09:59:58 接続試行
FW 10:00:12 遮断
↓
並べると順番が崩れる
↓
・何が先か分からない
・同一事象として追えない
・原因特定が遅れる
＝ 時刻同期不備で追跡不能切り分け（最短コース）
主要機器の現在時刻を確認する
NTP設定有無と参照先を確認する
タイムゾーン設定が統一されているか確認する
同一事象を複数ログで突き合わせ、秒単位のズレを確認する
仮想基盤、クラウド、SaaS側の時刻基準も確認する
今すぐ効く対処（テンプレ）
・全機器のNTP設定を確認して統一する
・参照先NTPサーバを標準化する
・タイムゾーンを統一する
・ズレが大きい機器は即補正する
・重要機器は日次で時刻ズレ監視を入れる
・SIEM側でも受信時刻と発生時刻の差分を確認する
恒久対策／再発防止チェックリスト
□ 全機器でNTP設定が有効になっている
□ 参照先NTPサーバが統一されている
□ タイムゾーン設定が統一されている
□ 仮想基盤、クラウド、SaaSも含めて時刻基準を整理している
□ 時刻ズレを監視する仕組みがある
□ 新規導入機器の時刻設定確認を標準手順にしている
□ SIEMで時刻差分を確認できる
□ 定期的に時刻同期状態を点検している
落とし穴（やりがちミス）
・NTP設定を入れず手動設定のまま使う
・機器ごとに別の時刻源を使う
・タイムゾーンの違いを軽く見る
・仮想基盤の時刻同期任せにする
・ログ基盤側で吸収できると思い込む
・障害が起きるまでズレに気づかない
まとめ（行動指針）
ログ調査で一番大事なのは、時系列。
時刻がズレているだけで、証跡の価値は大きく落ちる。
まずやるべきは、全機器の時刻源を揃えること。
次に、ズレを監視すること。
「ログを取る前に、時計を合わせる」
ここを外すと、追跡は必ず苦しくなる。