アクセスログに何が残り、何が残らないのかを整理し、痕跡が無いことを「何も起きていない」と読み替えない考え方を解説。POST のボディが記録されない理由、時刻同期と保全、平常時との比較による異常の判断、情報処理安全確保支援士試験での問われ方まで。
インシデント対応は、残った痕跡を読むところから始まります。ところが実際の調査でつまずくのは「何が残っていたか」より「何が残っていなかったか」の方です。記録の限界を知らないまま調べると、痕跡が無いことを「何も起きていない」と読み替えてしまいます。情報処理安全確保支援士試験でも、ここを突く設問が繰り返し出ます。
| 要求の部分 | 既定で残るか | 備考 |
|---|---|---|
| メソッドと URI（クエリ文字列を含む） | 残る | GET のパラメータはここに含まれる |
| 状態コード・応答サイズ | 残る | 成功したかどうかの判断に使える |
| 一部のヘッダ（User-Agent・Referer） | 設定による | 書式の指定で増減する |
| メッセージボディ | 残らない | POST で送られた値は既定では記録されない |
| 応答の本文 | 残らない | 何が返ったかは、サイズからしか推し量れない |
つまり、GET で送られた値は URI として残りますが、POST で送られた値は残りません。設定が書き換えられた時刻の要求は記録されているのに、何を送られたのかが分からない——という状況は、この違いから生まれます。このときは、別の記録（機器やアプリの動作ログ、設定の差分、ファイルの更新時刻）へ当たって突き合わせます。
要求が記録されていることと、それが成功したことは別です。状態コードと応答サイズの組み合わせが手がかりになります。同じ要求が並んでいても、404 が続いていれば試行が空振りしていた可能性が高く、200 で応答サイズが大きければ何かが返っています。権限で弾かれた記録（拒否）と、通ってしまった記録（許可）を分けて数えることで、被害の範囲を確定できます。
# 接続を試した共有と、実際に読めた共有は違う
connect user=sales14 share=sales result=ok
connect user=sales14 share=keiri result=denied
connect user=sales14 share=jinji result=denied
read user=sales14 share=sales files=1842
# → 被害は sales 共有の 1,842 件に確定できる
記録は「残っていること」より「平常時と比べられること」に価値があります。同じ時間帯に別のアカウントも動いているとき、業務どおりの量と桁違いの量が並んでいれば、後者が異常だと言えます。逆に、平常時の姿を知らなければ、目の前の記録が異常なのかどうかを判断できません。監視のしきい値を決めるにも、まず平常時を測ることから始めます。
複数のサーバや機器のログを突き合わせるには、時刻が揃っていることが前提です。NTP による同期とタイムゾーンの統一を、あらかじめ済ませておきます。ずれたまま調査に入ると、前後関係を取り違え、原因と結果が入れ替わった筋書きを立ててしまいます。
一つの記録で分からないことは、別の記録で補います。Web サーバのアクセスログに送信内容が残っていなくても、アプリの動作ログには「設定が変更された」「配布物が展開された」といった結果が残っていることがあります。ファイルの更新時刻、設定の差分、データベースの監査記録、機器の動作ログ——これらを時刻で並べ直すと、記録の隙間が埋まって筋書きが立ちます。
それでも埋まらない部分は、埋まらないまま報告します。「ここまでは確認できた」「ここから先は記録が無く不明」と線を引くほうが、推測で埋めるより役に立ちます。そして、次に同じことが起きたときに分かるよう、何を記録すべきだったかを再発防止に書き残します。監査記録の項目・保存期間・しきい値の見直しは、その典型です。
そのサーバが侵害されていれば、そのサーバのログも消去・改ざんされうる、と考えます。別のサーバへ転送して保管する、追記のみ可能な形で保存する、書き込み権限を絞る、といった手当てをしておきます。調査で対象の機器を触るときは、揮発しやすいもの（メモリ上の情報、確立中の通信）から順に採り、原本を変更しない形で保全します。
調査で見たもの、判断したこと、実施した対処、その時刻——これらも記録に残します。後から経緯を説明できるようにするためであり、途中で担当が交代しても続けられるようにするためでもあります。「痕跡が無いので問題なしと判断した」のような判断は、根拠と一緒に書いておかないと、後から検証できません。報告では、応急でどこまで止めたかと、根本対策として何が残っているかを必ず分けて書きます。
午後問題では、ログの断片を示して「攻撃と判断した根拠」「成功したか否か」「流出した情報の範囲」を書かせる形が定番です。根拠を書くときは、何を見たのか（状態コード、応答サイズ、件数、接続元、時刻）を具体的に挙げます。また、「攻撃に使われた値が確認できなかった理由」のように、記録の限界そのものを問う設問も出ます。令和4年度 春期 午後Ⅰ 問2 では、POST のボディがアクセスログに残らないことが根拠として問われました。
IPA 公式 PDF：令和4年度 春期 午後Ⅰ問題（問2 でログの限界が問われた） ↗本文はこの公式 PDF でご覧ください（アプリ内には転載していません）。
IPA 公式 PDF：令和5年度 秋期 午後問題（問1 は画面の異常から追う構成） ↗本文はこの公式 PDF でご覧ください（アプリ内には転載していません）。