監査に使えるログとは？ 追跡できる記録と保存範囲の決め方
発注の承認を取り消した人を調べたいのに、通信の記録と注文が結び付かない。一方、調査に使わない自由記述は大量に残っている。そんな購買システムの仮想例から、必要なログを考えます。取引IDや時計を合わせて一件を追い、記録を追加する範囲と、保存しない内容を分けていきます。
ログとは、システムで起きた出来事の記録である。設計の出発点を「何を取れるか」から「何を後で確かめたいか」へ変えたい。調査に必要なつながりが欠けるなら記録を追加し、目的に関係のない秘密情報が混ざるなら内容を絞る。追加と削減は、相反する方針ではない。
この記事の目次
一件の操作を、記録から最後まで追う
以下は編集上の提案である。「誰が権限を変更し、その後どの対象へアクセスしたか」という問いを一つ選び、今の記録で答えてみる。実際の事故を待たず、許可された検証操作で追跡できるかを確かめると、収集量の一覧には表れない不足を発見しやすい。
変更の時刻はあっても、変更前後の役割が分からないかもしれない。利用者の識別子はあっても、業務上の対象が残っていないかもしれない。別々の記録の時刻が揃わず、前後関係が曖昧になることもある。その不足に対して必要な項目を追加するのであって、リクエスト本文を丸ごと保存すれば解決するとは限らない。
記録が結び付いたら、それを誰が読み出せるかも確かめる。必要な担当者が事故のたびに例外申請を繰り返さなければ調べられない状態も、誰でも顧客の記録を検索できる状態も、目的と権限が噛み合っていない。平常時と調査時の権限を分ける案を、運用責任と一緒に検討する。
主体・取引ID・時計の違いをほどく
架空の取引T42に「受付09:00」「承認09:02」「送信09:01」の記録があっても、サーバー間に時計差があれば未承認送信と断定できない。取引識別子、イベントの意味、時計の同期条件を対応させて読む。説明に必要な記録をそろえることと、パスワードやトークンの本文を保存することは別であり、前者のために後者を収集する必要があるとは限らない。
同じ名前を、同じ主体の証拠にしない
一連の記録をつなぐときは、認証側の主体、アプリ側のセッション、業務要求、中央のイベントを別の識別子として扱う。例えばOpenID Connect Core 1.0の5.7節では、発行者を表すissと主体を表すsubの組が安定した識別子であり、メールアドレスや表示名には同じ保証がない。8節には、利用先によって異なるsubを返す方式もある。表示名だけで横断検索した結果を、同じ人物の履歴と扱わない。
これはOpenID Connectの仕様上の区別で、全製品がその識別子をログへ出すという意味ではない。実際のID対応を許可された範囲で検証し、別システムのIDへの対応、セッションの開始・終了、共有アカウントの利用期間を結び付ける。対応表が現在の名簿だけなら、当時の利用者を確定できない。分かるのが共有アカウントまでなら、個人の行為の断定をそこから先へ広げない。
発生時刻と到着時刻を分け、検索の失敗を診断する
OpenTelemetryのログデータモデルは、発生元の時計によるTimestampと、収集系が観測したObservedTimestampを区別する。後者は中央保存の完了時刻とは限らない。遅れて届いた承認ログを到着順で並べれば、承認後の処理が先に起きたように見える。発生順を見る欄と収集の遅れを見る欄を別に持つ理由である。
UTC表記へそろえることと、時計が正しいことも別だ。2024年の国際共同指針は時刻の形式、同期と検証、ログの取り込みの遅れを扱う。時計差の範囲を実際に確認できた場合にだけ、その範囲を含む発生時刻の区間を比べる。区間が重なる操作は時刻だけで前後を確定できず、要求の対応や処理順の記録も必要になる。同期状況が分からないのに、細かな秒数で結論を強くしない。
検証操作が中央で見つからなければ、まず生成元にそのイベントがあるかを見る。無ければ生成条件、あれば転送と取り込み、到着を確認できるのに検索できなければID・項目変換・時刻範囲・閲覧権限を調べる。これは各段階の記録を照合する編集上の診断であり、実際に欠落や遅延を測った結果ではない。転送の遅れと分かった場合も、復元済みの確認までは対象期間を未確認として残す。
生成・転送・検索の、どこで途切れたか
ログを検索して該当がなかったとしても、出来事が起きていないとは限らない。送信が途切れた、項目の名前が変更された、検索する時刻の範囲が違った、という可能性がある。OWASPも記録停止の検知や、ログ機構が失敗する場合の試験を扱っている。確認すべきなのは、保存先の容量だけではなく、出来事から検索結果までの経路である。
ここでの編集提案は、記録されるはずの検証操作と、実際に検索できた記録を対応させることだ。たとえば、許可された権限変更を行った際に、対象と時刻が辿れるかを確かめる。利用者の本番データを無断で動かす必要はなく、管理された対象で試す。
もし記録の停止が発見されたら、その期間を「異常なし」の集計から外すだけで済ませない。未確認の期間として明示し、代替となる記録の有無を調べる。すべてが復元できると約束せず、説明できる範囲を区切る。過剰な収集を減らす方針と、観測できていない期間を認める姿勢は両立する。
足りないつながりを足し、不要な秘密を除く
NISTのSP 800-92は、生成から転送、保存、分析、廃棄までを含むログ管理を扱う。米国の2006年の技術指針であり、企業への導入効果を比較した実験ではない。また、日本の全企業に同じ保存期間を課す資料でもない。ここでは、記録の量だけでなく運用全体を設計する考え方を参照する。NIST「Guide to Computer Security Log Management」
一方、OWASPのLogging Cheat Sheetは、アプリケーション側の記録に焦点を当てる。機器のログだけでは足りない業務上の情報がある一方、パスワードやアクセストークンなどをそのまま記録すべきでないとしている。観測を増やすことと、秘密を複製することを同一視しないための実装上の指針だ。OWASP「Logging Cheat Sheet」
両者は異なる実験結果を競わせる資料ではない。前者は管理の全体像、後者はアプリケーションで残す内容と保護の具体化に重心がある。どちらからも「長く大量に残せば監査に合格する」という効果量や保証は得られない。
詳しく残す前に、複製してはいけないものを決める
障害解析では、入力された内容が分かると原因を特定しやすい。しかし、入力には顧客の自由記述や認証情報が含まれ得る。業務の本体では厳しく管理していても、解析用の記録へ複製した途端に、別の担当者や外部サービスへ見える範囲が広がることがある。
そこで、保存する項目を意図して選ぶ。出来事の種類、対象を追うための識別子、成功・失敗など、調査の問いに必要な情報を整理する。そのうえで、内容そのものが必要な場面と、識別できれば足りる場面を分ける。識別子も別の資料と結び付けば個人を特定できる場合があるので、名前を消しただけで安全と呼ばない。
詳細な記録を一時的に増やす必要があるなら、対象、閲覧できる人、解除する条件を定める。原因が解消した後も詳細モードが残り続ければ、一時対応が恒常的な収集へ変わる。取得後に消すだけで済ませず、送信先や複製先まで追えるかを確認したい。
この提案は、重要な事象まで記録しないことを勧めるものではない。内容を絞る作業と、必要な事象を残す作業を別々に点検する。重要な操作の記録が抜けているなら、機密情報の削除と同時に、その記録経路を補う。
一括保存と対象追加の、どちらを選ぶか
仮想例として、社内の購買システムを考える。現在は通信の記録だけがあり、発注の承認を取り消した人と対象の注文が分からない。この場合は、承認変更という業務上の出来事を追加する価値がある。通信記録を長く残すだけでは、もともと記録されていない関係を取り戻せない。
一方、その出来事は既に追えるが、解析用のログへ申請者の自由記述や秘密情報まで保存されているとする。調査で内容自体を使っていないなら、対象の識別と状態の変化を残し、不要な内容の収集を止める案を優先する。必要な証拠が揃っているという条件が、選択を追加から絞込みへ変える。
ただし、不正の疑いがあり特定期間の記録を保全する必要が生じたなら、平常時の削減をその記録へ機械的に適用しない。利用目的、権限、保存の状態を明確にして扱う。量を減らすことが目的ではなく、説明と保護の両方を成立させることが目的だからである。
通常の保存と、調査中の保全を分ける
保存期間を決める際には、調査や業務に必要な期間、適用される義務、契約、情報の性質を合わせて確認する。全項目に一律の年数を付ければ、説明しやすくはなる。しかし、すぐに検索したい記録と、限定的な理由で保管する記録を、同じ状態で抱える必要があるとは限らない。
NISTの原資料は、通常の保存と、調査などのために本来廃棄する記録を保全することを区別している。平常時の廃棄ルールがあるからといって、調査中の証拠まで機械的に削除してよいわけではない。NIST SP 800-92本文、3.1節
ここからの提案は、通常の保存期間と、保全の開始・解除の判断を別に記録することである。誰が何を根拠に保全し、いつ見直すかを残す。この記事では個別の法的義務や年数を判定しない。必要な保存を短縮する際は、その根拠を担当部門と確認する。
監査への回答を、容量の報告から変える
次のレビューでは、「何件を何年残しているか」に加え、「どの問いに答えられるか」「答えられない範囲はどこか」を示す。必要な記録が止まったときに分かるか、保管したデータを読み出せるかも、検証した範囲を添える。
保存量は作業の規模を表しても、証拠の十分さを直接は表さない。足りないつながりは追加し、不要な秘密は除き、必要な人が保護された記録を辿れるようにする。ログ投資の優先順位は、その順序で決めたい。