paint-brush
では、APIキーとは実際には何ですか?そして、それはどのようにセキュリティを提供しますか?@algolia
3,743 測定値
3,743 測定値

では、APIキーとは実際には何ですか?そして、それはどのようにセキュリティを提供しますか?

Algolia8m2022/05/20
Read on Terminal Reader
Read this story w/o Javascript

長すぎる; 読むには

標準的な定義から始めます。 API キーは、API (アプリケーション プログラミング インターフェイス) のサービスを要求するアプリケーションまたはユーザーを識別および認証するために使用される文字列です。 この記事では、API キーとは何か、API キーがどのように機能するかについての裏話を知りたい好奇心旺盛な人々 (技術者または非技術者) のために、この定義を詳しく説明します。 API キーは、内部にアクセスするための秘密のコードです 識別と認証 API キーは、他のアプリケーションにサービスを提供するすべてのアプリケーションの標準的なセキュリティ メカニズムです。 それらが唯一の方法ではありませんが (API は JWT を使用できます。これについては、API キーと JWT 認証について説明しました)、API キーは、API を保護するために最もよく使用される方法です。

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - では、APIキーとは実際には何ですか?そして、それはどのようにセキュリティを提供しますか?
Algolia HackerNoon profile picture

標準定義から始めます。

API キーは、API (アプリケーション プログラミング インターフェイス) のサービスを要求するアプリケーションまたはユーザーを識別および認証するために使用される文字列です。

この記事では、API キーとは何か、API キーがどのように機能するかについての裏話を知りたい好奇心旺盛な人々 (技術者または非技術者) のために、この定義を詳しく説明します。

API キーは、内部にアクセスするための秘密のコードです

識別と認証

API キーは、他のアプリケーションにサービスを提供するすべてのアプリケーションの標準的なセキュリティ メカニズムです。

それらが唯一の方法ではありませんが (API は JWT を使用できます。これについては、ここで説明しました: API キーと JWT 認証) API キーは、API を保護するために最もよく使用される方法です。

Google Maps APIは、API キーを必要とする API サービス (「エンドポイント」) の例です。 Google の API に物理的な住所 (たとえば、「1001 Main Street, NY, NY」) を指定すると、API は最も可能性の高い場所の緯度と経度 (40.736124774992504、-73.82508447321075) を返します。

ただし、有効な API キーがないと、Google はリクエストに応答しません。特別な許可が必要です。 API キーにより、Google はユーザーが誰であるか、マップ サービスにアクセスする権利があるかどうかを知ることができます。

これは認証と呼ばれます (この記事の後半で説明する承認とは対照的です)。

ところで、仕組みを簡単に説明すると、 「Google の API にアドレスを渡す」「 Google に API キーを送信する」と書くときは、Google のサーバーに情報を送信する (リクエストを送信する) ことを指しています。 Post や Get などのHTTP リクエスト メソッドを介して)、情報を受信します(同じ API からの応答を取得します)。

要約すると:

開発者が、Google のほぼ完全な世界の住所のリストを使用してマップ アプリケーションを作成する場合、まず Google にサインアップし、Google Map API サービスを使用する権利を持つ API キーを取得する必要があります。

すべての API で API キーが必要または使用されるわけではありません

API キーを必要としない API もあります。たとえば、動画の視聴に使用するYoutube の URLは、実際には API キーを必要としない API リクエストです。

世界中のどこからでも、どのデバイスからでも、すべての人 (開発者だけでなく) が無料で使用できます。

とはいえ、 Youtube の APIは、API キーを必要とする他のサービスも提供します。たとえば、チャンネルの再生リスト、コメント履歴、使用統計、その他の Youtube が所有する何百ものデータに関する情報 (非公開または通常有料) を提供するサービスなどです。

使いやすさ: API ファーストの考え方

API に関する中心的な懸念事項の 1 つは、その使いやすさです。以下でセキュリティのコンテキストで繰り返しますが、使いやすさは API の使用に最も重要です。

すべての API ファースト企業は、API 製品を使用する際のすべての摩擦を最小限に抑えたいと考えています。これには、API へのアクセスを簡単かつ安全にすることが含まれます。これは、まさに API キーが提供するように設計されているものです。

API キー – 仕組み

前述のように、API キーを使用すると、サーバーはそのサービスにアクセスしようとしている開発者またはアプリケーション (リクエスターまたはユーザー) を識別できます。

API キーは、一連のアクセス権も定義します。アクセス権は、要求者が特定のアクションを実行することを許可し、他のアクションを実行することを禁止します。

詳細に入りましょう。

API キーは一意の識別子であり、通常は長い文字列です

API キーは、数字と文字の組み合わせで構成される一意の識別子です。英数字以外の文字が含まれているものもあります。

一意の識別子は、それ自体では何も意味しません。唯一の意味はその独自性です。パスワードや暗証番号に似ています。

API キーは通常 64 文字を超えており、ユニバーサル一意識別子(多くの場合GUIDと呼ばれます) を作成するシステム ランダマイザーによって生成されます。

アクセスの取得: 認証または失敗

API キーは、API を介してアプリケーションのデータと機能にアクセスする方法と考えてください。

すべての API リクエスターはサーバーに一意の識別子を送信します。サーバーはこの識別子を使用して、サービスを要求している個人またはアプリケーションがそうする権利を持っているかどうかを判断 (認証) します。

サーバーは、API 呼び出し (リクエスト) のリクエスターを認証できない場合、失敗の応答を返します。これが、API キーを作成する理由の背後にある基本的な考え方です。サーバーが認識しないキーを使用すると、サービスを使用できなくなります。

ただし、サーバーAPI キーを認識し、キーの所有者を認証した場合、そのユーザーはサービスを使用する権利を持ちます。

次のステップは、サーバーがリクエスターに 1 つ以上の操作を許可することです。

認可

承認プロセスは、要求者の権利範囲を決定します。認可は、認証されたリクエスタが API を使用できる正確な方法を定義します。

これには、権利(アクセスできる機能とデータ) と範囲(データの量、API を使用できる期間など) の定義が含まれます。

権利

権利とは、あなたができることに関するものです。リクエスタの API キーにデータを検索する権限が含まれている場合、リクエスタはデータを読み取って検索を実行できます。

リクエスタがデータを書き込む権利を持っている場合、リクエスタは一部またはすべての書き込み操作を実行できます。書き込みアクセスには、通常、より詳細な情報が付属しています。たとえば、リクエスタはインデックスを更新する権限を持っているが、レコードを削除する権限を持っていない場合があります。

権利を結合することもできます。たとえば、リクエスターは読み取りと書き込みの両方の機能を持っている場合もあれば、読み取り専用の場合もあります。通常、リクエスターには、さまざまなアクションを実行するための複数の API があります。例えば:

検索では読み取り専用。

閲覧とインデックス作成 (追加、更新、削除) のための読み取りおよび書き込みアクセス。

他の API の作成など、すべてを含む管理者アクセス

管理者権限

すべての API システムにはグローバル API キーがあり、読み取りと書き込み操作だけでなく、API が実行できるその他すべての操作に完全にアクセスできます。

たとえば、管理 API を使用すると、アプリケーションやユーザーは、ユーザー、識別子、権利、スコープの追加、削除、変更などのメタ アクションを実行できます。

管理 API キーの機能を考えると、この API キーを完全に安全にする必要があります。

同じことが書き込みレベルの API キーにも当てはまります。ユースケースによっては、読み取り専用キーの方が柔軟な場合があります。ビジネス機密データの読み取りには、Web サイトで製品や映画を検索するよりも高いセキュリティが必要であることは明らかです。

範囲

要求者が何かを行う権利を取得すると、API はその権利内で要求者の機能を制限または拡張できます。たとえば、リクエスタがインデックスを更新する一般的な権限を持っている場合、API キーはリクエスタのアクセスを特定のインデックスのみに制限できます。

または、API キーは、リクエスターが少数のレコードのみにアクセスできるようにする読み取り専用アクセスの範囲を設定できます。

特定の IP アドレスを除外することにより、スコープを使用してセキュリティを強化できます。有効期間を設定することもできます。たとえば、1 日に 1 回のリクエスト、または 30 日間にわたる 1 日あたりの少数のリクエストに対して設定できます。

最後に、API キーはフィルターベースの制限を提供できます。たとえば、API キーを使用すると、ユーザーは「衣料品」または「食品」のアイテムのみを更新できます。または、事前定義された検索またはフィルターを実行するように読み取り専用リクエスターを制限することもできます。

API の使用を制限する最後のポイントの良い例は、読み取り専用アクセスを許可するが、機密データを除外するフィルターで制限する場合です。これによりセキュリティが強化され、リクエスタはパブリック ビュー専用に設計されたデータを表示できるようになります。

しかし、セキュリティについてはさらに議論が必要です。

API キーの保護

セキュリティに関しては、API キーはこれまでのところしか機能しません。基本的に、キーが盗まれたり漏洩したりすると、セキュリティはなくなります。

API キーの盗難または漏えい

API キーを取得する方法は多数あります。ハッカーは、リクエストを傍受し、キーを盗み、リクエストをより有害なものに変更できます。

または、よくあることですが、開発者がインターネット経由で API キーを送信して、だれでも簡単に見つけられるように API キーを誤って公開してしまうことがあります。または、誤って Git リポジトリにプッシュします。または、ナプキンに書いてレストランのテーブルに置いておきます。

セキュリティ対策

一部のセキュリティ セーフガードは、追加のセキュリティ チェックに依存しています。これらのメソッドの一部では、リクエスタが余分な作業を行う必要があり、API の人気が低下します。 API 101 を覚えておく価値があります。

使いやすさは API の使用に最も重要であるため、すべての摩擦を最小限に抑えたいと考えています。

API のユーザーに追加のオーバーヘッドや負担を必要としない、いくつかのセキュリティ セーフガードを次に示します。

API を呼び出すことができる回数を制御するレート制限を作成します。

攻撃を最小限に抑えるために、他の制限またはアプリケーション制限を作成します。

攻撃検出方法を使用して、予期しない動作、リファラー、または既知の攻撃動作を知らせる。

標準外の要求、またはプライバシーやデータに損害を与える要求を拒否する。

また、前述のように、非機密データへのアクセスを削除します。

新しい API キーの生成を定期的に手動で作成または自動化します。

技術的な注意:これらのセーフガードの多くは、API 要求のパラメーターとしてヘッダーに追加できます。

開発者が API キーを提供するだけでなく、それ以上のことを行う必要がある、最も一般的な API セキュリティ手法を次に示します。

セキュア API キーと呼ばれる特別な種類の API キーを使用します。

ログインして、ユーザー ID とパスワードを使用する。

認証と承認に認証トークン (JWT トークンなど) を使用する。

暗号化。これが機能するには、ユーザーは API サーバーと同じ暗号化ソフトウェアを持っている必要があります。暗号化ソフトウェアは API キーを、API サーバーだけが理解できる判読不能なデータに変換します。

保護された API キー: 一時的な API キーを使用してサーバーベースのセキュリティを提供する

セキュア API キーには、標準 API キーに対する追加のセキュリティ セーフガードが含まれています。そのため、ダッシュボードで変更または管理することはできません。

さらに重要なことは、(b) ユーザーの ID が含まれているため、キーを使用できるのは 1 人のユーザーだけです。

通常、API キーはすべてのユーザーに対して1 回生成され、一生同じままです。ただし、永久キーには 2 つの欠点があります。

誰かがキーを盗むと、盗難が発見されてキーが取り外されるまで、そのキーを使用できます。

何万人ものユーザーに一意のキーが必要な場合は、それらすべてを作成して維持する必要があります。また、新しい API キーの生成は自動化できますが、ほとんどの場合、コードを手動で変更する必要があります。

ほとんどの本番レベルのアプリケーションは、追加作業なしで、より安全で管理しやすいものを必要としています。

仕組み: セキュア API キーは、キー生成の一部としてその情報を含めることにより、セッションやユーザー ID を活用します。基本的に、キーは、ユーザー識別子とキーのスコープ (タイムアウト制限、セキュリティ フィルターなど) を組み合わせることで、オンザフライで生成されます。

キーが生成されると、リクエスタは常に、生成された API キーそのユーザー ID およびスコープを送信する必要があります。 API サーバーは、ユーザー ID とスコープを使用してキーを再生成し、ユーザーが送信したキーと比較します。それらが異なる場合、それは明らかにハックです。

この二重チェック ロジックは、セキュリティを向上させるための 1 つのステップにすぎません。次のステップは、API ユーザーにログインを求めることです。

ログイン – ユーザー ID、パスワード、JWT トークン、OAuth、および OpenID を使用した API キーの作成

ここで言及する最後のセキュリティ メソッドには、API ユーザーにログインを要求することが含まれます。

このシナリオでは、ログオンが成功すると、API サーバーは、API ユーザーがログインしている間に使用する必要がある一意の判読不能なトークンを発行します。さらに、トークンにはユーザー資格情報が含まれているため、ユーザー以外がトークンを送信します。

したがって、一時的な Secured API Key メソッドを次の 2 つの重要な方法で改善します。

JWT にはログオンが必要です。

JWT は、ユーザーのログオン資格情報の暗号化されたバージョンを値に含むトークンを生成します。これらのユーザー資格情報により、API サーバーは、連続するすべての API 要求でユーザーを認証できます。

JWT トークンの詳細と、API キーとの違いをご覧ください。

最適な API の設計と実装 – 使用状況の追跡

API キーの目的、外観、操作方法、および API キーで実行できることとできないことについて説明しました。

また、セキュリティについても詳しく説明しました。最後に、API の使用状況を追跡し、API を改善するという別の側面について説明します。

API は、その設計と機能を改善するためにユーザー エクスペリエンスに依存しています。競争が激化する API 市場で最高の API を提供したい企業は、顧客が API をどのように使用しているかを知る必要があります。

API プロバイダーは、すべての要求 (どの要求、要求の数、各要求の成功と失敗) をログに記録することにより、レポート、デバッグ、および分析を API の設計と実装に追加します。