ログ監査をしておらず侵入検知できない『セキュリティの話⑩』
サーバは普通に動いている。
アラートも鳴っていない。
実はその裏で 侵入はとっくに起きていた。
原因は ログを「保存しているだけ」で、監査していないこと。
初学者が「何かあったら見ればいい」で済ませがちな、最後に効いてくる致命傷だ。
冒頭の一言要約
ログは“集めるだけ”では意味がない。
見ていなければ、侵入は存在しないのと同じ。
症状（あるある）
不正ログインに誰も気づかない
侵入後の痕跡を追えない
いつ・誰が・何をしたか不明
事後対応がすべて推測になる
ログはあるが誰も見ていない
監査対応で詰む
原因と仕組み（なぜ起きるか）
ログを定期的に確認していない
アラート条件を作っていない
ログが分散していて見づらい
保存期間が短すぎる
正常／異常の基準がない
「侵入されたら分かる」という思い込み
侵入は
派手なアラートを出さない。
多くの場合、
ログにだけ“痕跡”が残る。
それを見ていなければ、
侵入は“無かったこと”になる。
図：ログ監査の有無で変わる未来
[侵入]
│
├─ ログ監査あり → 早期検知・被害最小
│
└─ ログ監査なし → 長期潜伏・被害拡大
切り分け（最短コース）
ログの保存先確認
ローカルのみか
集約されているか
重要ログの有無確認
SSH
sudo
Web / DB
保存期間確認
数日で消えていないか
失敗ログインの有無
grep "Failed password" /var/log/secure
誰が最後に見たか確認
「見ていない」が答えなら危険
今すぐ効く対処（テンプレ）
◆ 最低限やるべきこと
重要ログを把握
SSH
sudo
認証系
週1回は目視確認
失敗ログイン回数を意識する
◆ 一歩進んだ対応
ログを集中管理（syslog 等）
失敗回数でアラート
深夜・休日の操作を検知
※ 高価なSIEMは不要。
まず「見る」こと。
恒久対策／再発防止チェックリスト
監査対象ログを決める
ログ保存期間を十分確保
ログを集約する
異常の基準を定義
定期確認を作業に組み込む
侵入想定でログを見直す
アラート条件を段階的に追加
「見ていないログは無いのと同じ」と認識
落とし穴（やりがちミス）
保存しているだけで満足
何を見ればいいか決めていない
異常が起きてから探し始める
ログが多すぎて放置
監査＝大規模ツールと思い込む
まとめ（行動指針）
ログ監査がない運用は、
「侵入に気づけない前提」で動いている。
集める → 見る → 気づく。
この3点を回すだけで、
侵入は「後から知る事故」ではなく
「止められる事象」になる。
