MENU

Azure FirewallのHTTPヘッダー挿入がHTTPSで動かない原因｜SKUとTLS条件

Azure

Azure FirewallでHTTPヘッダー挿入を設定したのに、HTTPS通信へ反映されないことがあります。最初に確認すべきなのは、Azure FirewallのSKUとTLS Inspectionの有無です。

結論として、HTTPSのリクエストヘッダーを追加・上書きできるのは、Azure Firewall Premiumで対象通信をTLS Inspectionにより復号している場合だけです。StandardとBasicはHTTP通信に限ってヘッダー挿入を利用できます。Premiumを使っていても、アプリケーションルールでTLS Inspectionが有効になっていなければ、HTTPS内部のヘッダーは変更されません。

この記事では、Azure FirewallのHTTPヘッダー挿入がHTTPSで動かない原因、SKUごとの対応範囲、TLS証明書の条件、Microsoft Entraテナント制限へ利用するときの注意点、確認手順を具体的に解説します。

目次

Azure FirewallでHTTPヘッダーを挿入する方法とHTTPSの制限

Azure FirewallのHTTPヘッダー挿入は、アプリケーションルールに一致したWebリクエストへ、指定したHTTPリクエストヘッダーを追加または上書きする機能です。

2026年7月に一般提供され、Azure portal、Azure CLI、PowerShell、REST API、Terraform、Azure Firewall PolicyのDraft＋Deployから構成できます。Microsoft Entraテナント制限、Azure Virtual Desktop、VDI、SaaSアクセス制御、バックエンド連携、企業のインターネット出口制御などが主な用途として挙げられています。

重要なのは、HTTPとHTTPSではAzure Firewallが確認できる範囲が異なることです。

HTTPではリクエストヘッダーが平文であるため、Basic、Standard、Premiumのいずれでも挿入できます。一方、HTTPSではリクエストヘッダーを含むHTTP通信全体が暗号化されるため、TLS通信をいったん復号しなければヘッダーを変更できません。

SKUごとの対応範囲

対応関係を整理すると、次のようになります。(Microsoft Learn)

Azure Firewallの状態HTTPへの挿入HTTPSへの挿入条件
Basic可能不可HTTP通信のみ
Standard可能不可HTTP通信のみ
Premium、TLS Inspection無効可能不可HTTPSを復号できない
Premium、TLS Inspection有効可能可能対象アプリケーションルールでもTLS Inspectionを有効化
Premium、TLS Inspection対象外の通信可能不可復号されないHTTPSには挿入できない

StandardやBasicでも、HTTPSをFQDNベースで許可するアプリケーションルールは作成できます。しかし、HTTPSを許可できることと、HTTPS内部のHTTPヘッダーを書き換えられることは別です。

StandardやBasicはTLSのSNIなどを利用して宛先を判定できますが、暗号化されたHTTPリクエストの中身までは復号しません。そのため、アプリケーションルールのプロトコルを単にHTTPS:443へ変更しても、ヘッダー挿入は機能しません。(Microsoft Learn)

HTTPヘッダーは追加だけでなく上書きもできる

Azure FirewallのHTTPヘッダー挿入では、対象ヘッダーがリクエストに存在しない場合は新しく追加され、同名のヘッダーがすでに存在する場合は設定した値で上書きされます。対象となるのはリクエストヘッダーであり、Webサーバーから返されるレスポンスヘッダーを変更する機能ではありません。

動作を整理すると、次のとおりです。

元のリクエストAzure Firewallの設定転送されるリクエスト
対象ヘッダーなしX-Organization: contosoヘッダーを追加
X-Organization: unknownX-Organization: contosocontosoへ上書き
複数のカスタムヘッダーを設定複数の名前と値を指定各ヘッダーを追加または上書き
予約済みヘッダーを指定Authorizationなど設定不可

上書きできることは、セキュリティ用途で特に重要です。たとえば、利用者が任意のテナント制限ヘッダーを送信していたとしても、Azure Firewall側で組織が指定した値へ置き換える設計にできます。

ただし、バックエンドサービスでカスタムヘッダーをアクセス制御に使う場合、ヘッダーだけを唯一の認証手段にしてはいけません。バックエンドへの直接アクセスを禁止し、Azure Firewallを必ず経由するルート、TLS、IDベース認証などと組み合わせます。

HTTPSでHTTPヘッダーを挿入するための条件

HTTPSで利用する場合は、次の条件をすべて満たす必要があります。

Azure FirewallとFirewall PolicyをPremiumにする

TLS InspectionはPremiumの機能です。Azure Firewall本体だけでなく、関連付けるFirewall PolicyもPremiumにそろえる必要があります。PremiumのファイアウォールにはPremiumポリシーを関連付けます。(Microsoft Learn)

既存のStandard環境をPremiumへ変更した場合は、ファイアウォールだけでなく、ポリシーのSKUや関連付け状態も確認してください。

TLS Inspection用のCA証明書を設定する

Azure Firewall PremiumはHTTPS通信をいったん終端し、内容を確認したあと、宛先WebサーバーとのTLS通信を再確立します。つまり、クライアントとAzure Firewall、Azure FirewallとWebサーバーの間に、それぞれTLS接続が作られます。(Microsoft Learn)

この処理には、Azure Key Vaultへ格納した有効な中間CA証明書が必要です。また、Azure Firewallが生成してクライアントへ提示する証明書を信頼できるように、端末やワークロードへ組織のルートCAまたは中間CA証明書を配布します。(Microsoft Learn)

主な確認項目は次のとおりです。

確認対象確認内容
Azure Key VaultTLS Inspection用の中間CA証明書がシークレットとして保存されているか
マネージドIDAzure FirewallがKey Vaultの証明書シークレットを取得できるか
Firewall PolicyTLS Inspectionが有効か
クライアント端末組織のCA証明書を信頼しているか
証明書の有効期限証明書が期限切れになっていないか
アプリケーションTLSの中間復号を拒否する仕様ではないか

CA証明書が正しく設定されていない場合、ヘッダーが挿入されないだけでなく、ブラウザに証明書エラーが表示されたり、アプリケーションのHTTPS通信自体が失敗したりします。

アプリケーションルールでもTLS Inspectionを有効にする

Firewall Policy全体でTLS Inspectionを設定しただけでは不十分です。HTTPヘッダーを挿入する対象のアプリケーションルールでも、TLS Inspectionを選択する必要があります。

Azure Firewall Premiumでは、ルールごとにTLS通信を復号するかどうかを制御できます。HTTPヘッダー挿入を設定したルールと、実際に通信へ一致しているTLS Inspectionルールが別になっている場合、期待したヘッダーは追加されません。(Microsoft Learn)

Azure portalでHTTPヘッダー挿入を設定する手順

Azure portalでは、既存のFirewall Policyにあるアプリケーションルールへ設定します。

HTTP通信で設定する場合

  1. Azure portalで対象のFirewall Policyを開きます。
  2. 「ルール」を開きます。
  3. 対象のルールコレクショングループを選択します。
  4. アプリケーションルールを新規作成するか、既存ルールを編集します。
  5. 送信元、宛先FQDN、プロトコルを設定します。
  6. 「HTTP Header Insertion」セクションを開きます。
  7. 挿入するヘッダー名と値を入力します。
  8. 必要に応じて複数のヘッダーを追加します。
  9. ルールを保存します。

Basic、Standard、Premiumのいずれでも、HTTP通信であればこの方法を利用できます。(Microsoft Learn)

HTTPS通信で設定する場合

HTTPSでは、前述の設定に加えて次の内容を確認します。

  1. Azure FirewallとFirewall PolicyがPremiumであることを確認します。
  2. Firewall PolicyのTLS Inspection設定を有効にします。
  3. Azure Key Vaultに保存した中間CA証明書を指定します。
  4. アプリケーションルールのプロトコルにHTTPS:443を設定します。
  5. 対象ルールでTLS Inspectionを有効にします。
  6. 「HTTP Header Insertion」にヘッダー名と値を入力します。
  7. 保存後、Draftを利用している場合は本番ポリシーへDeployします。

Azure Firewall Policy Draftを編集しただけでは、実際の通信へ変更は適用されません。Draft＋Deployを利用している環境では、デプロイまで完了しているかを確認してください。

REST APIやIaCで設定するときの構成

REST APIでは、アプリケーションルールにhttpHeadersToInsertを指定します。HTTPSを復号するルールでは、TLS終端を示すterminateTLSも重要です。

以下は主要部分だけを抜粋した構成イメージです。

{
  "name": "allow-saas-with-header",
  "ruleType": "ApplicationRule",
  "sourceAddresses": [
    "10.20.0.0/16"
  ],
  "targetFqdns": [
    "service.example.com"
  ],
  "protocols": [
    {
      "protocolType": "Https",
      "port": 443
    }
  ],
  "terminateTLS": true,
  "httpHeadersToInsert": [
    {
      "headerName": "X-Organization-Context",
      "headerValue": "contoso"
    }
  ]
}

httpHeadersToInsertはApplicationRuleのプロパティです。NetworkRuleやNatRuleではなく、対象のアプリケーションルールに設定します。実際に利用するAPIバージョンやTerraformプロバイダーのスキーマは、デプロイ時点の公式ドキュメントで確認してください。(Microsoft Learn)

Azure CLIでは--http-headers-to-insert、PowerShellではNew-AzFirewallPolicyApplicationRuleCustomHttpHeaderを使ってカスタムヘッダーを作成できます。設定後はルールコレクショングループを再取得し、ヘッダー名と値が保存されていることを確認します。(Microsoft Learn)

Microsoft Entraテナント制限に利用するときの注意点

Azure FirewallのHTTPヘッダー挿入は、Microsoft Entraテナント制限の実装候補として公式に挙げられています。ただし、テナント制限v1とv2では、使用するヘッダーと制御方式が異なります。古い構成例をそのままコピーしないことが重要です。

テナント制限v1で使うヘッダー

テナント制限v1では、Microsoftのサインイン要求に対して主に次の2つのヘッダーを挿入します。

Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com
Restrict-Access-Context: aaaabbbb-0000-cccc-1111-dddd2222eeee

Restrict-Access-To-Tenantsには、アクセスを許可するテナントのドメインまたはテナントIDをカンマ区切りで指定します。Restrict-Access-Contextには、制限を設定する自組織のテナントIDを指定します。許可リストに空白を入れない点にも注意が必要です。(Microsoft Learn)

対象となる代表的なサインインドメインは次のとおりです。

  • login.microsoftonline.com
  • login.microsoft.com
  • login.windows.net

テナント制限v1では、クライアントが勝手に許可テナントを追加できないように、すでにRestrict-Access-To-Tenantsが存在していても、プロキシまたはファイアウォール側で正規の値へ上書きすることが求められます。Azure Firewallの上書き機能は、この要件に適しています。(Microsoft Learn)

一方、*.login.microsoftonline.comを一括でTLS Inspectionの対象にすると、デバイス登録などに使われるサブドメインまで復号してしまいます。Microsoftのドキュメントでは、device.login.microsoftonline.comとenterpriseregistration.windows.netをTLSの復号およびヘッダー挿入から除外するよう案内されています。(Microsoft Learn)

テナント制限v2で使うヘッダー

テナント制限v2では、許可・拒否の内容をMicrosoft Entraのクロステナントアクセスポリシーで管理します。企業プロキシからは、次の形式でポリシーを識別するシグナルを付与します。

sec-Restrict-Tenant-Access-Policy: <DirectoryID>:<policyGUID>

DirectoryIDは自組織のMicrosoft EntraテナントID、policyGUIDはクロステナントアクセスポリシーのオブジェクトIDです。このヘッダーは次のサインインドメインへ送信します。(Microsoft Learn)

  • login.live.com
  • login.microsoft.com
  • login.microsoftonline.com
  • login.windows.net

v2へ移行するときは、v1のRestrict-Access-To-Tenantsによる許可リストをそのまま残さず、許可対象をMicrosoft Entra側のパートナーポリシーへ移します。また、login.live.comへ送信していた次のv1設定は、v2と競合するため削除します。(Microsoft Learn)

sec-Restrict-Tenant-Access-Policy: restrict-msa

Azure Firewallによるv2ヘッダー挿入は認証プレーン中心

企業プロキシ方式でテナント制限v2のヘッダーを挿入した場合、提供されるのは認証プレーンの保護です。匿名のTeams会議参加、匿名のSharePointファイル参照、持ち込まれたトークンによる直接アクセスなど、認証を経由しないデータプレーンまで同じように保護できるわけではありません。(Microsoft Learn)

要件に応じて、次のように使い分けます。

実現したいこと検討する方式
社内ネットワークからの外部テナントへのサインインを制御Azure Firewall Premiumによるヘッダー挿入
Microsoft Entra側で許可・拒否を細かく管理テナント制限v2のクロステナントアクセスポリシー
プロキシを通らない端末も対象にしたいUniversal tenant restrictions v2や端末側制御
匿名アクセスやデータプレーンも保護したいプロキシ方式だけに依存せず、Entra、Global Secure Access、端末制御を組み合わせる
TLS Inspectionを受け入れないクライアントがある条件付きアクセスや管理対象端末の制御を併用

Entraテナント制限のサインイン先はHTTPSです。そのため、Azure Firewall StandardまたはBasicのHTTPヘッダー挿入だけで、Entraテナント制限を実装することはできません。PremiumとTLS Inspectionが必須です。(Microsoft Learn)

TLS Inspectionを利用できないクライアントに注意する

クライアントアプリによっては、組織が配布したCA証明書を信頼しなかったり、証明書ピンニングなどによってTLSの中間復号を拒否したりすることがあります。

Microsoft Entraの公式ドキュメントでも、TLSのbreak and inspectに対応できないプラットフォームでは、プロキシによるテナント制限のヘッダー挿入が機能しないと説明されています。特に、ユーザー証明書ストアへ入れたCA証明書をアプリが利用しないケースには注意が必要です。(Microsoft Learn)

そのため、本番展開前にはブラウザだけでなく、実際に利用する次のクライアントを個別にテストします。

  • Microsoft 365デスクトップアプリ
  • Azure Virtual Desktopクライアント
  • モバイルアプリ
  • PowerShellやCLIツール
  • 業務用SaaSの専用クライアント
  • サービス間通信を行うバックエンドアプリ

ブラウザでは正常でも、専用アプリだけ通信に失敗する場合、HTTPヘッダー挿入の設定よりも先に、アプリがTLS Inspectionに対応しているかを確認します。

挿入できない予約済みヘッダー

HTTPヘッダー挿入では、すべてのヘッダーを自由に変更できるわけではありません。接続制御、認証、Cookie、セキュリティ、転送情報などに関わる一部のヘッダーは予約済みです。(Microsoft Learn)

代表例は次のとおりです。

分類挿入できない主なヘッダー
接続・メッセージ制御host、connection、content-length、transfer-encoding、upgrade
認証・Cookieauthorization、proxy-authorization、cookie、set-cookie
セキュリティcontent-security-policy、strict-transport-security、x-frame-options
転送情報x-forwarded-for、x-forwarded-proto、forwarded
その他metadata

たとえば、Azure FirewallからAuthorizationヘッダーを付加してバックエンド認証を代行する構成は作れません。必要な場合は、予約されていないカスタムヘッダーを使うか、Microsoft Entra ID、マネージドID、OAuth、mTLSなど別の認証方式を採用します。

ヘッダー名と値の上限

設定できるヘッダーには、次の上限があります。(Microsoft Learn)

項目上限
ヘッダー名100文字
1つのヘッダー値16,000文字
1アプリケーションルール内のヘッダー名と値の合計16,384バイト

HTTPヘッダーを大量に設定すると、ルールコレクショングループのJSONサイズも増加します。その結果、同じルールコレクショングループへ保存できるルール数が減る可能性があります。JSONサイズの上限へ達した場合は、HTTPヘッダー挿入用のルールを別のルールコレクショングループへ分割します。(Microsoft Learn)

HTTPSで動かないときの確認表

症状主な原因確認・対処
HTTPでは付くがHTTPSでは付かないBasicまたはStandardを使用Premiumへ変更し、TLS Inspectionを構成する
Premiumなのに付かないアプリケーションルールでTLS Inspectionが無効対象ルールのTLS InspectionまたはterminateTLSを確認
一部の宛先だけ付かない別ルールへ一致している、またはTLS復号の除外対象ルールの優先順位、FQDN、URL、送信元、プロトコルを確認
ブラウザに証明書エラーが出るクライアントが組織CAを信頼していないルートCAまたは中間CA証明書を正しく配布
専用アプリだけ失敗するTLS Inspection非対応、証明書ピンニングアプリの仕様を確認し、必要なら対象外化や別方式を検討
設定した値ではなく元の値が届く通信が別ルートを通過、または対象ルールに不一致UDR、Virtual WANルート、ルールログを確認
ルールを保存できない予約済みヘッダー、文字数、JSONサイズ超過ヘッダー名と上限を確認し、ルールコレクショングループを分割
Draftでは設定済みだが動かない本番ポリシーへ未DeployDraftのデプロイ状態を確認
Entraテナント制限が効かないv1とv2の混在、ヘッダー値や対象ドメインの誤り利用中のバージョンを確定し、対応するヘッダーだけを設定

HTTPSへの挿入条件、CA証明書、ルール単位のTLS Inspection、予約済みヘッダーを順に確認すると、原因を切り分けやすくなります。(Microsoft Learn)

HTTPヘッダーが挿入されたか確認する方法

受信側のログで確認する

最も確実なのは、受信したリクエストヘッダーを記録できる検証用Webサーバーを用意する方法です。

Azure Firewallによるヘッダー挿入は、クライアントがリクエストを送信したあとに行われます。そのため、クライアント側のcurl -vやブラウザの開発者ツールだけでは、Azure Firewallが後から追加したヘッダーを確認できない場合があります。

検証用サーバーまたはバックエンドのアクセスログで、実際に受信したヘッダーを確認してください。

TLS証明書の発行者を確認する

HTTPS通信でTLS Inspectionが動作している場合、クライアントにはAzure Firewallが組織の中間CAを使って生成した証明書が提示されます。

ブラウザやクライアントから証明書チェーンを確認し、発行者が組織のTLS Inspection用CAになっているかを調べます。元のWebサイトの公開CA証明書がそのまま見えている場合、その通信はTLS Inspectionされていない可能性があります。(Microsoft Learn)

Azure Firewallのアプリケーションルールログを確認する

Azure Firewallの診断設定でアプリケーションルールログをLog Analyticsへ送信すると、接続がどのルールに一致し、許可または拒否されたかを確認できます。

構造化ログではAZFWApplicationRuleテーブルを利用できます。ただし、ルールログは通信が対象ルールに一致したことを調べるものであり、受信側へ届いたヘッダー値そのものはバックエンド側でも確認するのが確実です。(Microsoft Learn)

Azure FirewallのHTTPヘッダー挿入を正しく使う判断基準

HTTPSでHTTPヘッダー挿入が動かない場合は、次の順序で確認します。

  1. Azure Firewall本体とFirewall PolicyがPremiumか
  2. Firewall PolicyにTLS Inspection用CA証明書が設定されているか
  3. クライアントが組織のCA証明書を信頼しているか
  4. 対象アプリケーションルールでTLS Inspectionが有効か
  5. 実際の通信がそのアプリケーションルールへ一致しているか
  6. 設定したヘッダーが予約済みではないか
  7. Draftを利用している場合、本番へDeploy済みか
  8. 受信側のサーバーログでヘッダーを確認したか

StandardとBasicで利用できるのはHTTPへの挿入だけです。HTTPS、Microsoft Entraテナント制限、HTTPSベースのSaaS制御で使う場合は、Premiumへ変更するだけでなく、TLS Inspection、証明書配布、ルール単位の復号設定までを一つの構成として設計してください。

また、Microsoft Entraテナント制限では、Azure Firewallの公式サンプルに含まれるv1ヘッダーを無条件に流用せず、現在利用するv1またはv2の方式を先に確定します。特にv2では、Azure Firewallによるヘッダー挿入だけでデータプレーンまで保護できるわけではないため、クロステナントアクセスポリシーやGlobal Secure Access、管理対象端末の制御も含めて判断することが重要です。

Azure
HTTPヘッダー Azure Firewall Microsoft Entra ID TLS Inspection

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次