NGINXとAzure Active DirectoryでAPIアクセスを保護

NGINX | 2022年10月06日

APIはアプリケーションの接続性において重要な役割を果たしますが、攻撃を受けやすいという側面もあります。従来のモノリシックアプリでは、保護すべきエントリーポイントは1つだけでした。マイクロサービスアーキテクチャでは、1つのアプリがAPIで接続された多数のマイクロサービスで構成されることが多く、各APIに数百ものエンドポイントが存在する場合もあります。そのため、APIの潜在的な攻撃対象領域は非常に広くなり、新しいAPIが追加されるたびにセキュリティ境界に新たなエントリーポイントが生じます。

APIを保護するための戦略は数多くあります。その中でも特に基本的なものの1つが、アクセス制御です。簡単に言えば、ユーザーの本人確認（認証、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を使用すると、クライアントはエンドユーザーまたはデバイスのアイデンティティを検証できます。これは、認証と認可の両方を含むアクセス制御の一部です。

認証は、ユーザーまたはデバイスが本人または正当なデバイスであることを検証します
認可は、認証済みのユーザーまたはデバイスがアクセスできる対象を決定します

OIDCにはさまざまな実装があり、このチュートリアルではAzure ADを使用します。また、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にログインします。

左側のメニューで［App registrations］をクリックします。

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

［新規登録］ボタンをクリックします。

図2：Azure ADアプリの登録

新しいアプリケーションを作成するには、名前とリダイレクトURIを入力し、［登録］ボタンをクリックします。このデモでは、Postmanを利用するため、Postman OIDCリダイレクトURIを使用します。

図3：新しいAzure ADアプリの作成

アプリが作成されたら、APIへのアクセスを許可するためのOAuthスコープを作成する必要があります。左側のメニューにある［Expose an API］リンクをクリックします。

図4：APIを公開

［スコープの追加］をクリックします。

図5：スコープの追加

デフォルトのApplication ID URIを使用するか、独自のApplication ID URIを作成して、［保存して続行］ボタンをクリックします。独自のApplication ID URIを作成する場合は、使用するドメインをAzure ADに登録する必要があります。

図6：Application ID URL

このデモでは、Microsoftの例に基づいてスコープを設定します。以下の情報をフォームに入力し、［Add scope］ボタンをクリックします。

スコープ名： Employees.Read.All
同意できるユーザー： 管理者とユーザー
管理者の同意の表示名： Employeeレコードへの読み取り専用アクセス
管理者の同意の説明： すべてのEmployeeデータへの読み取り専用アクセスを許可します。
ユーザーの同意の表示名： 自分のEmployeeレコードへの読み取り専用アクセス
ユーザーの同意の説明： 自分のEmployeeデータへの読み取り専用アクセスを許可します。

図7：スコープの追加

次に、クライアントアプリケーションを承認する必要があります。そのために、Client IDを取得します。左側のメニューで［Overview］をクリックし、［Application (client) ID］をコピーします。

図8：Application Client ID

もう一度［Expose an API］リンクをクリックし、［Add a client application］ボタンをクリックします。

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

［Client ID］フィールドにApplication Client IDを貼り付け、Application ID URIの横にあるチェックボックスをオンにします。次に、［Add application］ボタンをクリックします。

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

次に、このデモでは、認可コードフローで認可コードを使用するため、Postman用のクライアントシークレットが必要です。左側のメニューにある［Certificates & secrets］リンクをクリックし、［New client secret］ボタンをクリックします。

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

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

図12：シークレット名

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

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

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

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

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

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

図14：Azure ADテナントのWell-Knownエンドポイント

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

図15：Gateway Serviceのプロキシポリシー

次に、Azure ADテナントのJKWS URIを［URI Location］フィールドに貼り付け、［Add］ボタンをクリックします。

図16：JSON Web Tokenアサーションポリシー

［保存して公開］ボタンをクリックして、このポリシーをAPIゲートウェイクラスターに反映します。

図17：Service Gateway Policy

以上で完了です。API Connectivity Managerインスタンスは、設定済みのサービスゲートウェイでJWT Assertionを実行するように構成されました。

Postmanを使用したテスト

次に、設定をテストし、想定どおりに動作することを確認します。まず、Azure AD Applicationから以下の情報を取得してください。

アプリケーションのクライアントシークレット（先ほど保存したもの）
OAuthスコープ
OAuth認可エンドポイント
OAuthトークンエンドポイント

OAuthスコープを取得するには、Azureポータルを開き、アプリの登録ページに戻ります。次に、左側のメニューで［APIの公開］リンクをクリックし、スコープの［コピー］アイコンをクリックします。この値は数分後に使用するため、保存しておいてください。

図18：APIスコープ

OAuth認可エンドポイントとトークンエンドポイントを取得するには、左側のメニューで［Overview］リンクをクリックし、続いて［Endpoints］ボタンをクリックします。その後、認可エンドポイントとトークンエンドポイントのURIをコピーします。

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

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

Postmanを開き、［Environments］メニューをクリックします。次に、［Create Environment］リンクをクリックします。

図21：Postman Create Environment

環境に名前を付け、前の手順で保存した値を使用して6つの変数を［Initial Value］列と［Current Value］列に追加し、［Save］ボタンをクリックします。

client_id：Azure ADアプリケーションのクライアントID
client_secret:Azure AD Applicationのクライアントシークレット
auth_url：Azure ADテナントのOAuth認可URL
token_url：Azure ADテナントのOAuthトークンURL
tenant_id：Azure ADディレクトリ（テナント）ID
scope：Application ID URLを含むAzure AD ApplicationのAPIスコープ

図22：Postman環境変数

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

右上で環境を「ACM」に変更します
アドレスバーにAPI URLを入力します
［Auth］タブをクリックします
Change the TypeをOAuth 2.0に変更します
Auth設定を下にスクロールし、次の変数を設定します。
認証URL：{{auth_url}}
アクセストークンURL: {{token_url}}
クライアントID： {{client_id}}
クライアントシークレット： {{client_secret}}
［Get New Access Token］ボタンをクリックします

図23：Postmanリクエスト

図24：Postmanの認証設定

ブラウザーウィンドウが開き、Azure ADの資格情報を使用してログインするよう求められます。認証に成功するとPostmanにリダイレクトされ、次のウィンドウが表示されます。［Use Token］ボタンをクリックします。

図25：Postmanでトークンを使用

OAuthアクセストークンを取得したので、API呼び出しを実行できます。［Save］ボタンをクリックしてから、［Send］ボタンをクリックします。

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

図26：Postmanで成功したリクエスト

まとめ

これで、API Connectivity ManagerがAzure AD OAuthアクセストークンを使用してAPIを保護するようになりました。次のステップは、OAuthスコープを追加し、API Connectivity ManagerのAPIゲートウェイクラスターで、それらのスコープを保護対象のAPIに渡すよう設定することです。ただし、これについては別の記事でご紹介します。