【ITニュース解説】Apigee API Products, Developer, Apps and API Keys

Apigeeのセキュリティモデルは、API（Application Programming Interface）へのアクセスを安全かつ効率的に管理するための仕組みである。このモデルでは、APIキーが主要な認証情報として機能し、APIキーは単独で存在するのではなく、「開発者（Developer）」、「アプリ（App）」、そして「APIプロダクト（API Product）」という三つの要素の関係性の結果として生成される。この仕組み全体を理解することは、システムエンジニアを目指す上で、APIの提供側と利用側の双方の視点からセキュリティと運用を考える上で非常に重要である。

まず、全体的な流れを概観する。API提供者、つまりあなたがAPIを提供したい側だとすると、まずAPIプロダクトを公開する。次に、APIを利用したい開発者が開発者ポータルに登録する。開発者は自身が利用するアプリを作成し、そのアプリがアクセスを必要とするAPIプロダクトを選択する。すると、Apigeeはそのアプリに対して一意のAPIキーを生成する。開発者は、自身のアプリがAPIリクエストを行う際に、このAPIキーを含める。Apigeeは、リクエストに含まれるAPIキーが有効であるか、そしてそのキーが要求されたAPIプロダクトへのアクセス権限を持っているかをチェックし、問題なければリクエストを処理する。

次に、このセキュリティモデルを構成する主要な要素について詳しく見ていこう。

一つ目の要素は「APIプロダクト」である。APIプロダクトとは、API提供者が開発者に対して提供するAPIリソース（プロキシ）の束であり、ビジネス上および法的な利用単位となる。APIプロダクトは具体的に以下の内容を定義する。どのAPIプロキシ（およびその特定のパス）が含まれるか、1分、1時間、1日あたりに何回リクエストできるかというクォータ（利用制限）、そして、誰がアクセスできるかというアクセスポリシー（例えば、社内開発者向けか外部開発者向けか）である。例えば、ある会社が天気APIとニュースAPIを構築している場合、「無料ティア」というAPIプロダクトには天気APIとニュースAPIの一部が含まれ、1日100回、1分5回の利用制限がある。一方、「プレミアム天気」というAPIプロダクトには、天気APIの全エンドポイント（過去データなどプレミアムな機能も含む）が含まれ、1日10,000回、1分100回といったより多くの利用制限が設定される。このように、APIプロダクトは異なる利用シナリオやビジネスモデルに合わせてAPIの提供内容をパッケージ化する役割を果たす。

二つ目の要素は「開発者」である。開発者とは、あなたのAPIを利用する個人または企業を指す。彼らは通常、あなたの開発者ポータルを通じて登録される。開発者はアプリの所有者であり、連絡先情報（メールアドレスや氏名）を含むプロフィールを持っている。例えば、Jane Smithという開発者が「Cool Mobile Apps Inc.」という会社に所属し、APIを利用する主体となる。

三つ目の要素は「アプリ」である。アプリとは、開発者が作成する特定のプロジェクトやアプリケーションであり、あなたのAPIを呼び出す必要があるものを指す。一人の開発者が複数のアプリを持つことが可能である。例えば、Jane SmithがiOS用の天気ウィジェットアプリとAndroid用の天気ウィジェットアプリという、二つの異なるアプリを作成する場合がある。このアプリこそが、APIプロダクトへのアクセス権を付与される具体的なエンティティであり、アプリがAPIプロダクトへのアクセスを承認されると、ApigeeはそのアプリのためにAPIキーという認証情報を生成する。

四つ目の要素は「APIキー」である。APIキーは、特定のアプリのために生成される一意の文字列であり、パスワードのような秘密のトークンである。このAPIキーは、ApigeeへのすべてのAPIリクエストに含めて提示されなければならない。通常、これはリクエストヘッダー（例：x-apikey）またはクエリパラメータとして渡される。Apigeeは、このキーを検証することによって、以下の二つの主要なチェックを行う。まず、認証として、このキーがApigeeによって発行されたものであり、現在有効であるかを確認する。次に、認可として、このキーを所有するアプリが、要求されたAPIプロキシを含む特定のAPIプロダクトにアクセスする権限を持っているかを確認する。

これらの要素が連携する具体的な流れを見てみよう。まず、API提供者であるあなたが「CompanyX-Free-Tier」と「CompanyX-Premium-Weather」というAPIプロダクトを作成する。次に、開発者のJaneがあなたの開発者ポータルで登録し、アカウントを作成する。Janeはログイン後、自身のダッシュボードで「新しいアプリ」を作成し、「Weather-Widget-iOS」と名付ける。この際、彼女はそのアプリが「CompanyX-Free-Tier」プロダクトへのアクセスを必要とすることを選択する。API提供者であるあなたは、Janeのアプリのフリーティアへのアクセス要求を承認する（この承認は自動化されている場合もある）。承認されると、Janeの開発者ポータルダッシュボードには、「Weather-Widget-iOS」アプリの詳細ページに、生成された新しいAPIキーが表示される。このキーは自動的に「CompanyX-Free-Tier」プロダクトへのアクセスが承認されている。最後に、JaneのiOS開発者は、このAPIキーをアプリのコードに組み込む。アプリは、そのAPIキーを含めて、あなたのAPI（例：https://companyx.apigee.net/v1/weather/forecast?city=London）を呼び出す。

アプリからのリクエストがApigeeに到達すると、Apigeeはほぼ瞬時に以下の検証を実行する。まず、「APIキーが有効でアクティブであるか」を確認する。これは、「Weather-Widget-iOS」アプリに属するキーであるため、有効と判断される。次に、「このアプリがどのAPIプロダクトに対して承認されているか」を調べる。これは「CompanyX-Free-Tier」であることがわかる。その上で、「呼び出されたURLパス（/v1/weather/forecast）が、『CompanyX-Free-Tier』プロダクトに含まれるAPIプロキシによって提供されているか」を確認する。この場合、天気APIプロキシが含まれているため、これも有効である。最後に、「アプリが設定されたクォータ（1日100回）を超過していないか」をチェックする。今日まだ50回しか呼び出していない場合は、クォータ内であると判断される。これら全ての検証がパスした場合、リクエストはバックエンドの天気サービスに転送され、処理される。もしJaneが、「CompanyX-Free-Tier」プロダクトには含まれていないプレミアムなエンドポイント（例：/v1/weather/historical）を呼び出そうとした場合、Apigeeはそのリクエストをブロックし、403 Forbiddenエラーを返すだろう。これは、そのプロダクトが当該エンドポイントを含んでいないためである。

このApigeeのセキュリティモデルは、APIアクセスを管理し、収益化するための強力で柔軟性があり、かつ監査可能な方法を提供する。APIプロダクト、開発者、アプリ、APIキーという各要素が密接に連携することで、どの開発者のどのアプリがどのAPIにどれだけアクセスできるかをきめ細かく制御できるようになるのだ。この理解は、将来システムエンジニアとしてAPI関連の業務に携わる際に、設計、実装、運用、セキュリティといった多岐にわたる側面で役立つ基盤となるだろう。