AI製品のための安全なAPIキー管理

AI製品のための安全なAPIキー管理は、プロバイダーの認証情報を保管庫に入れるだけの問題ではありません。AIアプリケーションは、プロンプト、ファイル、取得したコンテキスト、ツール引数、モデル出力を、しばしば複数のプロバイダーと環境にまたがるシステムを通して送信します。キー自体が保存時に完璧に暗号化されていても、周辺のリクエスト経路では、ブラウザバンドル、デバッグログ、CI出力、サポート用エクスポート、あるいは権限過多のルーティングサービスを通じて機密データが露出する可能性があります。

したがって、実務上の目標はより広範です。長期有効なプロバイダーキーを信頼できないクライアントから遠ざけ、各ワークロードに対して最小限で有用なIDを付与し、各モデル境界をまたいで移動できるデータを制御し、ローテーションと失効を混乱を招くものではなく日常的な運用にすることです。

このガイドは、プラットフォーム、セキュリティ、AI製品の各チームが実装できる運用モデルを示します。そこには、脅威モデル、キー在庫テンプレート、コントロールプレーンのアーキテクチャ、無停止ローテーションの実行手順、ログ記録ルール、CI/CDの保護策、インシデント対応ワークフロー、本番環境向けチェックリストが含まれます。

AIキーがまたぐ5つの境界

まず、シークレットや、それが許可するデータが移動しうる場所を把握することから始めます。多くの失敗は、チームがプロバイダーキーだけを保護し、その隣接する境界のいずれかを見落とすことによって起こります。

この境界マップにより、設計上の問いは「キーをどこに保管するか？」から、「どのIDが、どのデータで、どのルートを通じて、どの要求を行え、あとにどのような証跡が残るのか？」へと変わります。

サーバー側のキー保管モデルを使用する

長期有効なプロバイダー認証情報は、ブラウザ、モバイル、デスクトップ、または拡張機能のクライアントに配布すべきではありません。エンドユーザーのデバイスに送られたものは、そのユーザー自身、または同じ権限で動作するマルウェアによって回収可能であるとみなすべきです。

より安全なパターンは次のとおりです。

1. クライアントは、ユーザーセッション、デバイス認証情報、または短命のアプリケーショントークンを使用して、あなたのバックエンドに認証します。
2. あなたのバックエンドは、要求された機能を認可し、ユーザーごとまたはテナントごとの制限を適用します。
3. ゲートウェイまたはサーバーサイド統合が、承認済みのプロバイダーとモデルを選択します。
4. プロバイダーキーは実行時に取得されるか、デプロイメントプラットフォームを通じて信頼されたワークロードに提供されます。
5. プロバイダーからの応答は、同じポリシー境界を通って返されます。

クライアントがプロバイダーのシークレットを知る必要はありません。クライアントが受け取るのは、あなたが定義した制限内であなたの製品を呼び出す権限だけです。

コーディングエージェントやローカル開発ツールでは、意図的な例外モデルを用いて同じ原則を適用します。開発者はローカルの認証情報を必要とする場合がありますが、それは失効、利用の帰属、限定されたスコープを備えた製品またはゲートウェイの認証情報であるべきです。会社全体で dotfiles にコピーされた共有の組織横断的なプロバイダーキーであってはなりません。

何かをローテーションする前にキーの在庫を構築する

どのワークロードがどのキーを使っているかチームが把握していないと、ローテーションのプロジェクトは失敗します。認証情報を変更する前に、機械可読な在庫を作成し、所有者を割り当ててください。

少なくとも、以下を記録してください:

キーの値を在庫に入れないでください。保存するのはメタデータと管理されたシークレットへの参照だけにしてください。

環境、ワークロード、リスクごとにIDを分離する

最も一般的なアンチパターンは、すべてのサービスで共有される単一の本番キーです。1つのリポジトリ、テストランナー、委託先のノートPC、またはサポート記録が漏洩するまでは便利です。その後、チームは無関係な製品に影響を与えずにキーを失効できなくなります。

以下については、個別のIDを使用することを推奨します:

• 本番、ステージング、開発、ローカルテスト。
• 顧客向けトラフィック、内部ツール、バッチジョブ、評価パイプライン。
• ツールを呼び出したり機密データを処理したりできる高リスクのワークフロー。
• 契約上の境界で分離が必要な場合の、異なる事業部門またはテナント。
• 緊急時またはブレークグラスのアクセス。これは通常運用中は無効のままにするか、厳格に制御する必要があります。

プロバイダーが制限機能を提供している場合は、それを適用してください。制限には、許可されたAPI、モデル、送信元ネットワーク、プロジェクト、リファラ、アプリケーション、またはクォータが含まれる場合があります。たとえば Google Cloud の API キーに関するガイダンスでは、キーの制限、分離、不要なキーの削除、リポジトリへのコミット回避、使用状況の監視が推奨されています。

プロバイダーが十分にきめ細かな制御を提供していない場合は、自社のゲートウェイでそれらを強制してください。中央ゲートウェイは、呼び出し元のワークロードを検証し、承認済みルートにマッピングし、予算とレート制限を適用し、ベンダーの認証情報を、1つのレビュー済みサーバーサイド境界の内側に保持できます。ルーティングとフェイルオーバー設計については、より広範なAI API gateway architecture guideを参照してください。

プロンプトとログのガバナンスをキー管理の一部として扱う

APIキーはデータパスを承認します。キーを保護しても、そのパスを制御しなければ、AI特有の主要なリスクは未解決のままです。

リクエストをルーティングする前に、ペイロードを分類し、最小限必要なルールを適用してください。

• 認証情報、トークン、Cookie、秘密鍵、接続文字列を削除する。
• モデルが必要としないフィールドを除外する。
• タスクがそれらなしで実行できる場合は、直接識別子をトークン化または仮名化する。
• サポートされていない規制対象データまたは契約上制限されたデータを拒否する。
• システム指示を、信頼できないユーザー内容や取得内容から分離する。
• エージェントが外部システムを呼び出す前に、ツール引数を検証する。

ログには明示的なスキーマが必要です。開発者がリクエストオブジェクトをログに残さないことを覚えておくことに頼らないでください。どのフィールドを許可するかを定義し、それ以外はすべて破棄または変換してください。

有用な本番イベントには、次の内容を含めることができます。

{
  "request_id": "req_01J...",
  "tenant_id_hash": "tnt_7f2...",
  "workload": "support-chat-api",
  "route_policy": "support-low-risk-v3",
  "provider": "selected-provider",
  "model": "selected-model",
  "input_tokens": 842,
  "output_tokens": 211,
  "latency_ms": 1370,
  "status": 200,
  "key_version": "v12",
  "redaction_policy": "customer-support-v4"
}

デフォルトでは、認可ヘッダー、生のプロバイダーキー、完全なプロンプト、アップロードされた文書、マスクされていないツール引数、または完全なモデル出力を含めるべきではありません。ペイロードの取得が、厳密に管理された評価やインシデント対応のために必要な場合は、時間を限定し、アクセス制御を行い、通常のテレメトリとは明確に分離してください。

OWASP Logging Cheat Sheetは、アクセストークン、パスワード、暗号化キー、その他の機密データをアプリケーションログから除外するための有用なベースラインを提供します。

ダウンタイムなしのAPIキーのローテーションを設計する

ローテーションは、安全に実施できる場合にのみ統制として機能します。障害を引き起こす手順書は、緊急時まで先送りされることになります。

プロバイダーが重複する認証情報をサポートしている場合は、デュアルキーまたはバージョン管理されたシークレットのシーケンスを使用してください。

1. 新しいプロバイダーキーを作成します。 旧キーと同じ、またはそれより厳しい制限を適用します。
2. 新しいシークレットバージョンとして保存します。 プラットフォームがバージョンやエイリアスをサポートしている場合、既存の値をその場で上書きしないでください。
3. 新しいバージョンを受け入れる読み取り側をデプロイします。 ゲートウェイやワークロードを更新し、現在のエイリアスまたはバージョンを解決するようにします。
4. トラフィックを切り替えて観測します。 新しいキー版を使用して、成功したリクエスト、想定されるモデル、支出、レート制限、エラー率を確認します。
5. 旧いコンシューマーを削除します。 デプロイメントのインベントリ、ジョブ、ワーカー、災害復旧環境を確認します。
6. 旧キーを失効させます。 単に使用を停止するだけでなく、プロバイダー側で無効化してください。
7. 拒否を検証します。 制御されたテストで、旧資格情報がもはや機能しないことを確認する必要があります。
8. 証跡を記録します。 タイムスタンプ、所有者、影響を受けたワークロード、検証結果、次回レビュー日を保存します。

キーのバージョン選択をサポートするシステムでは、アプリケーションはシークレットの特定バージョンをハードコードするのではなく、安定したエイリアスを参照するべきです。

type ProviderCredential = {
  value: string;
  version: string;
};

async function loadProviderCredential(): Promise<ProviderCredential> {
  const activeVersion = await secretStore.resolveAlias("ai/provider/active");
  const value = await secretStore.readVersion("ai/provider", activeVersion);

  return { value, version: activeVersion };
}

value を出力したり、返されたオブジェクトをシリアライズしたり、エラーに添付したりしないでください。ログにはシークレットではないバージョン識別子のみを記録します。

OWASP Secrets Management Cheat Sheet では、作成、ローテーション、失効、期限切れ、監査、バックアップ、ブレークグラスアクセスを含むシークレットの完全なライフサイクルを計画することを推奨しています。また、実用的であればローテーションを自動化することも重視しています。

シークレットがリポジトリや CI ログに入るのを防ぐ

ソースコード、フィクスチャ、ビルド成果物、または CI のトランスクリプトに資格情報がコピーされた後では、シークレットマネージャーは役に立ちません。

3つの段階でコントロールを適用してください。

コミット前

• .env.example ファイルにはプレースホルダーを用意し、実際に使える資格情報は決して入れないでください。
• ローカルのシークレットファイルはバージョン管理の外に置いてください。
• 一般的なプロバイダーパターンと高エントロピー値を対象に、pre-commit フックで高速なシークレットスキャナーを実行してください。
• 後のコミットでシークレットを削除しても、履歴から消えるわけではないことを開発者に教えてください。

プッシュ時とプルリクエスト時

• 利用可能な場合は、リポジトリのシークレットスキャンと push protection を有効にしてください。
• 公開スキャナーが認識しない社内ゲートウェイトークン向けに、カスタムパターンを追加してください。
• 文書化されたバイパス理由を要求し、バイパスはセキュリティレビューに回してください。
• 生成ファイル、ノートブック、テストスナップショット、インフラ計画もスキャンしてください。アプリケーションのソースだけに限定しないでください。

GitHub では、push protection を、push 処理中にスキャンを行い、検出されたシークレットがリポジトリに入る前にブロックする方法として説明しています。検出されたからといってキーを保持する理由にはなりません。コミットされたことが確認された認証情報は漏えいしたものとして扱い、ローテーションしてください。

CI/CD 中

• 保存されたクラウド認証情報よりも、ワークロード ID または短命なフェデレーションを優先します。
• シークレットは、それを必要とするジョブとステップにのみ公開します。
• 既知のシークレット値はマスクしますが、主な制御手段としてマスキングに依存しないでください。
• シークレット取得の前後ではシェルのトレースを無効にします。
• 信頼できないフォークされたコードがデプロイ用シークレットにアクセスできないようにします。
• 成果物、キャッシュ、クラッシュダンプ、テストレポートに誤って機密情報が記録されていないか確認します。

シークレットをログに残さずに使用状況を監視する

適切な監視とは、権限そのものを記録せずに「誰がどの権限を使ったか?」に答えることです。

追跡する項目:

• ワークロード、環境、テナントまたはプロジェクト、キーのバージョン。
• プロバイダー、モデル、ルートポリシー、フォールバック経路。
• リクエスト数、トークン量、支出、レイテンシ、エラー種別。
• 有用な場合は、ソースネットワークまたはデプロイ ID。
• 拒否された読み取りを含む、シークレットマネージャーへのアクセス。
• キーの作成、制限の変更、ローテーション、失効、削除。
• 予期しない環境、地域、モデル、時間帯からの突然の使用。

総支出だけでなく、挙動に対してもアラートを設定します。低コストのキーが盗まれても、プロンプトが露出したり、内部ワークフローが調査されたりする可能性があります。逆に、正当なバッチジョブが認証情報の侵害なしに支出スパイクを引き起こすこともあります。プロバイダーの使用状況を、アプリケーションのリクエスト ID、ゲートウェイのポリシー判断、デプロイイベント、シークレットマネージャーの監査ログと相関させます。

認証情報の制御を補完するトラフィック制御については、LLM レート制限ガイドとLLM API フォールバックルーティング実践ガイドを参照してください。

漏えいから失効までのインシデント時計を使う

キーが漏えいした可能性がある場合、最初の目的は、攻撃者が実際に使用したかどうかを証明することではなく、封じ込めです。

次の手順で進めます:

1. 資格情報を疑わしいものとして扱う。 いつ、どこで漏えいした可能性があるかを記録します。
2. 通常の管理された手順で代替を作成する。 対応を急ぐために、新しいキーをチャットに貼り付けないでください。
3. 正当なワークロードを代替へ移行する。 事前に用意したローテーション手順を使用します。
4. 疑わしいキーを失効させる。 即時失効が受け入れがたい損害を生む場合は、切り替えを完了するまでルートを隔離し、制限を下げます。
5. すべてのコピー先を検索する。 ソース履歴、CIログ、成果物、コンテナレイヤー、サポートシステム、ダッシュボード、ノートブック、ローカル設定、バックアップを確認します。
6. 許可されたデータ経路を確認する。 キーがどのプロンプト、出力、ファイル、ツール、モデルにアクセスできたかを把握します。請求範囲だけではありません。
7. アクティビティを相関させる。 プロバイダーの使用状況、ゲートウェイログ、デプロイ、シークレットの読み取り、ユーザーのアクティビティを比較します。
8. 適切な所有者に通知する。 関連するデータと契約に応じて、セキュリティ、プラットフォーム、法務、プライバシー、顧客対応の各チームを巻き込みます。
9. 根本原因を取り除く。 不足していたスキャナー、制限、ID境界、またはログフィルターを追加します。
10. 時間を測定する。 検知、代替、トラフィック切り替え、失効、検証までの時間を記録します。

最も実用的な指標は、しばしば 露出から失効までの時間 です。これは、漏えいの確かな証拠を組織が把握してから、疑わしい資格情報がどれだけの間利用可能なままであるかを示します。この間隔を短縮するには、所有者の明確化、インベントリ、 автомат化、そしてテスト済みのローテーションが必要です。長いポリシー文書ではありません。

マルチプロバイダーAI製品の参照アーキテクチャ

安全なマルチプロバイダー構成は、5つのレイヤーに整理できます。

1. クライアントIDレイヤー: プロバイダーの資格情報を公開せずに、ユーザー、デバイス、エージェント、またはアプリケーションを認証します。
2. アプリケーション認可レイヤー: 製品の利用権、テナント境界、機能アクセス、予算を検証します。
3. データポリシーレイヤー: プロンプト、ファイル、取得したコンテキスト、ツール引数を分類し、マスキングします。
4. ゲートウェイおよびルーティングレイヤー: 承認済みモデルを選択し、クォータを適用し、シークレットではない属性情報を記録し、フェイルオーバーを処理します。
5. プロバイダー資格情報レイヤー: 分離されたベンダー資格情報を保管し、バージョンをローテーションし、信頼されたルーティングワークロードにのみ公開します。

この設計は被害範囲を限定します。侵害されたクライアントトークンが、ただちにプロバイダーキーを明らかにするわけではありません。侵害されたワークロードIDが、すべてのプロバイダーへのアクセスを与えるべきではありません。漏えいしたプロバイダー資格情報が、すべての環境を認可すべきではありません。ログ記録の失敗が、シークレットと完全なペイロードの両方を露出させるべきではありません。

Flatkeyの製品ポジショニングは、OpenAI互換の単一エンドポイントと、複数のモデルプロバイダーにまたがる統一アクセスです。これにより、アプリケーションが管理するベンダー固有の統合数を減らせますが、ゲートウェイがあっても、クライアント認証の保護、リクエストデータの分類、ログの設定、所有者の割り当て、失効テストまで、あなたの責任はなくなりません。本番展開の前に、アカウントとアーキテクチャで利用可能な正確な制御を評価してください。まずはFlatkey integration guideを参照し、current model access and pricingを確認できます。

Production checklist

このチェックリストは、ローンチ前と四半期ごとの統制レビュー時に使用してください。

Custody and identity

• 長期間有効なプロバイダーキーが、ブラウザー、モバイル、デスクトップ、または拡張機能のコードに含まれていない。
• 本番の各ワークロードに、識別可能な所有者と認証情報の経路がある。
• 本番、ステージング、開発、評価、ローカルアクセスが分離されている。
• 共有の人間用キーは、可能な限りワークロードまたはゲートウェイのIDに置き換えられている。
• プロバイダーとゲートウェイの制限は、実務上可能な最小範囲に設定されている。

Storage and delivery

• 信頼できる唯一の情報源は、管理されたシークレットストアまたは制御されたデプロイメントバインディングである。
• アプリケーションは実行時にのみシークレットを取得し、出力したりシリアライズしたりしない。
• CIジョブは、必要なステップに必要なシークレットだけを受け取る。
• シークレットへのアクセスと管理上の変更は監査される。
• 緊急時のブレークグラスアクセスは文書化され、時間制限があり、テストされている。

Data and observability

• 認可ヘッダーとキー値は、ログ、トレース、エラー、サポート向けエクスポートから除外されている。
• プロンプト、出力、ファイル、ツール引数のログ記録は、許可リスト方式のスキーマに従う。
• マルチプロバイダーのルーティングの前にマスキングが行われる。
• 使用状況は、ワークロード、環境、ルート、プロバイダー、モデル、キーのバージョンごとに帰属付けできる。
• アラートは、支出だけでなく、異常なルートやIDも対象にする。

Rotation and response

• 検証済みの二重キーまたはバージョン管理されたシークレットのローテーション手順書が存在する。
• 古いキーはプロバイダー側で失効され、使用不能であることが確認される。
• シークレットスキャンとプッシュ保護は、リポジトリと生成された成果物をカバーしている。
• 漏えいの疑いがある場合は、悪用の証明を待たずに直ちに封じ込めを開始する。
• 露出から失効までの時間は、訓練とインシデントの後に測定される。

FAQ

What is secure API key management for AI products?

AIモデルを呼び出すために使用される認証情報の完全なライフサイクルとリクエスト経路を管理する実践です。これには、サーバー側での保管、ワークロードID、最小権限、シークレット保管、ルーティングポリシー、プロンプトとログの統制、ローテーション、監視、インシデント対応が含まれます。

Should an AI API key be stored in an environment variable?

環境変数は配布手段にはなり得ますが、完全な管理システムではありません。シークレットには、管理された信頼できる唯一の情報源、制限されたデプロイメントアクセス、ローテーション、監査、そしてプロセスダンプ、ログ、デバッグエンドポイント、継承された子プロセスからの保護が必要です。これらの制御が改善される場合は、プラットフォームネイティブのシークレット注入または実行時取得を優先してください。

How often should AI API keys be rotated?

間隔は、プロバイダーの機能、脅威モデル、契約、社内ポリシーを用いて定義します。任意の暦上の数字を選ぶことよりも重要なのは、ローテーションが自動化されているか、または訓練済みであること、古いキーが失効されること、疑わしいキーを直ちに置き換えられること、そして期限切れの認証情報が気づかれないまま残らないことを証明することです。

制限付きキーで、ブラウザからAIプロバイダーを直接呼び出せますか？

一部のプロバイダーは、特定のAPI向けにクライアント側の制限をサポートしていますが、本番のAI製品では、配布された認証情報は回収され得ると想定すべきです。バックエンドまたはゲートウェイを使うことで、通常はユーザー認可、クォータ、プロンプトのマスキング、プロバイダー選択、不正利用への対応、キー失効について、より強力な制御が可能になります。

1つのゲートウェイキーのほうが、複数のプロバイダーキーより安全ですか？

アプリケーションコード内での認証情報の乱立を減らせますが、その代わり権限がゲートウェイに集中します。ゲートウェイの認証情報は、スコープが適切で、帰属可能で、レート制限され、監視され、ローテーション可能であり、クライアントから保護されていなければなりません。その背後にあるプロバイダー認証情報にも、引き続き分離とライフサイクル管理が必要です。

APIキーがGit履歴に現れた場合はどうすべきですか？

漏えいしたものとして扱ってください。失効またはローテーションし、正当な利用者を置き換え、プロバイダーとゲートウェイのアクティビティを確認し、現在のブランチと関連アーティファクトからその値を削除し、予防的なスキャンを追加します。履歴を書き換えても、まだ有効な認証情報は安全にはなりません。

出典と参考資料

• OWASP Secrets Management Cheat Sheet
• OWASP Logging Cheat Sheet
• GitHub: About push protection
• Google Cloud: Best practices for managing API keys