チーム向けの LLM API キー管理: 分離、ローテーション、支出制限、およびリーク対応

1 つの共有 LLM API キーは、最初の漏洩、説明のない請求、または運用停止が発生するまでは便利です。 API 鍵管理 の実際的な目標は、資格情報の秘密を保持することだけではありません。これは、無関係なアプリケーションを中断することなく、爆発範囲を制限し、使用状況を属性化し、安全にローテーションし、異常な支出を検出し、アクセスを取り消すことを目的としています。

このガイドは、プロバイダー、ゲートウェイ、内部アプリケーション、代理店、顧客向け製品にわたる LLM API キーの運用モデルをチームに提供します。これにより、検証されたセキュリティ事実と推奨される実装の選択肢が分離され、すべてのプロバイダーが同じコントロールを公開しているという想定が回避されます。

運用モデル: すべてのキーには境界が必要です

有用な鍵戦略は 1 つの質問から始まります。この鍵が悪用されたり取り消されたりした場合、何が失敗しますか? 答えが「会社全体」である場合、鍵の範囲が広すぎます。

事実: OpenAI の API キーの安全性に関するガイダンスでは、各チーム メンバーが固有の API キーを使用することを推奨し、キーの共有は利用規約に違反していると述べ、サポートされている場合は個々のキーに権限を割り当てることを推奨しています。 OpenAI のガイダンスでは、公開されたキーが所有者に代わってリクエストを行うために悪用される可能性があるため、ブラウザやモバイル アプリなどのクライアント側環境に API キーを展開しないようアドバイスしています。

推奨事項: 利便性ではなく、運用上の境界を考慮してキーを作成します。一般的な境界には次のものが含まれます:

• 環境: 本番、ステージング、開発、サンドボックス。
• アプリケーション: チャットボット バックエンド、ドキュメント プロセッサ、コーディング アシスタント、分析ワークフロー。
• 所有者: チーム、サービス アカウント、開発者、代理店クライアント、テナント。
• リスク レベル: 公開ワークフロー、内部自動化、バッチ ジョブ、実験的統合。
• プロバイダーまたはルート: 上流のプロバイダー A、プロバイダー B、承認されたモデル グループ、またはゲートウェイ ルート。

成長するチームにとって適切なデフォルトは、アプリケーションまたはサービスごとに 1 つの本番キー、環境ごとに 1 つの非本番キー、およびリスクの高い自動化または顧客レベルの使用には別のキーです。代理店や再販業者は、上流のプロバイダーの認証情報を共有するよりも、顧客レベルの仮想キーを優先する必要があります。

分散クライアントにはプロバイダー キーを決して置かないでください

ブラウザ、モバイル アプリ、デスクトップ拡張機能、パブリック プラグイン、および顧客側のスクリプトは、生のプロバイダー認証情報にとっては危険な場所です。キーを難読化したとしても、配布されたソフトウェアは検査、コピー、または傍受される可能性があります。

事実: OpenAI は、クライアント側環境に API キーを展開しないよう明示的に警告します。モバイル アプリケーションに関する調査でも、iOS アプリで永続的な LLM API 認証情報の漏洩が報告されており、分散クライアントに埋め込まれた認証情報は漏洩する傾向があるという同じ現実的な警告を裏付けています。

推奨事項: バックエンドまたはゲートウェイ パターンを使用します:

1. クライアントは、ユーザー セッション、JWT、顧客トークン、または有効期限の短い認証情報を使用してアプリケーションを認証します。
2. バックエンドは、ユーザー、テナント、プラン、要求された操作を検証します。
3. バックエンドまたは AI API ゲートウェイは、保護されたサーバー側の認証情報を使用して上流の LLM プロバイダーを呼び出します。
4. ポリシーのチェック、ロギング、コスト計算の後に、応答がクライアントに返されます。

この設計により、支出が発生する前に商品ルールを適用できます。たとえば、無料プランのユーザーは小規模なモデルに制限でき、有料テナントはより高い日次割り当てを受け取ることができ、内部管理ワークフローはより厳格な監視を備えた別のルートを使用できます。

インシデント対応が必要になる前に主要なインベントリを作成します

チームは、漏洩中に、どのサービスが公開されたキーを所有しているのか誰も知らないことに気づくことがよくあります。それは在庫の失敗です。

事実: OWASP API 2023 年のセキュリティ トップ 10 には、重大な API セキュリティ リスクとして不適切な在庫管理が含まれています。 LLM インフラストラクチャの場合、主要なインベントリは API インベントリの一部です。どの認証情報が存在するか、何にアクセスできるか、誰がその認証情報を所有しているかを知る必要があります。

推奨事項: すべてのキーにはメタデータが必要です。少なくとも、

• キー名と内部キー ID。
• オーナー チームと緊急連絡先。
• 環境: 実稼働、ステージング、開発、サンドボックス。
• 目的: アプリケーション、ワークフロー、テナント、統合、または開発者の使用。
• サポートされている場合に許可されるプロバイダー、モデル、エンドポイント、またはルート。
• 作成日、最後に使用したタイムスタンプ、レビュー予定日。
• 支出上限または割り当て。
• ローテーションのステータスとリンクされたデプロイメント構成。

アラート内で読みやすい命名規則を使用してください。例:

prod-supportbot-teamcx-gpt4class-2026q3
stg-docprocessor-platform-lowcost-2026q3
tenant-acme-prod-standard-2026q3
dev-jlee-sandbox-2026q3

正確な形式は一貫性よりも重要です。目標は、アラートで「tenant-acme-prod-standard が 1 日のしきい値を超えました」と通知し、責任ある所有者が何をすべきかを認識できるようにすることです。

プラットフォームで許可されている場合は、最小限の権限を適用します

すべてのプロバイダーやゲートウェイが同一の権限制御を公開しているわけではありませんが、原則は一貫しています。キーはワークロードが必要とすることのみを実行できる必要があります。

推奨事項: サポートされている場合は、次のコントロールの 1 つ以上によってキーを制限します:

• プロジェクト: キーを組織全体ではなくプロジェクトにバインドします。
• モデル: 承認されたモデルのみを許可します。高価なモデルや実験的なモデルはデフォルトでブロックされます。
• エンドポイント: チャットの完了は許可されますが、無関係な管理エンドポイントは拒否されます。
• プロバイダ ルート: すべての上流プロバイダに直接アクセスする代わりに、ゲートウェイ ルートを許可します。
• レート: 分あたりのリクエストまたは同時リクエストの上限。
• 予算: キーごと、チームごと、またはテナントごとの支出制限を適用します。

たとえば、ステージング キーは通常、最も高価な本番モデルにアクセスする必要はありません。文書分類作業者はおそらく、画像生成にアクセスする必要はありません。顧客向けのテナント キーは、別のテナントの予算を消費できません。

レイヤーで支出コントロールを設計する

LLM API セキュリティとコスト管理は重複しています。キーの漏洩は、セキュリティ イベントとして検出される前に、請求異常として検出されることがよくあります。

事実: OpenAI アカウントのセキュリティ ガイダンスでは、合理的な支出制限を推奨しており、API キーを区切ることで機能、チーム、製品、またはプロジェクトごとに使用状況を簡単に確認できることに注意してください。 OpenAI の使用状況レポートは、プロジェクト ID、ユーザー ID、API キー ID、モデル、バッチ、サービス層などのフィールドによる詳細な分析もサポートしています。

推奨事項: 1 つのグローバル上限ではなく階層化された制限を使用します:

• キーごとの制限: は、1 つの認証情報で予算全体が使い果たされることを防ぎます。
• チームごとの制限: 部門の使用量を可視化し、責任を持たせることができます。
• テナントごとの制限: は、SaaS と代理店のシナリオでの顧客の使用を分離します。
• 毎日の異常しきい値: 使用量が通常のパターンから逸脱するとアラートがトリガーされます。
• グローバル緊急停止: 不正行為が発生した場合に迅速な停止を可能にします。

ハード制限は便利ですが、正規のバッチ ジョブを中断する可能性があります。より安全な生産パターンは、一連の制御です:

1. 予想される 1 日の支出の 50% でアラートを発します。
2. 80% でエスカレーションします。
3. 重要でないトラフィックを 100% でスロットルします。
4. グローバル シャットダウンを使用する前に、問題のあるキー、テナント、またはルートのみをブロックします。

トレードオフ: 予算を厳格に設定すると、請求リスクは軽減されますが、可用性リスクが生じる可能性があります。ワークロードごとの階層制限: インタラクティブな運用トラフィック、顧客向けの有料トラフィック、バックグラウンド ジョブ、実験、開発者サンドボックスがすべて同じように失敗してはなりません。

キーと論理アクターごとに使用状況を追跡

キーは資格情報を識別します。リクエストの原因となった実際のユーザー、テナント、機能、またはワークフローを特定できない場合があります。 AI の使用状況を有用に分析するには、技術面とビジネス面の両方を記録します。

推奨事項: プライバシーとポリシーが許可する場合は、リクエストごとに次のフィールドを収集します:

• ID とタイムスタンプをリクエストします。
• API キー ID または仮想キー ID。
• アプリケーション、チーム、テナント、ユーザー、またはワークフローの識別子。
• プロバイダー、モデル、ルート、サービス層。
• プロンプトおよび完了トークンの数、または同等の使用単位。
• 推定費用。
• レイテンシ、ステータス コード、再試行回数、およびエラー クラス。

コストのオブザーバビリティを不必要なデータ収集に変えないでください。個人データ、顧客の秘密、または規制されているコンテンツが含まれる可能性がある場合は、デフォルトで完全なプロンプトを保存しないでください。多くの場合、チャージバックと異常検出には、ハッシュ化されたユーザー ID、テナント ID、トークン数、モデル名で十分です。

ダウンタイムのないローテーション: 安全なワークフロー

事実: NIST の鍵管理ガイダンスでは、鍵管理を生成、保管、アクティブ化、ローテーション、一時停止、失効、破棄などのライフサイクル規律として扱っています。 LLM API キーの場合、ローテーションは 1 回限りのセキュリティ作業ではありません。これは運用ワークフローです。

推奨事項: ダウンタイムのないローテーション プロセスを使用してください:

1. 置換キーを作成します。 必要な権限、予算、ルート、メタデータを照合します。古いキーはまだ取り消さないでください。
2. シークレット マネージャーに保存します。 ローカル ファイル、チャット メッセージ、チケット、貼り付けられた環境変数は避けてください。
3. 構成を段階的にデプロイします。 一度に 1 つのサービス、リージョン、ワーカー グループ、またはテナント セグメントを更新します。
4. トラフィックの動きを確認します。 リクエストが新しいキーで到着していること、エラー率と遅延が正常のままであることを確認します。
5. 古いキーへの書き込みを凍結します。新しいデプロイメントによるそのキーの参照を停止します。
6. 古いキーを取り消します。 トラフィックが移動した後は、忘れられたフォールバックとして残すのではなく、無効にします。
7. 監査の遅れを監査します。 古いキー ID のログ、デプロイメント マニフェスト、シークレット ストア、CI 変数、ランタイム エラーを検索します。

静的な環境変数を依然として使用しているアプリケーションの場合、回転は不安定になります。動的なシークレットの読み込み、集中構成、またはゲートウェイ管理の仮想キーに移行します。少なくとも、失効前にどのデプロイメントを変更する必要があるかを文書化してください。

漏洩対応ランブック

キーが漏洩した場合、スピードが重要になります。応答は、請求パニックの中で即席で作成するのではなく、インシデントが発生する前に作成する必要があります。

即時封じ込め

1. 公開されたキーを取り消すか一時停止します。
2. 失効により運用が中断される場合は、まず交換を発行し、重要なトラフィックを直ちに切り替えてください。
3. 不正行為が依然として存在する場合は、ルート、テナント、またはプロバイダをブロックします。
4. 悪用を特定するために必要なログを保存します。

調査

1. キーが出現した場所を特定します: リポジトリ、フロントエンド バンドル、モバイル アプリ、ログ ファイル、サポート チケット、ベンダー ツール、またはチャット。
2. 最後に知られている正当な使用法を見つけます。
3. 暴露が疑われる前後の使用量を比較します。
4. 使用したモデル、リクエストの量、コスト、可能な場合は地理、異常なステータス コードを確認します。
5. 依存するシークレットまたは隣接するシステムも公開される可能性があるかどうかを確認します。

回復と予防

1. 同じ環境で複数のシークレットが漏洩した可能性がある場合は、依存する認証情報をローテーションします。
2. 必要に応じて、オーナー チームおよび影響を受ける顧客関係者に通知します。
3. シークレット スキャンをリポジトリと CI パイプラインに追加します。
4. クライアント側の呼び出しをバックエンドまたはゲートウェイの背後に移動することで再発を防止します。
5. インシデントのタイムライン、根本原因、コストへの影響、および管理の改善を文書化します。

予測: チームがより多くのエージェント、プラグイン、自動化ツール、顧客固有のワークフローを LLM に接続するにつれて、重要な漏洩はますます第一にコストに関するインシデント、第二にセキュリティ インシデントとして認識されるようになります。キーごとのアトリビューションと予算管理を備えたチームは、1 つの共有認証情報を使用するチームよりも早く問題を解決できます。

マルチプロバイダー チーム向けのゲートウェイ管理キー

組織で複数の LLM プロバイダを使用している場合、直接プロバイダ キーにより、異なるダッシュボード、異なる請求ビュー、異なる権限モデル、一貫性のないローテーション プロセスなど、分散したガバナンスが生じる可能性があります。

ゲートウェイ管理のキー層は、上流のプロバイダーの資格情報を非表示にしたまま、アプリケーション側のキーを発行することでこれを簡素化できます。アプリケーションは OpenAI 互換の API エンドポイントを呼び出しますが、ゲートウェイはルーティング、使用状況分析、請求の帰属、およびポリシーの適用を処理します。

推奨事項: 必要な場合は、ゲートウェイまたはプロキシ層を検討してください:

• 複数のプロバイダーにわたるチームキーを 1 か所で管理します。
• Unified AI API 請求とキーごとの支出レポート。
• 代理店、再販業者、または SaaS テナント用の顧客レベルの仮想キー。
• 中央モデルの許可リスト、ルート ポリシー、および緊急停止。
• テナント、機能、ワークフロー、またはパートナー顧客ごとの使用状況の属性。

トレードオフ: ゲートウェイはガバナンスを向上させ、上流の認証情報を隠しますが、リクエスト パスの一部になります。運用インフラストラクチャと同様に監視します。遅延、可用性、エラー率、キューイング、再試行動作、プロバイダー固有の障害はすべて重要です。

実装チェックリスト

• 組織全体の共有キーを、アプリ、環境、テナント、またはワークフローごとにスコープ指定されたキーに置き換えます。
• ブラウザ、モバイル アプリ、デスクトップ拡張機能、パブリック スクリプトから生のプロバイダ キーを削除します。
• クライアント リクエストをバックエンドまたは AI API ゲートウェイ経由でルーティングします。
• すべてのキーに所有者、目的、環境、許可されたモデル、予算を添付し、メタデータを確認します。
• 必要に応じて、最小限の権限を適用します: プロジェクト、エンドポイント、モデル、ルート、レート、予算の制御。
• キーごと、チームごと、テナントごと、およびグローバルな支出制限を設定します。
• キー ID、論理アクター、モデル、トークン使用量、推定コスト、レイテンシー、ステータス コードをログに記録します。
• ダウンタイムのないローテーション ワークフローを作成し、緊急事態が発生する前にテストします。
• 封じ込め、調査、防止の手順を記載した漏洩対応ランブックを作成します。
• 非アクティブなキーを確認し、所有者または最近の正当な使用がないものはすべて取り消します。

実用的な結論

最もリスクの高いキーから始めます。つまり、本番環境で使用されているキー、複数のユーザーによって共有されているキー、多くの場所に埋め込まれているキー、または最大の費用を負担しているキーです。所有者を指定し、境界ごとに分割し、予算を追加し、クライアントが参照できる場合はバックエンドまたはゲートウェイの背後に移動し、ローテーション方法を文書化します。

その後、繰り返します。強力な LLM API キー管理は、シークレット ストレージに関する単一の決定ではありません。これはライフサイクルです。つまり、インベントリ、分離、最小権限、使用状況の帰属、コスト管理、ローテーション、およびリーク対応です。結果は単純です。何か問題が発生したときに、AI 予算全体ではなく、1 つのアプリケーション、テナント、またはワークフローのみがリスクにさらされることになります。

関連資料

• 本番 LLM API ルーティングとフォールバックの設計
• 以前の Model Gate ブログメモ
• 紹介 Model Gate 記事