サインインログ、Webアクセスログ、EDR、SaaS監査ログ、DNS/プロキシログをどう読むか。初心者が初動で見るべき順番と記録の残し方を整理する。
ログは「あとで読む証拠」ではなく初動の地図
セキュリティログは、専門家だけが読む巨大な記録ではない。不審なメール、不審なログイン、管理画面へのアクセス、SaaSの権限変更が起きたとき、最初に「何が、いつ、誰に、どこから起きたのか」を確認するための地図である。
初心者がつまずきやすいのは、ログの種類が多すぎることだ。いきなりSIEMの検索式や検知ルールから入ると、何を見ればよいか分からなくなる。まずは、サインインログ、Webアクセスログ、EDRアラート、SaaS監査ログ、DNS/プロキシログの5種類を分けて読むと、初動で迷いにくい。
この記事では、攻撃手順ではなく、防御・確認・記録のためのログの読み方を整理する。実際に手を動かす練習は アクセスログ解析ミニCTF と ログ分析の基礎 に進むとよい。
ここで扱うログ例は学習用の整理であり、特定製品の完全な運用手順ではない。実務では、自社のログ保持期間、権限、個人情報の扱い、インシデント対応規程に従って確認する。
最初に見る5種類のログ
ログは、種類ごとに答えられる質問が違う。1つのログだけで断定せず、複数のログを同じ時間軸でつなぐのが基本だ。
| ログの種類 | 最初に見ること | 分かること |
|---|---|---|
| サインインログ | ユーザー、時刻、IP、端末、MFA結果、対象アプリ | 誰がどこから認証したか |
| Webアクセスログ | URL、ステータスコード、メソッド、IP、User-Agent | どのページや管理画面へアクセスがあったか |
| EDR / 端末アラート | ホスト名、ユーザー、プロセス、検知名、隔離状態 | 端末上で何が実行されたか |
| SaaS監査ログ | 権限変更、外部共有、OAuth同意、管理者操作 | SaaS上で設定や共有が変わったか |
| DNS / プロキシログ | 宛先ドメイン、許可/ブロック、カテゴリ、初回観測 | 端末がどこへ通信しようとしたか |
Microsoft Entra IDのサインインログは、Who、How、Whatの観点で認証リクエストを説明できる。GitHubの監査ログも、誰が、何を、いつ実行したかを確認するための入口になる。製品名が違っても、読む軸は大きく変わらない。
1行のログは「時刻、主体、起点、操作、結果」で読む
ログを読むときは、まず1行を5つに分ける。
| 見る軸 | 例 | 確認したいこと |
|---|---|---|
| 時刻 | 2026-05-17 09:14:08 JST | 他のログと同じ時間帯で見られるか |
| 主体 | [email protected] / svc-backup | 人か、サービスアカウントか |
| 起点 | 203.0.113.45 / device-014 | 通常の場所や端末と合うか |
| 操作 | signIn, repo.permission_change, GET /admin/ | 何をしようとしたか |
| 結果 | success, failure, 401, blocked | 成功したのか、失敗したのか |
ここで重要なのは、成功ログだけを見ることではない。失敗ログも、攻撃者が入口を探している兆候になる。逆に、失敗が多いだけではインシデントとは限らない。時刻、送信元、対象、成功の有無、直後の操作を組み合わせて判断する。
通常時を知らないと異常は読めない
ログ分析でよくある失敗は、「珍しいもの」を全部アラートにしてしまうことだ。深夜のログイン、海外IP、管理者操作、API実行は目立つが、正規の保守作業やバックアップでも起きることがある。
最初に作るべきなのは、精密な検知ルールではなく通常時のメモだ。
| 通常時の観点 | メモすること |
|---|---|
| サインイン | 管理者が使う国、VPN、MFA方式、通常時間帯 |
| Web | 正常な管理画面パス、定期監視のUser-Agent |
| SaaS | 定期的に権限を変更する担当者、承認済みOAuthアプリ |
| 端末 | 業務で使う管理ツール、バックアップソフト、EDR例外 |
| 通信 | 正常な外部API、CDN、SaaS連携先 |
このメモがあるだけで、初動の会話はかなり変わる。「海外IPだから危険」ではなく、「このユーザーは普段VPN経由で国内からしかサインインしない。今回だけ未管理端末から成功している」と説明できるようになる。
初動で残す記録はタイムラインにする
インシデント対応では、ログを見た人の頭の中だけで判断しない。あとから別の担当者が追えるように、最低限のタイムラインを残す。
| 時刻 | 観測したこと | 根拠ログ | 次の確認 |
|---|---|---|---|
| 09:14 | 同一IPから管理画面らしきURLへ連続アクセス | Webアクセスログ | 認証成功の有無を確認 |
| 09:16 | 対象ユーザーでサインイン失敗が複数回発生 | サインインログ | MFA結果と端末を確認 |
| 09:18 | SaaSで外部共有設定が変更された | SaaS監査ログ | 共有先と対象ファイルを確認 |
タイムラインには、推測を書きすぎない。事実、根拠、未確認事項を分ける。たとえば「侵害された」と書く前に、「不審なサインイン成功がある」「直後に共有設定変更がある」「本人確認は未実施」と分けて記録する。
クラウドログはUTC、社内チケットはJST、端末ログはローカル時刻になりやすい。初動メモでは、時刻のタイムゾーンを必ず書く。時刻がずれると、原因と結果の順番を誤認しやすい。
見落としやすい5つの落とし穴
初心者がログを見るときに、特に見落としやすい点がある。
1つ目は、サービスアカウントを人間と同じように扱うことだ。svc- や bot のような名前でも、権限が強い場合は被害が大きい。誰が所有し、どのシステムが使い、いつローテーションしたかを見る。
2つ目は、NATやプロキシの内側を見ないことだ。送信元IPが同じでも、裏側の端末やユーザーが違う場合がある。可能ならVPN、プロキシ、EDR、IdPを合わせて見る。
3つ目は、失敗ログだけで安心することだ。連続失敗の直後に別のIPや別の端末から成功していないかを確認する。
4つ目は、ログが残っていない状態を正常と誤解することだ。監査ログが無効、保持期間が短い、権限不足で見えない場合は、調査できないこと自体をリスクとして記録する。
5つ目は、ログに秘密情報を貼ってしまうことだ。調査メモやチケットへAPIキー、Cookie、トークンをそのまま転記しない。必要なのは識別子、時刻、対象、実施した対応である。
防御・運用へつなげる
ログを読めるようになる目的は、犯人探しではない。次の確認を早く決め、再発防止へつなげることだ。
フィッシング報告なら、メール原本、サインインログ、SaaS監査ログをつなぐ。フィッシング確認チェックリスト と フィッシング報告テンプレート を使うと、報告時に必要な情報が抜けにくい。
管理画面や境界機器が関係するなら、Webアクセスログ、認証ログ、変更履歴を同じ時間軸で見る。インターネット公開管理画面の緊急点検チェックリスト と SIEMとログ管理 を併用すると、見るべきログを整理しやすい。
SaaS権限が関係するなら、ユーザー一覧だけでなく、OAuthアプリ、外部共有、管理者権限、監査ログを見る。SaaS権限棚卸しチェックリスト と SIEMとSOARの違い も合わせて確認したい。
まとめ：ログは「誰が何をしたか」を説明するために読む
セキュリティログの読み方は、難しい検索式を覚えることから始めなくてよい。最初は、サインインログ、Webアクセスログ、EDR、SaaS監査ログ、DNS/プロキシログを分け、時刻、主体、起点、操作、結果をそろえることから始める。
ログは単独では断片でしかない。複数のログを同じ時間軸でつなぎ、通常時との差分を見て、事実と推測を分けて記録する。これができると、インシデント対応、SaaS棚卸し、フィッシング報告、脆弱性対応の初動がかなり安定する。
次に手を動かすなら アクセスログ解析ミニCTF を解き、基盤の考え方は SIEMとログ管理 で確認する。検知後の流れは インシデント対応 に進むと、ログが実務の判断につながる。
参考情報
- NIST SP 800-92: Guide to Computer Security Log Management — ログ管理の目的、体制、保持、運用プロセスを確認できる。
- OWASP Logging Cheat Sheet — アプリケーションログで記録すべきイベント、除外すべきデータ、運用上の注意点を確認できる。
- Microsoft Learn: Sign-in logs in Microsoft Entra ID — Entra IDのサインインログで確認できる情報を確認できる。
- GitHub Docs: Reviewing the audit log for your organization — GitHub組織の監査ログで確認できる操作履歴を確認できる。
