マルチモデル AI ゲートウェイのプロバイダー認証情報ボールト: 個別のランタイム、管理者、請求、および BYOK アクセス
マルチモデル AI ゲートウェイ向けの実用的な資格情報ボールト パターン: 上流のプロバイダー キーを分類し、ランタイムを管理者アクセスから分離し、BYOK 資格情報をテナントにバインドし、安全にローテーションし、すべての資格情報の決定を監査します。
ダウンストリーム API キーとアップストリーム プロバイダーの認証情報により、さまざまな問題が解決されます。ゲートウェイによって発行された開発者キーは、アプリ、チーム、テナント、予算、およびポリシーのコンテキストを識別します。アップストリーム プロバイダー キーを使用すると、ゲートウェイがお金を使ってプロバイダー アカウント内のモデルにアクセスできるようになります。これらを同じ種類のシークレットとして扱うと、チームは共有プロジェクト内に 1 つの無制限のキー、ランタイム サービスの管理者資格情報を所有することになり、どのテナントがどのプロバイダ側の料金の原因となったかを答える信頼できる方法がなくなります。
実際的なパターンは、プロバイダー認証情報ボールトです。これは、アップストリーム認証情報のインポート、分類、保存、選択、ローテーション、監査を行うための専用のコントロール プレーンです。これは、アプリケーション コード、モデル構成ファイル、テナント レコード、分析イベント内ではなく、ルーター、請求台帳、ポリシー エンジン、運用ワークフローの背後に配置する必要があります。
読者の問題: 上流の認証情報が目に見えないインフラストラクチャになる
ほとんどのマルチモデル展開は、1 つの OpenAI 互換リクエストを利用可能な最適なプロバイダーにルーティングするという単純な目標から始まります。その後、さらに多くのアカウントが表示されます。本番用の 1 つのプロバイダ プロジェクト、評価用の別のプロバイダ、ビジネス ユニット用の Anthropic ワークスペース、Gemini 用の Google Cloud プロジェクト、BYOK 契約用の顧客指定のキーがいくつか表示されます。
The risk is not merely secret leakage. It is loss of authorization context.有効なプロバイダー キーは技術的にはエンドポイントを呼び出すことができるかもしれませんが、ゲートウェイはそのキーがこのテナント、このモデル ファミリー、このデータ保持ポリシー、この予算、このリージョン、この自動化パスに許可されているかどうかを知る必要があります。
事実: プロバイダー プラットフォームでは、さまざまなアカウント境界と認証情報の種類が公開されています。 OpenAI はプロジェクトとサービス アカウントを文書化し、サービス アカウントの API キー権限はデフォルトでプロジェクトの API リソースに対する読み取りおよび書き込みアクセスを許可します。 OpenAI は、通常のプロジェクト/ランタイム API の使用とは別に、管理 API キー オブジェクトも公開します。 Anthropic はワークスペースを組織の境界として文書化し、管理 API エンドポイントには標準の API キーとは異なる管理 API キーが必要であると述べています。 Anthropic 氏は、API キーは作成されたワークスペースに関連付けられており、ワークスペース間で移動できないことにも注意しています。 Google の Gemini API キーのドキュメントには、すべての Gemini API キーが Google Cloud プロジェクトに関連付けられており、キーが侵害された場合の被害を軽減するために API 制限を推奨していると記載されています。
推奨事項: 汎用の「provider_key」フィールドを 1 つ作成して完了とみなさないでください。正規化されたポリシー モデルをゲートウェイに公開しながら、プロバイダー固有の境界を保持する認証情報インベントリを構築します。
キーを受け入れる前に認証情報の分類を定義する
A vault should reject ambiguous credentials.インポート時に、オペレーターまたは自動化ワークフローは資格情報を分類する必要があります。 At minimum, use these categories:
- 実行時推論認証情報: プロバイダーのサポートに応じて、チャット、応答、埋め込み、モデレーション、文字起こし、画像生成などのモデル推論エンドポイントを呼び出すためにゲートウェイによって使用されます。
- 管理自動化認証情報: プロバイダー側の組織、ワークスペース、プロジェクト、ユーザー、キー、または管理リソースを管理するために使用されます。これらはランタイム リクエスト パス上にあってはなりません。
- 請求およびレポートの認証情報: プロバイダーがこれらの API をサポートしている場合、使用状況、請求書、費用、または組織レポートを取得するために使用されます。レポート ジョブがモデルの使用法を生成できないように、推論キーとは別にしておいてください。
- 評価専用の認証情報: ベンチマーク、QA、移行、またはステージングのワークフローで使用されます。割り当てが低く、環境ラベルが明確であり、本番環境のフォールバック資格がないことが必要です。
- 顧客の BYOK 認証情報: 特定のテナント、プロバイダー アカウント、契約、およびデータ ポリシーにバインドされた顧客指定のキー。お客様が明示的にオプトインしない限り、共有ルーティングにプールしないでください。
This taxonomy is not just documentation.これにより、アクセス制御、ルーティングの適格性、アラート、ローテーションのワークフローが促進されるはずです。カテゴリ、所有者、プロバイダー アカウントの境界、および使用を許可せずに資格情報をインポートした場合、資格情報は無効のままにする必要があります。
シークレットは製品レコードではなくボールトに保存します
ボールトは、アップストリーム認証情報を復号化できる唯一のコンポーネントである必要があります。他のシステムでは、参照、ハッシュ、ステータス フィールド、ポリシー メタデータは保存される場合がありますが、認証情報の値自体は保存されません。
これらの場所にアップストリーム シークレットを保存しないでください
- Tenant profile rows.
- Model routing configuration files.
- Prompt logs or trace spans.
- Analytics event payloads.
- Developer-facing CI variables.
- サポート チケット、チャット ツール、またはスクリーンショット
使用可能なボールト設計には 2 つのプレーンがあります。 秘密プレーンは暗号化された認証情報を保存し、復号化操作を厳密に制御します。 メタデータ プレーンには、ルーティングとガバナンスで使用される非機密属性が保存されます。通常、ルーターに必要なのは、認証情報 ID とディスパッチ時の短期間のメモリ内シークレットの取得だけであり、すべてのプロバイダー キーへの広範なデータベース アクセスは必要ありません。
コンテナーを高価値インフラストラクチャとして保護します。エンベロープ暗号化またはマネージド KMS、厳格なサービス ID、非常事態手順、バックアップと復元のテスト、アクセス レビュー、異常な復号化ボリュームに関するアラート。中央保管庫はガバナンスを簡素化しますが、リスクも集中させます。それがトレードオフです。
すべての認証情報にポリシー メタデータを添付する
メタデータ モデルは、ゲートウェイがプロバイダーのエンドポイントに接続する前に資格情報が適格かどうかを判断できるように、十分に明示的である必要があります。
実際の認証情報レコードには次のものが含まれます。
- credential_id: 内部の不変識別子。
- プロバイダ: OpenAI、Anthropic、Gemini、Azure OpenAI、または別のアダプター。
- provider_account_boundary: 組織、プロジェクト、ワークスペース、クラウド プロジェクト、サブスクリプション、または同等のもの
- credential_class: ランタイム、管理者、請求、評価、または BYOK。
- 環境: 本番、ステージング、開発、評価、サンドボックス。
- tenant_binding: 共有プラットフォーム認証情報、単一テナント、テナント グループ、または顧客の BYOK テナント。
- allowed_model_families: 例: テキスト生成、埋め込み、ビジョン、画像、オーディオ、特定のモデル プロファイル。
- allowed_endpoints: プロバイダーのエンドポイントにマッピングされた正規化されたゲートウェイ機能。
- data_policy: 許可される保持クラス、ロギング クラス、常駐要件、機能制限。
- budget_scope: コスト センター、再販業者の顧客、社内部門、または契約。
- オーナー: 指名されたチームまたは責任者
- 作成日、有効期限、回転期限、最終使用日。
- health_status: 不明、正常、劣化、未承認、クォータ枯渇、無効。
- emergency_disable: 通常のポリシー状態とは関係なく即時ルーティングをブロックします。
Keep this model provider-neutral, but do not erase provider realities. Anthropic ワークスペースにバインドされたキーと Google Cloud プロジェクトに関連付けられた Gemini キーは、どちらもテキストを生成できるという理由だけで交換可能ではありません。ゲートウェイには、監査、チャージバック、安全なフェイルオーバーのためにその出所が必要です。
Separate runtime, admin, and billing access
最も重要なルールは単純です。実行時推論に使用されるキーは、プロバイダー組織、ワークスペース、ユーザー、プロジェクト、または管理リソースを管理してはなりません。
実行時のトラフィックは大量であり、最大の運用面にさらされます。 It passes through request routers, retry logic, streaming handlers, model adapters, and incident workflows. Admin credentials are low frequency and high impact.これらは、短い TTL、必要に応じて人間による承認という名前が付けられ、強力なロギングが行われ、ランタイム ルーティングの資格がない、別の承認パスの背後に存在する必要があります。
請求資格情報も分離に値します。請求書を照合するレポート ジョブは完了を生成できてはならず、実行時推論キーが使用状況レポートを取得する唯一の方法であってはなりません。プロバイダーがきめ細かい分離を提供していない場合は、ゲートウェイで補います。資格情報を分離し、資格情報を取得できる内部サービス ID を制限し、すべての使用を記録します。
推奨事項: 認証情報クラスをラベルではなく、ハード承認境界にします。ランタイム ディスパッチャは、設定ミスによって ID が参照された場合でも、管理者認証情報の復号化をリクエストできないようにする必要があります。
認証情報選択ポリシー エンジンを構築する
資格情報の選択は、ゲートウェイがダウンストリーム呼び出し元を認証した後、プロバイダー呼び出しが試行される前に行う必要があります。ポリシー エンジンは、いくつかの入力を結合する必要があります。
- テナント ID とダウンストリーム API キーのスコープ
- リクエストされたモデル プロファイルまたはプロバイダー固有のモデル ID。
- エンドポイント機能: チャット、埋め込み、画像、音声、バッチ、ファイル、ツール、管理自動化
- データの保持と居住地の要件
- 予算、クレジット予約、コストセンター
- レート制限の状態と割り当てのプレッシャー
- 認証情報のメタデータ、健康状態、環境、テナントのバインディング
エンジンは、選択した資格情報で許可、ポリシー理由で拒否、または承認が必要という 3 つの結果のいずれかを返す必要があります。拒否は、運用チームが開発者に機密事項を明らかにすることなく問題を解決できるほど正確である必要があります。
決定例:
{
"テナントID": "テナント_42",
"requested_profile": "fast-text-prod",
"エンドポイント": "chat.completions",
"data_policy": "no_prompt_logging",
"credential_requirements": {
"クラス": "ランタイム",
"環境": "生産"、
"テナントバインディング": "テナント_42",
"allowed_model_family": "テキスト",
"health_status": "健康"
}、
「決定」: 「許可」、
"credential_id": "cred_8f2...",
"audit_reason": "テナントの BYOK 資格情報がランタイム テキスト プロファイルとデータ ポリシーに一致します"
}「次のキーを試す」というフォールバックを実装しないでください。フォールバックではポリシーを再実行する必要があります。共有プラットフォーム認証情報は、プロバイダー アクセスには有効でも、BYOK のみの顧客には無効である場合があります。別のプロジェクトの認証情報に割り当てがある可能性がありますが、コスト帰属または保持要件に違反している可能性があります。
予備容量ではなく、テナント所有のアクセスとして BYOK を処理します
BYOK は信頼モデルを変更します。顧客は、プロバイダー アカウント内でトラフィックを課金、管理、または分離できるように資格情報を提供しました。この認証情報は、顧客のテナントとプロバイダー アカウントの来歴にバインドされている必要があります。
推奨される BYOK コントロール:
- 顧客、プロバイダー、アカウント境界、環境ごとに 1 つの Vault レコード
- BYOK 認証情報によるクロステナント ルーティングはありません。
- お客様が明示的にオプトインしない限り、共有フォールバック キャパシティとしては使用できません。
- 生のキーを明らかにしない、顧客に表示される健康状態
- Separate rotation workflow that allows the customer to add a replacement before the old key is disabled.
- 使用状況分析と請求書における明確な帰属: ゲートウェイ テナント、プロバイダー アカウントの境界、認証情報 ID、モデル プロファイル、リクエスト トレース ID。
代理店、再販業者、パートナー API 自動化の場合、サービスがテナントと認証情報をプログラムでプロビジョニングする場合があるため、BYOK はより複雑になる可能性があります。同じルールが引き続き適用されます。自動化では認証情報をインポートしてバインドできますが、テナントの所有権を曖昧にしてはなりません。
プロンプトを漏らさずにプリフライト ヘルス チェックを追加
認証情報は、取り消されたキー、間違ったワークスペース、モデル アクセスの欠落、無効な課金、クォータの枯渇、エンドポイントの制限、地域ポリシーの不一致、プロバイダーの停止など、さまざまな理由で失敗する可能性があります。実稼働リクエストが到着した後に初めてそれが判明すると、騒々しいインシデントが発生します。
顧客にプロンプトを送信せずに機能を検証するヘルスチェックを使用します。合成チェックでは、最小限のエンドポイントを呼び出したり、必要に応じて許可されたモデルをリストしたり、それが唯一の実用的なオプションである場合は無害な固定プロンプトを送信したりすることがあります。これらのチェックを安価に保ち、レートを制限し、テレメトリと請求において合成トラフィックとしてラベル付けします。
ヘルスチェックを実行する必要があります:
- 認証情報のインポート時。
- 本番ルーティングの認証情報を有効にする前。
- プロバイダ側の制限変更後
- ローテーション切り替え中。
- 本番環境の資格を持つ資格情報を取得するために定期的に行われます。
トレードオフ: 自動チェックは期限切れのキーや範囲が範囲外のキーを早期に検出しますが、チェックの設計が不十分だと、プロバイダの停止中に不必要なプロバイダ呼び出し、請求ノイズ、または誤った警報が発生する可能性があります。タイムスタンプ、プロバイダー エラー クラス、テストされたエンドポイント、およびテストされたモデル ファミリとともに正常性結果を保存します。シークレットの値や機密性の高いプロンプトは保存しないでください。
リスクの高い 1 つのスロットではなく、2 つのスロットでローテーションします
認証情報のローテーションは、削除して祈るような操作であってはなりません。 2 スロット ローテーション モデルを使用します。
<オル>ローテーションの期限は、操作ビューとアラートに表示される必要があります。緊急ローテーションには、より短いパスが必要です。認証情報を無効にし、ルーティングをブロックし、承認された交換を有効にし、インシデントのレビューのためにすべての監査記録を保存します。
プロバイダーがサポートするプロバイダー キーを制限する
ゲートウェイ ポリシーは必要ですが、プロバイダ側の制限により、キーが侵害されたり悪用されたりした場合の影響範囲が減少します。 Gemini およびその他のクラウド プラットフォーム API キーの場合は、利用可能な場合は API/サービス制限と適切なアプリケーション制限を使用します。プロバイダー プロジェクト、ワークスペース、サービス アカウントの場合、プロジェクト スコープのランタイム キーで十分な場合は、広範な組織権限を避けてください。
推奨事項: すべての認証情報クラスに対してプロバイダ側の制限チェックリストを維持します。チェックリストは、圧力によってスキップされる可能性のある別個のセキュリティ タスクではなく、輸入承認とローテーション承認の一部である必要があります。
トレードオフ: プロバイダー側の制限により、運用上のオーバーヘッドが増加します。新しいエンドポイント、モデル ファミリ、リージョン、または自動化機能には、ポリシーと制限の変更が必要になる場合があります。これは、漏洩後に 1 つのキーが共有プロジェクト内のすべてのワークロードにアクセスできることが判明するよりも望ましい方法です。
追加専用の認証情報の監査ログを保存する
監査証跡は、誰が認証情報をインポートしたか、認証情報に何が許可されているか、どのルーティング決定によって認証情報が選択されたか、いつ失敗したか、いつローテーションまたは取り消されたかを明らかにする必要があります。
これらのイベントをログに記録します:
- 認証情報が作成またはインポートされました。
- 許可されたエンドポイント、テナント バインディング、データ ポリシーなどのメタデータが変更されました。
- ヘルスチェックが実行され、結果が記録されました。
- リクエストのルーティング ポリシーによって選択された認証情報。
- 内部サービス ID によって要求された認証情報の復号化。
- 認証、認可、割り当て、または制限エラーにより、プロバイダー呼び出しが失敗しました。
- ローテーションが開始され、トラフィックが変更され、古い認証情報が取り消されました。
- 緊急時の無効化が有効または解除されます。
- 管理者または非常用認証情報にアクセスしました。
生の認証情報の値を監査イベントに含めないでください。資格情報 ID、プロバイダー アカウント境界、リクエスト トレース ID、アクター ID、およびポリシー決定理由を使用します。大量のランタイム トラフィックの場合は、詳細な復号化テレメトリをサンプリングできますが、ルーティングの選択とコストの帰属は、請求とインシデント対応に十分な完全性を維持する必要があります。
実装チェックリスト
- 認証情報の分類を作成し、未分類のインポートを拒否する
- すべてのプロバイダーのシークレットを専用の暗号化された保管庫に移動します。
- ルーティング メタデータを機密資料とは別に保存します。
- ランタイム、管理者、請求、評価、BYOK 認証情報を個別の認可クラスにします。
- BYOK 認証情報をテナントおよびプロバイダー アカウントの来歴にバインドする
- 上流の認証情報を選択する前に、ポリシー エンジンの承認を要求します。
- 本番環境の適格性を確認する前に、迅速かつ安全なヘルスチェックを実行します。
- 段階的なトラフィック シフトとプロバイダ側の取り消しを伴う 2 スロット ローテーションを使用します。
- 可能な場合には、プロバイダ側の制限を適用します。
- インポート、使用、失敗、ローテーション、取り消しに関する追加専用の監査ログを維持する
- 管理者の認証情報は、短い TTL、名前付き承認、強力なロギング、ランタイム使用なしなど、非常に厳しい制御の背後に維持します。
実行可能な結論
まず、ゲートウェイ、スクリプト、CI ジョブ、評価ハーネス、パートナー自動化で現在使用されているすべての上流プロバイダー認証情報のインベントリを作成します。それぞれに、クラス、所有者、プロバイダー アカウント境界、テナント バインディング、許可されたエンドポイント、許可されたモデル ファミリ、ローテーション期限、および緊急無効化ステータスを割り当てます。分類できないものは、目的が明確になるまで無効にするか隔離する必要があります。
次に、1 つのアーキテクチャ ルールを適用します。下流の開発者はゲートウェイ スコープのキーを受け取ります。ゲートウェイのみが上流のプロバイダー アクセスを制御します。この分離により、プロバイダー、プロジェクト、ワークスペース、BYOK 顧客が増加しても、最小限の権限、テナントの属性、請求の正確性、データ ポリシーのルーティング、安全な自動化を維持できます。