API キー管理は、ダッシュボードの小さなタスクではなくなりました。 AI API を使用するチームにとって、AI API は、プロンプトの送信、モデル出力の受信、ツールの呼び出し、または従量制推論に費用を費やすすべてのアプリケーションのセキュリティ、コスト、および運用モデルの一部です。
多くのチームは、ローカル環境ファイル内の 1 つのプロバイダー キーから始めます。これは、同じキーが CI 変数、ノートブック、IDE 拡張機能、エージェント、バッチ ジョブ、顧客統合、およびサポート スクリプトに現れるまで機能します。その時点で、キーの漏洩は単なる認証の問題ではありません。プロンプトと応答を公開したり、予期せぬ請求をトリガーしたり、プレミアム モデルを呼び出したり、アプリケーション権限でツールを実行したり、推測に頼ってインシデント対応を行う可能性があります。
このガイドでは、API 鍵管理をライフサイクルとして扱います。つまり、鍵がどのように設計、発行、保管され、スコープ設定され、監視され、ローテーションされ、取り消されるかということです。 AI API アクセスに焦点を当てており、通常の API セキュリティ上の懸念事項に、モデル アクセス、トークンベースの支出、マルチプロバイダ認証情報、顧客属性、および OpenAI 互換クライアントが加わります。
API キーが API セキュリティに適合する場所
API キーは通常、認証情報の所有を証明します。 「この発信者は有効な秘密を持っていますか?」という質問に答えます。それ自体では、重要な認証の質問すべてに答えられるわけではありません。
バックエンドは、呼び出し元が特定のテナント、オブジェクト、モデル、エンドポイント、ツール、ワークスペース、レポート、または管理機能にアクセスできるかどうかを判断する必要があります。 OWASP API オブジェクト レベルの認証の破損、認証の破損、無制限のリソース消費、機能レベルの認証の破損などのセキュリティ トップ 10 のリスクは、有効な認証情報がシステムの 1 層にすぎないことを思い出させます。
AI API の場合、同じキーが非常に異なるリスク プロファイルでアクションを実行できる可能性があるため、この区別は重要です。 1 つの内部ワークフローに対して低コストのテキスト モデルを呼び出すことができるキーは、自動的にプレミアム モデルの呼び出し、バッチ ジョブの作成、別のテナントのデータへのアクセス、電子メールの送信ツールの呼び出し、または請求設定の管理を実行できるようにすべきではありません。
耐久性のある API セキュリティ モデルは、次の 3 つの懸念事項を分離します。
- 認証: リクエストに有効な資格情報があることを証明します。トークン、またはセッション。
- Authorization: 認証された呼び出し元が現在のテナント、環境、ビジネス コンテキストで何を実行できるかを決定します。
- ガバナンス: 支出、レート、モデル アクセス、データ公開、管理制御を制限するため、1 つの間違いが限定的な影響を及ぼします。 radius.
API キーは便利ですが、機密性の高いリソースや価値の高いリソースを保護する唯一のコントロールであってはなりません。 HTTPS、サーバー側の認証チェック、監査ログ、最小特権、レート制限、支出制限、安全なシークレット処理と組み合わせて使用します。
ライブ API キー インベントリから始めます
名前を付けられないキーは管理できません。実用的な最初のステップは、AI システムで使用されるすべての API キーと認証情報に似たオブジェクトのライブ インベントリです。
少なくとも、各キー レコードには、キー ID、不可逆ハッシュまたはフィンガープリント、所有者、作成者、チームまたはテナント、環境、ワークロード、スコープ、許可されたモデル、許可されたエンドポイント、支出ポリシー、レート ポリシー、IP 制限（該当する場合）、ステータス、作成時間、有効期限、最後に使用されたタイムスタンプ、ローテーションが含まれている必要があります。
インベントリには、運用環境のランタイム キー以上のものを含める必要があります。個人開発者キー、サービス アカウント キー、CI/CD キー、ワークスペース キー、顧客キーまたはテナント キー、販売代理店管理キー、請求/レポート キー、管理者 API 認証情報、上流プロバイダ認証情報が含まれます。
最も重要なフィールドは、所有権、目的、範囲、最終使用、および制限ポリシーです。これらがなければ、オフボーディング、ローテーション、漏洩への対応、コスト調査、カスタマー サポートなど、今後のあらゆるセキュリティ タスクが遅くなります。
鍵の境界を意図的に設計する
API 鍵管理の最大の間違いは、1 つの鍵を多くの境界にまたがって使用することです。共有プロダクション キーは最初は便利ですが、帰属が破壊され、取り消しが混乱を招きます。漏洩した場合、問題の原因となっているワークロードを特定できないまま、すべてのサービスのトラフィックを停止しなければならない可能性があります。
適切なキー境界は、ビジネスとソフトウェアの形状に従います。本番環境と開発、人間とサービス、顧客を社内チーム、テナント同士、実行時認証情報を管理者認証情報、ゲートウェイ発行の顧客キーを上流のプロバイダ キーから分離します。
環境の境界
開発、ステージング、本番では別のキーを使用する必要があります。開発キーは、実稼働データや実稼働予算に達してはなりません。ステージング キーは、厳密に制御された理由がない限り、実際の顧客のワークロードにアクセスしてはなりません。
ワークロードの境界
各サービス、バッチ ジョブ、エージェント フリート、統合、またはスケジュールされたタスクには、独自のキーまたはサービス アカウントが必要です。これにより、どのワークロードが費用を費やしたか、どのサービスが認証に失敗し始めたか、どの統合で非推奨のモデルが使用されているか、インシデント中にどのキーを凍結する必要があるかなど、基本的な質問に答えることができます。
テナントと顧客の境界
マルチテナント システムには、帰属と分離が必要です。顧客向けの API キーを使用してプロンプトを送信する場合、リクエストは顧客、テナント、アプリケーション、そして理想的には仮名のエンドユーザーまたはアクターに関連付けられる必要があります。あるテナントのキーが侵害されても、別のテナントのデータ、モデル プロファイル、予算、またはログへのアクセスが許可されるべきではありません。
プロバイダー認証情報の境界
アップストリーム プロバイダー キーは、顧客や内部アプリケーションに発行するキーとは異なります。プロバイダーの資格情報はサーバー側に保管し、ボールトまたはシークレット マネージャーに保存する必要があり、ブラウザ、モバイル アプリ、デスクトップ クライアント、パブリック ノートブック、または顧客が管理する環境には決して送信しないでください。
ゲートウェイは、上流のプロバイダーの資格情報をゲートウェイの背後に保持しながら、顧客向けの 1 つのキー サーフェスを公開することで、この点に役立ちます。これにより、プロバイダー全体での使用状況分析、失効、チーム管理、ポリシー適用を一元化することが可能になります。 OpenAI 互換の API を中心にクライアントを標準化する場合、多くのツールが単一のベース URL とベアラー トークンを想定しているため、ゲートウェイの境界が特に重要になります。
モデル、エンドポイント、ツール、および支出に最小限の権限を適用する
最小限の権限とは、キーがそのワークロードに必要なアクセスのみを持つ必要があることを意味します。 AI システムの場合、スコープは API エンドポイントの単なるリストではありません。これには、モデル、ツール、トークンの予算、レート制限、テナント、データ クラス、管理機能も含まれます。
実用的な AI API キー ポリシーには、次のものが含まれます。
- 許可されたモデル ファミリまたは特定のモデル ID。
- チャットの完了、埋め込み、バッチ ジョブ、イメージ生成などの許可されたエンドポイント。
- 禁止された管理 API、ランタイム キーのキー管理 API、課金 API、およびワークスペース管理 API。
- 1 分あたりのリクエストと 1 分あたりのトークンに対するキーごとのレート制限。
- テナントごと、チームごと、または顧客ごとの支出制限。
- プレミアム モデルの制御により、低リスクのワークフローで突然最も高価なキーを使用することはできません。モデル。
- ツールの権限（キーが外部コネクタ、コード実行、取得システム、またはビジネス アクションを呼び出すことができるかどうかなど）。
- ネットワーク パスが予測可能な、安定したサーバー側のワークロード用の IP 許可リスト。
支出制御は、従量制 AI API の API セキュリティの一部です。キーが漏洩すると、機密データにアクセスしない場合でも、直接的な経済的損害が発生する可能性があります。レート制限は役立ちますが、それだけでは十分ではありません。トークンの量、再試行、バッチ ジョブ、ツール呼び出し、モデルの選択はすべてコストに影響します。安全な実装では、レート制御と支出上限、モデル許可リスト、異常検出、緊急凍結制御を組み合わせる必要があります。
モデルのコストとアクセス ポリシーを比較するチームは、セキュリティと財務の調整を維持する必要があります。モデルの価格設定は調達の問題だけではありません。これは、侵害されたキーまたは誤って設定されたキーが使用できる金額を決定します。承認済みのモデル プロファイルを予算に関連付けて維持し、モデルの組み合わせが変更されたときに、特に AI モデルの価格設定 を使用してコストと機能別にワークロードをルーティングする場合にプロファイルを確認します。
シークレットを適切な場所に保存
API キーは、シークレット マネージャー、サーバー側の構成、制御された CI/CD 変数、または Vault でバックアップされたゲートウェイに属します。これらは、ソース コード、ブラウザ JavaScript、モバイル バンドル、デスクトップ アプリ パッケージ、公開ノートブック、スクリーンショット、チャット メッセージ、分析ペイロード、サポート チケット、またはログには属しません。
クライアント側の露出は、一般的な障害モードです。プロバイダー キーがブラウザーまたはモバイル アプリに埋め込まれている場合、アプリを検査できる人は誰でもプロバイダー キーを抽出し、アカウント所有者に代わってリクエストを行うことができます。制御されていない環境で実行されているブラウザー、モバイル アプリ、IDE フリート、およびエージェントの場合は、サーバー側のプロキシまたは有効範囲が狭い短期間の委任資格情報を使用します。有効期間の長いプロバイダ認証情報を、制御できないクライアントに配布しないでください。
CI/CD にも同じ規律が必要です。キーを保護された変数として保存します。それらを読み取りまたは変更できる人を制限します。ビルド ログに環境変数を出力しないようにします。失敗したリクエスト ダンプの Authorization ヘッダーを編集します。プレビュー デプロイメントとフォークされたプル リクエストは、保護された本番パイプラインとは異なる信頼ゾーンとして扱います。
ログと可観測性システムには特別な注意が必要です。キーのフィンガープリント、リクエスト ID、テナント ID、モデル ID、応答ステータス、トークン カウンタ、コスト カウンタ、IP またはクライアントのメタデータ (該当する場合)、およびポリシーの決定を保存します。完全な API キーを保存しないでください。トレース、リバース プロキシ ログ、例外レポート、Webhook ペイロード、サポート ツール、分析イベント、配信不能キューのシークレットを秘匿化します。
緊急事態の前にローテーションを構築する
ローテーションとは、単に 1 つのキーを削除して別のキーを作成することではありません。デプロイされたサービスがまだ古いキーに依存している場合、削除するとダウンタイムが発生します。信頼性の高いローテーション プロセスでは、オーバーラップ、観察、明確なリタイア ポイントを使用します。
一般的なパターンは、2 つのアクティブなスロットを持つローテーション グループです。置換キーを作成し、それをすべての依存システムに展開し、古いキーの最後の使用状況を観察し、トラフィックが移動したときに古いキーを凍結し、信頼ウィンドウの後に削除します。ロールバック ルールを明確にしてください。古いキーはいつ再有効化できるのか、誰がそれを承認できるのか、どのくらいの期間使用可能な状態を維持できるのかなどです。
キーの有効期間が短いと、認証情報が失効するリスクは軽減されますが、運用上の負担が増大します。キーの有効期間が長いと、導入の混乱は軽減されますが、資格情報を忘れたり、従業員のオフボーディングのギャップが発生したりする可能性が大きくなります。適切なポリシーはワークロードによって異なります。高価値の実稼働サービス アカウントは、自動化により固定スケジュールでローテーションされる場合があります。一時的な開発者キーはすぐに期限切れになります。顧客管理の統合では、より長い移行期間と明確な非推奨メッセージが必要になる場合があります。
すべてのキーを同じ方法でローテーションしないでください。キーの一覧表示、作成、削除、または変更が可能な管理資格情報は、実行時推論キーよりもリスクが高いため、より強力な制御、より狭いアクセス、およびより積極的な監視が必要です。特定の検討された理由がない限り、ランタイム キーには管理権限を持たせるべきではありません。
リークと異常な使用を検出する
リーク検出は、複数のシステムが相互に強化する場合に最も効果的に機能します。ソース管理シークレット スキャンでは、リポジトリにコミットされたキーをキャッチできます。 CI チェックにより、マージ前に明らかなリークをブロックできます。カスタム パターンは内部キー形式を検出できます。プロバイダーのダッシュボードから異常なアクティビティが明らかになる場合があります。ゲートウェイ テレメトリでは、新しい IP、新しい地域、認証バーストの失敗、突然の支出速度、または予期しないモデルへの呼び出しを表示できます。
便利なセキュリティ ダッシュボードには、休止中のキー、所有者のいないキー、制限のないキー、有効期限が近づいているキー、新しいネットワークから使用されているキー、トークンが急速に増加しているキー、トラフィックを受信している凍結されたキー、失敗した認証バースト、支出上限に近づいている顧客キーなどが含まれます。
検出ではログやデータもカバーする必要があります。非同期システム。 Webhook、バックグラウンド ジョブ、キュー、および遅延完了には、リクエスト ID と元のキーの属性が必要です。そうしないと、疑わしいコールバックまたはバッチ結果を、それを作成したキーとテナントに結び付けることができない可能性があります。
Git 履歴にシークレットが表示された場合、リポジトリから削除するだけでは十分ではありません。リポジトリ、ビルド ログ、ミラー、フォーク、パッケージ アーティファクト、またはキャッシュされたページにアクセスした人は、すでにキーをコピーしている可能性があります。認証情報は無効化または凍結してから置き換える必要があります。
侵害された API キーへの対応
優れたインシデント対応計画は、短く、リハーサルが行われ、具体的である必要があります。通常、最初に決定するのは、凍結するか取り消すかです。フリーズは、調査用の記録を保存しながら、トラフィックを迅速に停止します。取り消しによりキーは永久に無効になります。一部のチームは、監査の継続性と即時ロールバックのオプションが必要な場合に、最初にフリーズを使用します。他のものは、公的リークが確認された場合に自動的に取り消されます。どちらのアプローチにも自動化と明確な権限が必要です。
実際の応答フローは次のようになります。
- 重大度と信頼度に基づいて、疑わしいキーを凍結または取り消します。
- 所有者、テナント、ワークロード、スコープ、モデル アクセス、支出ポリシー、最後に使用されたタイムラインを特定します。
- 異常なプロンプト、モデル、エンドポイント、ツール、IP、トークンの量、コスト。
- 影響を受けるデータ、テナント、ダウンストリーム アクション、請求への影響を評価します。
- スコープと制限を修正した置換キーを発行します。
- コミットされたシークレット、公開されたログ、広範な CI 変数、クライアント側のバンドルなどの根本原因を削除します。
- 予防策を追加します。シークレット スキャン、ログの秘匿化、範囲の絞り込み、有効期限の短縮、支出アラートなどの制御を行います。
- インシデントを文書化し、ランブックを更新します。
置き換え手順で同じリスクが再現されるべきではありません。10 個のサービス間で共有されていたためにキーが漏洩した場合は、それを別のサービス アカウント キーに置き換えます。ログから漏洩した場合は、新しいキーを発行する前にログを修正してください。すべてのモデルを呼び出す可能性があるために支出が過剰な場合は、モデルの許可リストを追加して支出制限を行います。
ゲートウェイで管理されるキーとマルチプロバイダーの AI アクセス
AI チームは複数のモデル プロバイダーを使用することがよくあります。各プロバイダーには、独自のキー モデル、ワークスペース構造、レート制限、モデル名、価格設定、および管理 API があります。すべてのプロバイダー キーをすべてのアプリケーションで直接管理すると、運用リスクが増大します。
ゲートウェイ管理のキー モデルを使用すると、その複雑さを軽減できます。アプリケーションは、顧客向けキーまたは内部キーを使用してゲートウェイを呼び出します。ゲートウェイは呼び出し元を認証し、テナント ポリシーを適用し、モデルと支出の制御を強制し、使用状況を記録し、サーバー側でアップストリーム プロバイダーの資格情報を使用します。これは、マルチモデル アプリケーション、内部プラットフォーム、代理店、再販業者サービスに役立ちます。
Model Gate の場合、ゲートウェイの役割が関係するのは、顧客向けの集中キー、統合された使用状況分析、チーム管理、支出制限、IP セキュリティ、Telegram 運用統合、パートナー API の自動化、および不正行為への対応です。顧客やダウンストリーム サービスをプロビジョニングする企業の場合、パートナー API 自動化 を使用すると、キーの作成、更新の制限、凍結、再販業者のワークフローを手動ではなく一貫させることができます。
ゲートウェイによってアプリケーション チームからすべての責任がなくなるわけではありません。安全なストレージ、バックエンドの認証、テナントの分離、エンドポイントの設計、CI/CD の衛生管理、プロンプトと応答のデータ ポリシー、およびプロバイダー側の制限 (可能な場合) も引き続き必要です。ゲートウェイは価値の高いコントロール プレーンになるため、強力なヴォールティング、監査ログ、アクセス制御、可用性計画、管理の分離が必要です。
よくある API 鍵管理の間違い
最も一般的な間違いは予測可能です。チームはプロバイダー キーをクライアント アプリに直接入力します。サービスと顧客ごとに 1 つのプロダクション キーを使用します。最初に削除し、後で展開することでローテーションします。所有者、制限、スコープ、有効期限なしでキーを作成します。完全な Authorization ヘッダーをログに記録します。彼らは AI のコスト管理をレート制限のみに依存しています。これらはランタイム サービスの管理者資格情報を提供します。彼らは、漏洩したキーを失効せずに Git から削除します。彼らは従業員をオフボードしますが、個人キー、ローカル環境ファイル、CI 変数はアクティブなままにします。
もう 1 つの微妙な間違いは、プロンプトと応答のログを純粋に操作可能なものとして扱っていることです。詳細なログは不正行為の調査に役立ちますが、個人データ、顧客のコンテンツ、秘密、規制情報が含まれている場合もあります。多くの場合、メタデータ優先のロギングのほうが安全です。デフォルトで鍵のフィンガープリント、モデル ID、トークン カウント、コスト、ステータス コード、ポリシー決定、リクエスト ID を取得し、より詳細なデバッグ データを取得するには制御されたアクセスが必要です。
実装チェックリスト
強力な API 鍵管理プログラムは、重点を絞ったチェックリストから始めることができます:
- すべての鍵、所有者、ユーザーのインベントリを作成します。
- 環境、ワークロード、テナント、顧客、認証情報クラスごとにキーを分離します。
- プロバイダ認証情報をサーバー側およびブラウザ、モバイル アプリ、ノートブック、パブリック クライアントの外部に移動します。
- モデル、エンドポイント、ツール、テナント、予算、および管理には最小限の権限を使用します。
- 支出制限、レート制限、モデル許可リスト、異常アラート、緊急凍結制御を追加します。
- シークレット マネージャー、ボールト、保護された CI 変数ストア、またはゲートウェイ管理の認証情報システムにシークレットを保存します。
- ログ、トレース、分析、サポート ツール、Webhook、エラーからシークレットを秘匿化します。
- 重複するキーによるローテーション、最終使用の監視、凍結、最終的な削除を実装します。
- カスタム キー パターンを含む、リポジトリと CI/CD でのシークレット スキャンを統合します。
- 個人キー、サービス アカウント、ワークスペース キー、および顧客キーのオフボード動作を文書化します。
- ランタイム推論資格情報を別の場所に保管します。
- 実際の漏洩によってプロセスが強制される前に、インシデント対応をテストしてください。
結論
API AI API のキー管理とは、ID、権限、コスト、および運用上の影響範囲を制御することです。安全なキーは単なるランダムな文字列ではありません。所有者、目的、範囲、環境、予算、有効期限、ローテーション パス、監査証跡、およびインシデント対応計画があります。
実際的な目標は、すべてのリクエストに関して官僚主義を作り出すことではありません。これは、通常の作業をより安全にするためです。開発者は構築でき、サービスは実行でき、顧客はプロビジョニングでき、セキュリティ チームはキーの漏洩や支出の急増時に何が起こったかに答えることができます。インベントリと境界から始めて、最小限の権限、安全なストレージ、ローテーション、監視、応答の自動化を追加します。マルチプロバイダーの AI アクセスの場合、ゲートウェイはその制御の多くを一元化できますが、アプリケーションの承認と秘密の衛生管理は依然として中核的なエンジニアリング責任です。