KEEL

運用

第13章 運用

Runbook・アラート・キーローテーション・LiteLLM サプライチェーン・四半期レビューを運用担当向けに定義する。

主な読者: インフラセキュリティPM

運用の目的

Phase 1 本番以降、LLM ゲートウェイは 24/7 業務基盤 となる。本章は Runbook、アラート、キーローテーション、LiteLLM サプライチェーン、四半期レビューを定義する。

運用体制

役割責務一次対応時間
L1（ヘルプデスク）接続 FAQ、申請案内営業時間
L2（インフラ）障害、スケール、パッチ24/7 オンコール
L3（セキュリティ）DLP、インシデント24/7（重大時）
CoE（Phase 2）モデル選定、ベストプラクティス月次

Runbook 一覧

IDシナリオ概要
RB-01ゲートウェイ全ダウンレプリカ再起動 → ロールバック → 経営通知
RB-02プロバイダ 5xx 多発ステータス確認 → フェイルオーバー → ベンダーケース
RB-03コスト急増該当キー特定 → 一時停止 → PM 通知
RB-04DLP 誤検知多発ルール調整チケット → セキュリティ承認
RB-05Key Vault アクセス失敗MI 権限確認 → フェイルオーバー判断
RB-06LiteLLM CVE 公表緊急パッチ手順（下記）

RB-01 詳細（抜粋）

  1. Azure Monitor でアラート確認
  2. kubectl rollout restart または Container Apps リビジョン再起動
  3. 5 分以内に復旧しなければ前リビジョンへロールバック
  4. ステータスページ更新、#llm-gateway-incidents に投稿
  5. ポストモーテム 48h 以内にドラフト

アラート設計（運用版）

重要度例対応 SLA
P1全ダウン、データ漏洩疑い15 分以内初動
P2エラー率上昇、単一 AZ 障害1 時間
P3コスト 85% 通知翌営業日
P4パッチ利用可能計画ウィンドウ

アラート疲労を防ぐ — Phase 1 終了時点で 有効アラート 10 本以内 を目標にチューニング。

キーローテーション

対象周期手順
プロバイダ API キー90 日Key Vault 新バージョン → LiteLLM リロード → 旧版無効化
仮想キー90 日 or プロジェクト終了利用者に 7 日前通知 → 新キー発行 → 猶予 14 日 → 旧キー失効
ゲートウェイマスターキー180 日メンテナンスウィンドウで実施
TLS 証明書自動更新（Let's Encrypt / Key Vault）期限 30 日前アラート

ローテーション中の留意

LiteLLM サプライチェーン

活動頻度内容
バージョン追跡週次GitHub Releases、CVE 監視
非脆弱パッチ月次メンテナンスウィンドウで適用
Critical CVE72h 以内緊急パッチ or WAF ルールで緩和
イメージスキャンビルド毎Trivy / Defender for Containers
SBOM 保管リリース毎監査用

OSS のため ベンダー SLA はない。自社でパッチ判断とテスト環境が必須。

アップグレード手順

  1. ステージングに新イメージデプロイ
  2. 回帰テスト（第 12 章 T1-T6）
  3. カナリア 10% トラフィック（可能なら）
  4. 全量切替、24h 監視強化

バックアップ・DR

対象方法保持
LiteLLM DB（キーメタ）日次スナップショット30 日
設定（Git）GitOps無期限
ログSIEM 側ポリシー1 年

RTO 4h / RPO 1h（Phase 1）— Phase 2 で改善。

四半期レビュー

アジェンダ（90 分）

  1. KPI レビュー（利用率、コスト、インシデント）
  2. DLP ルール効果・誤検知率
  3. 新モデル・プロバイダ評価
  4. コンプライアンス更新（規制動向）
  5. ロードマップ更新（Phase 2/3）
  6. 未決事項クローズ

参加者

経営スポンサー、PM、セキュリティ、インフラ、SE リード（各 1 名）

成果物

変更管理（運用期）

変更承認ウィンドウ
設定微調整L2随時
新モデルセキュリティ月次
メジャーバージョンL2 + セキュリティ四半期

利用者コミュニケーション

運用 KPI

KPI目標
可用性99.5%（Phase 1）
P1 初動15 分以内 100%
パッチ適用（Critical）72h 以内
四半期レビュー実施100%

テンプレ・コンプライアンス → 第 11〜12 章。

セキュリティパッチ Runbook（LiteLLM 特化）

トリガー

手順

  1. 影響調査 — 稼働バージョン、公開経路、JWT/MCP/Guardrails 有効化の有無
  2. ステージング適用 — バージョン固定（litellm==x.y.z）で再現ビルド
  3. 回帰テスト — Virtual Key 発行、/chat/completions、予算ブロック、DLP flag
  4. 本番適用 — メンテナンス窓。ロールバック用イメージを保持
  5. 鍵ローテーション — Critical 時はプロバイダ API キー全ローテーション
  6. 事後報告 — インシデントチケット、CVE 番号、適用版を記録

監視クエリ例（概念）

シグナル意味
401/403 急増 on /key/*権限昇格試行の可能性
未知 Host ヘッダーCVE-2026-49468 系の探索
/mcp-rest/test/* への外部 IP即ブロック + 調査

四半期レビューへの追加項目

v1.8 — CF AIG 運用 Runbook 追記

日次

週次

月次

既知の制限（運用受け入れ）

制限影響緩和
BYOK コストは best-effortダッシュボードと AWS 請求がズレるCUR を正、GW は予算ストップ用
Spend limits は eventually consistent短時間バーストで上限超過しうるレート制限を併用 [72]
トークンはアカウントスコープ漏洩時の影響が広いアカウント分割・短期ローテーション [77]
ログにプロンプト全文コンプライアンスリスクDLP・マスキング・保持期間ポリシー

v1.8.1 — Cloudflare Access 自動 metadata（U-CF-02 解消）

項目現状（2026-07 調査）KEEL の扱い
機能名Identity-driven budgets and routingPhase 2 候補
提供形態Closed beta（2026-06-05 発表）[74][90]GA 時期は 公式未公表
申込CF ブログ から closed beta signup本番必須なら申込、待ち期間は手動 metadata
動作Access OAuth → JWT から email / IdP group を metadata 自動付与 [74]honor system からの脱却
Spend limitsOpen beta・全プラン無料 [90]Phase 1 から利用可

Phase 1 → Phase 2 移行パス

Phase 1: 手動 cf-aig-metadata（user_id, project_code）+ Spend limits
    ↓ Access closed beta 参加 or GA
Phase 2: Access アプリで GW エンドポイント保護 → 検証済み identity をログ・予算に反映

結論（U-CF-02）: GA 日は未確定だが、代替手段は明確 — Phase 1 は手動 metadata、本番前に beta 申込または GA 待ちのどちらかを PM が決定する。

v1.10 — サプライチェーン Runbook 追補

AI 時代の供給網リスク

リスク説明対応
SlopsquattingLLM 幻覚パッケージ名への先回り登録導入前の実在確認（第 9 章）
postinstall 攻撃npm install だけで感染（axios 事件等）lock ファイル + npm ci
新規パッケージ即導入公開直後の悪意ある版min-release-age クールダウン

四半期レビューに追加:

← 導入手順入口コンプライアンス →
KEEL