Azure Front Door の背後のアプリを守る｜App Service 認証（Easy Auth）とオリジンロックの設計

WAFもDDoS保護も、オリジンのURLを直接叩かれた時点で素通りされます。

だから最初に決めるのは「オリジンを閉じられるか」です。閉じられないなら、通信元を2段で見分けることになります。

お客様専用のアプリを社外から使えるようにするとき、Azure Front Door で受けて Microsoft Entra ID でサインインさせる、という構成をよく採ります。素直な構成に見えますが、この2つを組み合わせたときだけ現れる詰まり方がいくつかあります。この記事では、オリジンを直接叩かせないための設定と、サインインの戻り先がずれる問題を中心に、設計と確認の勘所を整理します。

株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIプライベート）の支援を提供しているIT企業です。また、お客様専用のセキュアなAI基盤SaaSサービス「AIプライベート」シリーズとして、帳票の読み取りと入力業務を自動化する「AI-OCRプライベート」も提供しています。

公開面の守りとサインインは、別の設計として考える

この構成には、役割の違う2つの仕組みが入っています。混ぜて考えると、片方だけ効いている状態に気づけません。

Microsoft Learn は前者について「Azure Front Door の機能は、トラフィックが Front Door のみを通過する場合に最適です。Front Door 経由で送信されていないトラフィックをブロックするように配信元を構成する必要があります。そうしないと、トラフィックで Front Door の Web アプリケーション ファイアウォール、DDoS 保護、およびその他のセキュリティ機能のバイパスが発生する可能性があります」と書いています。Front Door を置いただけでは守りは完成しません。

オリジンロック：IPアドレスのフィルターだけでは足りない

まず「閉じられるか」を決める

通信元を見分ける話に入る前に、決めておくことがあります。そもそもオリジンの公開経路を閉じてしまえるなら、それがいちばん確実です。見分ける必要がなくなるからです。

Front Door には、オリジンへのトラフィックを制限する方法が複数あります。Learn の対応表では、Private Link は Premium レベルのみ、マネージドIDは Standard と Premium、IPアドレスのフィルターと Front Door 識別子はクラシックを含む全レベルで使えます。

このうち Private Link を使うと、経路そのものが閉じます。Learn は「Azure App Service と Azure Functions では、Private Link を使用すると、パブリック インターネット エンドポイント経由のアクセスが自動的に無効になります」としています。オリジンの公開URLが存在しなくなるので、ヘッダーを突き合わせる必要はありません。

ではなぜ、この記事で以降の話をするのか。Private Link を選べない事情があるからです。Premium を採れない場合、Private Link に対応しないオリジンを使う場合、あるいは既存の Standard の構成に後から手を入れる場合です。その場合は公開経路が残るので、「誰から来た通信か」を見分けるしかありません。以降はその前提で読んでください。

閉じられないときは、2段で見分ける

オリジンを Front Door 経由に限定する方法として、まず思いつくのが送信元IPの制限です。Front Door がオリジンへ接続するIPは AzureFrontDoor.Backend というサービスタグで表されるので、これを許可すればよさそうに見えます。

ところがこれだけでは不十分です。Learn の指摘は明快で、「他の Azure のお客様が同じ IP アドレスを使用しているため、IP アドレスのフィルター処理だけでは配信元へのトラフィックをセキュリティで保護するには不十分です」としています。サービスタグが表すのは「Front Door というサービスの出口」であって、「あなたの Front Door」ではありません。他社の Front Door から同じオリジンを叩けてしまいます。

そこで2段構えにします。Front Door はオリジンへの要求すべてに X-Azure-FDID というヘッダーを付け、そこに自分のプロファイル固有の識別子を入れます。オリジン側でこの値を検証すれば、「自分の Front Door から来た通信」だけを通せます。

App Service や Azure Functions なら、アクセス制限の機能でIPとヘッダーの両方を一度に指定できます。アプリ側のコードを変えずに済むのが利点です。

az webapp config access-restriction add \
  --resource-group <リソースグループ> --name <アプリ名> \
  --rule-name "Azure Front Door only" --action Allow --priority 200 \
  --service-tag AzureFrontDoor.Backend \
  --http-header x-azure-fdid=<Front Door ID>

ここで押さえておきたい性質が3つあります。

規則を1つ足すと、残りは暗黙的にすべて拒否になる

Learn の表現は「1 つ以上のエントリがある場合、リストの最後にあるものは暗黙的にすべて拒否になります」です。許可規則を1本書いた時点で、それ以外は403になります。作業中の自分の接続元を締め出さないよう、順番に注意してください。

ヘッダーのフィルターは4種類だけ

使えるのは X-Forwarded-For・X-Forwarded-Host・X-Azure-FDID・X-FD-HealthProbe の4つです。1つのヘッダー名につき最大8個の値をカンマ区切りで指定できます。またヘッダーのフィルターは規則そのものの後で評価され、両方の条件が成立してはじめて規則が適用されます。

IPアドレスは直接書かない

Learn は「Front Door の IP アドレス空間は定期的に変更されます。IP アドレスをハードコーディングする代わりに、AzureFrontDoor.Backend サービス タグを使用してください」と明記しています。あわせて、Azure の基盤サービスからの通信のために 168.63.129.16 も許可します。

Front Door 経由でサインインすると、戻り先がオリジン名になる

ここがこの構成でいちばん時間を溶かすところです。症状は「サインイン画面までは出るのに、認証後に戻ってきたところで403になる」という形で現れます。

原因は、App Service が自分の公開名を何で判断しているかにあります。Learn は「一部の構成では、App Service は Azure Front Door FQDN ではなく、その完全修飾ドメイン名 (FQDN) をリダイレクト URI として使用します。この構成により、クライアントが Azure Front Door ではなく App Service にリダイレクトされるときに問題が発生します」と説明しています。

つまり、認証後の戻り先が Front Door の公開ホスト名ではなく、オリジンのホスト名で組み立てられます。そしてオリジンは先ほどロックしてあるので、ブラウザがそこへ飛んだ瞬間に403で弾かれます。ロックが正しく効いているからこそ落ちるので、原因が見えにくくなります。

解決は、リバースプロキシが付けるヘッダーを見るように設定を変えることです。Learn は「これを変更するには、forwardProxy を Standard に設定し、Azure Front Door が設定した X-Forwarded-Host ヘッダーを App Service が考慮するようにします」としています。

そして、ここが最大の落とし穴です。Learn は続けてこう書いています。

「Azure portal を使用して forwardProxy 構成を変更することはできません。az restを使用する必要があります」

ポータルの認証設定をどれだけ眺めても、この項目は出てきません。設定画面に無いものを探して時間を使いがちなので、最初から知っておく価値があります。設定の実体は次の形です。

"httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

Application Gateway など他のリバースプロキシを使う場合は、参照するヘッダーが違うため別の設定値が要ります。

ヘルスプローブと、認証から外すパス

Front Door はオリジンが健全かどうかを定期的に確認します。このプローブはサインインを経ないので、アプリ全体に認証を必須にしていると認証画面へ誘導され、オリジンが不健全と判定されることがあります。

Learn は、全体に認証を掛ける方法について「この方法でのアクセスの制限は、アプリへのすべての呼び出しに適用されますが、これは、多くのシングルページ アプリケーションのように、一般公開されているホーム ページを必要とするアプリには適切でない場合があります。例外が必要な場合は、構成ファイルで除外されたパスを構成する必要があります」としています。プローブが叩くパスを、この除外に入れておきます。

もう1つ、認証の経路では Front Door のキャッシュを無効にします。Learn も「認証ワークフローの Azure Front Door キャッシュを無効にします」と明記しています。サインインの途中の応答が別の利用者に配られると、事故になります。

アプリ登録は、インフラの構成には含まれない

Easy Auth を Microsoft Entra ID で使うには、Entra ID 側のアプリ登録が要ります。ここで理解しておきたいのは、アプリ登録は Azure のリソースではなく Entra ID 側のオブジェクトなので、インフラの構成をコードで管理していても、その中には入らないということです。

この性質は、検証環境を本番と同じ形で作ったときに効いてきます。リソースは同じ構成で揃うのに、アプリ登録だけは付いてきません。APIのアクセス許可や管理者の同意が空のままになり、実際にサインインを試すまで誰も気づけません。環境を増やすときは、アプリ登録の中身を本番と並べて突き合わせる手順を用意しておくと確実です。

Learn も、環境ごとに分けることを推奨しています。「各アプリの登録には、独自のアクセス許可と同意が割り当てられるようにしてください。デプロイ スロットごとに個別のアプリ登録を使用することで、環境間でアクセス許可を共有することを回避します」。

あわせて、既定の挙動も押さえておきます。Learn は「組織内のユーザーに対して Microsoft ID プロバイダーを使用する場合は、既定の動作として、Microsoft Entra テナント内のどのユーザーでもアプリケーションのトークンを要求できます」としています。社内の特定の人だけに使わせたいなら、Entra ID 側でアプリケーションへの割り当てを制限する設定が別に必要です。サインインできること自体は、使ってよいことを意味しません。

動作確認：「302が返った」で終わらせない

この構成の確認では、素直に見えて役に立たない確認方法が2つあります。

1. 302が返ることは、そのパスが存在する証明にならない

認証が手前で受けるので、存在しないパスを叩いても302が返ります。新しく足したルートが動いているかを302の有無で判断すると、実際には配置できていないのに成功したと誤認します。見るべきは302の中身、つまり戻り先として組み立てられたURLが公開ホスト名を指しているかどうかです。前章の不具合は、ここまで見ていれば配置の直後に気づけます。

2. コマンドラインからの単純な要求と、ブラウザでは挙動が違う

Easy Auth にはクロスサイトリクエストフォージェリの対策が入っており、セッションCookieで認証された要求・既知のブラウザからの要求かどうか・Origin や Referer の有無といった条件を見て、自動的に拒否することがあります。このため、コマンドラインから素朴に叩いた結果と、ブラウザで操作した結果は一致しません。健全な配置を「失敗した」と誤判定しないよう、ブラウザ相当のヘッダーを付けて確認するか、実際にブラウザで確認します。

確認の順番としては、①公開ホスト名でトップページが応答する ②保護されたパスがサインインへ誘導され、その戻り先が公開ホスト名になっている ③オリジンのホスト名へ直接行くと403になる、の3点を見ます。③まで見てはじめて、オリジンロックが効いていると言えます。

プランの選択と、移行の期限

設計を始める前に、2つ確認しておきます。

1つ目は期限です。Learn には「Azure Front Door(classic)は2027年3月31日に廃止されます。サービスが終了するため、プロファイル作成、新規ドメインオンボーディング、管理証明書のサポートは終了しています」とあります。これから作るなら Standard か Premium を選びます。

2つ目は、レベルの選択です。冒頭で触れたとおり、Private Link で経路そのものを閉じられるのは Premium だけです。Standard で始めて後から閉じたくなると、レベルの変更と経路の作り直しが発生します。オリジンをどこまで閉じるかは最初に決めておくほうが安くつきます。閉域構成の全体像は、Azure OpenAI・AI Searchを閉域で使うとあわせてご検討ください。

弊社の支援

弊社は、お客様専用のAI基盤やアプリをAzure上に構築する形で、AIの業務活用を支援しています。この記事で扱った公開面の設計は、「社外から使えること」と「関係者だけが使えること」を両立させるための土台にあたります。

構成はコードで管理し、本番と同じ形の検証環境を用意して、反映前に確認できるようにしています。ただしこの記事で触れたとおり、アプリ登録のようにコードに含まれない要素もあります。そこは手順と確認項目で補います。権限の考え方はゼロトラストとはもあわせてご覧ください。

よくあるご質問

お客様専用のアプリをどこまで公開し、どこから先を関係者に限定するかは、ご要件によって変わります。現在の構成やご要望をお聞かせいただければ、設計案と進め方をご提案します。お問い合わせよりお気軽にご相談ください。

関連サービス・関連コラム

• クラウド導入支援（Azure）｜アセスメントから移行・運用まで一気通貫で伴走
• Azure OpenAI・AI Searchを閉域で使う｜Private Endpointと仮想ネットワークの設計
• ゼロトラストとは｜中小企業がMicrosoft 365で始めるセキュリティ
• AIエージェントに「権限」をどう与え、統制するか｜Entra Agent IDとCopilot Studioの権限モデル
• Azureのインフラ払い出しをセルフサービス化する｜IaCとDeployment Stacksで申請から変更管理まで統制する
• Application Insights Smart Detectionのアラート設定勘所｜検知した異常が誰にも届かない状態を防ぐ
• Azure Functions Flex Consumption のデプロイと運用｜従来プランとの違いと利用の注意点
• Azure Container Apps の料金を抑える設定｜使わない間は止めるか、常時起動にするかの判断基準
• Azureの構成をBicepで管理するときの落とし穴｜手作業の設定が消える理由と、本番に適用する前の確認
• Azure DevOps で本番環境へのデプロイを管理する｜承認・自動確認・切り戻しの組み立て方
• 稼働中のシステムを別のAzureリージョンへ移す｜引き継がれない設定と、切り替えの順序設計

まずは無料トライアルで、効果をご確認ください

「AIプライベート」は短期・低コストで試せます。帳票入力（AI-OCR）・電話対応（AI-Voice）・計画づくり（AI-Enhance）の自動化から、クラウド（Azure・Microsoft 365）・DXのご相談まで、お気軽にどうぞ。