マルチモデル AI ゲートウェイのプロバイダー認証情報ボールト: 個別のランタイム、管理者、請求、および BYOK アクセス
マルチモデル AI ゲートウェイ向けの実用的な資格情報ボールト パターン: 上流のプロバイダー キーを分類し、ランタイムを管理者アクセスから分離し、BYOK 資格情報をテナントにバインドし、安全にローテーションし、すべての資格情報の決定を監査します。
ダウンストリーム API キーとアップストリーム プロバイダーの認証情報により、さまざまな問題が解決されます。ゲートウェイによって発行された開発者キーは、アプリ、チーム、テナント、予算、およびポリシーのコンテキストを識別します。アップストリーム プロバイダー キーを使用すると、ゲートウェイがお金を使ってプロバイダー アカウント内のモデルにアクセスできるようになります。これらを同じ種類のシークレットとして扱うと、チームは共有プロジェクト内に 1 つの無制限のキー、ランタイム サービスの管理者資格情報を所有することになり、どのテナントがどのプロバイダ側の料金の原因となったかを答える信頼できる方法がなくなります。
実際的なパターンは、プロバイダー資格情報ボールトです。これは、アップストリーム資格情報のインポート、分類、保存、選択、ローテーション、監査を行うための専用のコントロール プレーンです。これは、アプリケーション コード、モデル構成ファイル、テナント レコード、または分析イベント内ではなく、ルーター、請求台帳、ポリシー エンジン、および運用ワークフローの背後に配置する必要があります。
リーダーの問題: 上流の認証情報が目に見えないインフラストラクチャになる
ほとんどのマルチモデルのデプロイメントは、1 つの OpenAI 互換リクエストを利用可能な最適なプロバイダーにルーティングするという単純な目標から始まります。その後、さらに多くのアカウントが表示されます。運用用の 1 つのプロバイダ プロジェクト、評価用の別のプロバイダ、ビジネス ユニットの Anthropic ワークスペース、Google Gemini のクラウド プロジェクト、BYOK 契約用の顧客指定のいくつかのキーです。
リスクは単に機密漏洩だけではありません。認可コンテキストの喪失です。有効なプロバイダー キーは技術的にエンドポイントを呼び出すことができる可能性がありますが、ゲートウェイはそのキーがこのテナント、このモデル ファミリー、このデータ保持ポリシー、この予算、このリージョン、およびこの自動化パスに許可されているかどうかを知る必要があります。
事実: プロバイダ プラットフォームでは、さまざまなアカウント境界と認証情報の種類が公開されています。 OpenAI はプロジェクトとサービス アカウントを文書化し、サービス アカウント API のキー権限はデフォルトでプロジェクトの API リソースに対する読み取りおよび書き込みアクセスになります。 OpenAI は、通常のプロジェクト/ランタイム API の使用とは別に、管理者 API キー オブジェクトも公開します。 Anthropic はワークスペースを組織の境界として文書化し、管理者 API エンドポイントには標準の API キーとは異なる管理者 API キーが必要であると述べています。 Anthropic は、API キーが作成されたワークスペースに関連付けられており、ワークスペース間で移動できないことにも注意します。 Google の Gemini API キーのドキュメントには、すべての Gemini API キーが Google Cloud プロジェクトに関連付けられており、キーが侵害された場合の被害を軽減するために API の制限を推奨していると記載されています。
推奨事項: 汎用の「provider_key」フィールドを 1 つ作成して完了とみなさないでください。正規化されたポリシー モデルをゲートウェイに公開しながら、プロバイダー固有の境界を保持する認証情報インベントリを構築します。
キーを受け入れる前に認証情報の分類を定義します
ボールトはあいまいな資格情報を拒否する必要があります。インポート時に、オペレーターまたは自動化ワークフローは資格情報を分類する必要があります。少なくとも次のカテゴリを使用してください:
- ランタイム推論資格情報: プロバイダーのサポートに応じて、チャット、応答、埋め込み、モデレーション、文字起こし、画像生成などのモデル推論エンドポイントを呼び出すためにゲートウェイによって使用されます。
- 管理自動化認証情報: プロバイダー側の組織、ワークスペース、プロジェクト、ユーザー、キー、または管理リソースの管理に使用されます。これらはランタイム リクエスト パス上にあってはなりません。
- 請求およびレポートの認証情報: プロバイダがこれらの API をサポートしている場合、使用状況、請求書、費用、または組織レポートを取得するために使用されます。レポート ジョブがモデルの使用法を生成できないように、それらを推論キーから分離してください。
- 評価専用の認証情報: ベンチマーク、QA、移行、またはステージング ワークフローで使用されます。割り当てが低く、明確な環境ラベルがあり、本番フォールバック資格がない必要があります。
- 顧客 BYOK 認証情報: 特定のテナント、プロバイダー アカウント、契約、およびデータ ポリシーにバインドされた顧客指定のキー。顧客が明示的にオプトインしない限り、共有ルーティングにプールしないでください。
この分類法は単なるドキュメントではありません。これにより、アクセス制御、ルーティングの適格性、アラート、ローテーションのワークフローが促進されるはずです。カテゴリ、所有者、プロバイダー アカウントの境界、および使用を許可せずに資格情報をインポートした場合、資格情報は無効のままにする必要があります。
シークレットは製品レコードではなくボールトに保存します
ボールトは、アップストリームの認証情報を復号化できる唯一のコンポーネントである必要があります。他のシステムでは、参照、ハッシュ、ステータス フィールド、ポリシー メタデータは保存される場合がありますが、資格情報の値自体は保存されません。
これらの場所にアップストリーム シークレットを保存しないでください
- テナント プロファイル行。
- モデル ルーティング構成ファイル。
- プロンプトログまたはトレーススパン。
- 分析イベント ペイロード。
- 開発者向けの CI 変数。
- サポート チケット、チャット ツール、またはスクリーンショット。
使用可能なボールト設計には 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: コスト センター、再販業者の顧客、社内部門、または契約。
- オーナー: 指定されたチームまたは責任者。
- created_at、expires_at、rotation_due_at、last_used_at.
- health_status: 不明、正常、劣化、未承認、quota_exhausted、無効です。
- emergency_disable: 通常のポリシー状態とは独立した即時ルーティング ブロック。
このモデルをプロバイダー中立に保ちますが、プロバイダーの現実を消去しないでください。 Anthropic ワークスペースにバインドされたキーと Google Cloud プロジェクトに関連付けられた Gemini キーは、どちらもテキストを生成できるという理由だけで交換可能ではありません。ゲートウェイには、監査、チャージバック、安全なフェイルオーバーのためにその出所が必要です。
個別のランタイム、管理者、および課金アクセス
最も重要なルールは単純です。ランタイム推論に使用されるキーは、プロバイダーの組織、ワークスペース、ユーザー、プロジェクト、または管理リソースを管理してはなりません。
実行時のトラフィックは大量であり、最大の運用面にさらされます。これは、リクエスト ルーター、再試行ロジック、ストリーミング ハンドラー、モデル アダプター、およびインシデント ワークフローを通過します。管理者の資格情報は頻度が低く、影響力が大きいです。これらは、短い TTL、必要に応じて人間による承認という名前が付けられ、強力なログが記録され、ランタイム ルーティング資格がない、別の承認パスの背後に存在する必要があります。
請求先認証情報も分離に値します。請求書を照合するレポート ジョブは完了を生成できてはならず、ランタイム推論キーが使用状況レポートを取得する唯一の方法であってはなりません。プロバイダーがきめ細かい分離を提供していない場合は、ゲートウェイで補います。資格情報を分離し、資格情報を取得できる内部サービス ID を制限し、すべての使用をログに記録します。
推奨事項: 資格情報クラスをラベルではなくハード認可境界にします。ランタイム ディスパッチャーは、構成ミスによって ID が参照された場合でも、管理者資格情報の復号化を要求できないようにする必要があります。
認証情報選択ポリシー エンジンを構築する
資格情報の選択は、ゲートウェイがダウンストリーム呼び出し元を認証した後、プロバイダ呼び出しが試行される前に行う必要があります。ポリシー エンジンは複数の入力を結合する必要があります:
- テナント ID とダウンストリーム API キー スコープ。
- リクエストされたモデル プロファイルまたはプロバイダー固有のモデル ID。
- エンドポイント機能: チャット、埋め込み、画像、音声、バッチ、ファイル、ツール、または管理自動化。
- データの保存と保存の要件。
- 予算、クレジット予約、コストセンター。
- レート制限の状態と割り当てのプレッシャー。
- 認証情報のメタデータ、健全性、環境、およびテナントのバインディング。
エンジンは、選択した資格情報で許可、ポリシー理由で拒否、または承認が必要という 3 つの結果のいずれかを返す必要があります。拒否は、運用チームが開発者に機密事項を明らかにすることなく問題を解決できるほど正確である必要があります。
決定例:
{
"tenant_id": "tenant_42",
"requested_profile": "fast-text-prod",
"endpoint": "chat.completions",
"data_policy": "no_prompt_logging",
"credential_requirements": {
"class": "runtime",
"environment": "production",
"tenant_binding": "tenant_42",
"allowed_model_family": "text",
"health_status": "healthy"
},
"decision": "allow",
"credential_id": "cred_8f2...",
"audit_reason": "tenant BYOK credential matches runtime text profile and data policy"
}「次のキーを試す」というフォールバックを実装しないでください。フォールバックではポリシーを再実行する必要があります。共有プラットフォーム認証情報は、プロバイダー アクセスには有効でも、BYOK のみの顧客には無効である場合があります。別のプロジェクトの認証情報に割り当てがある可能性がありますが、コスト帰属または保持要件に違反する可能性があります。
予備容量ではなく、テナント所有のアクセスとして BYOK を処理します
BYOK は信頼モデルを変更します。顧客は、プロバイダー アカウント内でトラフィックを課金、管理、または分離できるように資格情報を提供しました。その認証情報は、顧客のテナントとプロバイダー アカウントの来歴にバインドされている必要があります。
推奨される BYOK コントロール:
- 顧客、プロバイダー、アカウント境界、環境ごとに 1 つの Vault レコード。
- BYOK 認証情報によるクロステナント ルーティングはありません。
- 顧客が明示的にオプトインしない限り、共有フォールバック容量としては使用できません。
- 生のキーを明らかにしない、顧客に表示される健全性状態。
- 古いキーが無効になる前に、顧客が代替キーを追加できるようにする個別のローテーション ワークフロー。
- 使用状況分析と請求書における明確な帰属: ゲートウェイ テナント、プロバイダー アカウント境界、認証情報 ID、モデル プロファイル、リクエスト トレース ID。
代理店、再販業者、パートナー API 自動化の場合、サービスがテナントと資格情報をプログラムでプロビジョニングする場合があるため、BYOK はより複雑になる可能性があります。同じルールが引き続き適用されます。自動化では認証情報をインポートしてバインドできますが、テナントの所有権を曖昧にしてはなりません。
プロンプトを漏らさずにプリフライト ヘルス チェックを追加
認証情報は、キーの取り消し、間違ったワークスペース、モデルへのアクセスの欠落、課金の無効化、クォータの枯渇、エンドポイントの制限、リージョン ポリシーの不一致、プロバイダの停止など、さまざまな理由で失敗する可能性があります。実稼働リクエストが到着した後でのみ発見すると、騒々しいインシデントが発生します。
顧客にプロンプトを送信せずに機能を検証するヘルスチェックを使用します。合成チェックでは、最小限のエンドポイントを呼び出したり、必要に応じて許可されたモデルをリストしたり、それが唯一の実用的なオプションである場合は無害な固定プロンプトを送信したりすることがあります。これらのチェックを安価にし、レートを制限し、テレメトリと課金では合成トラフィックとしてラベル付けします。
ヘルスチェックを実行する必要があります:
- 認証情報のインポート時。
- 実稼働ルーティングの認証情報を有効にする前。
- プロバイダ側の制限変更後。
- ローテーション切り替え中。
- 実稼働資格のある資格情報に対して定期的に。
トレードオフ: 自動チェックは、期限切れのキーや範囲が範囲外のキーを早期に検出しますが、チェックの設計が不十分だと、プロバイダの停止中に不必要なプロバイダの呼び出し、請求ノイズ、または誤った警報が発生する可能性があります。タイムスタンプ、プロバイダー エラー クラス、テストされたエンドポイント、およびテストされたモデル ファミリとともに正常性結果を保存します。シークレットの値や機密性の高いプロンプトは保存しないでください。
リスクの高い 1 つのスロットではなく、2 つのスロットでローテーションします
資格情報のローテーションは、削除して祈る操作であってはなりません。 2 スロットのローテーション モデルを使用します:
- 置換認証情報を非アクティブとして、完全なメタデータと所有者とともにインポートします。
- 合成ヘルスチェックを、対象のエンドポイント、モデル ファミリー、アカウント境界に対して実行します。
- 必要に応じて、安全な合成トラフィックまたは低リスクのトラフィックの小さなスライスに対してシャドウ適格性を有効にします。
- 運用トラフィックを段階的に移行します古い認証情報から新しい認証情報に移行します。
- 認証情報 ID ごとにエラー、レイテンシ、割り当て、コストの帰属を監視します。
- 新しい認証情報が安定したら、古い認証情報へのフォールバックをフリーズします。
- プロバイダーで古い認証情報を取り消し、ボールト レコードを取り消し済みとしてマークします。
- 失効後に古い認証情報を使用して復号化やプロバイダー呼び出しが発生しないことを確認します。
ローテーションの期限は、オペレーション ビューとアラートに表示される必要があります。緊急ローテーションには、より短いパスが必要です。資格情報を無効にし、ルーティングをブロックし、承認された交換を有効にし、インシデントレビューのためにすべての監査記録を保存します。
プロバイダーがサポートしている場合はプロバイダー キーを制限します
ゲートウェイ ポリシーは必要ですが、プロバイダ側の制限により、キーが侵害されたり悪用されたりした場合の影響範囲が減少します。 Gemini およびその他のクラウド プラットフォーム API キーについては、利用可能な場合は API/サービス制限と適切なアプリケーション制限を使用します。プロバイダー プロジェクト、ワークスペース、サービス アカウントの場合、プロジェクト スコープのランタイム キーで十分な場合は、広範な組織権限を避けてください。
推奨事項: すべての資格情報クラスのプロバイダー側の制限チェックリストを維持します。チェックリストは、圧力によってスキップされる可能性のある別個のセキュリティ タスクではなく、輸入承認とローテーション承認の一部である必要があります。
トレードオフ: プロバイダ側の制限により、運用上のオーバーヘッドが増加します。新しいエンドポイント、モデル ファミリ、リージョン、または自動化機能には、ポリシーと制限の変更が必要になる場合があります。これは、漏洩後に 1 つのキーが共有プロジェクト内のすべてのワークロードにアクセスできることが判明するよりも望ましい方法です。
追加専用の認証情報の監査ログを保持する
監査証跡は、誰が認証情報をインポートしたか、認証情報に何が許可されているか、どのルーティング決定によって認証情報が選択されたか、いつ失敗したか、いつローテーションまたは取り消されたかを明らかにする必要があります。
これらのイベントをログに記録します:
- 認証情報が作成またはインポートされました。
- 許可されたエンドポイント、テナント バインディング、データ ポリシーなどのメタデータが変更されました。
- ヘルスチェックが実行され、結果が記録されました。
- リクエストのルーティング ポリシーによって選択された認証情報。
- 内部サービス ID によって要求された認証情報の復号化。
- 認証、認可、割り当て、または制限エラーのため、プロバイダー呼び出しが失敗しました。
- ローテーションが開始され、トラフィックが変更され、古い認証情報が取り消されました。
- 緊急時の無効化が有効またはクリアされます。
- 管理者または緊急認証資格情報にアクセスしました。
監査イベントに生の認証情報の値を入れないでください。資格情報 ID、プロバイダー アカウント境界、リクエスト トレース ID、アクター ID、およびポリシー決定理由を使用します。大量のランタイム トラフィックの場合は、詳細な復号化テレメトリをサンプリングできますが、ルーティングの選択とコストの帰属は、請求とインシデント対応に十分な完全性を維持する必要があります。
実装チェックリスト
- 認証情報の分類を作成し、未分類のインポートを拒否します。
- すべてのプロバイダーのシークレットを専用の暗号化された保管庫に移動します。
- ルーティング メタデータをシークレット マテリアルとは別に保存します。
- ランタイム、管理者、請求、評価、BYOK 資格情報を別の認可クラスにします。
- BYOK 認証情報をテナントおよびプロバイダー アカウントの来歴にバインドします。
- 上流の認証情報を選択する前に、ポリシー エンジンの承認が必要です。
- 本番環境の適格性を確認する前に、即時に安全なヘルスチェックを実行します。
- 段階的なトラフィック シフトとプロバイダ側の取り消しを伴う 2 スロット ローテーションを使用します。
- 可能な限りプロバイダ側の制限を適用します。
- インポート、使用、失敗、ローテーション、取り消しに関する追加専用の監査ログを維持します。
- 管理者の資格情報を非常に厳しい制御の背後に保持します。短い TTL、名前付き承認、強力なロギング、ランタイム使用なし。
実用的な結論
まず、ゲートウェイ、スクリプト、CI ジョブ、評価ハーネス、パートナー自動化で現在使用されているすべての上流プロバイダー認証情報のインベントリを作成します。それぞれに、クラス、所有者、プロバイダー アカウント境界、テナント バインディング、許可されたエンドポイント、許可されたモデル ファミリ、ローテーション期限、および緊急無効化ステータスを割り当てます。分類できないものは、目的が明確になるまで無効にするか隔離する必要があります。
次に、1 つのアーキテクチャ ルールを適用します。下流の開発者はゲートウェイ スコープのキーを受け取ります。ゲートウェイのみが上流のプロバイダー アクセスを制御します。この分離により、プロバイダ、プロジェクト、ワークスペース、BYOK 顧客が増加しても、最小限の権限、テナントの属性、請求の正確性、データ ポリシーのルーティング、安全な自動化を維持できます。