API ポリシーを使用してアクセスを管理する
学習の目的
この単元を完了すると、次のことができるようになります。
- API 管理でのアクセス制御ポリシーの目的を説明する。
- Anypoint API Manager で利用できる主なアクセスポリシーの種類を特定する。
- ユースケースに基づいて、特定のアクセスポリシーを適用する場合とその理由を説明する。
アクセス制御ポリシー
すべての API が、あらゆる利用者を対象としているわけではありません。社内チーム向けに構築される API もあれば、信頼できるパートナー向け、または一般公開向けの API もあります。ただし、公開 API であっても制限は必要です。そこで役立つのが、アクセス制御ポリシーです。
アクセス制御ポリシーは、誰がどのような条件で API をコールできるかを定義するルールです。これらのポリシーは Anypoint API Manager でプロキシレベルで適用されるため、チームはバックエンドシステムを変更することなくアクセスを管理できます。
これらは、いくつかの重要な方法で API の保護に役立ちます。
-
認証: 承認済みアプリケーションまたはユーザーのみが要求を行えるようにする
-
レート制御: システムパフォーマンスを維持するために、API をコールできる頻度を制限する
-
要求の検証: 受信要求が特定の要件を満たしていることを確認する
アクセスポリシーにより、API オーナーは、自社のサービスが意図したとおりに使用されていることを確信できます。機密データの保護、トラフィック急増の回避、または単純な使用制限の適用など、いずれの場合でも、ポリシーを使用すれば一貫した方法で大規模に対応できます。
Anypoint API Manager のアクセスポリシーの種類
Anypoint API Manager では、チームがトラフィックを効果的に保護して管理できるよう、さまざまな種類のポリシーが提供されています。これらのポリシーは API プロキシに適用されるため、バックエンドのロジックを変更することなく、簡単に設定や更新を行うことができます。
利用可能な主なポリシーの種類は次のとおりです。
-
クライアント ID 適用: API にアクセスするために、有効なクライアント ID とクライアントシークレットの提供をアプリケーションに要求します。これは最も一般的なポリシーの 1 つで、消費側アプリケーションの登録と認証によく使用されます。
-
OAuth 2.0 アクセストークン適用: 外部の OAuth 2.0 プロバイダーに対してトークンの検証を適用します。これは通常、API がより広範な承認システムの一部である場合や、委任アクセスのために ID プロバイダーと統合する場合に使用されます。
-
レート制限: クライアントが一定期間内に実行できる要求数を制限します (例: 1 時間あたり 1,000 要求)。過剰な使用を防ぎ、システムの安定性を確保するのに役立ちます。
-
スパイク制御: バックエンドサービスに過剰な負荷がかかる可能性のあるトラフィックの急増を防ぐことに重点を置く。短い時間枠内で過剰な要求を一時的に遅延または拒否することで、トラフィックを平滑化します。
各ポリシーにはそれぞれ異なる目的があり、必要に応じて組み合わせることができます。たとえば、ある API では、不正アクセスとリソースの枯渇を防ぐために、認証とレート制限の両方を適用することがあります。適切な組み合わせのポリシーを適用することで、チームは信頼できるコンシューマーに対するパフォーマンスと可用性を維持しながら、大規模に API を保護できます。
プロキシレベルでのポリシーの動作
Anypoint Platform では、アクセスポリシーは、トラフィックがバックエンドサービスに到達するかなり前の段階で、プロキシで適用されます。プロキシはフィルターとして機能し、各要求を有効なポリシーと照合して、その要求を許可、ブロック、または変更するかどうかを判断します。
これはリアルタイムで行われます。たとえば、レート制限ポリシーが設定されている場合、プロキシは各クライアントからの要求数を数え、バックエンドサービスに要求を転送する前に制限を適用します。OAuth 2.0 ポリシーが有効になっている場合、プロキシはコールを渡す前にトークンを確認します。
ポリシーのロジックは、API コード自体ではなく、ゲートウェイによって処理されます。つまり、ポリシーの更新は API Manager で一元的に行うことができ、すべての環境に即座に反映されます。
このアプローチにより、ポリシー適用の一貫性、拡張性、アプリケーション層からの分離が保たれます。これは、本番環境で API を管理するうえで重要です。
特定のポリシーを使用する場合とその理由
開発者は、対象者、ユースケース、機密性のレベルに基づいて、使用するポリシーを選択します。ポリシーの決定に影響する一般的なシナリオには、次のようなものがあります。
-
社内専用 API: API が社内システムでのみ使用される場合、開発者は厳格な認証を省略し、代わりに IP フィルタリングと要求の検証を採用することがあります。ポリシーの重点は、信頼性の確保と偶発的な誤使用の回避に置かれます。
-
パートナー向け API: 信頼できるパートナーと API を共有する場合、クライアント ID 適用が不可欠になります。これにより、誰が API をコールしているかを認証し、アプリケーションごとの使用状況を追跡できます。また、コンシューマー間で公平な使用を保証するために、レート制限が使用されることもあります。
-
公開 API: 一般公開される API には、強力な境界が必要です。ユーザーの確認には OAuth 2.0 がよく使用され、パフォーマンスの保護にはレート制限とスパイク制御が役立ちます。監査要件を満たすために、ログ記録やコンプライアンスに関するポリシーを適用するチームもあります。
-
トラフィックの多いシステムまたは重要なシステム: コアビジネスプロセスを支える API や、大規模なユーザーベースにサービスを提供する API では、パフォーマンスの保護が重要です。スパイク制御は急激な要求の増加を平滑化し、レート制限はバックエンドシステムへの過負荷を防ぎます。
ポリシーの選択は、優れた API 設計の重要な要素です。適切な組み合わせにより、コンシューマーが効果的に利用できる状態を保ちながら、サービスを保護します。
MUA での活用例: フライトデータ API へのアクセス制御
Mule United Airport のチームは、新しいフライトデータ API の本番稼働準備がほぼ整いました。この API はリアルタイムの発着案内板を支え、今後はモバイルアプリケーションのサポートや、航空会社パートナーとの最新情報の共有にも対応する予定です。
稼働開始前に、チームは API Manager を使用して適切なアクセスポリシーを適用します。
- 公開ダッシュボードには、1 日を通して最新情報を確認する数千人の旅行者からのトラフィックに対応するために、レート制限を設定します。
- パートナーアプリケーションには、登録済みアプリケーションのみが詳細なフライトデータにアクセスできるように、クライアント ID 適用を設定します。
- さらなる保護のために、悪天候やシステムアラート発生時のトラフィックの急増を平滑化するスパイク制御を有効にします。
これらのポリシーを設定することで、チームはバックエンドサービスに変更を加えることなく、さまざまなユースケースにわたってアクセスを管理できます。API Manager を通じてすべてのトラフィックを監視し、必要に応じて調整を行います。十分に検討したアクセス制御をプロキシレベルで適用することで、MUA はフライトデータ API を保護し、ユーザーに信頼性の高いエクスペリエンスを提供し、トラフィックが増加しても制御を維持できます。
API の保護は、出発点にすぎません。次の単元では、Anypoint Platform がトラフィックの監視、問題の検出、本番環境での高いパフォーマンスの維持にどのように役立ち、本番稼働後も長期にわたって API の信頼性を保てるかについて見ていきます。