MENU

Azure Application Gateway WAF v2でDRS 2.1が適用できない原因とWAFポリシーへの移行手順

Azure

Azure Application Gateway の WAF v2 で Microsoft 既定ルールセット（DRS 2.1）を有効化しようとすると、「RuleSetType ‘Microsoft_DefaultRuleSet’ does not exist…」というエラーでつまずくケースが増えています。本記事では、この原因であるレガシー WAF 構成と WAF ポリシー方式の違いを整理し、移行スクリプトを用いて無停止で DRS 2.1 を適用するための実践的な手順と注意点を詳しく解説します。

目次

問題の概要：DRS 2.1 が Application Gateway WAF v2 に適用できない

North Europe リージョンの Azure Application Gateway（WAF v2 SKU）で、以下のような状況に遭遇している管理者は少なくありません。

  • ポータルから Microsoft 既定ルールセット（DRS）2.1 を選択して保存しようとするとエラーが出る
  • OWASP 3.2 のルールセットは問題なく設定できる
  • 代表的なエラー：
    RuleSetType 'Microsoft_DefaultRuleSet' does not exist for Application Gateway Firewall in context 'properties.webApplicationFirewallConfiguration'
  • その後、ポータルに 「レガシー WAF 構成を使用中。WAF ポリシーへアップグレード推奨」 というアドバイザリが表示される

まず押さえておきたいポイントは、次の 2 点です。

  • DRS 2.1 自体は Application Gateway WAF v2 で正式サポートされている（リージョン依存の制限ではない）
  • エラーの原因は webApplicationFirewallConfiguration という レガシー WAF 構成 を使っていることにあり、WAF ポリシー方式への移行が前提 になっている

実際、Microsoft Q&A でも同様の質問に対して、「DRS 2.1 は WAF v2 North Europe でサポートされており、レガシー構成ではなく WAF ポリシーを使う必要がある」 と明示されています。

原因：レガシー WAF 構成と WAF ポリシー方式の違い

今回のエラー文に登場する properties.webApplicationFirewallConfiguration は、Application Gateway リソース直下に存在する 旧式（レガシー）の WAF 設定 を指しています。

現在の Azure WAF では、「WAF ポリシー」リソースにすべての設定を集約し、それを Application Gateway／リスナー／パスに関連付ける のが推奨かつ新しい構成です。

違いを整理すると、次のようになります。

項目レガシー WAF 構成
（WebApplicationFirewallConfiguration）		WAF ポリシー方式
（Firewall Policy リソース）
設定の保存場所Application Gateway リソース内部独立した WAF ポリシー リソース
関連付け範囲ゲートウェイ単位のみゲートウェイ全体 / リスナー単位 / パス単位で柔軟に設定可能
利用できるルールセットOWASP CRS 系のみ（3.2 まで）DRS 2.1（Microsoft_DefaultRuleSet）+ Bot Manager 等 最新機能
今後の新機能原則追加されない（レガシー）WAF ポリシー側に集約して追加される
Microsoft 推奨既存環境のみ・移行推奨新規は必ず WAF ポリシー方式

DRS 2.1 は RuleSetType = "Microsoft_DefaultRuleSet" を持つ Microsoft 既定ルールセット です。このルールセットは WAF ポリシーでのみ利用可能 で、レガシー構成の webApplicationFirewallConfiguration からは参照できません。そのため、エラー文の通り RuleSetType 'Microsoft_DefaultRuleSet' does not exist… というエラーが出てしまいます。

自分の Application Gateway が「レガシー構成」かを見分ける方法

現在の構成がレガシーかどうかは、Azure ポータルの画面で簡単にチェックできます。

  1. Application Gateway を開く
  2. 左メニューから [Web アプリケーション ファイアウォール] を選択
ポータルの見え方状態説明
「WAF ポリシー」の項目はなく、
ゲートウェイ直下に「ファイアウォール ステータス」「ルールセット」などが表示される		レガシー WAF 構成WebApplicationFirewallConfiguration に設定が保存されている状態
上部に「WAF ポリシー」が表示され、
ポリシーのリンクをクリックすると別画面に遷移する		WAF ポリシー方式DRS 2.1 などの最新のルールセットや機能を利用可能

さらに、ポータル上部に「レガシー WAF 構成を使用中。WAF ポリシーへアップグレード推奨」といったバナーが出ていれば、ほぼ確実にレガシー構成です。

解決策の全体像：DRS 2.1 を使うなら WAF ポリシー移行が必須

整理すると、解決のために必要なことはシンプルです。

  1. 既存のレガシー WAF 構成を、同等設定を持つ WAF ポリシーに移行 する
  2. 新しい WAF ポリシー側で DRS 2.1（Microsoft_DefaultRuleSet 2.1） を有効化する
  3. Application Gateway に対して WAF ポリシーを関連付け、WebApplicationFirewallConfiguration は無効化（null）する

Azure 公式ドキュメントでも、新しい WAF 構成はすべて WAF ポリシーに集約されるべきであり、既存の WAF 設定がレガシー側にある場合は「Migrate WAF Config to a WAF Policy」を使うよう案内されています。

移行前に確認しておきたいポイント（チェックリスト）

いきなりスクリプトを叩く前に、最低限次の項目は整理しておくと安全です。

確認項目内容おすすめ対応
WAF モード「検出（Detection）」か「防御（Prevention）」か移行直後は検出モードで挙動を観察すると安心
カスタムルールIP 制限 / Geo 制限 / 特定パスのみ Allow などどのルールが重要かを洗い出し、移行後も同等になるか確認
除外設定特定ヘッダー / クッキー / フィールドの検査除外誤検知が多いアプリほど重要。設定内容をメモしておく
対象アプリどのリスナー／パスがどのアプリに対応しているか将来的にリスナー単位・パス単位の WAF ポリシー分割を検討
ログ出力ApplicationGatewayFirewallLog の出力先Log Analytics / Storage / Event Hub などを確認し、移行後も同じく監視できるようにする

レガシー構成から WAF ポリシーへ：移行スクリプトの流れ

Microsoft は、レガシー WAF 設定を WAF ポリシーへコピーするための PowerShell ベースの移行スクリプトを提供しています。ドキュメントでは、既存構成をエクスポート → 同一設定を持つ WAF ポリシーの作成 → Application Gateway への関連付け という一連の流れが説明されています。

概念的な処理フローは次の通りです。

  1. Az モジュールと認証の準備
    • Connect-AzAccount でサインイン
    • 対象サブスクリプションを Select-AzSubscription で選択
  2. 既存 Application Gateway の取得
    • Get-AzApplicationGateway で WAF 構成を含むオブジェクトを取得
  3. 現在の WAF 設定のエクスポート
    • レガシー側のカスタムルール・除外・有効なルールセット情報を抽出
  4. 同等設定の WAF ポリシーを新規作成
    • 既存のモード（Detection/Prevention）、カスタムルール、除外設定をコピー
  5. Application Gateway に新しい WAF ポリシーを関連付け
  6. WebApplicationFirewallConfiguration を無効化（null）して完全にポリシー方式へ移行

移行スクリプトは、原則として無停止（トラフィックを止めず）で実行可能 です。ただし、ポリシー適用後の挙動確認のために、最初は WAF を検出モードにしてログを確認する運用が推奨されます。

DRS 2.1 を WAF ポリシーで有効化する手順（ポータル）

移行が完了し、Application Gateway に WAF ポリシーが関連付いている状態になったら、DRS 2.1 を有効化します。

  1. ポータルで WAF ポリシー リソースを開く
  2. [管理ルール]（Managed rules） を選択
  3. 「ルールセットの追加」または既存ルールセットの編集を行い、以下を選択
    • ルールセット種別（Rule set type）：Microsoft_DefaultRuleSet
    • バージョン（Rule set version）：2.1
  4. 必要に応じて Bot Manager 1.1 などの別ルールセットも有効化
  5. 保存し、ポリシーがデプロイされるのを待つ

Azure の公式ドキュメントでは、Application Gateway WAF の推奨ルールセットとして DRS 2.1 が案内されており、OWASP CRS 3.3.2 をベースに Microsoft Threat Intelligence による独自ルールが追加されている と説明されています。

PowerShell で DRS 2.1 を設定する最小例

ポータルからの設定に問題がある場合や IaC に組み込みたい場合は、PowerShell で直接 WAF ポリシーを更新することもできます。以下は、すでに存在する WAF ポリシーに DRS 2.1 を設定し、Application Gateway に関連付ける最小例です（リソース名は環境に合わせて変更してください）。

$rgName      = "<ResourceGroupName>"
$policyName  = "<WafPolicyName>"
$gwName      = "<ApplicationGatewayName>"

# 既存の WAF ポリシーを取得
$policy = Get-AzApplicationGatewayFirewallPolicy `
  -Name $policyName `
  -ResourceGroupName $rgName

# 先頭のマネージドルールセットを書き換え（必要に応じてインデックスを調整）
$policy.ManagedRules.ManagedRuleSets[0].RuleSetType    = "Microsoft_DefaultRuleSet"
$policy.ManagedRules.ManagedRuleSets[0].RuleSetVersion = "2.1"

# ポリシーを更新
Set-AzApplicationGatewayFirewallPolicy -InputObject $policy

# Application Gateway を取得
$gw = Get-AzApplicationGateway `
  -Name $gwName `
  -ResourceGroupName $rgName

# レガシー WAF 構成を無効化し、ポリシーを関連付け
$gw.WebApplicationFirewallConfiguration = $null
$gw.FirewallPolicy = $policy

# 設定反映
Set-AzApplicationGateway -ApplicationGateway $gw

ポイントは、レガシー構成を明示的に null にしておくこと です。これを行わないと、意図せず古い設定が残り、動作の切り替えが分かりづらくなります。

DRS 2.1 の特徴と OWASP 3.2 との違い

せっかく移行するのであれば、「なぜ DRS 2.1 を選ぶのか」を理解しておくと運用上の納得感が高まります。

項目OWASP 3.2（従来）DRS 2.1（Microsoft_DefaultRuleSet 2.1）
ベースOWASP CRS 3.2OWASP CRS 3.3.2 ベース
Microsoft 独自ルール一部 / なしMicrosoft Threat Intelligence による WebShell/CVE 対応ルールなどが追加
スコアリング方式バイナリ判定寄り（古いルールセット）アノマリースコアに基づきしきい値超過時にブロック（チューニングしやすい）
カバーする攻撃カテゴリSQLi / XSS など主要攻撃同様のカテゴリ＋最新 CVE、WebShell、Node.js などの追加検知
推奨度新規用途には非推奨（アップグレード推奨）Azure WAF が推奨する最新の既定ルールセット

Microsoft のドキュメントでも、新規に WAF ポリシーを作成する場合は「最新の推奨ルールセット DRS 2.1」を使うべき とされています。

DRS 2.1 へのアップグレード時に気をつけたい落とし穴

単にルールセットを切り替えるだけでも、思わぬ誤検知（false positive）が増えたり、逆に防ぎたい攻撃がすり抜けたりする可能性があります。特に、OWASP 3.2 → DRS 2.1 の移行では以下の点に注意しましょう。

1. ルールオーバーライド／除外設定の扱い

Azure のドキュメントによれば、ポータルでルールセットを切り替えた場合、既存ルールセットに対するルールオーバーライドやルール単位の除外設定はリセットされる 場合があります。

PowerShell でアップグレードする場合は、ドキュメントのサンプルのように 既存のルールオーバーライドを DRS 2.1 向けにマッピングし直すコード を組むことで、オーバーライドや除外を極力引き継ぐことが推奨されています。

2. 最初は Detection モードで運用する

DRS 2.1 に切り替えた直後は、いきなり Prevention モードで本番トラフィックをブロックするのではなく、一定期間は Detection モードで動かし、ApplicationGatewayFirewallLog を観察しながら除外・オーバーライドを調整 するのがおすすめです。

  • 新しく追加されたルール（特に MS-ThreatIntel 系）がどの程度ヒットするかを確認
  • 業務アプリ特有のパラメーターやヘッダーで誤検知が多い場合は、該当ルールを log のみにするか、除外設定を追加

3. マルチサイト構成では「範囲」を意識する

一つの Application Gateway に複数の Web アプリケーションを載せている場合、グローバルポリシーだけで運用すると、すべてのアプリで同じルールセットが適用されてしまう ため、誤検知のチューニングが難しくなります。

  • 静的コンテンツ中心のサイトはルールを軽めにする
  • 会員サイトや決済画面などは別の WAF ポリシーで厳しめのルールにする

といった形で、リスナー／パス単位の WAF ポリシー を活用すると運用負荷が大きく下がります。

よくある質問（FAQ）

Q1. 「North Europe だから DRS 2.1 が使えない」ということはありますか？

A. いいえ、ありません。 Microsoft Q&A でも、North Europe の WAF v2 で DRS 2.1 がサポートされていることが明記されており、今回のようなエラーはあくまで レガシー WAF 構成を使っていることが原因 と説明されています。

Q2. 「OWASP 3.2 は見えるのに、DRS 2.1 が選べない」のはなぜですか？

A. レガシー構成を使っているサイン です。レガシー構成では、OWASP 3.2 などの旧来の CRS ルールセットは選択できますが、Microsoft_DefaultRuleSet（DRS）系はポータルから選択肢として現れません。WAF ポリシー方式へ移行すれば、DRS 2.1 を含む Azure 管理ルールセットが利用できるようになります。

Q3. DRS 2.1 に切り替えたら、ログに「BLOCKING_EVALUATION」「949110」などのルールが見えます。正常ですか？

A. 正常なケースが多い です。WAF のログには、アノマリースコアによる評価ルール（BLOCKING_EVALUATION 系）や、評価用のルール ID（例：949110）が記録されることがあります。これらは、複数の検知結果をまとめて「しきい値超過」として扱うための仕組みであり、必ずしも単独で誤検知とは限りません。

個別のルール ID に対する調整（除外やオーバーライド）を行う際には、DRS 2.1 のルール一覧ドキュメントを参照しながら、どのルールグループ（SQLI / XSS / RCE など）に属しているか を確認しましょう。

Q4. 移行スクリプトを必ず使う必要がありますか？

A. 「DRS 2.1 を使いたい」かつ「既存の WAF 設定（除外・カスタムルール）を出来るだけ保ちたい」のであれば、事実上必須です。

  • 設定が少ない検証環境などでは、ポータルから「新規 WAF ポリシーを作成 → 手作業で設定コピー」でも構いません。
  • 本番環境で除外やカスタムルールが多い場合は、移行スクリプトを使って構成をコピーする方が安全で効率的 です。

まとめ：DRS 2.1 を使うなら、まずレガシー構成卒業から

この記事で取り上げた状況では、問題の本質は 「Application Gateway WAF v2 で DRS 2.1 がサポートされていない」ことではなく、「まだレガシー WAF 構成を使い続けている」 ことにありました。

  • DRS 2.1 は WAF v2 で正式サポートされており、Azure が推奨する最新のルールセット
  • エラー RuleSetType 'Microsoft_DefaultRuleSet' does not exist… は、レガシー構成（WebApplicationFirewallConfiguration）から DRS 2.1 を指定しようとしたことが原因
  • 解決策は、Microsoft 提供の移行スクリプトなどを用いて WAF ポリシー方式へ移行し、そのポリシーで DRS 2.1 を有効化すること

一度 WAF ポリシー方式へ移行してしまえば、DRS 2.1 だけでなく、今後追加される各種機能やルールセット も柔軟に活用できるようになります。これから Application Gateway WAF を運用していく上で、「レガシー構成からの卒業」 は避けて通れないステップです。

もし同じようなエラーやアドバイザリに悩んでいる場合は、まずは検証環境で WAF ポリシーへの移行と DRS 2.1 の有効化を試し、その挙動を確認してから本番環境に展開していくことを強くおすすめします。

Azure
WAF Azure Application Gateway DRS 2.1 Microsoft_DefaultRuleSet

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次