インフラ担当の役割
インフラ部門はゲートウェイの 可用性・ネットワーク境界・シークレット・監視 を担う。Phase 1 はシンプルな構成で開始し、Phase 2 で HA とマルチリージョンを検討する。
デプロイメントパターン
| パターン | 構成 | 適用 |
|---|
| P1-A | Azure Container Apps + LiteLLM | Phase 1 推奨（運用簡素） |
| P1-B | AKS 上 LiteLLM（最小 2 レプリカ） | 既存 AKS 標準がある場合 |
| P2-A | APIM + バックエンド LiteLLM | マネージド API 管理が必要な場合 |
| P2-B | マルチリージョン Active-Passive | 災害対策・海外ユーザー |
KEEL 社内標準が AKS の場合は P1-B を優先。Container Apps はパイロット速度重視時に有効。
ネットワーク設計
推奨トポロジ（Phase 1）
[社内端末 / VPN]
↓
[Azure Firewall / NSG]
↓
[Private Endpoint] → [LiteLLM Service]
↓ ↓
[Key Vault PE] [Azure OpenAI PE]
要件チェックリスト
- [ ] ゲートウェイ管理 API は社内ネットワークまたは VPN のみ
- [ ] プロバイダ API への egress は 許可リスト（
*.openai.com 等） - [ ] Private Link / Private Endpoint でパブリックインターネット経由のデータ経路を最小化
- [ ] 開発者向けエンドポイントは
llm-gateway.keel.internal 等の内部 DNS
| 接続種別 | Phase 1 | Phase 2 |
|---|
| 社内オフィス | VPN または ZTNA | ZTNA 標準化 |
| リモート開発 | VPN 必須 | 条件付きパブリック + mTLS |
| CI/CD | 専用仮想キー + 固定 egress IP | 同上 |
ゲートウェイをパブリックに晒す場合、WAF + IP 制限 + 強認証が必須。Phase 1 は プライベート優先。
高可用性（HA）
| 要素 | Phase 1 最小 | Phase 2 目標 |
|---|
| ゲートウェイレプリカ | 2（AZ 分散） | 3+ Auto-scale |
| プロバイダ障害 | セカンダリモデルへのフォールバック定義 | 自動フェイルオーバー |
| Key Vault | RA-GRS またはソフト削除有効 | 同上 + ローテーション自動化 |
| RTO / RPO | RTO 4h / RPO 1h | RTO 1h / RPO 15m |
ヘルスチェック
- Liveness:
/health/liveliness - Readiness: プロバイダ接続確認を含む
/health/readiness - 依存: Key Vault、ログシンク、主要プロバイダ 1 系統
シークレット管理
| シークレット | 保管場所 | ローテーション |
|---|
| プロバイダ API キー | Azure Key Vault | 90 日（またはプロバイダ推奨） |
| ゲートウェイマスターキー | Key Vault | 180 日 |
| 仮想キー | LiteLLM DB（ハッシュ） | 利用者ごと 90 日 or プロジェクト終了時 |
| DB 接続文字列 | Key Vault | 90 日 |
平文キーを Git・Slack・チケットに置かない を技術的に強制する（pre-commit hook、スキャナ）。
監視スタック
| レイヤー | ツール例 | 監視対象 |
|---|
| メトリクス | Azure Monitor / Prometheus | RPS、レイテンシ、エラー率、トークン量 |
| ログ | Log Analytics / Loki | 監査ログ、DLP イベント |
| トレース | OpenTelemetry | リクエスト追跡 |
| アラート | PagerDuty / Teams Webhook | 閾値超過、ヘルスダウン |
| ダッシュボード | Grafana / Azure Workbooks | コスト、チーム別利用 |
必須アラート（Phase 1）
| アラート | 条件 | 通知先 |
|---|
| GatewayDown | readiness 失敗 3 回連続 | インフラオンコール |
| CostSpike | 日次コスト前日比 300% | PM + インフラ |
| DLPBlockBurst | 10 分で 50 件超ブロック | セキュリティ |
| ErrorRateHigh | 5xx > 5% が 5 分 | インフラ |
| KeyVaultAccessFail | 取得失敗 | インフラ + セキュリティ |
キャパシティプランニング
| 規模 | 同時ユーザー | 推奨スペック（LiteLLM） |
|---|
| パイロット | 〜50 | 2 vCPU / 4GB × 2 レプリカ |
| Phase 1 | 〜100 | 4 vCPU / 8GB × 2、DB 小 |
| Phase 2 | 〜500 | Auto-scale 2〜8、Redis キャッシュ |
パッチ・変更ウィンドウ
- LiteLLM: 月 1 回メンテナンスウィンドウ（第 13 章サプライチェーン参照）
- OS / コンテナベース: 脆弱性 Critical は 72h 以内
- 設定変更: ステージング → カナリア 10% → 全量
引き渡し
- 開発者向けエンドポイント URL・仮想キー取得手順 → 第 9 章
- 運用 Runbook 詳細 → 第 13 章
LiteLLM デプロイのハードニング（2026 CVE 反映）
2026 年上半期に LiteLLM プロキシ向けの 複数の重大 CVE が公開された。KEEL が LiteLLM を採用する場合、インフラ層での緩和とバージョン管理をセットで実施する。
最小バージョン・依存関係
| コンポーネント | 推奨バージョン | 理由 |
|---|
| LiteLLM | 最新 stable 推奨（公式）。最低でも追補ハードニング済み系列（例: 1.84.3 / 1.85.2 / 1.86.2 以降） | GHSA-4xpc-pv4p-pm3w: 1.84.0 で初修正、追補ハードニングは maintained line へバックポート [31][32] |
| Starlette | ≥ 1.0.1（依存として含まれる場合も SBOM で確認） | Host Header 系の前提コンポーネント |
| 供給網 | 1.82.7 / 1.82.8 は使用禁止。該当期間に pip install した環境は侵害調査と秘密ローテーション | 2026-03 悪意ある PyPI 公開。公式 Docker image 利用時は影響外と公式説明 |
ネットワーク・リバースプロキシ必須設定
| 対策 | 内容 |
|---|
| Host ヘッダー検証 | CDN/WAF/NGINX で server_name 許可リスト。生の LiteLLM をインターネット直公開しない |
| MCP テストエンドポイント遮断 | POST /mcp-rest/test/* をエッジでブロック（CVE-2026-42271 表面） |
| 管理 API | 社内 VPN / Private Link のみ。proxy_admin ルートは IP 制限 |
| 秘密のローテーション | 影響版・公開経路・管理 API 変更有無を確認し、Critical 時は 全プロバイダ API キー をローテーション |
JWT 認証を使う場合
enable_jwt_auth: true 時は v1.83.0 以降必須。OIDC userinfo キャッシュは sha256(token) キーに修正済み。JWT 無効時の代替: Phase 1 は Virtual Key のみに限定も可。
出典: LiteLLM Host Header Auth Bypass、LiteLLM Supply Chain March 2026、GHSA-4xpc-pv4p-pm3w
v1.8 — Cloudflare AI Gateway 構築パターン（Pattern S-CF）
LiteLLM 自前ホスト（P1-A/B）に加え、マネージド Edge ゲートウェイ を使う場合のインフラ設計メモ。
トポロジ
[開発者端末 / CI]
↓ HTTPS（インターネット or ZTNA）
[gateway.ai.cloudflare.com/v1/{account}/{gateway}/...]
↓ CF AIG: 認証 · ログ · レート/Spend · DLP
[Amazon Bedrock bedrock-runtime / 他 BYOK]
構築ステップ（mediba 検証 + 公式の統合）
| # | 作業 | 詳細 |
|---|
| 1 | CF アカウント・AI Gateway 作成 | ログ有効・Authenticated Gateway ON [71][77] |
| 2 | レート制限 | PoC は厳しめ（例 3 req/min）で 429 動作確認 [71] |
| 3 | Spend limits | 固定/スライディングウィンドウ、provider/model/metadata スコープ [72] |
| 4 | Bedrock BYOK | API キー or IAM JSON をプロバイダキーに登録 [75] |
| 5 | ゲートウェイトークン発行 | Run 権限。漏洩時は即ローテーション [77] |
| 6 | DNS / ファイアウォール | 端末から gateway.ai.cloudflare.com への egress 許可 |
Bedrock 側のハードニング
| 項目 | 推奨 |
|---|
| BYOK キー | Bedrock API キー（検証記事）または IAM 最小権限 [71][75] |
| モデル制限 | IAM ポリシーで許可モデルを絞る（本番必須）[71] |
| コスト按分（事後） | 2026-04〜 IAM principal / session tag を CUR 2.0 で有効化 [78] |
| リアルタイム停止 | CF AIG Spend limits がゲートキーパー。CUR は請求確定用 |
隔離・マルチテナント
| 要件 | 実装 |
|---|
| ゲートウェイごとにトークン分離 | CF アカウント分離（トークンはアカウントスコープ）[77] |
| 検証済みユーザー属性 | Cloudflare Access + IdP で JWT から metadata 自動付与（ベータ）[74] |
| 手動 metadata | cf-aig-metadata: {"user_id":"...","project_code":"..."} [71] |
手動 metadata は honor system。本番では Access 連携または社内発行スクリプトで端末環境変数を配布し、改ざん検知はログ監査で補う。
監視・アラート（CF AIG 利用時）
| アラート | 条件 | 通知先 |
|---|
| SpendLimit429 | 429 率が閾値超 | PM + インフラ |
| RateLimit429 | レート制限超過の急増 | インフラ |
| AuthFailure | 401/403 急増 | セキュリティ |
| LogExportLag | ログエクスポート遅延 | インフラ |
AWS 側は Cost Anomaly Detection + 日次 CUR ジョブを併設（第 13 章）。
v1.8.1 — KEEL 向け CF AIG プラン選定表
| Phase | 推奨 CF プラン | 理由 | 追加契約 |
|---|
| PoC（〜30 名） | Workers Free | コア機能・10 万ログで足りる [83] | なし |
| 本番（〜100 名） | Workers Paid | Logpush・ログ 1,000 万/GW [82] | Bedrock BYOK のみ |
| 高度 DLP | Workers Paid + Cloudflare Zero Trust | カスタム DLP プロファイル [82] | ZT ライセンス |
| 全社・長期ログ | Enterprise 見積 | ログ無制限・カスタム契約 [82] | 営業 |
Logpush 最小構成（Workers Paid 時）
- AI Gateway ログを Logpush → S3 / R2 / Datadog 等（アカウントあたりジョブ最大 4）[83]
- SIEM 取り込みはプロンプトマスキング方針を先に固定（第 7 章）
- Free プランでは Logpush 不可 — SIEM 恒久連携＝Paid 必須 [82]
研修 — インフラコース D 補助（設定レビュー 15 分）
以下の構成図をレビューし、NG 項目を挙げる:
- LiteLLM をインターネットに直公開
- Host ヘッダー未検証
- 1.82.7 のイメージが残存
- プロバイダキーがコンテナ env に平文
| チェック | 合格基準 |
|---|
| 公開経路 | WAF/Private Link のみ |
| LiteLLM 版 | 最新 stable / 追補ハードニング系列 |
| 秘密 | Key Vault のみ |
| ログ | SIEM 到達 5 分以内 |
v1.10 付録 — 顧客 AWS 案件向け（エージェント接続パターン）
本パックの Phase 1 標準は Azure + 社内 GW です。顧客環境が AWS の場合、Zenn 記事 の次パターンを参照アーキテクチャとして提案できます。
短命認証（IAM Identity Center / SSO）
# 人間が承認してからエージェント用プロファイルで操作
aws sso login --profile agent-readonly-dev
aws ec2 describe-instances --profile agent-readonly-dev
| ポイント | 理由 |
|---|
| セッションに有効期限 | 平文の長期アクセスキーを置かない |
| ロール削除で失効 | 退職・異動時の消し忘れを構造的に防ぐ |
| CloudTrail 記録 | エージェント操作を API イベントとして追跡 |
読み取り専用から開始し、必要な分だけ権限を足す（フル権限から削る方式は危険）。
シークレット — キー名は「目次」、値は「本体」
| 比較 | スプレッドシート共有 | Secrets Manager 参照 |
|---|
| 共有されるもの | 値そのもの | キー名のみ |
| アクセス制御 | シート共有設定 | IAM ポリシー |
| 監査 | 不明瞭 | GetSecretValue が CloudTrail に記録 |
| 漏洩時 | 値漏洩で終了 | キー名だけでは不可 |
Azure 対応: Key Vault シークレット名の露出は同様に許容範囲。値は Managed Identity 経由のみ。
DB 接続経路 — SSM Session Manager 一本化
aws ssm start-session \
--target i-xxxxxxxxxxxx \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters '{"host":["db.internal"],"portNumber":["5432"],"localPortNumber":["15432"]}'
| 利点 | 内容 |
|---|
| インバウンド SSH 不要 | アタックサーフェス最小化 |
| 認証は IAM に集約 | 退職時は IAM から外すだけ |
| セッション監査 | 誰がいつ DB トンネルを張ったか追跡可能 |
ネットワーク設計（SG・プライベートサブネット）は別軸。本付録はエージェント統制の一層です。
v1.11 — LiteLLM 権限の交差評価（MCP）
MCP Permission Management では、Key · Team · End User · Agent · Org の 5 段階で権限が交差する。
| レベル | フィールド例 | 合成ルール |
|---|
| Key | object_permission.mcp_servers | 明示リストがあれば採用 |
| Team | 同上 | Key と Team 両方にあれば intersection |
| Org | 同上 | ceiling（上限） として効く |
ツール粒度: mcp_tool_permissions: {server_id: [tool_name, ...]} はサーバ許可後に さらに intersection。
Virtual Key RBAC（要約）
| ロール | 権限 |
|---|
proxy_admin | 全プラットフォーム管理 |
org_admin | 組織配下 |
internal_user | 自分のキー CRUD（チーム設定次第） |
チームメンバーに /key/generate 等を付与するかは team member permissions で制御（RBAC ドキュメント）。
Phase 2 設計メモ: tool_permission ガードレールで Bash allow + git clean 引数 deny を GW 側に置ける（tool_permission）。IDE ローカル shell は別途クライアント層が必要。
