WafCharm導入前に必要なAWS WAFルールのプライオリティ設定の確認手順についてまとめてみた
この記事について
サイバーセキュリティクラウド社が提供する「WafCharm」というAWS WAFの運用支援サービスを導入すると、攻撃パターンに応じたルールが自動で作成・更新されます。
導入時の注意点として、AWS WAF上にWafCharm由来の新たなルールを作成するという特性から、「既存のWAFルールとプライオリティ（優先度）が競合して、ルールの適用に失敗する」 というケースが公式ブログで紹介されています。
今回は、このようなケースを事前に回避するために知っておくべきことや、事前準備の具体的な手順についてまとめてみました。
はじめに
WafCharmは、AWS WAF上に自動生成するルールに、あらかじめ決まったプライオリティ番号を割り当てます。
AWS WAFの既存ルール（カスタムルールやマネージドルール）が、その番号とかぶってしまうと競合が起き、導入しようとしたWafCharmのコンソール側で「設定エラー: 適用失敗」と表示されることがあります。
AWS WAFでは、1つのWeb ACL（ルールの入れ物）の中に複数のルールを入れられますが、その際、どのルールから順番に評価するかを決めるのがプライオリティです。（数字が小さいほど先に評価されます。）
この番号はWeb ACLの中で重複できません。ここが今回のポイントです。
この記事は 「問題が起きてから直す」のではなく、「導入する前に競合しない設計をしておく」 ことに絞って解説します。
エラーが出てからの直し方や、CLIでの細かい書き換え手順は、他の記事を文中で紹介させていただきます。
そもそも、なぜ導入時に競合するのか
理由はシンプルで、WafCharm由来のルールも既存ルールも、1つの同じWeb ACL内で、「同じ番号の並び」を共有しているからです。
WafCharmは自動生成するルールに予め定められた特定の番号帯を使いますが、既存のルールがたまたま同じ番号を使っていると、Web ACL内で重複が起きてエラーになってしまいます。
公開情報をもとにすると、番号の住み分けの目安は次のとおりです。
| 帯 | 用途 | 方針 |
|---|---|---|
| 0〜99 | 既存の独自ルール向け（推奨帯） | 自分たちのルールはこの帯に寄せる |
| 101〜421 | WafCharm が自動生成するルール（予約帯） | ここは使わない |
| 422〜 | 空き | 必要に応じて。ただし将来の予約拡張に注意 |
概念図だと以下のようなイメージです。
注意：上記の番号は公式の情報に基づく一例です。予約される範囲は仕様変更や契約プランで変わる可能性があるため、実際の導入時には最新の仕様を必ず確認してください。
導入前にチェックしておくべきこと
手順1：現行のルールと優先度を一覧化する
まず、対象のWeb ACLに今どんなルールが、どのプライオリティで入っているかを書き出します。
AWS CloudShellなどから次のコマンドで現状を取得できます。
現在のWeb ACLの設定を取得する（REGIONAL または CLOUDFRONT）
aws wafv2 get-web-acl \
--name <Web ACLの名前> \
--scope REGIONAL \
--id <Web ACLのID> \
--region ap-northeast-1
このコマンドは「今の設定を読み取るだけ」で、何も変更しません。
出力された情報の中のRulesに、各ルールのNameとPriorityが入っています。ここから棚卸し表を作ります。
手順2：棚卸し表を作る
次のような表に落とすと、競合が一目で分かります。
| ルール名 | 種別（独自/マネージド） | 現在の優先度 | 予約帯(101〜421)と衝突 | 移し先 |
|---|---|---|---|---|
| block-badbot | 独自 | 200 | 衝突 | 20 |
| allow-office-ip | 独自 | 150 | 衝突 | 10 |
| AWSManagedRulesCommonRuleSet | マネージド | 50 | OK | 50（据え置き） |
作るときのポイントは3つです。
- 予約帯（101〜421）と衝突している行に必ず印を付ける
- 独自ルールは、衝突していなくても 0〜99 の若い番号にまとめておくと将来も安全
- マネージドルールも、番号次第では移動が必要（移動方法は独自ルールと少し異なる。後述）
手順3：移し先の番号を決める
衝突している独自ルールを、0〜99の空いている番号に振り直します。
このとき、評価してほしい順番を意識して番号を付けます（先に効かせたいルールほど小さい番号に）。
ここまで机上で決めてから、実際の変更に入ることが重要です。
なお、AWS WAFは番号の小さいルールから順に「これは許可？ブロック？」と判定していきますが、一度マッチしたルールで結論が出ると、そこで評価が止まります。
そのため、一例としては以下のような並べ方があります：
- 許可したいもの（例：自社オフィスのIP）→ いちばん小さい番号
- 確実にブロックしたいもの（例：既知の悪性Bot）
- マネージドルール（AWSが用意した汎用的な検知）
- （このあとに WafCharm の自動ルールが入ってくる）
※順番を間違えると「許可したいIPがブロックされる」といった事故が起きます。番号は“空いているところ”ではなく“正しい順番”で決めましょう。
移し先が決まったら、実際にプライオリティを変更します。
変更の具体的な方法は、種別によって次のように使い分けます。
独自ルール：WAFコンソールのJSONエディタで、対象ルールのPriorityを0〜99の値に直接書き換える
マネージドルール：JSONエディタでは優先度を直接編集できないため、AWS CLIでPriorityを指定して更新する
※CLI で「プライオリティだけ」を安全に書き換える具体的な手順（get-web-acl → JSONを編集 → update-web-acl）は、既存の記事で解説されています。
導入後の確認
プライオリティ設定の変更とWafCharm導入が終わったら、次を確認します。
- WafCharmの管理画面で、ルールのステータスが 「適用失敗」になっていないこと
- Web ACLのプライオリティが、棚卸し表で決めた 意図どおりの並びになっていること（再度 get-web-acl で確認できます）
エラーが「適用失敗」として出てしまった場合の、原因がプライオリティ競合かどうかの切り分けと直し方は、WafCharm 公式ブログ（再掲）が参考になります。
まとめ
WafCharm導入時のプライオリティ競合は、着手前の設計で防ぐことができます。ポイントを再掲します。
- WafCharmの予約帯（公開情報の目安で 101〜421）を避け、独自ルールは0〜99に寄せる
- 導入前に棚卸し表を作り、予約帯と衝突する既存ルールを洗い出す
- 番号の予約範囲は変わりうるので、導入時に最新仕様を確認する
以上、この記事がどなたかの助けになれば幸いです。
参考
- Advanced RuleポリシーでStatusが「設定エラー: 適用失敗」となるケースへの対応方法例（Priority起因の場合）
https://www.wafcharm.com/jp/blog/if_status_in_advanced_rule_policy_has_apply_failed_error_caused_by_priority/ - WafCharmルールについて (AWS WAF v2)
https://console.wafcharm.com/ja/help/about_wafcharm_rules_aws_v2_ja - 【AWS WAF】ルールの優先度だけを変更する方法
https://dev.classmethod.jp/articles/how-to-change-only-the-priority-of-aws-waf/
