API キーとは何ですか？ その仕組みと保護方法

Scrapeless Scraping API は x-api-token ヘッダーを通じてリクエストを認証します。ここで、Scrapeless アカウントの API キーが呼び出しクライアントを特定します。

APIキーとは何ですか？

APIキーは、APIプロバイダーがソフトウェアクライアント、プロジェクト、アカウント、または統合に発行する値です。クライアントは、リクエストにキーを含めます。APIゲートウェイまたはアプリケーションは、認証情報を検索し、そのステータスと制限をチェックし、ポリシーを適用し、アクセス、使用、および監査目的のためにリクエストを所有者に関連付けます。

「キー」という言葉は誤解を招くことがあります。APIキーは、データを暗号化または署名するために使用される暗号鍵であるとは限りません。多くのシステムでは、これは不透明なランダム資格情報です。一部の設計では、公開識別子と秘密のコンポーネントを使用します。他の設計では、オペレーターが資格情報のタイプを特定できるように、秘密を明らかにすることなく、認識可能なプレフィックスをエンコードします。

APIキーは、サーバー間APIや開発者ツール、データサービス、地図、メッセージング、自動化、内部サービスに一般的です。彼らの魅力は運用のシンプルさです：クライアントは1つの認証情報を送信し、プロバイダは呼び出しを特定できます。そのシンプルさは、キーが十分なエントロピーで生成され、安全に転送され、秘密として保存され、最小限の有用な権限に制限されているときにのみ安全です。

APIキー認証の仕組み

1. プロバイダーが資格情報を発行します。 ダッシュボードまたは管理APIは、名前付きプロジェクト、サービスアカウント、または統合用のキーを作成します。
2. クライアントは秘密を保管します。 サーバーアプリケーションは、シークレットマネージャー、保護された環境インジェクション、または他の承認された認証情報ストアからそれを読み取ります。
3. クライアントがリクエストを送信します。 鍵は通常、TLS経由のHTTPヘッダーに表示されます。
4. サービスはキーを解決します。 重要な識別子または安全な検索は、無関係な秘密を公開することなく、保存された資格情報レコードを見つけます。
5. サービスはポリシーを評価します。 それはアクティブステータス、スコープ、リソース制限、ネットワーク条件、クォータ、およびその他の制御をチェックします。
6. サービスは安全な監査データを記録します。 ログは、操作を特定するためにフルシークレットではなく、キーIDまたはフィンガープリントを使用します。

リクエストは認証されていても権限がない場合があります。認証は、どのクライアントが資格情報を提示したかを示します。認可は、そのクライアントがこのリソースに対してこのアクションを実行できるかどうかを示します。サービスは、両方の決定を明示的に行うべきです。

APIキーはどこに送信すべきですか？

API固有のヘッダーまたは標準 Authorization ヘッダーは通常適切な場所です。Scrapeless Scraping APIはこのヘッダー形式を使用します:

x-api-token: REDACTED

リクエストはHTTPSを使用する必要があります。これにより、トランスポートはヘッダーをパッシブネットワーク監視から保護し、サーバーを認証します。TLSはキーがアプリケーションログ、デバッグトレース、ブラウザー拡張機能、または侵害されたエンドポイントに到達した後は保護しないため、ストレージと可視性の制御が引き続き必要です。

The OWASP REST セキュリティ チートシート APIキーやその他のセキュリティトークンをURLに配置することは推奨されません。なぜなら、URLは多くのシステムによってキャプチャされるからです。互換性のためにクエリ文字列認証が存在する場合がありますが、新しいAPIはヘッダーを優先すべきです。

APIキーが証明できることとできないこと

有効なキーは、呼び出し元がリクエスト時にその資格情報を所持していることを証明します。それは、どの人間がリクエストを開始したか、デバイスが信頼できるか、またはキーを提示しているソフトウェアが意図されたソフトウェアであるかを証明するものではありません。コピーされたキーは、供給者が制限を追加したり、送信者に依存する証明を行わない限り、別のマシンから再生されることがよくあります。

公開ウェブページ、デスクトップバイナリ、ブラウザ拡張機能、およびモバイルアプリケーションに埋め込まれたキーは、ユーザーがそれらの環境を制御しているため、持続可能な秘密として保持できません。難読化は偶発的な発見を遅らせる可能性がありますが、信頼モデルを変更することはありません。公開クライアントは、制御されたバックエンドを呼び出すか、公共ソフトウェア用に作成された認証設計を使用するべきです。

APIキーは、敏感なリソースに対するユーザーレベルの権限を置き換えるべきではありません。すべてのユーザーアクションが1つのプロジェクトキーを共有する場合、サービスは個々の同意、役割、または取り消しを信頼性を持って区別できません。ユーザー認証と承認は別のレイヤーに属します。

APIキー vs OAuth vs ベアラートークン

これらのカテゴリは重なり合っています。OAuthアクセストークンは一般的にベアラートークンとして使用されます。APIキーもベアラー方式で提示されることがありますが、その提示はシステムをOAuthに変えるわけではありません。JWTはベアラートークンとして使用されることがありますが、不透明なベアラートークンも一般的です。

APIキーの設計

よく設計されたキーは、暗号的に安全なランダムソースから生成され、推測に耐えられる長さである必要があります。値は、センシティブなアカウントデータをエンコードしてはいけません。認識可能なプレフィックスは、シークレットスキャナーやオペレーターがプロバイダーと資格情報の種類を特定するのに役立ちますが、予測不可能な部分がセキュリティを担保しなければなりません。

多くのサービスは、完全な秘密を一度だけ表示します。バックエンドは、すべての平文の資格情報を表示用に保管するのではなく、一方向の検証子または保護された秘密表現を保存します。別の非秘密キーIDがルックアップ、ログ、および管理をサポートします。

システムは、プロジェクトごとに複数のアクティブキーを許可する必要があるため、デプロイメントはすべての環境に共通のシークレットなしで認証情報を変更できます。各キーには名前、所有者、作成イベント、最終使用情報、制限、および取り消し制御が必要です。

APIキーの保存方法

プロダクションサービスは、集中管理されたシークレット管理システムまたは承認されたプラットフォームシークレットストアからキーを取得する必要があります。アクセスは、シークレットが必要なワークロードアイデンティティに制限されるべきです。人間のアクセス、エクスポート、および管理変更は監査可能であるべきです。

The OWASP シークレット管理チートシート 中央ストレージ、プロビジョニング、監査、ローテーション、およびライフサイクル管理に関する内容です。環境変数は配信メカニズムになり得ますが、自動的にプライベートであるわけではありません：プロセスの検査、クラッシュレポート、ビルドログ、または不注意な診断により、それらが露呈する可能性があります。

ソース管理にキーをコミットしたり、コンテナイメージに配置したり、課題トラッカーに貼り付けたり、チャットを通じて共有したりしないでください。 CWE-798 エントリ：ハードコーディングされた資格情報 ソフトウェアに埋め込まれた認証情報が広範な露出を生み出し、変更が困難である理由を説明します。

スコーピングと制限

キーは、そのワークロードが必要とするAPI、操作、リソース、および環境のみを許可すべきです。開発、ステージング、製品用の資格情報を分けてください。プロセスが決して書き込まない場合は、読み取り専用の権限を使用します。漏洩が無制限のコストやトラフィックを生み出せないように、クォータを制限してください。

ネットワーク制限、許可されたオリジン、アプリケーション署名、またはサービスIDは有用なコンテキストを追加できますが、それぞれの制御には限界があります。ソースIPルールはモバイルネットワークや共有エグレスには難しいです。ブラウザのオリジン制限は、参加しているブラウザフローのみを保護し、公開されているキーを秘密にすることはありません。制限を層として扱い、認証情報保護の代替としないでください。

回転と撤回

ローテーションは古い資格情報を新しいものに置き換えます。安全なプロセスでは、2番目のキーを作成し、シークレット配信経路を通じてワークロードを更新し、新しいキーIDの下でトラフィックを確認し、その後古いキーを無効にします。複数キーのサポートにより、すべてのインスタンスで強制的な同時展開を防ぎます。

キーが露出している疑いがある場合、所有者が離れた場合、統合が引退した場合、または資格情報に正当な目的がなくなった場合は、すぐにキーを取り消してください。インシデント処理では、安全な監査記録を通じて影響を受けたリソースとアクションを特定し、その後、どのようにして価値が漏れたのかを調査し、配信経路を修正できるようにします。

期限は忘れられた資格情報の寿命を制限します。短い有効期限は、自動的に更新され、観察される場合にのみ有用です。期限切れのキーを永続的な緊急資格情報で静かに置き換えるシステムは、コントロールを無効にします。

キーを漏らさずに監視する

ログには、非秘密のキーID、プロジェクト、決定、エンドポイント、レスポンスクラス、タイムスタンプ、およびリクエストの相関識別子が記録されるべきです。完全なキーを書くことは決してありません。データがアプリケーションプロセスを離れる前に、削除処理は実行されるべきであり、ヘッダー、例外メッセージ、トレース、およびサポートバンドルをカバーする必要があります。

異常なエンドポイント、リージョン、トラフィック量、エラーパターン、キーの目的と一致しない環境からの使用に警告を出します。最後に使用されたタイムスタンプは休止中のキーを見つけるのに役立ちますが、観測された使用の不在は取り消し前に確認する必要があります。監視のカバレッジが不完全な場合があるためです。

一般的なAPIキーの間違い

• すべての環境に1つの鍵。 開発のリークはその後、生産に影響を与える可能性があります。
• URLのキー。 クエリ文字列は、ログ、分析、ブラウザ履歴、リファラーに広がっています。
• フロントエンドコードのキー。 公開クライアントは、共有された長期秘密を保護することはできません。
• 永続的な制限のない資格情報。 過剰な権限は、露出の影響を拡大します。
• ログに完全な秘密があります。 中央の可観測性システムは認証情報リポジトリになります。
• 所有者や目的はありません。 誰も古いキーがまだ必要かどうかを決定できません。
• 静かな自動型変換。 キーを数字として扱うと、先頭の文字や精度が変わることがあります。認証情報は不透明な文字列です。

APIキーを使用するタイミング

結論

APIキーはソフトウェアクライアントまたはプロジェクトを識別するための簡潔な認証情報です。文字列自体はシステムの一部に過ぎません。セキュリティは高エントロピー生成、ヘッダーに基づくTLSトランスポート、狭いスコープ、保護されたストレージ、安全なログ記録、観察された使用、計画的なローテーション、および即時の取り消しから生まれます。APIキーは制御されたアプリケーションアクセスに適しており、ユーザー委任システムに拡大したり、公開クライアントがそれらを露出できる場所に埋め込んだりするべきではありません。