ログは「信頼の起点」ではない：Log Injectionという名の静かなる改竄
多くのエンジニアが犯す最大の過ちは、ログを「神聖な記録」と錯覚することだ。ログは事実の断片に過ぎず、悪意あるユーザーが介入する余地がある限り、それは偽装工作のキャンバスへと変貌する。
今日のテーマは「ログインジェクション（Log Injection）」だ。単なる改行コード（\n, \r）の挿入による見かけ上の偽造と思っているなら、君はまだこの攻撃の真の脅威を理解していない。これは、SIEM（セキュリティ情報イベント管理）やログ分析基盤を汚染し、インシデント対応担当者の認知を歪め、最終的にフォレンジックを無効化する、極めて「戦略的」な攻撃なのだ。
—
1. なぜ「ただの改行」がシステムを殺すのか
ログインジェクションの根本的な問題は、「出力側のコンテキスト」と「入力側のデータ」を同じストリームで処理している点にある。
攻撃者は、アプリケーションがログに出力する文字列に、制御文字を混入させる。例えば、ユーザーエージェントやログイン名に \n[INFO] User:admin login success といった文字列を注入する。すると、ログファイルには本来存在しない「管理者がログイン成功した」という偽のイベントが一行挿入されることになる。
これは単なるいたずらではない。現代の運用現場では、ログはDatadogやSplunk、ELK Stackに吸い上げられ、アラートのトリガーとなる。攻撃者は「偽の成功ログ」を注入することで、攻撃の痕跡を隠蔽し、逆に「偽の異常ログ」を大量投入することで、監視担当者をアラート疲れ（Alert Fatigue）に追い込み、本当の侵入を見逃させるという二段構えの工作を行うのだ。
2. 構造化ログへの転換：アーキテクチャによる防衛
文字列置換によるサニタイズは、もはや過去の遺物だ。正規表現でのフィルタリングは、エスケープシーケンスの組み合わせや文字エンコーディングの差異（Unicode正規化の不一致など）によって容易にバイパスされる。
防御の要諦は、「ログを構造化データとして扱い、通信プロトコルレベルで分離すること」にある。
JSON形式でログを出力すれば、ログ収集基盤側でそのフィールドを正しくパースできる。もし入力値に改行が含まれていても、それはJSONの単一の値（Value）として扱われ、ログファイルの行構造を破壊することはない。
実装例：Rustによる型安全な構造化ログ出力（tracing crate）
use tracing::{info, instrument};
[instrument]
fn handle_login(user_id: &str) {
// 構造化ログを出力する。
// 入力値 user_id に改行が含まれていても、
// JSONの文字列値としてエスケープされるため、ログ構造は破壊されない。
info!(
event = “login_attempt”,
user_id = %user_id, // %はDisplayトレイトを呼び出し、適切にエスケープ処理される
status = “success”
);
}
fn main() {
// コンソール出力時にはJSONフォーマッタを利用する
tracing_subscriber::fmt().json().init();
let malicious_input = “attacker\n[INFO] User:admin login success”;
handle_login(malicious_input);
}
3. 生成AI時代の「プロンプト・ログインジェクション」
現在、我々が直面している新たな脅威は、LLM（大規模言語モデル）の推論結果をログに吐き出す際に発生する「プロンプト・ログインジェクション」だ。
LLMはプロンプトに含まれる命令に従う。もし、ユーザーからの入力をログに記録し、そのログを後段のLLMエージェントが「分析」のために読み込むアーキテクチャを組んでいる場合、ログに書き込まれた悪意あるプロンプトが、分析側のAIを乗っ取る可能性がある。
これを防ぐには、「ログ・ガードレイル」の導入が不可欠だ。
- 推論の分離: ログデータには決してLLMの実行権限（Tool Use権限）を与えない。
- 非構造化データのサンドボックス化: ログを読み取るAIモデルには、特定のシステム命令を無効化するシステムプロンプトを固定的に付与する。
- 不変的な監査ログ: ログファイル自体をWORM（Write Once Read Many）ストレージに保存し、改竄不能性を担保する。
4. 最後に：インフラの視点からの監査
君がテックリードとして行うべき監査は、コードだけではない。以下を確認してほしい。
1. ログフォーマットの強制: 全マイクロサービスでJSONログ出力を必須とし、生テキストの出力はCI/CDパイプラインのLintで弾くこと。
2. SIEMの取り込みルール: ログ取り込み時の正規化ルールを監視し、予期せぬ改行や制御文字が検出された場合に、即座にセキュリティエンジニアへ通知が飛ぶよう設定すること。
3. メモリ境界の保護: 低レイヤのC/C++モジュールがログ出力を行う場合、メモリ破壊によってログバッファがオーバーフローしないか、ASLRやStack CanaryといったOSレベルの保護が有効かを確認すること。
ログはシステムが語る「物語」だ。その物語を誰に書かせるのか。悪意ある攻撃者にペンを持たせてはならない。我々セキュリティアーキテクトが設計するのは、侵入を許さない壁だけでなく、「たとえ侵入されても、システムが語る真実を歪めさせない強固な監査基盤」なのだ。
この領域において、妥協は最大の脆弱性である。君たちのログ基盤が、今日からより堅牢なものになることを期待している。
コメント