概要
「ログを残す」という要件だけでは、異常に気付いた人が何を確認できるかは決まりません。新規システムの発注担当者は、守りたい業務と確認したい操作を挙げ、通知を受けた後の判断者まで決めます。開発担当者は、その判断に必要な情報を記録し、探せる形にします。OWASPのログ設計資料
OWASP（オワスプ）は、ソフトウェアの安全性を高めるための資料やツールを無料公開する非営利団体です。
OWASPの紹介
この記事では、不審な操作を見つけることと、発生後に影響を調べることの両方を扱います。稼働状況を把握する監視やアクセス数の分析とは目的を区別して、必要な記録を選びます。
確認された事実：ログの欠落は調査範囲に関わる
アスクルの2025年の事例について、同社の2025年12月12日の第13報は、一部の通信ログ・アクセスログが失われていたため、攻撃者が閲覧した可能性のある情報の範囲を完全に特定することは困難と説明しています。第13報3ページ
これは当該報告時点の調査上の制約です。この記載から、同社にログや監視が一切なかった、ログ設計の不備が侵入原因だった、と結論付けません。サービス全体のその後の状況は事例記事の続報と区別して確認します。
一般化したリスク：記録があっても使えない
ログがサーバー内だけにあると、そのサーバーの破壊や侵害と同時に失われる可能性があります。記録が残っていても、誰の操作か、どのデータを対象にしたかが分からなければ、影響範囲の調査には使いにくくなります。OWASP A09
一方、入力内容や通信を丸ごと保存すると、パスワード、トークン、個人情報がログへ複製される場合があります。量を増やすだけでは、情報流出の対象と確認コストも増えます。OWASPは目的に応じた項目の選定と、秘密情報などの除外を示しています。Logging Cheat Sheet
推奨する設計：操作から通知後の確認まで決める
以下はOWASPの考え方を基にした設計案です。製品を導入する前に、業務の中で何を知る必要があるかを整理します。
1. 重要な操作と記録項目を対応させる
たとえば顧客管理システムでは、ログインの成功・失敗、権限の変更、顧客情報の一括出力、管理者の操作を検討します。操作の時刻、操作主体の内部ID、対象、成否、関連する処理IDをそろえると、複数のサービスをまたぐ動作も追いやすくなります。記録形式と時刻の基準も合わせます。Logging Cheat Sheetのイベント・項目
発注時には「顧客情報の出力後、誰が・いつ・どの範囲を出力したかを調べられる」のように確認したい状態を示します。開発側はテスト用の利用者とデータで実際に操作し、記録から再現できることを納品時に示します。通常の画面アクセスログだけでこの条件を満たすかは別に確認します。
2. 残さない情報と保存の責任を決める
パスワード、認証トークン、秘密鍵、Cookieやリクエスト本文の無条件な保存を避けます。外部入力をそのままメッセージへ連結せず、構造化した項目へ記録し、改行などによる記録の偽装も防ぎます。Logging Cheat Sheetの除外・収集
ログの保存先はアプリケーションの管理権限から分離し、書き込みと閲覧・削除の権限を必要な範囲に絞ります。別の保存先へ送る場合も転送遅延や欠落を検知します。保存期間は調査に必要な期間、扱う情報、費用から決め、削除まで確認します。Logging Cheat Sheetの保護・廃棄
保存期間を長くするほど調査に使える範囲は広がりますが、機密情報へのアクセス管理と保管費用も必要です。すべてを無期限に残す方針ではなく、業務責任者が理由を確認できる形にします。
3. 通知先と対応手順を一緒に設計する
認証失敗の増加、通常と異なる大量出力、権限変更など、通知する条件を決めます。最初からすべてを緊急通知にせず、確認すべき重要度を分け、通常業務で発生する誤検知を見ながら調整します。アラート過多や対応手順の不足もOWASP A09が挙げる課題です。OWASP A09
通知ごとに、受信担当、一次確認する画面、利用停止を判断する人、担当不在時の連絡先を残します。営業時間外に対応できないなら、その条件と翌営業日までに生じる影響を要件として共有します。「24時間監視」という文言だけで、即時の人による対応まで含まれるとは判断しません。
4. 監視の仕組み自体を試験する
検証環境で、想定した認証失敗や権限変更を行い、記録・通知・担当者の確認まで通します。収集先への接続断、容量不足、時刻ずれも試し、ログの停止を知る方法を確認します。ログ処理の失敗がアプリケーションに与える影響も、業務上の要件に照らして決めます。Logging Cheat SheetのVerification