Azure Web Application Firewall on Azure Application Gateway の2026年4月更新ポイントを一言でいうと、新機能の大規模発表というより、Application Gateway 上のWAFを「WAFポリシー中心」で設計・監視・監査する重要性を再確認すべき更新です。特に、security admins はWAFポリシーとルールセット、identity teams は認証まわりの誤検知、compliance teams はログ・証跡・適用範囲を見直すべきです。
Microsoft Learnの該当ページは、繁体字中国語版で「Last updated on 2026-04-22」と表示されています。一方、公開されているGitHub履歴では2026年4月20日にリンク修正、4月28日に「Applies to」セクション追加のコミットが確認できます。そのため、本記事では「2026年4月に確認すべき実務上の更新ポイント」として、公式本文と公開履歴をもとに整理します。(Microsoft Learn)
Azureの最新動向: What Is Azure Web Application Firewall on Azure Application Gateway?で何が変わったか
今回の更新でまず押さえたいのは、Azure Web Application Firewall on Azure Application Gateway が、Application Gateway に対するWAF機能であることが明確に示されている点です。Azure WAFにはAzure Front Doorなど別の展開先もありますが、このドキュメントの対象はApplication Gatewayです。公開履歴では、2026年4月28日のコミットで Applies to: Application Gateway が追加されています。(GitHub)
また、本文ではAzure Web Application FirewallがSQLインジェクションやクロスサイトスクリプティングなどの一般的な攻撃からWebアプリケーションを保護し、OWASP Core Rule Setをベースにしていることが説明されています。WAF機能はWAFポリシー内に存在し、Application Gateway全体、個別リスナー、パスベースルーティング規則に関連付けられる点も重要です。(Microsoft Learn)
ここで誤解しやすいのは、「2026年4月22日に新しい防御機能が一斉追加された」と読むことです。公式ページ本文とGitHub履歴を見る限り、少なくとも確認できる範囲では、ドキュメント整理・対象範囲の明確化・関連リンク修正の性格が強い更新です。したがって、運用側が取るべき行動は「新機能をすぐ有効化する」よりも、既存のWAFポリシー、ログ、ルール例外、監査証跡が最新の推奨構成に沿っているかを点検することです。(GitHub)
Azure Web Application Firewall on Azure Application Gatewayの基本を短く整理
Azure Web Application Firewall on Azure Application Gateway は、Application Gatewayに統合して使うWebアプリケーション向けの防御レイヤーです。バックエンドコードを直接変更せずに、SQLインジェクション、XSS、コマンドインジェクション、HTTPリクエストスマグリング、リモートファイルインクルードなどの攻撃検出・防御を支援します。(Microsoft Learn)
Application Gateway自体は、TLS終端、Cookieベースのセッションアフィニティ、ラウンドロビン負荷分散、コンテンツベースルーティング、複数サイトのホスティングなどを提供するアプリケーション配信コントローラーです。ここにWAFを組み合わせることで、アプリケーション配信とWeb攻撃対策を同じ入口で管理できます。(Microsoft Learn)
特に実務で大事なのは、WAFの設定が「Application Gateway本体に何となく付いている機能」ではなく、WAFポリシーとして管理される点です。WAFポリシーには、マネージドルール、カスタムルール、除外設定、ファイルアップロード制限などが含まれます。(Microsoft Learn)
2026年4月更新で見るべきポイント
| 確認ポイント | 実務での意味 | 主な担当 |
|---|---|---|
| 対象がApplication Gatewayであること | Azure Front Door向けWAFと混同せず、Application Gateway配下のWebアプリを点検する | security admins |
| WAFポリシー中心の設計 | グローバル、サイト単位、URI単位でポリシーを分けられる | security admins、compliance teams |
| WAF_v2が前提になる領域 | WAFポリシー関連付けはWAF_v2でサポートされるため、古い構成を洗い出す | security admins |
| カスタムルールの優先処理 | 許可ルールを広く作ると、後続のマネージドルール評価を止める可能性がある | security admins |
| 認証トークンやCookieの除外 | Entra IDや認証基盤のトークンが誤検知を起こす場合、除外範囲を最小化する | identity teams |
| Azure Monitor、Defender for Cloud、Sentinel連携 | 検知・可視化・監査証跡を運用プロセスに組み込む | security admins、compliance teams |
| Detection modeからPrevention modeへの移行 | いきなり本番ブロックせず、ログ確認後に防御モードへ移行する | security admins |
Microsoft Learnでは、Application GatewayにWAF_v1とWAF_v2があること、WAFポリシー関連付けはWAF_v2でのみサポートされることが明記されています。既存環境で古いSKUやレガシーWAF構成が残っている場合、2026年4月の確認タイミングで棚卸しすべきです。(Microsoft Learn)
WAFポリシーを「どこに適用するか」が運用品質を左右する
Azure Web Application Firewall on Azure Application Gateway の運用で最も重要なのは、WAFポリシーの適用範囲です。Application Gatewayでは、WAFポリシーをグローバル、リスナー単位、パスベースルール単位に関連付けられます。つまり、同じApplication Gatewayの背後に複数サイトがある場合でも、サイトごと、URIごとに異なる防御方針を持てます。(Microsoft Learn)
たとえば、以下のように分けると実務で扱いやすくなります。
| 適用範囲 | 向いているケース | 設計例 |
|---|---|---|
| グローバルポリシー | すべてのサイトに共通の最低限の防御を適用したい | 既知の攻撃パターン、基本的なBot対策、ログ取得を共通化 |
| サイト単位ポリシー | サイトごとに用途やリスクが違う | 静的サイトは誤検知を抑え、会員サイトはSQLi・XSS防御を強める |
| URI単位ポリシー | ログイン、決済、管理画面など高リスクパスを強化したい | /login、/admin、/payments だけ厳しいルールと短い例外リストを適用 |
注意したいのは、全サイトに同じ強いルールを一律適用すると、問い合わせフォーム、検索フォーム、SSO連携、ファイルアップロードなどで誤検知が起きやすくなることです。逆に、誤検知を恐れて全体ルールを弱めると、重要なログイン画面や決済画面まで防御が甘くなります。
おすすめは、グローバルポリシーでベースラインを作り、重要なリスナーやURIにだけ強いポリシーを上書きする設計です。Microsoft Learnのポリシー概要でも、より具体的なポリシーが上位の広いポリシーを上書きする考え方が説明されています。(Microsoft Learn)
security adminsが確認すべき設定
security admins は、まずWAFが「有効かどうか」ではなく、どのモードで、どのルールセットを、どの範囲に適用しているかを確認すべきです。
Detection modeとPrevention modeを使い分ける
Application Gateway WAFには、検出モードと防止モードがあります。検出モードでは脅威アラートを監視・記録しますが、受信リクエストはブロックしません。防止モードでは、ルールが検出した侵入や攻撃をブロックし、攻撃者には403が返されます。Microsoft Learnでは、新規デプロイしたWAFを本番環境で短期間Detection modeにしてログを取得し、例外やカスタムルールを調整してからPrevention modeへ移行することが推奨されています。(Microsoft Learn)
実務では、以下の順で進めると失敗しにくくなります。
| フェーズ | 実施内容 | 判断基準 |
|---|---|---|
| 初期導入 | Detection modeでWAFログを収集 | 正常ユーザーのリクエストが大量にMatchedになっていないか |
| チューニング | 誤検知ルール、対象パラメーター、Cookie、URIを確認 | ルール全体の無効化ではなく、限定的な除外で対応できるか |
| 段階的ブロック | 高リスクURIや一部サイトからPrevention modeへ移行 | 403増加、ログイン失敗、決済失敗が許容範囲か |
| 本番定着 | 定期レビューと変更管理に組み込む | 新機能リリース時にWAF例外もレビューされているか |
アノマリースコアを理解する
Azure WAFのCRSでは、単に「ルールに一致したら即ブロック」ではなく、アノマリースコアで判断されます。Criticalは5、Errorは4、Warningは3、Noticeは2として扱われ、しきい値5以上でブロック対象になります。つまり、Criticalルール1件ならPrevention modeでブロックされますが、Warning 1件だけでは通常ブロックに至りません。(Microsoft Learn)
この仕組みを理解していないと、「ログにMatchedが出ているのにブロックされない」「1つのWarningなのに危険なのでは」といった誤解が起きます。運用ダッシュボードでは、単純なヒット件数だけでなく、最終アクションがBlockedかDetectedか、合計スコアがしきい値に達したかを見る必要があります。
カスタムルールは強力だが、広すぎるAllowに注意する
カスタムルールは、マネージドルールセットより先に評価されます。AllowまたはBlockのカスタムルールに一致すると、後続のカスタムルールやマネージドルールの評価が止まる場合があります。Microsoft Learnでも、カスタムルールが高い優先度を持つこと、AllowまたはBlock時にそれ以降の評価が行われないことが説明されています。(Microsoft Learn)
たとえば、社内IPアドレスからの通信をAllowするルールを作る場合でも、すべてのパスを無条件に許可するのは危険です。社内端末が侵害された場合、WAFをすり抜ける経路になります。より安全なのは、管理画面へのアクセス制御、特定ヘッダー、特定URI、送信元範囲を組み合わせ、必要最小限に絞ることです。
identity teamsが確認すべき認証まわりのポイント
identity teams が関わるべき理由は、WAFの誤検知がログイン、SSO、トークン、Cookie、認証後リダイレクトに影響することがあるためです。Microsoft Learnでは、WAF評価から特定のリクエスト属性を除外できる例として、認証に使われるActive Directory挿入トークンやパスワードフィールドが挙げられています。(Microsoft Learn)
ただし、除外設定は「認証まわりが壊れるから全部除外する」ではなく、次のように絞り込むべきです。
| よくある課題 | 悪い対応 | 推奨対応 |
|---|---|---|
| SSO後のトークンが誤検知される | 認証関連URIをWAF対象外にする | 該当ヘッダー、Cookie、パラメーターだけを除外 |
| ログインフォームでXSSルールが反応する | XSSルールグループ全体を無効化 | 該当フィールドと該当ルールIDを確認し、限定除外 |
| パスワード変更画面でブロックされる | /account/* 全体をAllow | /account/change-password の必要項目だけを調整 |
| 多要素認証後のリダイレクトで403が出る | Prevention modeを全体で解除 | Detection modeで該当トランザクションIDを追跡して原因ルールを特定 |
identity teams は、WAFログの requestUri、hostname、ruleId、ruleGroup、action、transactionId などをsecurity adminsと一緒に確認すると、誤検知の範囲を狭くできます。WAFログはJSON形式で記録され、Azure Monitor Logsと統合できます。(Microsoft Learn)
compliance teamsが見るべき監査・証跡ポイント
compliance teams にとって重要なのは、WAFが入っているかどうかだけではありません。どのWebアプリに、どのポリシーが、いつ、誰の承認で、どのモードで適用されているかを証跡として説明できることです。
Azure Application Gateway WAFは、Azure Monitor、Microsoft Defender for Cloud、Microsoft Sentinelと連携して監視できます。Microsoft Learnでは、WAFログがAzure Monitorに統合され、Defender for CloudがAzure・ハイブリッド・マルチクラウドリソースのセキュリティ状態を集中表示すること、SentinelでSIEM/SOARとして脅威可視化や対応に活用できることが説明されています。(Microsoft Learn)
監査観点では、最低限以下を残しておくと説明しやすくなります。
| 監査項目 | 残すべき証跡 | 確認頻度 |
|---|---|---|
| WAF適用範囲 | Application Gateway、リスナー、URI単位のポリシー関連付け | 月次、構成変更時 |
| モード | Detection / Prevention の状態と変更理由 | 変更時 |
| ルールセット | DRS/CRSのバージョン、Bot Managerの有効化状態 | 四半期、重大脆弱性対応時 |
| 例外設定 | 除外対象、対象ルール、承認者、期限 | 月次 |
| ログ保全 | Log Analytics、Storage、Event Hub、Sentinel連携 | 月次 |
| インシデント対応 | Blocked/Detectedイベント、対応チケット、再発防止策 | インシデントごと |
コンプライアンス対応では、「WAFがあるから安全」と説明するより、「WAFポリシー、ログ、例外、変更管理を運用している」と説明できる状態が重要です。
ルールセットはDRS/CRSの更新状況を確認する
公式のルールセット関連ページでは、Application Gateway WAFのDefault Rule Set（DRS）がAzure管理のルールセットとして、一般的な脆弱性や攻撃からの保護を支援し、必要に応じて新しい攻撃シグネチャに対応するため更新されることが説明されています。DRS 2.2はOWASP CRS 3.3.4をベースにし、Microsoft Threat Intelligenceチームによる追加保護も含むとされています。(Microsoft Learn)
既存のWAFポリシーで古いCRSやDRSを使っている場合は、最新の推奨ルールセットへの移行を検討すべきです。ただし、ルールセットを変更すると新しいルールやルールグループが追加される可能性があり、ポータルで新しいマネージドルールセットを割り当てる場合、既存のルール状態、アクション、ルールレベル除外が新しい既定値にリセットされる可能性があります。事前にテスト環境で検証し、必要なオーバーライドと除外を再定義してから本番展開するのが安全です。(Microsoft Learn)
Bot ManagerはSEO・広告・監視チームとも調整する
Application Gateway WAFでは、Bot Manager Rule Setを有効化して、Bad bots、Good bots、Unknown botsのカテゴリごとに動作を制御できます。Microsoft Learnでは、悪意あるBotをブロックし、検証済み検索エンジンクローラーを許可し、未知の検索エンジンクローラーをブロックし、未知Botをログに記録する既定動作が説明されています。(Microsoft Learn)
この設定はsecurity adminsだけで決めると、SEOや広告計測に影響する場合があります。たとえば、検証済み検索エンジンBotは許可しても、独自の監視Bot、外部診断サービス、広告検証Bot、パートナー企業のクローラーがUnknown扱いになることがあります。
Bot対策を強化する際は、以下を事前確認すると失敗を減らせます。
| 確認対象 | 見るべき点 |
|---|---|
| 検索エンジンBot | Googlebot、Bingbotなどの検証済みBotが正常に通るか |
| 監視サービス | 外形監視、合成監視、SRE用のヘルスチェックがブロックされないか |
| 広告・マーケティング計測 | 広告検証、リンクチェッカー、SNSプレビューが影響を受けないか |
| 悪性Bot | 短時間大量アクセス、ログイン試行、スクレイピングが減っているか |
| 例外 | IP固定ではなく、可能ならUser-Agentだけに頼らない条件設計にする |
リクエストサイズとファイルアップロードは見落としやすい
WAF運用では、SQLiやXSSだけでなく、リクエスト本文やファイルアップロードのサイズ制限も重要です。Microsoft Learnでは、Application Gateway v2 WAFでCRS 3.2以降を使う場合、リクエスト本文サイズ、ファイルアップロードサイズ、リクエスト本文検査をより細かく制御できることが説明されています。(Microsoft Learn)
特に、ファイルアップロード機能を持つアプリでは注意が必要です。画像投稿、CSVインポート、本人確認書類アップロード、サポート添付ファイルなどがある場合、WAFのサイズ制限が業務フローを止めることがあります。
実務では、以下のように確認します。
| 項目 | 確認内容 |
|---|---|
| 最大リクエスト本文サイズ | 通常フォーム、検索条件、APIリクエストが制限を超えないか |
| 最大ファイルアップロードサイズ | 業務上必要な最大ファイルサイズと一致しているか |
| 本文検査の有効/無効 | 無効化すると本文内の攻撃検査が弱まる点を理解しているか |
| multipart/form-data | ファイルアップロード判定はContent-Typeにも依存する |
| Detection / Prevention | Prevention modeではサイズ超過がブロックにつながる可能性がある |
サイズ制限を緩める場合は、「ユーザー利便性のため」だけでなく、マルウェアスキャン、ストレージ制限、バックエンドアプリの最大処理サイズ、監査ログとの整合性もあわせて確認してください。
レガシーWAF構成は2027年3月15日を意識して移行する
Application Gateway WAF v2のレガシーWAF構成は、2024年3月15日に非推奨が発表され、2027年3月15日に廃止予定とされています。Microsoft Learnでは、WAF ConfigurationからWAF Policyへのアップグレードが推奨されており、WAF Policyでは新しいマネージドルールセット、カスタムルール、ルール単位の除外、Bot保護、新しいWAFエンジンなどの高度な機能を利用できると説明されています。(Microsoft Learn)
既存環境で確認すべきことは、以下の3つです。
| 確認項目 | 対応 |
|---|---|
| WAF_v1が残っていないか | Application Gateway v2 / WAF_v2への移行計画を作る |
| WAF_v2でもレガシーWAF構成を使っていないか | WAF Policyへ移行する |
| 移行後に例外・ルールが再現されているか | Detection modeでログ確認し、Prevention modeへ戻す |
期限が近づいてから移行すると、検証不足のまま例外設定を広げることになりがちです。2026年時点では、重要システムから順にWAFポリシー化し、変更管理と監査証跡を整えておくべきです。
よくある失敗と回避策
| 失敗パターン | 起きる問題 | 回避策 |
|---|---|---|
| Detection modeのまま放置する | 攻撃を検知してもブロックできない | チューニング完了日とPrevention移行日を決める |
| 誤検知対策でルールグループ全体を無効化する | 本来止めるべき攻撃まで通る | ルールID、パラメーター、URI単位で限定除外する |
| 社内IPを広くAllowする | 社内端末侵害時にWAFを迂回される | 管理画面など必要範囲に絞る |
| ログを取得していない | ブロック理由も監査証跡も説明できない | Azure Monitor LogsやSentinelへ連携する |
| ルールセット変更を本番で直接実施する | 新ルールでログインや決済が止まる | テスト環境、Detection mode、段階展開を使う |
| WAFを脆弱性修正の代替と考える | アプリ本体の根本原因が残る | WAFは緩和策、コード修正とパッチ適用を並行する |
2026年4月更新後に実施したいチェックリスト
Azure Web Application Firewall on Azure Application Gateway を運用している組織は、次の順で確認すると効率的です。
| 優先度 | チェック項目 | 完了条件 |
|---|---|---|
| 高 | Application Gateway WAF_v2を使っているか | WAFポリシー関連付けが使える構成になっている |
| 高 | WAFポリシーの適用範囲を棚卸ししたか | グローバル、リスナー、URI単位の関連付けが一覧化されている |
| 高 | ログ取得が有効か | WAFログがLog Analytics、Storage、Event Hub、Sentinelなどに送られている |
| 高 | Detection modeのまま放置していないか | Prevention mode移行の判断基準と期限がある |
| 中 | 重要URIに専用ポリシーがあるか | ログイン、管理画面、決済、APIに適切なポリシーがある |
| 中 | 認証トークンの誤検知を確認したか | identity teamsと除外設定をレビュー済み |
| 中 | Bot Managerの影響を確認したか | 検索Bot、監視Bot、広告Botへの影響が確認済み |
| 中 | ルールセット更新計画があるか | DRS/CRSのバージョンと移行手順が文書化されている |
| 中 | レガシーWAF構成が残っていないか | WAF Policyへの移行計画がある |
| 低 | コストとログ保持期間を確認したか | 監査要件と運用コストのバランスが取れている |
まとめ: 今回の更新は「WAFを入れているか」から「運用できているか」への確認ポイント
2026年4月更新として確認すべき本質は、Azure Web Application Firewall on Azure Application Gateway を単なる追加機能ではなく、ポリシー、ルール、ログ、例外、監査を含む継続運用の仕組みとして見ることです。
security admins は、WAF_v2、WAFポリシー、DRS/CRS、Bot Manager、Detection/Prevention modeを点検してください。identity teams は、SSO、認証トークン、Cookie、ログインURIで誤検知が起きていないか確認してください。compliance teams は、WAF適用範囲、例外承認、ログ保持、インシデント対応証跡をレビューしてください。
次に取るべき行動は明確です。まずApplication Gateway配下のWAFポリシーを棚卸しし、ログを確認し、Detection modeのまま残っている環境を洗い出します。そのうえで、重要URIから段階的にチューニングし、Prevention modeと監査証跡をセットで運用に組み込むことが、2026年時点のAzure WAF運用で最も実効性のある対応です。
コメント