クラウドWAFのルール設計とチューニング
文書番号：2608.00004
要旨
クラウドWAFの調整では、ルールが一致したこと、最終的に通信が拒否されたこと、その通信が業務上必要だったことを区別する必要があるのだ。本稿はAWS WAF、Google Cloud Armor、Azure WAFを対象に、ルールの構造と評価の流れを比較し、選定、観測、誤検知分析、例外設計、遮断移行、更新と復旧を一つの手順として整理するのだ。
AWSでは内部ルールのアクションとラベル、Cloud Armorでは攻撃カテゴリの式と感度・検査フィールド除外、Azureではルールセットと異常スコアなど、調整する単位が異なるのだ。製品の用語を一対一に置換するより、何を検査から外し、何を観測し続け、どこで最終判断するかへ分解すると、移行時の防御範囲を説明できるのだ。
対象読者はWeb/APIのWAF設計・運用担当者なのだ。製品仕様は2026年10月11日に確認した公開資料に基づく時点記録なのだ。構成、検索API、変更票は説明用の例であり、実測した検知性能や全環境へ適用できる推奨設定ではないのだ。
1 保護対象 ｜ 2 評価の構造 ｜ 3 ルールと容量 ｜ 4 観測と分類 ｜ 5 例外設計 ｜ 6 同一要件の比較 ｜ 7 遮断と復旧 ｜ 8 更新管理 ｜ 9 移行と運用記録
第1章 保護対象とチューニングの目的
1.1 守る業務と許可する通信を先に決める
マネージドルールは、提供者が維持する攻撃検知ルールを利用する仕組みなのだ。利用者は、対象業務、適用する通信、ルールの有効状態、一致時の動作、例外、更新方法を決めるのだ。SQLを使う検索APIと、ファイルを受け付ける申請画面では、正常入力も誤遮断の影響も異なるのだ。
最初に、保護対象のHostとPath、Method、入力形式、利用者、重要操作、利用サイクルを一覧にするのだ。公開経路とWAFの関連付けを対応付け、WAFを迂回する入口がある場合は別の対策を決めるのだ。正常通信の仕様そのものをコードへ同期する設計はWAFの継続的強化と防御検証で扱うのだ。
| 業務 | 正常通信の特徴 | 調整前に確かめること |
|---|---|---|
| ログイン・認証連携 | 署名値、長いToken、リダイレクト | 認証成功率、外部IdPとの往復 |
| 検索・自由記述 | 引用符、技術用語、コード片 | 許容する入力とサーバー側処理 |
| 注文・決済 | 認証状態、外部連携、再送 | 二重処理、失敗時の復旧 |
| 添付・一括取込 | 大きな本文、multipart、CSV | サイズ上限、ファイル処理、低頻度の正規操作 |
| 監視・提携API | 非ブラウザー、固定形式、定期実行 | クライアント認証、送信元、Challengeの適否 |
1.2 調整の成功条件を分ける
正常通信を通すために検査を広く外せば、業務は回復しても防御範囲が縮むのだ。逆に遮断件数が増えても、それが正規利用者なら改善とは言えないのだ。成功条件は、正常業務の維持、必要な攻撃検知、理由を説明できるログ、再現可能な変更と復旧の四つへ分けるのだ。
試験対象は現行設定と候補設定でそろえ、正常系と攻撃系の両方を比較するのだ。検査上限を超える部分、除外した入力、記録できない経路は、試験結果と合わせて残すのだ。誤検知率の母集団とケース設計はWAF誤検知検証ツール設計を参照するのだ。
1.3 比較する製品と対象外
AWS WAF、Cloud Armor、Azure WAFのマネージドルールを中心に比較するのだ。AzureはApplication GatewayとFront Doorを区別するのだ。WAF全体の選定にはDDoS、Bot、API、配置、契約、支援体制も関係するため、その判断はWAF・WAAP 6製品の選定条件とPoCへ分けるのだ。
第2章 ルール一致から最終判定までの構造
2.1 同じ設計判断が異なる階層へ置かれる
| 設計判断 | AWS WAF | Cloud Armor | Azure WAF |
|---|---|---|---|
| ルールをまとめる | Web ACLからManaged Rule Groupを参照 | Security Policyの式からカテゴリを呼ぶ | WAF PolicyへManaged rule setを追加 |
| 適用する通信を絞る | Scope-downなど | 式の条件と優先順位 | Policyの関連付けと製品別機能 |
| 個別検知を調整する | RuleActionOverrides | 感度、signature ID、除外 | 個別ルール、アクション、除外 |
| 検知結果を利用する | ラベルを後続ルールへ渡す | 一致するPolicyルールの動作 | 異常スコアや個別Action |
| 非遮断で観測する | 内部ルールのCountなど | Preview | DetectionやLog |
この表は機能が完全に同じという意味ではないのだ。例えば、Policy全体をDetectionにする設定と、一つの内部ルールだけをCountにする設定では、観測中も維持できる防御が異なるのだ。対象となる階層と評価順を確認して使うのだ。
2.2 AWS：内部ルールと後続評価
AWS WAFではWeb ACLのルールからManaged Rule Groupを参照し、その内部に提供者のルールがあるのだ。Web ACL側で内部ルールのActionを上書きしても、提供元のグループ自体は変更されないのだ。1
Web ACL
├─ ManagedRuleGroupStatement
│ ├─ Name / Version
│ ├─ ScopeDownStatement
│ └─ RuleActionOverrides
│ └─ 対象の内部ルールをCountへ変更
├─ ラベルとPathなどを組み合わせる後続ルール
└─ Default action
検知をCountへ変更し、付与されたラベルを後続ルールで評価する設計では、検知と最終的な遮断条件を分けられるのだ。ただし、前段で終端Actionが成立すると後段まで進まないため、ラベルを使うルールの順序と前段Actionを合わせて確認するのだ。
グループの戻り値だけをCountへ上書きするOverrideActionと、内部ルールをCountへ変えるRuleActionOverridesは別なのだ。前者では内部の最初の終端一致でグループ評価が止まり、後続の内部ルールをすべて観測できるわけではないのだ。内部ルールの試験では個別Actionの上書きを使うというAWSの説明に沿って、設定の意味を確認するのだ。1
2.3 Cloud Armor：カテゴリの式と優先順位
Cloud Armorでは、Security Policyの一致条件からevaluatePreconfiguredWaf()を呼び、SQLi、XSSなどのカテゴリを評価するのだ。次はCRS 4.22系のSQLiルールを感度1で使う式の例なのだ。23
evaluatePreconfiguredWaf('sqli-v422-stable', {'sensitivity': 1})
sensitivityは指定値以下の感度に属するシグネチャを有効にするのだ。基本集合から外す場合はopt_out_rule_ids、感度0から選択的に加える場合はopt_in_rule_idsを使うのだ。これは攻撃らしさの得点を全要求へ付ける設定ではなく、評価するシグネチャ集合の選択なのだ。2
Policyの優先順位、Action、Previewを合わせて管理するのだ。一つの式へ多くのカテゴリを束ねると、原因の追跡や個別調整が難しくなるため、カテゴリと命名・優先度の対応を記録する設計にするのだ。Previewで観測する候補と本番で強制する既存ルールの関係も確認するのだ。4
2.4 Azure：Policyと異常スコア
Azure WAFでは、Application GatewayとFront Doorで、関連付ける場所、利用機能、ルールセットを確認するのだ。Application GatewayのDRS 2.2はOWASP CRS 3.3.4を基礎とするルールセットであり、Microsoft独自の保護を含むのだ。版や有効状態は対象Policyで確定するのだ。5
Application Gatewayの異常スコア方式では、一致したルールの重大度に応じて点数が加算されるのだ。Criticalは5、Errorは4、Warningは3、Noticeは2で、閾値5に達するとPreventionで遮断されるのだ。Detectionでは記録しながら通信を通すのだ。6
個別一致A：Warning +3
個別一致B：Notice +2
↓
合計5へ到達
↓
Preventionでは遮断／Detectionでは記録
この例ではAだけなら閾値へ届かず、Bとの組合せで遮断へ進むのだ。調査では個別一致と最終Actionを同じ要求へ関連付ける必要があるのだ。すべてのルールが同じ方式で動くと仮定せず、対象ルールのAction上書きや、利用するAzure実装の仕様を確認するのだ。
第3章 保護要件からルールと容量を選ぶ
3.1 技術スタックと入力面を選定へ反映する
AWS Managed RulesにはBaseline、用途別、IP reputation、Botや不正利用に関係するグループがあるのだ。全グループを一律に追加するより、アプリケーションの技術と業務へ対応付けて選ぶのだ。名称・対応機能・料金・設定要件は公式一覧と対象環境で確認するのだ。7
| 条件 | AWSで確認するグループの例 | 確認する業務条件 |
|---|---|---|
| 一般的なWeb入力 | CommonRuleSet、KnownBadInputsRuleSet | 自由記述、サイズ、既存の正常入力 |
| SQLを扱う入力 | SQLiRuleSet | 検索条件とサーバー側の安全な処理 |
| Linux・Unix・Windows | LinuxRuleSet、UnixRuleSet、WindowsRuleSet | 実際の技術スタックと露出する入力 |
| PHP・WordPress | PHPRuleSet、WordPressRuleSet | 管理画面、プラグイン、投稿形式 |
| 管理画面 | AdminProtectionRuleSet | 正規公開する管理Pathと認証 |
| 送信元の評価 | AmazonIpReputationList、AnonymousIpList | VPN、監視、共有回線の正規利用 |
| 不正ログイン・登録 | ATPRuleSet、ACFPRuleSet | 対象Endpointと製品が求める設定 |
| Bot・大量要求 | BotControlRuleSet、AntiDDoSRuleSet | クライアント種別、負荷、追加費用 |
表の名称はAWSManagedRules接頭辞を省略しているのだ。存在する機能をすべて有効にする表ではなく、選定時に確認する候補なのだ。高度なBot管理の必要性は、業務上の損失から判断する記事へ接続するのだ。
3.2 AWSのWCUと構成例
WCUはルール評価の容量であり、通信量やルール数そのものではないのだ。確認時点のWeb ACL上限は5,000 WCUなのだ。上限内であることと、費用や保守負荷が妥当であることは別に判断するのだ。8
次表は公開資料のWCUを使った計算例なのだ。導入時は対象版をDescribeManagedRuleGroupなどで確認し、追加するカスタム条件も含めてCheckCapacityで照合するのだ。9101112
| 説明用の構成 | 内訳 | グループ合計WCU |
|---|---|---|
| 一般Web | Common 700 + KnownBadInputs 200 + SQLi 200 + AmazonIpReputation 25 + AnonymousIp 50 | 1,175 |
| 管理画面を持つWeb | Common 700 + AdminProtection 100 + KnownBadInputs 200 + SQLi 200 + AmazonIpReputation 25 | 1,225 |
| WordPress | Common 700 + KnownBadInputs 200 + SQLi 200 + PHP 100 + WordPress 100 + AmazonIpReputation 25 | 1,325 |
これらは例外用ルール、Scope-down、ラベル照合などを加える前の値なのだ。Scope-down自体の追加料金という意味ではなく、その中に定義する条件のWCUを計算するのだ。文字列変換や追加条件も含めて、最終的なルール集合を評価するのだ。13
余力は一律の「安全なWCU帯」で決めず、予定する例外、緊急ルール、次の版への更新に必要な容量から設計するのだ。容量が足りない場合も、Web ACLを分ければ同じ通信へ同じ保護を掛けられるとは限らないため、関連付けるリソースと適用範囲から見直すのだ。
3.3 Cloud ArmorとAzureの選択単位
Cloud Armorでは、対象カテゴリとルールセット世代、感度、必要な署名を決めるのだ。まず対象の正常通信を評価できる集合を選び、感度を変えた際に増える一致を記録するのだ。感度を下げて誤検知を回避した場合は、外れたシグネチャ集合も確認するのだ。2
Azureでは対象実装のDRS、版、有効ルール、Action、除外を一組として確定するのだ。Application GatewayのDRS 2.2ではPL2のルールが既定で無効という条件があるのだ。PL2を使う際はログで分析して調整するという提供者の手順に沿い、PLの違いを独自の危険度得点として解釈しないのだ。5
第4章 非遮断で観測し、業務と照合する
4.1 観測範囲と期間を決める
新しいルールや変更候補は、試験環境で調整した後、非遮断で実通信を観測するのだ。既存の防御を全体で無効にするのではなく、候補の対象と観測方法を決めるのだ。AWSのCount、Cloud ArmorのPreview、AzureのDetectionは名称だけでなく適用階層が異なるため、設定前後の防御範囲を記録するのだ。1446
観測期間は日数だけで決めず、平日・休日、月次処理、請求、販売開始、外部連携などの利用条件を確認するのだ。観測できない低頻度機能は、再現試験と業務担当者の確認で補うのだ。期間中に一致がなかったことだけで、そのルールが正常通信へ影響しないと結論にしないのだ。
4.2 要求、一致、最終動作をつなぐ
| 記録群 | 確認する情報 | 使う目的 |
|---|---|---|
| 要求 | Host、Path、Method、時刻、相関ID | 同一要求を各層で照合する |
| 検知 | ルールセット、版、個別ID、対象入力 | 何に一致したかを調べる |
| 評価 | ラベル、スコア、優先順位、Action | 一致から最終動作への過程を調べる |
| 業務 | 操作、利用者区分、認証状態、成功・失敗 | 正常性と影響を判断する |
| 観測条件 | ログ設定、サンプリング、保持期間 | 見えていない範囲を残す |
AWSのsampled requestsは初期の傾向把握に使い、全件記録として扱わないのだ。詳しい調査ではWAFログやアプリ側の記録を使い、記録される項目とマスキングの設定を確認するのだ。本文やTokenを必要以上に保存せず、調査に必要な入力位置と再現可能な匿名化例を残すのだ。1516
4.3 一致した要求を分類する
| 分類 | 調べること | 処置候補 |
|---|---|---|
| 攻撃と確認 | 悪用条件と対象業務 | 遮断、回帰試験への追加 |
| 正常通信 | 承認仕様と業務成功 | 狭い例外、設定修正 |
| 監視・診断 | 実行者、期間、対象 | 条件付きの扱いを定義 |
| 正規Bot・提携処理 | 認証、クライアント、用途 | 対象経路の制御を調整 |
| 必要だが攻撃に似る入力 | 自由記述、コード、添付 | 対象ルールと入力面を絞って調整 |
| 判断保留 | 仕様やログの不足 | 観測継続、担当へ確認 |
検索欄にSQLの用語があるだけで攻撃と決めず、アプリが何を受け付ける機能かを確認するのだ。一方、過去に通っていたことだけで正規の仕様とみなさず、所有者と利用目的を確かめるのだ。
第5章 例外が変える防御範囲を設計する
5.1 調整方法によって失う検査が異なる
| 調整 | 変わるもの | 確認すべき残存防御 |
|---|---|---|
| 個別Actionを非遮断へ変更 | 一致後の動作 | 検知ログと後続の判定 |
| 個別シグネチャを無効化 | その検知自体 | 他ルールが何を検知できるか |
| 入力フィールドを除外 | 検査するデータ | 残る入力面と除外値の補完制御 |
| グループの適用範囲を限定 | グループへ渡す要求 | 対象外要求を検査する別の制御 |
| 先行するAllow | 後続評価までの到達 | 以後の検査を飛ばす範囲 |
「例外」という名称が同じでも、要求全体を通すのか、一つの値だけを検査対象から外すのかで影響が変わるのだ。選択肢は狭いものから検討し、製品がその単位を表現できるか確認するのだ。
5.2 AWSのScope-downとラベル
Scope-downは、グループへ渡す要求の集合を絞る条件なのだ。特定の検索PathをScope-downで外せば、その要求は当該グループの評価対象外になるのだ。内部ルールが見る特定フィールドだけを外す機能として扱ってはいけないのだ。Scope-down内の文字列変換もグループ本体へ継承される前処理ではないのだ。13
特定の内部ルールだけが誤検知する場合は、そのルールをCountへ変更し、ラベルとPathなどを組み合わせる後続ルールを検討するのだ。これにより他の内部ルールを維持できる場合があるのだ。ただし、そのラベルに対応する検知を許可する条件が広いほど、同じ条件内の攻撃も拒否しなくなるのだ。正常要求が通ることと、別の攻撃が引き続き止まることを分けて試験するのだ。
5.3 Cloud Armorの署名除外とフィールド除外
Cloud Armorでopt_out_rule_idsを使うと、対象シグネチャを評価集合から外すのだ。一方、フィールド除外は、対象ルールの検査からHeader、Cookie、Queryなどの指定部分を外すための設定なのだ。除外対象、対応するルールセット、signature IDを明確にするのだ。フィールド除外を持つWAFルールにはallowを使えない制約もあるのだ。17
例えば検索条件のQuery値だけが誤検知する場合、SQLiカテゴリ全体の感度を下げる前に、対象の署名と入力値を特定するのだ。フィールド除外で必要な範囲を表現できるなら、その範囲に限定して再試験するのだ。別フィールドに置いた同種の攻撃まで検査されなくなっていないかも確認するのだ。
5.4 Azureの除外とスコアへの影響
Azureでは対象実装の除外機能を確認し、個別ルール、ルールグループ、ルールセットのどこへ適用するかを選ぶのだ。Front Doorの除外は指定属性を評価から外す仕組みであり、要求の残りを検査する範囲を保てるのだ。Application Gatewayの設定へそのまま転記せず、それぞれの対応項目を確認するのだ。1819
異常スコア方式では、除外やルール無効化によって加算される点が変わるのだ。正常要求の最終遮断が解消しても、別の攻撃で必要な閾値に達するかを確認するのだ。個別一致の減少だけで調整成功とせず、最終Actionとアプリ側の業務結果まで照合するのだ。
第6章 同じ検索APIを三つの製品で調整する
6.1 共通の要求と試験条件
架空のGET /api/searchで、Queryのfilterへ技術文書の検索語を入力できるとするのだ。正常な検索にSQL用語が含まれ、SQLiルールが一致した状況を想定するのだ。サーバー側では入力検証と安全なDBアクセスを維持し、WAFの例外をアプリの脆弱性修正の代わりにしないのだ。
調整前に、正常検索、同じPathの別パラメーター、別Path、明確に拒否すべき試験要求を固定するのだ。現行設定で、どの個別ルールが一致し、最終的にどこで拒否されたかを記録するのだ。以下は設定判断の例であり、そのまま配備する完成設定ではないのだ。
6.2 AWSで内部ルールの動作を分ける
- SQLiを含む対象グループと版を記録するのだ。
- 誤検知した内部ルールを特定し、必要なルールを個別にCountへ上書きして一致を確認するのだ。
- 付与されたラベルとPath・Methodなどを後続ルールで評価する案を作るのだ。
- 正常検索の許可条件と、その外側で遮断する条件を明示するのだ。
- 他の内部ルール、別Path、別入力の防御を再試験するのだ。
/api/search全体をグループから除外する案は、そのPathで当該グループの検査全体を失うのだ。特定フィールドだけの例外を意図しているなら、この案との差を明記するのだ。ラベルを用いる案でも、例外条件内の同じ検知を免除する残余リスクは残るのだ。
6.3 Cloud Armorで対象署名と入力面を絞る
- SQLiカテゴリの式、ルールセット世代、感度、優先順位を記録するのだ。
- Previewで一致したsignature IDと入力面を確認するのだ。
- 対象Queryをフィールド除外へ指定できるか確認するのだ。
- 署名全体のopt-outが必要なら、その署名が検査しなくなる範囲を記録するのだ。
- Preview候補と既存の強制ルールの両方を確認し、正常・異常の試験を再実行するのだ。
感度を下げる方法は対象署名以外も評価から外れる場合があるのだ。filterだけの問題を解くために、カテゴリ全体の防御をどこまで変えたかを見失わないようにするのだ。
6.4 Azureで個別一致と最終スコアを追う
- Application GatewayかFront Doorかを確定し、PolicyとDRS版を記録するのだ。
- 同じ要求の個別一致と最終Actionを照合するのだ。
- 対象実装で
filterの値を該当ルールだけの除外へ指定できるか確認するのだ。 - 除外後に残る個別一致とスコアを確認するのだ。
- 正常検索の成功と、攻撃試験の最終遮断をそれぞれ確かめるのだ。
例えば正常要求のスコアが複数の一致から生じていた場合、一つのルールだけを調整しても拒否が続くことがあるのだ。最終的に拒否されたという結果から一つのルールを推測せず、要求単位で加算過程を追うのだ。
6.5 比較から得られる設計上の結論
同じ「正常な検索を通す」という要件でも、内部Actionの変更、フィールド除外、スコアの変化という異なる過程を通るのだ。したがって、どの製品が一律に細かいかではなく、要求をどの単位で表現でき、何を検査し続けられるかを比較するのだ。
この比較例の成果物は、設定名の対応表だけではないのだ。調整前後で通す正常要求、止める試験要求、検査を失う条件、観測するログを一組にした設計書なのだ。
第7章 遮断への移行と復旧
7.1 段階移行の判断材料
図はAWSの用語で表した運用サイクルなのだ。他環境でも対象、観測、例外、試験、承認、復旧という判断を対応付けるのだ。全ルールを一括で遮断へ移すより、影響と根拠が確認できた範囲から適用する設計にするのだ。
| 状態 | 判断 | 必要な確認 |
|---|---|---|
| 明確な攻撃で業務上不要 | 遮断候補 | 対象と誤検知の可能性 |
| 正常入力への一致がある | 調整を継続 | 例外範囲と残る防御 |
| 正常系試験は通るが観測が不足 | 限定適用または観測継続 | 未確認の利用サイクル |
| 重要操作の仕様が不明 | 担当確認を優先 | ログイン、申込、決済などへの影響 |
| 送信・ログの失敗で判定不能 | 試験基盤を修正 | 再現と相関の成立 |
観測期間中に一致がなかったことは判断材料の一つなのだ。正常利用を代表する試験、業務担当者の確認、復旧可能性と組み合わせて承認するのだ。
7.2 復旧条件を適用前に決める
変更前の設定を保存し、どのルールを非遮断へ戻すか、どの除外を取り消すか、誰が実行するかを決めるのだ。重要操作の成功率、4xx、問い合わせ、外部連携の失敗などから、停止・復旧の判断条件を対象業務に合わせて設定するのだ。
4xxの増加だけではWAF障害と断定せず、WAFの最終Actionとアプリの失敗を照合するのだ。復旧時は影響する最小範囲を戻し、元の防御を維持できるか確認するのだ。変更を戻すAPIが成功したことだけでなく、正常要求の回復と設定反映を確認して完了とするのだ。
7.3 上限超過と更新伝播を含めて試す
Bodyの検査上限は統合先や設定に依存するのだ。AWSでは上限超過時の評価方法を選ぶため、サイズ超過を許可するのか拒否するのかを、個別ルールのActionと合わせて確認するのだ。通常サイズだけでなく、上限直前・直後、大きな添付、本文後半に条件を置いた試験も用意するのだ。20
設定変更の伝播中には一時的な不整合が起こり得るため、反映直後の結果には実行時刻と対象経路を残すのだ。AWSの資料も変更の反映に数秒から数分を要する場合を説明しているのだ。14
第8章 ルール更新と例外の継続管理
8.1 提供者の更新を変更管理へ取り込む
| 製品 | 確認する更新単位 | 自社で維持する情報 |
|---|---|---|
| AWS | 利用グループの版、既定版、期限、変更内容 | 内部Action上書き、ラベル依存、容量 |
| Cloud Armor | ルールセット世代、stable・canary、署名 | 式、感度、opt-in/out、フィールド除外 |
| Azure | DRS世代、サポート状況、ルール変更 | 有効状態、Action、除外、対象実装 |
AWSでは版管理に対応するグループの更新を追い、対象版と既定版への追随を確認するのだ。Cloud Armorでは候補をPreviewで評価し、安定して強制するルールと分けるのだ。Azureではルールセット変更時に上書きや除外を再適用する必要があるため、画面で版を変える操作だけを更新完了としないのだ。2145
Azureのサポート方針では最新の複数世代を対象とするため、採用時と更新時に現行方針を確認するのだ。サポート対象内でも自社の正常通信への影響確認は必要なのだ。22
8.2 新版と旧版の差を同じ通信で確かめる
変更差分には追加・変更・廃止された検知、既定Action、有効状態、上限、除外の扱いを含めるのだ。版ごとに異なる入力を使うとルールの差と通信の差が混ざるため、同じ正常・異常試験集合を使うのだ。
新版で正常通信が通った場合も、旧版で必要だった例外を自動的に残さず、削除可能かを試験するのだ。反対に、旧版の例外を名称だけで引き継ぐと、対応するルールが変わった場合に意図を失うのだ。例外の理由と再現要求から読み直すのだ。
8.3 例外の所有者と期限を維持する
例外は、対象、理由、所有者、承認日、期限、補完制御、再試験条件を持つ構成情報として扱うのだ。アプリの入力仕様変更、ルールセット更新、クライアント廃止、障害対応の終了を再評価の契機にするのだ。
Countのまま残す場合も、観測の目的と次の判断時点を決めるのだ。検知を残していることと遮断していることは異なるため、運用報告には非遮断の対象範囲を示すのだ。
第9章 製品移行と実務記録
9.1 設定名よりも防御の意味を移す
移行では、対象通信、検査面、署名の選択、個別Action、評価順、最終判定、例外、更新条件を移行元から取り出すのだ。移行先が同じ条件を表現できない場合は、その差を追加制御や残余リスクへ対応付けるのだ。
AWSのラベルを使った後続判断を、別製品の広いAllowへ置換すると、検査を維持する意図が変わる場合があるのだ。Azureの個別一致を単独遮断と読み替えると、スコアの合成を失うのだ。Cloud Armorの感度を他製品の危険度へ機械的に置換することも避けるのだ。共通の試験要求を移行前後へ送って、許可・拒否と観測範囲の差を確認するのだ。
9.2 変更票と確認項目
| 記録項目 | 残す内容 |
|---|---|
| 対象 | 環境、関連付け先、Host、Path、Method、業務 |
| 設定 | Policy、ルールセット、版、個別ID、優先順位 |
| 変更 | Action、感度、除外、ラベル条件などの前後差 |
| 理由 | 業務仕様、誤検知、攻撃条件、提供者の更新 |
| 証拠 | 再現要求、WAFログ、最終Action、業務結果 |
| 影響 | 検査しなくなる範囲、容量、費用、利用者 |
| 承認と復旧 | 担当、適用時刻、停止条件、戻す設定 |
| 継続管理 | 例外の期限、次回試験、未確認事項 |
導入前は保護経路、関連付け、正常業務、ログ、容量を確認するのだ。観測中は個別一致と業務を照合し、遮断前は例外後の正常系・攻撃系と復旧を確認するのだ。更新後は実際に反映された版とActionを取得し、変更票との差を確認するのだ。
9.3 確認課題と結論
設計の確認には、検索の正常入力がSQLiへ一致した場合、添付がBody上限を超えた場合、複数の個別一致でAzureの閾値へ達した場合、AWSの先行ルールで評価が終わった場合を使うのだ。それぞれで、調査するログ、最小の調整、失う検査、再試験、復旧を説明できるか確かめるのだ。
クラウドWAFのチューニングは、個別設定を増やす作業ではなく、業務上必要な通信と必要な防御を両立させる変更管理なのだ。製品ごとの評価構造を理解し、要求から一致、最終Action、業務結果までを追い、例外と更新後の状態を同じ証跡で確認するのだ。