LLMゲートウェイ侵害に備える: LiteLLM系インシデント後の企業向け対応設計

LiteLLMのような共通ゲートウェイ層に関連した侵害報道は、AI基盤の信頼境界を再定義しました。ゲートウェイが改ざんされると、モデルAPIキー、プロンプト履歴、ルーティング規則、監査証跡まで同時に揺らぐ可能性があります。

参考: https://techcrunch.com/2026/03/31/mercor-says-it-was-hit-by-cyberattack-tied-to-compromise-of-open-source-litellm-project/

初動1時間でやるべきこと

初動では利便性より封じ込めを優先します。

• ゲートウェイ依存コンポーネントのデプロイを凍結
• 連携先モデルプロバイダー鍵を即時ローテーション
• 動的プラグイン読込・遠隔設定取得を停止
• 最小構成の既知安全ルーティングに強制切替

SaaS提供側であれば、疑わしいテナントを機能縮退モードに入れ、閲覧系機能のみ維持する設計が有効です。

影響範囲は「データ種別」で切る

被害範囲の特定は、システム境界ではなくデータ種別単位で行うと早くなります。

• 秘密情報（APIキー・サービストークン）
• 入出力ペイロード（プロンプト・応答）
• テナント別ルーティング情報
• ポリシー例外・上書き履歴

この切り口で整理すると、法務・CS・開発が同じ地図で会話できます。

復旧後に恒久化すべき4改善

1. 制御面と実行面の権限を分離する
2. 短命クレデンシャルをワークロード単位で払い出す
3. 署名付きビルドと来歴検証を強制する
4. テナント分離暗号化ログに移行する

重要なのは「次回起きても全社障害にしない」構造を作ることです。

AIゲートウェイ固有の検知指標

通常のCPU/メモリ監視だけでは遅れます。LLM運用向けに以下を監視します。

• テナント別のモデルルーティング逸脱率
• 予期しないプロンプト切り捨て増加
• プロバイダー認証失敗の急増
• 変更窓外でのポリシー上書き試行

これらを不可変監査ログと組み合わせることで、攻撃者の移動経路を再構築できます。

顧客通知は「確度」と「時系列」を分ける

通知文では、確定事項と調査中事項を明確に分離します。

• 何が起きたか（確定事実）
• 影響が及ぶデータ種別
• こちらで失効・再発行した資格情報
• 顧客側で推奨するローテーション対象

24時間以内に完全確定を約束するより、更新時刻を明示して継続公開する方が信頼されます。

30日ハードニング計画

• 1週目: 鍵ローテーション自動化・依存凍結ポリシー
• 2週目: 署名ビルド強制・サプライチェーン来歴検証
• 3週目: テナント分離ログと鍵階層再設計
• 4週目: ゲートウェイ侵害を想定した机上演習

まとめ

LLMゲートウェイは既に基幹インフラです。侵害対応を「臨時のセキュリティ作業」ではなく、継続的な信頼性運用の中核として扱う必要があります。