【メモ】ログ、監視、検知の初歩
はじめに
技術職にとって、ログは「何かあった後に見るもの」ではありません。
設計、運用、検知、インシデント対応を成立させるための基盤です。1
この章では、どんなログを考えるべきか、何を見ればよいか、監視と検知をどう捉えるかを整理します。
ログはなぜ重要か
ログがないと、次のような問いに答えにくくなります。
- 誰がいつログインしたか
- どの操作が行われたか
- 何が失敗し、何が成功したか
- どこから異常が始まったか
つまりログは、調査の材料であると同時に、平時の監視と異常検知の前提です。
まず考えたいログの種類
認証ログ
ログイン成功、失敗、多要素認証、権限変更などを追うためのログです。1
ここでは、次のような異常が見えます。
- 失敗の連続
- 失敗後の成功
- 想定外の時間帯や場所からの利用
- 権限変更や新規付与
操作ログ
重要データの閲覧、変更、削除、ダウンロード、設定変更の記録です。
誰が何をしたかを追うための基本になります。
アプリケーションログ
エラー、入力処理、認可失敗、業務イベントなど、アプリ内部で起きたことを把握するためのログです。
ただし、秘密情報をそのまま出さないよう注意が必要です。
監査証跡
後から検証や説明責任に耐える形で残すべき記録です。
単なるデバッグ出力とは目的が違います。
監視で考えるべきこと
監視は、「ログを保存すること」では終わりません。
何を異常とみなすか、どこで気付くかを設計する必要があります。1
考えたい観点は次のとおりです。
- 重要イベントを取れているか
- 通知すべき条件が決まっているか
- 誰が見るか決まっているか
- 取りっぱなしになっていないか
検知はベースラインとの差分で考える
異常は、単独イベントだけでなく、「普段と違う」ことで見える場合があります。
そのため、技術職はベースラインの感覚を持つことが重要です。
たとえば、次のような差分です。
- いつもと違う時間帯の大量操作
- 突然増えた認証失敗
- 想定外の管理操作
- 普段見ないエラーの急増
アラートは多すぎても少なすぎても問題
アラートが多すぎると、重要なものが埋もれます。
少なすぎると、異常を見逃します。1
そのため、検知では次のバランスが必要です。
- 誤検知を減らす
- 見逃しを減らす
- 重要度に応じて通知を分ける
- 見たあとに動ける形にする
タイムラインで整理する癖を持つ
調査やインシデント対応では、点で見たログを時系列でつなぐ力が必要です。1
次のように整理すると考えやすくなります。
- 最初の異常は何か
- その前後に何が起きたか
- 認証、操作、通信がどうつながるか
- どこで被害拡大を防げたか
この考え方は、後続のインシデント対応記事でも重要になります。
起こしやすい誤り
ログを残していれば十分と思う
保存だけでは検知になりません。
何を見るか、誰が見るか、どう通知するかが必要です。
調査に必要な情報が何かを考えずに出力する
逆にログが多すぎて、重要情報が埋もれることもあります。
必要な主体、対象、結果、時間が取れているかを見るべきです。
エラーを消すことを優先してログを軽視する
問題が起きたとき、再現できなくてもログがあれば追えることがあります。
運用に使えるログを残す設計が重要です。
日常で意識したい原則
- 認証、操作、アプリ、監査の観点でログを考える
- ログは保存だけでなく監視まで設計する
- ベースラインとの差分を見る
- アラートは見て動ける粒度にする
- 調査では時系列でつなぐ
ミニ確認
- 認証ログと操作ログでは、何が違うか
- 監視が保存だけでは足りないのはなぜか
- ベースラインとの差分を見る意味は何か
- アラート設計で重要なバランスは何か