監査ログ: 何を記録し、どう改ざんから守り、誰が読めるようにするか

概要

引用したOWASP Logging Cheat Sheetは、各エントリにいつ・どこで・誰が・何をを記録するよう求めている: イベントとログのタイムスタンプ、アプリケーションとホスト、操作を行ったユーザーまたはマシンのIDとその送信元アドレス、イベントの種類、対象となったオブジェクト、結果、理由。常にログを取るべきイベントの一覧には、認証の成功と失敗、認可の失敗、ユーザー管理操作、管理者権限の使用、機密データへのアクセス、鍵の使用とローテーション、設定変更が含まれている。監査ログとは、このうちプリンシパルに代わって取られた操作を記録する部分を指し、トラブルシューティング用の出力としてではなく、記録として保持されるものである。

重要な理由

監査ログに価値があるのは、重要な操作について漏れなく記録されており、なおかつその操作を行った本人がひそかに書き換えられない場合だけである。Cheat Sheet自身が挙げているログへの攻撃の一覧には、攻撃者が書き込みを妨害したり、痕跡を消すためにログを破損させたりすること、そして責任者を隠すために誤ったIDを記録させることが含まれている。

適用方法

• プリンシパルとオブジェクトが分かっているアプリケーション層から、安定したスキーマを持つ構造化レコードとして監査イベントを発行する: 実行者、実行者の種別、操作、対象の種別とID、結果、理由、リクエストID、UTCでのタイムスタンプ。
• 実行者は表示名ではなく識別子として記録し、なりすまし(「管理者Xがユーザーyとして操作」)は明示的に含める。
• セッション識別子、アクセストークン、パスワード、鍵、個人データ全体は書き込まない。Cheat Sheetはこれらを除外またはマスクすべきデータとして挙げている。
• エントリは、アプリケーションが変更できないストレージへ速やかに送る: 書き込み専用のデータベースロールの下にある追記専用テーブルや、保持ロック付きのオブジェクトストレージなど。引用したAmazon S3 Object Lockは、保持期間中はどのユーザーによる上書きや削除もコンプライアンスモードによって防がれる、write-once-read-manyモデルを説明している。
• 改ざん検知の仕組み、たとえばハッシュチェーンや定期的な署名済みダイジェストを追加し、スケジュールに沿って検証する。
• 読み取りアクセスは指定したグループに制限し、すべての読み取りをログに記録し、Cheat Sheetが求めるとおり権限リストを定期的に見直す。
• 保持期間をあらかじめ定義し、スケジュールどおりに削除する。目的を超えて監査データを保持し続けること自体がリスクになる。

落とし穴

監査レコードを、1週間でローテーションしてしまうアプリケーションログに混ぜてしまうこと。意図(「削除がリクエストされた」)は記録しても結果を記録しないこと。クエリできない自由記述のメッセージ。イベント内のクライアント提供のユーザーIDを信用してしまうこと。インシデントが起きるまで誰も読まない不変のログ。