Azure Application GatewayやAzure Front DoorのWAFで、正常なAPIリクエストまで遮断され、ルール全体の無効化や広範囲な許可ルールで対処している場合、Azure WAFの新しい「Exceptions」は検証する価値があります。
Exceptionsでは、リクエストURI、送信元IPアドレス、リクエストヘッダーを条件に、特定のルール、ルールグループ、マネージドルールセットだけWAF検査を回避できます。問題のある通信だけを限定的に通し、それ以外の保護を維持しやすくなる点が重要です。(Microsoft Learn)
結論として、誤検知対策のためにルールを全体無効化している環境や、Custom Allowルールで広くWAFを迂回させている環境は優先的に検証すべきです。一方、誤検知が発生していない環境や、対象SKU・ルールセットを使用していない環境では、直ちに設定変更する必要はありません。
2026年7月8日時点で確認できる公式情報では、英語版Azure Updatesの掲載日は2026年7月7日です。ステータスはPublic Previewであり、Azure Updates上では非運用環境での使用とテストを目的とする段階に位置付けられています。(Microsoft Azure)
Azure WAFのExceptionsで何が変わるのか
今回追加されたのは、Azure Application GatewayとAzure Front DoorのWAFポリシーにおける「ルール例外」の設定です。
従来も、誤検知を減らすためのExclusionsやCustom Allowルールは利用できました。しかし、両者には次のような調整上の難しさがありました。
- Exclusionsでは、ヘッダーやCookieなど、リクエスト内の特定要素をWAF検査から外す
- Custom Allowでは、条件に一致したリクエストについて、複数のマネージドルールセットを広く迂回する
- 特定のURIに対して、特定のルールだけを検査対象外にしたい場合、設定が広くなりやすい
Exceptionsでは、たとえば「特定のURIにアクセスしたときだけ、SQLインジェクション関連の特定ルールを適用しない」といった設定が可能になります。
Microsoftの公式ドキュメントでは、/login.phpや/logout.phpへのリクエストについて、SQLインジェクションルールの評価だけを回避する例が示されています。対象外にしていないルールやルールセットは引き続き評価されます。(Microsoft Learn)
今回の変更は、既存ポリシーを自動的に書き換えるものではありません。管理者がExceptionsを作成した場合に限って適用される、新しい調整手段です。
Exclusions・Exceptions・Custom Allowの違い
名称が似ているため、最初に役割を整理しておく必要があります。
この記事では、従来のExclusionsを「要素除外」、新しいExceptionsを「ルール例外」と表現します。
| 機能 | WAF検査から外す範囲 | 主な利用場面 | 注意点 |
|---|---|---|---|
| Exclusions | ヘッダー、Cookie、クエリパラメーターなど、リクエスト内の特定要素 | 認証トークンやCookieの値だけが誤検知される | 除外した要素の内容は対象ルールで検査されなくなる |
| Exceptions | 条件に一致するリクエストについて、指定したルール、ルールグループ、ルールセット | 特定URI、送信元IP、ヘッダーの通信だけが特定ルールに誤検知される | 対象範囲を広くすると防御上の死角が増える |
| Custom ruleのAllow | 条件に一致するリクエストについて、DRS、CRS、Bot Protectionなどを広く迂回 | 完全に信頼できる通信をWAFで許可する | 通常のシグネチャ検査や異常検知を広範囲に通過する |
Exclusionsは、特定のCookieやヘッダー値を無視しながら、リクエストの残りを検査したい場合に適しています。
一方、Exceptionsは、リクエスト自体をURI、IPアドレス、ヘッダーで識別し、そのリクエストに対して適用しないルールを選びます。ルール単位、ルールグループ単位、マネージドルールセット単位で範囲を設定できます。
Custom Allowルールが一致すると、DRS、CRS、Bot Protectionルールセットの評価を広く回避します。ただし、HTTP DDoSルールセットによる処理は継続します。Exceptionsでは、特定ルールだけを対象外にして、ほかの保護を残すことができます。(Microsoft Learn)
Exclusionsのままでよいケース
次のような場合は、新しいExceptionsに置き換える必要はありません。
- セッションCookieの値だけが誤検知される
- 認証トークンを格納した特定ヘッダーだけが検知対象になる
- JSON内の特定フィールドだけを検査対象から外したい
- 現在のExclusionsで誤検知を解消できている
リクエスト全体ではなく、特定の入力項目だけが問題なら、Exclusionsの方が目的に合っています。
Exceptionsが適しているケース
次のような環境では、Exceptionsが有力な選択肢になります。
- 特定APIのURIだけで同じWAFルールが誤検知される
- モバイルアプリからのリクエストだけが特定ルールに遮断される
- 固定IPを持つ取引先のAPI通信だけが特定ルールに抵触する
- 誤検知対策として特定ルールをポリシー全体で無効化している
- 1つのルールを避けるためだけにCustom Allowを設定している
とくに、現在ルールを全体無効化している場合は、Exceptionsによって適用除外を特定URIや送信元だけに狭められる可能性があります。
対象サービスと利用条件
Exceptionsは、すべてのAzure WAF構成で利用できるわけではありません。
| 対象サービス | 対象SKU・世代 | 必要なマネージドルールセット | 状態 |
|---|---|---|---|
| Azure Application Gateway | Application Gateway V2上のWAFポリシー | CRS 3.2、DRS 2.1以降 | Public Preview |
| Azure Front Door | Front Door Premium | DRS 2.1以降 | Public Preview |
どちらも次世代WAFエンジンが必要です。Application GatewayではCRS 3.2、DRS 2.1またはそれ以降、Azure Front DoorではDRS 2.1またはそれ以降が条件となります。(Microsoft Learn)
したがって、次の環境はそのままでは対象になりません。
- Application Gateway v1
- 古いCRSやDRSを使用しているApplication Gateway
- Azure Front Door Standard
- Azure Front Door Premiumでも古いルールセットを使用している構成
- Azure WAFを使用していない構成
古いルールセットを利用している場合、Exceptionsを使うためだけにすぐアップグレードするのではなく、先にルールセット更新による検知内容やスコアリングへの影響を確認してください。
Exceptionsで指定できる条件
Exceptionsでは、対象となるリクエストを次の属性で識別します。
| リクエスト属性 | 主な用途 |
|---|---|
| Request URI | 特定画面、特定API、特定パスへのリクエストを識別する |
| Remote IP address | 取引先や社内ネットワークなど、特定送信元を識別する |
| Request header name and value | クライアント種別やアプリ固有のヘッダーを識別する |
使用できる演算子は次のとおりです。
Equals：完全一致Starts with：指定した値で始まるEnds with：指定した値で終わるContains：指定した値を含むIP Match：1つ以上のIPアドレスと照合する
例外を適用する範囲は、次の3段階から選択できます。
- 特定のルール
- ルールグループ
- マネージドルールセット全体
Microsoftは、可能な限り特定ルール単位まで対象を絞ることを推奨しています。広い例外は、本来検知すべき攻撃まで通過させる可能性があるためです。(Microsoft Learn)
クエリやCookieだけを無視したい場合はExclusionsを使う
Exceptionsの識別属性として公式に示されているのは、URI、送信元IPアドレス、リクエストヘッダーです。
Cookie、クエリパラメーター、フォームフィールド、JSONの特定フィールドを識別条件として使う機能ではありません。これらの特定要素だけを検査対象外にしたい場合は、従来のExclusionsが適しています。(Microsoft Learn)
実務で考えられる活用例
特定APIだけがSQLインジェクションルールに誤検知される
たとえば、業務システムの/api/importが、正当なデータ内の文字列によって特定のSQLインジェクションルールに遮断されるケースです。
この場合、次のような方針が考えられます。
- 識別条件：Request URI
- 演算子：Equals
- 値：対象APIのURI
- 適用範囲：誤検知している特定ルール
SQLインジェクションのルールグループ全体を例外にするのではなく、ログで確認したルールIDだけを対象にすることが重要です。
固定IPの取引先APIが特定ルールに抵触する
接続元IPが固定されている取引先APIでは、Remote IP addressとIP Matchを利用できます。
ただし、送信元が信頼できるという理由だけでルールセット全体を例外にするのは避けるべきです。取引先システムが侵害される可能性や、取引先から送信されるデータに問題が含まれる可能性も考慮し、誤検知しているルールだけに絞ります。
特定クライアントのヘッダーが誤検知される
モバイルアプリや旧クライアントが送信する固有ヘッダーを条件に、特定ルールの検査を回避することもできます。
ただし、外部利用者が自由に設定できるヘッダーは、信頼できる認証情報にはなりません。ヘッダー条件だけで広いルールセットを迂回させず、対象ルールを限定してください。
自社環境で対応が必要か判断する
ExceptionsはPublic Previewですが、すべての利用者がすぐ設定すべき機能ではありません。
| 現在の状況 | 対応方針 |
|---|---|
| 正常なリクエストがWAFで継続的に遮断されている | Exceptionsの検証を開始する |
| 誤検知対策としてルールをポリシー全体で無効化している | 優先度を上げてExceptionsへの置き換えを検討する |
| 特定ルールを避けるためだけにCustom Allowを使用している | Exceptionsで範囲を狭められないか確認する |
| 特定CookieやパラメーターのExclusionsで解決している | 無理に変更しない |
| 誤検知が発生していない | 機能把握と監視だけでよい |
| Application Gateway v1やFront Door Standardを利用している | 現時点では対象外。SKU変更の費用と影響を別途評価する |
| CRS 3.1以前など古いルールセットを使用している | 先にルールセット更新の影響を検証する |
| 非本番環境や再現手順がない | 本番適用を急がず、検証環境を準備する |
ExceptionsのためだけにSKUやルールセットを変更すると、機能以外の構成、料金、検知結果にも影響する可能性があります。まず現在の誤検知による業務影響と、既存の回避設定が生むセキュリティリスクを比較してください。
Exceptionsを導入する手順
WAFログから誤検知を特定する
最初に、正常な通信がどのルールによって遮断されているか確認します。
最低限、次の情報を整理してください。
- 対象のWAFポリシー
- Application GatewayまたはFront Doorの対象エンドポイント
- マネージドルールセットの種類とバージョン
- 検知されたルールID
- ルールグループ
- 対象URI
- 送信元IPアドレス
- 関係するリクエストヘッダー
- 同じ条件で再現できるか
- アプリケーション担当者が正常な通信だと確認したか
「利用者が使えないから誤検知だろう」と判断するのは危険です。実際に攻撃文字列が送信されている可能性もあるため、WAF担当者だけでなく、アプリケーション担当者やセキュリティ担当者も確認します。
Exclusions・Exceptions・Allowから適切な方法を選ぶ
次の基準で選ぶと、過剰な例外を避けやすくなります。
- 特定の入力項目だけが問題：Exclusions
- 特定の通信と特定のルールの組み合わせが問題：Exceptions
- 信頼済み通信について複数ルールセットを広く迂回させる必要がある：Custom Allow
Exceptionsが新しいからという理由だけで、既存のExclusionsをすべて移行する必要はありません。
最も狭い条件を設計する
条件の設計では、対象を広げすぎないことが重要です。
URIを指定する場合は、可能ならEqualsを優先します。Containsで/apiのような短い文字列を指定すると、管理者が意図していない別のURIまで一致する可能性があります。
適用範囲も、次の順番で検討します。
- 特定ルール
- ルールグループ
- マネージドルールセット全体
最初からルールセット全体を対象にせず、特定ルールで解決できない理由を確認してから範囲を広げます。
Azure portalで例外を追加する
公式ドキュメントで案内されている基本的な操作手順は次のとおりです。
- 対象のWAFポリシーを開く
- 「Settings」から「Managed rules」を開く
- 「Exceptions」タブを選択する
- 「Add exceptions」を選択する
- 「Applies to」で対象ルールセットを選択する
- Entire ruleset、Rule group、Specific rulesのいずれかを選択する
- マッチ変数、演算子、値を指定する
- 例外を追加して保存する
Application Gatewayについては、Azure portalに加えてPowerShellとAzure CLIによる構成方法も公式ドキュメントに掲載されています。Azure CLIでは、az network application-gateway waf-policy managed-rule exception addコマンドが案内されています。(Microsoft Learn)
Public Preview中は、ポータル画面やコマンドのパラメーターが変更される可能性があります。自動化する場合は、実際に利用するAzure CLIやPowerShellモジュールのバージョンで動作を確認してください。
正常通信と攻撃通信の両方をテストする
「正常な通信が通った」だけでは、テストとして不十分です。
少なくとも次の点を確認します。
- 対象の正常リクエストが遮断されなくなった
- 対象外のURIでは従来どおりルールが機能する
- 例外にしていないWAFルールは引き続き評価される
- 類似した別URIが意図せず例外になっていない
- ヘッダーの値を変更した場合に例外が適用されない
- 不正なテストリクエストが適切に検知または遮断される
- WAFログで例外適用後の挙動を追跡できる
テスト結果には、正常系だけでなく、例外によって検知できなくなる攻撃パターンも記録します。
設定数の上限に注意する
Application GatewayとAzure Front Doorには、Exceptionsの上限があります。
| 制限対象 | 上限 |
|---|---|
| 1つのAzure WAFポリシーに設定できる例外 | 60件 |
| 1つのApplication Gatewayに関連付けられた全WAFポリシーの例外合計 | 60件 |
| 1つのAzure Front Doorに関連付けられた全WAFポリシーの例外合計 | 60件 |
| 1件の例外に登録できるIPアドレス | 最大600件 |
| 1件の例外に登録できるURI | 最大10件 |
| 1件の例外に登録できるリクエストヘッダー | 最大10件 |
複数のWAFポリシーを作成しても、Application GatewayまたはAzure Front Door単位の合計上限を超えられるとは限りません。ポリシーごとの60件と、サービス全体の合計60件を混同しないようにしてください。(Microsoft Learn)
例外をURIごとに細かく作りすぎると、上限に達しやすくなります。一方、上限を節約するために無関係なURIを1件へまとめると、例外範囲が広がります。件数ではなく、業務上の目的とリスクが同じものだけをまとめることが重要です。
Public Previewであることをどう扱うべきか
Azure Updatesにおける「In preview」は、すべてのAzureユーザーが非運用環境で利用、テストできる段階です。「Launched」、つまり一般提供され、本番対応として位置付けられた状態とは区別されています。(Microsoft Azure)
そのため、次の順序で評価するのが安全です。
- 検証用WAFポリシーで機能の表示と設定可否を確認する
- 再現可能な誤検知を1件だけ選ぶ
- 特定ルール単位のExceptionを作成する
- 正常通信と攻撃テストを実施する
- 変更前後のWAFログを比較する
- ロールバック方法を確認する
- 一般提供後に仕様と制限を再確認する
プレビュー機能を本番環境で利用するかどうかは、組織のクラウド利用基準、契約条件、セキュリティポリシーに沿って判断してください。Microsoftのドキュメントでも、Application GatewayとAzure Front DoorのExceptionsにはAzure Previewの追加使用条件が適用されると明記されています。(Microsoft Learn)
導入前に確認するチェック項目
技術条件
- Application Gateway V2またはFront Door Premiumである
- 次世代WAFエンジンを利用している
- 対応するCRSまたはDRSバージョンである
- 対象WAFポリシーにExceptionsタブが表示される
- 誤検知したルールIDとルールグループを特定できている
セキュリティ条件
- 正常な通信であることをアプリケーション担当者が確認している
- URI、IP、ヘッダーのうち最も限定しやすい条件を選んでいる
- 特定ルール単位で設定できない理由を確認している
- 例外対象のルールが防いでいた攻撃を把握している
- Custom Allowやルール全体無効化より範囲が狭くなっている
- Exceptionを脆弱性修正の代替手段にしていない
運用条件
- 設定理由と関連チケットを記録している
- 業務オーナーと技術オーナーを決めている
- 見直し予定日を設定している
- 変更前のWAFポリシー定義を保存している
- ロールバック手順を準備している
- ルールセット更新時に再テストする運用を決めている
- 例外数の上限を継続的に管理できる
失敗しやすい設定と回避策
誤検知ルールを調べずにルールグループ全体を例外にする
ルールグループ単位の例外は設定が簡単ですが、同じグループ内の正常に機能しているルールも適用されなくなります。
WAFログからルールIDを特定し、まず特定ルール単位で設定してください。Microsoftも、可能な限り狭い例外、特にルール単位の例外を使用するよう案内しています。(Microsoft Learn)
URIをContainsで広く指定する
Containsは便利ですが、短い文字列を指定すると想定外のパスにも一致します。
対象URIが固定ならEqualsを使用し、バージョン付きAPIなど共通の先頭部分が明確な場合に限ってStarts withを検討します。
リクエストヘッダーを信頼の根拠にする
利用者が自由に追加できるヘッダーを条件に、ルールセット全体を例外にすると、攻撃者も同じヘッダーを送信できる可能性があります。
ヘッダーは、通信を識別する補助条件として扱い、例外の適用範囲は特定ルールまで絞るのが安全です。
例外設定でアプリケーションの問題を隠す
同じ入力で繰り返しWAFが反応する場合、誤検知ではなく、アプリケーションが危険な形式のデータを受け入れている可能性もあります。
入力検証、エンコード、パラメーター化クエリ、認証・認可など、アプリケーション側で修正できないか先に確認してください。
一度設定した例外を放置する
システム改修によって問題のあったURIやヘッダーが廃止されても、例外設定だけが残ることがあります。
例外ごとに、作成理由、対象ルール、業務オーナー、作成日、見直し日を記録し、定期的に削除可否を確認してください。
よくある疑問
既存のWAFポリシーはすぐ変更する必要があるか
今回の機能は任意で追加する例外設定です。誤検知や広すぎる回避設定がなければ、直ちに変更する必要はありません。
まず、現在無効化しているルール、Exclusions、Custom Allowルールを棚卸しし、Exceptionsによって保護範囲を狭められるものがあるか確認します。
Azure Front Door Standardでも利用できるか
公式ドキュメントの対象はAzure Front Door Premiumです。Front Door Standardは対象として示されていません。(Microsoft Learn)
Application Gatewayの古いCRSでも利用できるか
Application Gatewayでは、次世代WAFエンジンとCRS 3.2、DRS 2.1またはそれ以降が必要です。古いCRSを利用している場合は、そのままでは利用できません。(Microsoft Learn)
Exceptionsを設定すれば他のWAFルールも動かなくなるか
適用範囲を特定ルールにした場合、ほかのルールやルールセットは引き続き評価されます。
ただし、ルールグループ全体やマネージドルールセット全体を対象にすれば、その範囲の検査は回避されます。設定時には、どの範囲を例外にしているかを必ず確認してください。(Microsoft Learn)
まず実施すべきこと
Azure WAFのExceptionsは、誤検知対策を単に増やす機能ではありません。これまでルール全体の無効化やCustom Allowで広く開けていた防御範囲を、特定リクエストと特定ルールの組み合わせまで狭められる点に価値があります。
対応要否を判断するため、まず次の3点を実施してください。
- Application GatewayまたはFront DoorのSKU、WAFエンジン、ルールセットバージョンを確認する
- 現在無効化しているマネージドルールとCustom Allowルールを棚卸しする
- 実際の誤検知を1件選び、非本番環境で特定ルール単位のExceptionを検証する
誤検知がなければ、急いで導入する必要はありません。一方、正常通信を通すために広範囲なWAF迂回を行っている環境では、現在の設定をより限定的なExceptionsへ置き換えられるか、早めに評価するのが適切です。
コメント