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 つの懸念事項を分離します。
- 認証: リクエストに有効な認証情報、トークン、またはリクエストが存在することを証明します。
- 承認: 現在のテナント、環境、およびビジネス コンテキストで認証された呼び出し元が実行できる内容を決定します。
- ガバナンス: 支出、料金、モデル アクセス、データ公開、および管理制御を制限して、1 つのミスが爆発範囲に制限されるようにします。
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、エラー レポートからシークレットを秘匿化します。
- 重複するキーによるローテーション、最終使用の監視、凍結、最終的な削除を実装します。
- シークレット スキャンを
- 個人キー、サービス アカウント、ワークスペース キー、顧客キーのオフボード動作を文書化します。
- ランタイム推論認証情報を管理プロバイダー認証情報とは別にしておきます。
- 実際の漏洩によってプロセスが強制される前に、インシデント対応をテストします。
結論
AI API の API キー管理は ID を制御することです。権限、コスト、および運用上の爆発範囲。安全なキーは単なるランダムな文字列ではありません。これには、所有者、目的、範囲、環境、予算、有効期限、ローテーション パス、監査証跡、およびインシデント対応計画があります。
実際的な目標は、すべてのリクエストに関して官僚主義を作り出すことではありません。これは、通常の作業をより安全にするためです。開発者は構築でき、サービスは実行でき、顧客はプロビジョニングでき、セキュリティ チームはキーの漏洩や支出の急増時に何が起こったかに答えることができます。インベントリと境界から始めて、最小限の権限、安全なストレージ、ローテーション、監視、応答の自動化を追加します。マルチプロバイダーの AI アクセスの場合、ゲートウェイはその制御の多くを一元化できますが、アプリケーションの承認と機密衛生は依然としてエンジニアリングの中核的な責任です。