セキュアなAPIアクセスを実現／NGINXとAzure Active Directory

APIはアプリケーションの接続性において重要な役割を果たす一方で、攻撃され易いという脆弱な面があります。これまで、モノリシックアプリでは、セキュリティを対策すべきエントリポイントは1つしかありませんでした。マイクロサービスアーキテクチャでは、1つのアプリがAPIを介して接続された多くのマイクロサービスで構成され、これらのAPIのそれぞれに数百のエンドポイントが存在する場合があります。このため、APIの潜在的な攻撃対象は膨大になり、新しいAPIが増えるたびに、セキュリティ境界にエントリポイントがうまれます。

APIを保護するための戦略はたくさんあります。最も基本的なものの1つはアクセス制御です。簡単に言えば、ユーザのIDを確認（認証、またはAuthN）し、特定のリソースにアクセス可能であることを確認（認可、またはAuthZ）する必要があります。OpenID Connect (OIDC) の実装は、APIで使用される最も一般的なアクセス制御アプローチの1つです。F5 NGINX Management Suiteの一部であるAPI Connectivity Managerを使用すると、数分で起動し、実行することが可能です。

このチュートリアルでは、API Connectivity ManagerとAzure Active Directory（Azure AD）を使用してJSON Web Token（JWT）検証を設定し、OIDCワークフローの認可部分を実行する方法を学習します。

OpenID Connectとは

OpenID Connect (OIDC)とは、OAuth 2.0プロトコルの上に構築されたアイデンティティプロトコルです。OIDCにより、クライアントはエンドユーザまたはデバイスのIDを確認できます。これは、次に示す認証と認可の両方を含むアクセス制御の一部です。

• 認証は、ユーザまたはデバイスが本人であることを確認する
• 認可は、検証済みのユーザまたはデバイスがアクセスできるものを決定する

このチュートリアルで使用するAzure ADなど、OIDCにはさまざまな実装があります。また、F5 BIG-IP Access Policy Manager (APM)、Okta、Auth0、Ping Identityなど、他のOIDCソリューションもAPI Connectivity Managerで使用することが可能です。

はじめるために必要なもの

次の前提条件を満たしていることを確認します。

• API Connectivity Managerが環境にインストールされ、構成されている
• アクティブなMicrosoft Azureアカウントである
• RESTクライアント（このチュートリアルではPostmanを使用）である

API Connectivity Managerへのアクセスが必要な場合は、NGINX Management Suiteの30日間無料トライアル版にサインアップします。

Azure ADアプリケーションの作成

ブラウザを開き、Azure Portal（Azureポータル）にログインします。

左側メニューの「App registrations（App登録）」をクリックします。

図１：Azure ADポータルのホームページ

「New registration（新規登録）」ボタンをクリックします。

図２：Azure ADアプリの登録

新しいアプリケーションを作成するには、name（名前）とredirect URI（リダイレクトURI）を入力し、「Register（登録）」ボタンをクリックします。このデモではPostmanを使用するので、Postman OIDCリダイレクトURIを使うことになります。

図３：Azure ADアプリの新規作成

アプリが作成されたので、APIへのアクセスを提供するOAuthスコープを作成する必要があります。 左側メニューの「Expose an API（APIを公開） 」リンクをクリックします。

図4：APIの公開

「Add a scope（スコープの追加）」をクリックします。

図5：スコープの追加

デフォルトのアプリケーションID URIをそのまま使用するか、独自のURIを作成して、「Save and continue（保存して続行）」 ボタンをクリックします。独自のアプリケーション ID URI を作成する場合は、希望のドメインをAzure ADに登録する必要があります。

図6：アプリケーションIDのURL

このデモでは、スコープはMicrosoftのサンプルに基づいています。フォームに次の情報を入力し、「Add scope（スコープの追加）」ボタンをクリックします。

Scope name（スコープ名）： Employees.Read.All（従業員。読み取り。全員）
Who can consent?（誰が同意できますか？）： 管理者とユーザ
Admin consent display name（管理者同意表示名）： Read-only access to Employee records（従業員レコードへの読み取り専用アクセス）
Admin consent description（管理者の同意に関する説明）： Allow read-only access to all Employee （dataすべての従業員データへの読み取り専用アクセスを許可する）
User consent display name（ユーザ同意表示名）： Read-only access to your Employee records（従業員レコードへの読み取り専用アクセス）
User consent description（ユーザ同意に関する説明）： Allow read-only access to your Employee data（従業員データへの読み取り専用アクセスを許可する）

図7：スコープの追加

次に、クライアントアプリケーションを承認する必要があります。これを行うには、クライアントIDを取得します。左側メニューの「Overview（概要）」リンクをクリックし、「Application (client) ID（アプリケーション（クライアント）ID）」をコピーします。

図8：アプリケーションクライアントID

「Expose an API（APIの公開）」リンクを再びクリックし、 「Add a client application（クライアントアプリケーションの追加）」ボタンをクリックします。

図9：クライアントアプリケーションの追加

「Client ID（クライアントID）」フィールドにアプリケーションクライアントIDを貼り付け、アプリケーションID URIの横にあるチェックボックスをオンにします。その後、「Add application（アプリケーションの追加）」ボタンをクリックします。

図10：クライアントアプリケーションの追加

次に、このデモでは、Authorization Code Flowで認可コードを活用するため、Postmanにはクライアントシークレットが必要となります。左側メニューの「Certificates & secrets（証明書とシークレット）」リンクをクリックし、「New client secret（新しいクライアントシークレット）」ボタンをクリックします。

図11：新しいクライアントシークレット

シークレットに名前を付け、有効期限はデフォルトのままにしておきます。

図12：シークレットの名前

次は、クライアントのシークレットをコピーして、パスワードボールトに保存し、後で使用できるようにします。

図13：クライアントシークレット

API Connectivity ManagerでのJWTアサーションの設定

Azure ADアプリケーションの設定を完了したら、API Connectivity ManagerでAPIゲートウェイクラスタを設定して、定義したサービスに対してJSON Web Token Assertionを実行できるようになります。この手順では、Azure ADテナントのJSON Web Key (JWK)セットのURIを決定する必要があります。

JWKS URIは、Azure ADテナントの既知のエンドポイントから取得できます：
https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration

このページには、jwks_uriキーを含むJSONペイロードが表示されます。後で、この値をコピーする必要があります。

図14：Azure ADテナントの既知のエンドポイント

JWKS URIを取得したら、API Connectivity Managerコンソールを開き、サービスプロキシの設定に移動します。「Add Policy（ポリシーの追加）」をクリックし、JSON Web Token Assertionに関するポリシーを追加します。

図15：Gateway Service Proxyに関するポリシー

次に、Azure ADテナントのJKWS URIを「URI Location（URIの場所）」フィールドに貼り付け、その後、「Add（追加）」ボタンをクリックします。

図16：JSON Webトークンアサーションに関するポリシー

「Save & Publish（保存して公開）」ボタンをクリックし、このポリシーをAPIゲートウェイクラスタにプッシュします。

図17：サービスゲートウェイに関するポリシー

以上です！これで、API Connectivity Managerのインスタンスは、設定されたサービスゲートウェイでJWTアサーションを実行するように設定されました。

Postmanによるテスト

では、ここからはいよいよセットアップをテストして、期待通りの動作であるかを確認しましょう。その前に、まずは、次のようなAzure ADアプリケーションから取得する必要があるものがいくつかあります。

• アプリケーションのクライアントシークレット（以前に保存済み）
• OAuthスコープ
• OAuth認可エンドポイント
• OAuthトークンエンドポイント

OAuthスコープを取得するには、Azureポータルを開き、アプリの登録ページに戻ります。次に、左側メニューの「Expose an API（APIを公開）」リンクをクリックし、「Copy（コピー）」のマークをクリックします。この値を保存し、後ほどすぐに使用できるようにします。

図18：APIのスコープ

OAuth認可とトークンのエンドポイントを取得するには、左側メニューの「Overview（概要）」リンクをクリックし、次に「Endpoints（エンドポイント）」ボタンをクリックします。その後、認可とトークンのエンドポイントURIをコピーします。

図19：Azure ADアプリケーションエンドポイント

図20：Azure ADアプリケーションエンドポイントのURL

Postmanを開き 「Environments（環境）」メニューをクリックします。その後、「Create Environment（環境の作成）」リンクをクリックします。

図21：Postmanの作成環境

環境に名前を付け、（前の手順で保存した）値を持つ6つの変数を「Initial Value(初期値)」列と 「Current Value（現行値）」列に追加し 「Save（保存）」ボタンをクリックします。

• client_id: Azure ADアプリケーションのクライアントID
• client_secret: Azure ADアプリケーションのクライアントシークレット
• auth_url: Azure ADテナントのOAuth認可URL
• token_url: Azure ADテナントのOAuthトークンURL
• tenant_id: Azure ADディレクトリ (テナント) ID
• scope: アプリケーションID URLを持つAzure ADアプリケーションのAPIスコープ

図22：Postmanの環境変数

Postmanで新しいタブを開き、次の手順を実行します。

• 右上の「Environment （環境）」をACMに変更する
• アドレスバーにAPI URLを追加する
• 「Auth」タブをクリックする
• 「Type（タイプ）」をOAuth 2.0に変更する
• Authの設定を下にスクロールし、次の変数を設定する
  • Auth URL: {{auth_url}}
  • Access Token URL: {{token_url}}
  • Client ID: {{client_id}}
  • Client Secret: {{client_secret}}
• 「Get New Access Token（新しいアクセストークンの取得）」ボタンをクリックする

図23：Postmanのリクエスト

図24：Postman Authの設定

ブラウザーウィンドウが開き、Azure ADのクレデンシャルを使ってログインするように求められます。認証に成功すると、Postmanにリダイレクトされ、次のウィンドウが表示されます。「Use Token（トークンの使用）」ボタンをクリックします。

図25：Postmanのトークン使用

これでOAuthアクセストークンが取得できたので、いよいよAPI呼び出しを行います。「Save（保存）」ボタンをクリックした後、「Send（送信）」ボタンをクリックします。

すべてが正しく設定されている場合は、200 OKレスポンスが表示されます。

図26：Postmanのリクエスト成功

APIアクセス制御の重要性とその解決策

APIアクセスとは、ユーザーが特定のリソースに接続し、操作するための手段を指します。しかし、異なるユーザーがアクセスする際には、適切な制御が求められます。APIゲートウェイは、このアクセス制限を実現するためのツールとして機能し、セキュリティを強化します。特に、異なる言語やコンテンツを扱う場合、アクセス制御は重要です。APIアクセス制限を適切に行うことで、セキュリティの問題を未然に防ぎ、ユーザーに安全な環境を提供できます。NGINXとAzure Active Directoryを組み合わせることで、これらの課題を解決し、よりセキュアなAPIアクセスを実現することが可能です。

結論

これで、API Connectivity ManagerがAzure AD OAuth Accessトークンを使用してAPIを保護できることが可能になりました。次の手順では、OAuthスコープを追加し、API Connectivity ManagerでAPIゲートウェイクラスタを設定し、これらのスコープを保護されたAPIに渡すことですが、これに関しては別の記事で説明します!

今すぐ始めましょう

NGINX Management Suiteの30日間無償トライアル版をお試しください。これには、API Connectivity ManagerとInstance Managerが含まれています。

A version of this post first appeared on codygreen.com. It is edited and reprinted here with permission from the author.