必須
キーはサーバー側のシークレットマネージャー、または保護された環境設定に保存されています。
ソース管理にコミットしないでください。
セキュリティガイド
APIキーセキュリティのベストプラクティスで、より安全な連携を構築する
APIキーセキュリティのベストプラクティスは、機密性の高い認証情報を簡単に公開することなく、AI APIとの接続を安全かつ有用に保つのに役立ちます。このガイドでは、連携の前、実行中、実行後に適用すべき実践的な対策を説明します。
以前の方法
以前のAI API連携では、キーをライフサイクルを持つ認証情報ではなく、便利な文字列として扱うことがよくありました。
現在の方法
AI APIのセキュリティ計画では、連携で保証できないことを明示したうえで、それぞれの制限に対して実行可能な代替策を提示する必要があります。
- クライアント側のキーを非公開にすることはできない
-
ブラウザー、モバイルパッケージ、または公開リポジトリに含めたものは、最終的に抽出されて再利用される可能性があります。
回避策認証情報をサーバー側のプロキシに移し、クライアントが必要とする限定的な操作だけを公開します。
- 正当なリクエストがすべて高額になるのを防ぐことはできない
-
認証情報が盗まれたり悪用されたりすると、リクエスト形式が正当なものに見える場合でも、トラフィックが発生する可能性があります。
回避策プロバイダーの上限、アプリケーションのクォータ、リクエスト予算、異常な使用量に対するアラートを設定します。
- 共有認証情報から個人を特定できない
-
チーム全体で1つのキーを使用すると、アクティビティの帰属や、侵害されたワークフローの調査が困難になります。
回避策人、環境、サービスごとに個別の認証情報または認証済みサービスIDを発行します。
- すでに漏えいしたキーを修復できない
-
公開投稿を削除したり、ログエントリを削除したりしても、クローラー、フォーク、監視システムによって作成されたコピーまでは消去できません。
回避策公開されたキーを無効化し、置き換え用のキーを発行して、使用状況を確認し、インシデントを記録します。
変更点
最新のAI API運用では、認証情報を管理対象のシークレットとして扱います。アプリケーションを接続する前に、単一の隠し変数に依存するのではなく、これらの要件を確認してください。
必須
本番環境、ステージング環境、ローカル開発環境、自動テストでは、それぞれ別の認証情報を使用します。
分離によって影響範囲を限定できます。
必須
アプリケーションは、AI APIを消費するリクエストを許可する前にユーザーを認証します。
プロバイダーキーはエンドユーザーのIDではありません。
必須
ログには、認証ヘッダー、リクエスト本文全体、シークレットを含むエラーの詳細を記録しません。
アプリケーションとプロバイダーのログを確認します。
必須
ローテーションと無効化には、担当者、文書化された手順、テスト済みの復旧方法が定められています。
計画は実行できてこそ役に立つ。
任意
使用状況のアラートとリクエスト制限は、プロバイダーとアプリケーション向けに設定されます。
本番環境では強く推奨されます。
誰が切り替えたのか
この変化が最も顕著に見られるのは、単一の実験用スクリプトから、実際のユーザーと運用責任を伴う共有AI APIサービスへ移行したチームです。
誰が切り替えたのか
デモに貼り付けるだけなら最も速い方法ではなく、AI API統合の段階と形態に合った制御パターンを選択してください。
1
ブラウザまたはモバイルクライアントを構築している
ユーザー認証、リクエスト検証、ユーザーごとの制限を備えたサーバーサイドプロキシを使用してください。
クライアントに必要なのはAI API機能へのアクセスであり、プロバイダーの認証情報へのアクセスではありません。
2
プライベートなバックエンドサービスを運用している
キーはリポジトリの外部に保存し、対応している場合はスコープを制限し、環境ごとに分離してください。
バックエンドでシークレットを保護しながら、アプリケーションにAI APIへの制御されたアクセスを提供できます。
3
AI API統合をローカルでテストしている
使い捨ての開発用キー、少額のリクエスト予算を使用し、ライブ呼び出しが不要な場合はフィクスチャまたはモックを利用してください。
ローカルスクリプト、共有ターミナル、スクリーンショット、デバッグログは、意図せず情報が漏洩する一般的な経路です。
誰が切り替えたのか
変更前と変更後の違いは、より複雑なプロンプトやモデルではありません。権限が存在する場所と、認証情報が侵害された場合にどれだけ迅速に封じ込められるかが変わったのです。
クライアント内のキー
アプリケーションの境界の内側で権限を管理します。
誰が切り替えたか
AI API統合の変更が難しくなる前に、セキュリティ対策を導入するのが最も簡単です。
より安全なAI APIアクセスを実践する
まずは、保護されたサーバールートを1つ、開発専用の認証情報を1つ、露出が疑われる場合の対応を文書化したものを1つ用意します。その後、統合の拡大に合わせて、ログの衛生管理、制限、ローテーション、レビューを追加します。目標は完全な秘匿性ではなく、制御されたアクセス、明確な責任の所在、そして問題が発生した際の影響範囲を小さくすることです。
- プロバイダーのキーをブラウザや公開リポジトリに置かないでください。
- 環境とサービスごとに認証情報を分けてください。
- 露出が疑われる場合は、直ちにローテーションしてください。
専用FAQ
これらの回答では、AI APIプロジェクトにAPIキーのセキュリティに関するベストプラクティスを適用する際に、実際によく寄せられる質問を取り上げます。
保護された環境設定、または専用のシークレットマネージャーを使ってサーバー上に保存してください。キーは、ブラウザのJavaScript、モバイルアプリケーションのバンドル、ソース管理、スクリーンショット、通常のアプリケーションログに含めないでください。
環境変数はキーをハードコードするより安全ですが、それだけで十分ではありません。ホスト、デプロイシステム、ログ、ビルドプロセス、エラー報告へのアクセスも制限し、確認する必要があります。
いいえ。認証情報を分けることで、本番環境を中断せずに開発用キーを無効化でき、異常なアクティビティの帰属も容易になります。可能な限り、ローカル作業、ステージング、本番環境、自動テストにはそれぞれ異なるキーを使用してください。
直ちにキーを失効または無効化し、信頼できる経路で代替キーを作成してください。未承認のアクティビティがないか利用状況とログを確認し、元の場所からシークレットを削除して、同じ露出が再発しにくくなるよう経緯を記録してください。
ブラウザやモバイルクライアントに配信されたキーは、公開されているものと考えるべきです。認証情報をサーバー側のルートの背後に置き、呼び出し元を認証し、リクエストを検証してから、承認済みの呼び出しをAI APIに転送する前に制限を適用してください。