1. 概要

クラウドリソースへの無制限なアクセスは、セキュリティ上推奨されていません。セキュリティ強化の方法として、アクセス元IPで制限をする、認証を付与するなどの方法があります。
一方、ハイブリッド勤務がそれなりに普及してきており、身元が保証されるオフィスからのアクセスはIPで制限し、それ以外の場所からアクセスする時のみ認証をするなど、複数のアクセス制御の方法を組み合わせたいケースがあります。

この要求をAWSで実現する方法を以前ご紹介しました。
Amazon CloudFrontとAWS Lambda@Edgeを用いてIPアドレスに基づく認証を構築してみた

今回は、同様のことをAzureで実現できないか、Azure Front DoorとAzure Web Application Firewall(以下、Azure WAFと表記)を用いて、特定のIPアドレス以外からのアクセスに対してMicrosoft Entra ID認証を要求する方法を試してみました。

2. 試作した構成

試作した構成を下記に示します。

図1：Front DoorとWAFを用いてEntra ID認証を行う構成

上記の構成に示されているコンポーネントを説明します。

Azure Front Door： Front Doorはコンテンツ配信ネットワークサービスです。Azure WAFと連携するためのフロントエンドとして用います。
Azure WAF: Azure WAFはアプリケーション層の通信を監視するセキュリティサービスです。WAFルールを定義して通信を制御できます。ここでは、送信元IPアドレスが許可されたものであれば通信を許可し、それ以外のIPアドレスであればEntra ID認証を要求するようにルールを定義します。
Entra ID: Microsoft製品に対する認証基盤です。アイデンティティベースの認証を行います。
Azure VM: Azureのコンピューティングリソースです。アクセス先のVNet内のリソースの役割です。他のサービスでも構いません。

3. Azure WAFおよびEntra IDを用いるメリット

Azure WAFを用いたIP制限は、以下のメリットが考えられます。

Azureネットワークセキュリティグループと同様に、ルールベースのアクセス制御が可能。
ルールにマッチ、アンマッチした時に、通信のリダイレクト処理をカスタマイズできる。

Entra IDを用いた認証は、以下のメリットが考えられます。

ユーザー管理を⼀元化できる。
シングルサインオン、監査、条件付きアクセス、およびロールベースのアクセス制御など、豊富な機能を利用可能。

4. 構築手順

構築手順を説明します。

VNetおよびVNet内のリソースを構築する
Azure Front Doorを作成する
Microsoft Entra IDにアプリケーションを登録する
Azure WAFを構築しWAFポリシーを作成する
動作確認をする

ステップ1：VNetおよびVNet内のリソースを構築する

アクセス先のVNetおよびVNet内のリソースを作成します。VNet内のリソースの構成は自由です。
上記構成では、Azure VM上でWebアプリケーションを実行することを想定しています。

ステップ2：Azure Front Doorを作成する

Azure CLIを使用してAzure Front Doorを作成します。手順は以下です。今回は動作確認なのでSKUはStandardとしました。

Azure Front Door プロファイルを作成する (sku パラメーター値はStandard_AzureFrontDoorを選択)
エンドポイントを追加する
配信元グループを作成する
配信元グループに配信元を追加する
ルートを追加する

ステップ3：Microsoft Entra ID にアプリケーションを登録する

まず、Microsoft Entra ID に、ステップ1で作成した認証をかけたいWebアプリケーションを登録します。
設定手順はアプリケーションを Microsoft Entra ID に登録するを参考にしました。
ここで、「リダイレクトURI(Redirect URL)」に、ステップ1で作成したVNet内のリソース、すなわちAzure VM上のWebアプリケーションのURLを設定します。

次に、ステップ4で作成するWAFポリシーのリダイレクトする認証先URLを取得します。
上記で登録したアプリの概要ページを開いて「エンドポイント」を表示し、「OAuth 2.0 承認エンドポイント (v2)」のURLをコピーします。

図2：リダイレクトする認証先のエンドポイント

コピーしたURLに以下のクエリパラメータを追加します。

client_id=[登録したアプリケーション (クライアント) ID]
response_type=code　　※認証コードを要求。認証コードは、後でトークンと交換するために使用
redirect_uri=[設定したリダイレクトID]　　※グイン後にユーザーがリダイレクトされるURLを指定
response_mode=query
scope=openid%20profile%20email　　※OpenID Connectのスコープ（openid、profile、email）を要求

最終的に、WAFポリシーに設定するリダイレクトURLは以下となります。

https://login.microsoftonline.com/[テナントID]/oauth2/v2.0/authorize?client_id=[登録したアプリケーション (クライアント) ID]&response_type=code&redirect_uri=[設定したリダイレクトID]&response_mode=query&scope=openid%20profile%20email

ステップ4：Azure WAFを構築しWAFポリシーを作成する

Azure Front Door⽤のWAFポリシーを作成します。動作確認なので、SKUはStandardとします。

セキュリティポリシーを適用します。
ここで、domainsにはステップ2で作成したAzure Front DoorのIDを、waf-policyには上記で作成したWAFポリシーのIDを設定します。

Azure Portalで、設定 > ポリシー設定に移動し、ステップ3で取得したリダイレクトURLを⼊⼒します。ブロック応答のステータスコードフィールド（例: 403 や 401）は任意項⽬です。

図3：ポリシー設定

WAFに受信トラフィックをフィルタリングするルールを以下のように作成します。

# 通信を許可するルールを作成
az network front-door waf-policy rule create \
 --action Allow \
 --name whitelist-ip-rule \
 --resource-group [リソースグループ名] \
 --policy-name [WAFポリシー名] \
 --priority 150 \
 --rule-type MatchRule \
 --disabled false \
 --defer

# 許可ルールにIP判定条件を登録
# [許可するIPリスト]のIPと一致するものは通信を許可する
az network front-door waf-policy rule match-condition add \
 --name whitelist-ip-rule \
 --resource-group [リソースグループ名] \
 --policy-name [WAFポリシー名] \
 --match-variable RemoteAddr \
 --operator IPMatch \
 --values [許可するIPリスト(スペース区切り)] \
 --negate false 

# 通信をリダイレクトするルールを作成
az network front-door waf-policy rule create \
 --action Redirect \
 --name redirect-rule \
 --resource-group [リソースグループ名] \
 --policy-name [WAFポリシー名] \
 --priority 300 \
 --rule-type MatchRule \
 --disabled false \
 --defer

# リダイレクトルールにIP判定条件を登録
# [許可するIPリスト]のIPと一致しないものはEntra IDにリダイレクトする
az network front-door waf-policy rule match-condition add \
 --name redirect-rule \
 --resource-group [リソースグループ名] \
 --policy-name [WAFポリシー名] \
 --match-variable RemoteAddr \
 --operator IPMatch \
 --values [許可するIPリスト(スペース区切り)]  \
 --negate true

ステップ5：動作確認をする

動作確認のために、認証無しでアクセスを許可されたIPアドレスと許可されていないIPアドレスのそれぞれから、Azure Front Doorにアクセスします。
許可されたIPアドレスに対しては認証なしでコンテンツに直接アクセスできることを確認します。
許可されていないIPアドレスに対してのみMicrosoft Entra ID認証が実行されることを確認します。

クライアントのIPアドレスが許可されたIPリストに含まれている場合: クライアントは認証無しで、ウェブサイトに直接アクセスできます。
クライアントのIPアドレスが許可されたIPリストに含まれていない場合: クライアントはMicrosoft Entra IDにリダイレクトして認証を求められます。
- 認証に成功した場合: クライアントはウェブサイトに正常にアクセスできます。
- 認証に失敗した場合： 401 Unauthorizedエラーが返却されます。

5. まとめ

アクセス元のIPアドレスで認証有無を選択する方法として、Azure Front DoorとAzure WAFを用いて、特定のIPアドレス以外にはEntra ID認証を実施する方法を試しました。Microsoft Entra IDを用いた認証の応用例としてもご参考になれば幸いです。