AWS WAF・Google Cloud Armor・Azure WAFのマネージドルール設計比較

AWS WAF、Google Cloud Armor、Azure WAFのマネージドルール構造、調整単位、導入手順を比較した詳細図

先に結論

3大クラウドのマネージドルールは、同じような攻撃を検知するが、組み立て方は同じではない。

製品	基本構造	調整の中心	設計上の特徴
AWS WAF	Web ACLからManaged Rule Groupを参照	内部ルールのアクション上書き、Scope-down、ラベル	検知結果を後続ルールへつなぎやすい
Google Cloud Armor	Security Policyルールの式から攻撃カテゴリ別ルールセットを呼ぶ	sensitivity、signature ID、リクエストフィールド除外、CEL条件	設定が明示的だが、カテゴリごとのルールが増える
Azure WAF	WAF PolicyへDRSなどのManaged rule setを追加	ルール／グループ単位の状態・アクション・除外	複数検知を異常スコアとして合算する

AWS WAFを基準に読むなら、Azure WAFは比較的近い。大きなルールセットをポリシーへ追加し、その内側を調整するからだ。

Google Cloud Armorは発想が異なる。SQLインジェクション、XSS、RCEなどの事前構成WAFルールを、Security Policyの一致条件として個別に呼び出す。したがって「AWSより複雑だが詳細にチューニングできる」とだけ表現するのは正確ではない。

より正確な結論は次なのだ。

Cloud Armorは、AWS WAFより設定が展開され、カテゴリ別の適用条件と感度を明示しやすい。一方、内部ルール別アクションや検知ラベルを使った後続処理まで含めると、AWS WAFの方が柔軟な部分もある。Azure WAFはAWSに近い管理構造を持つが、異常スコアリングによって遮断判定の考え方が異なる。

この記事は製品全体の優劣ではなく、2026年8月3日時点の「マネージドルールの作り」を比較する。DDoS、Bot管理、API発見、料金を含む総合比較は「6大WAF総合比較 2026」へ分ける。

まず共通部分を押さえる

どの製品でも、マネージドルールはベンダーが維持する複数シグネチャの集合である。利用者が書くのは攻撃検知ロジックそのものではない。次の判断をポリシーとして与える。

どのルールセットを使うか
どの通信へ適用するか
どの内部ルールを有効または無効にするか
一致したときに記録、遮断、Challengeなどの何を行うか
誤検知するフィールドをどこまで検査対象から外すか
更新版をいつ、どのように受け入れるか

違いは、この六つをどの階層へ配置するかにあるのだ。

AWS WAF：マネージドルールグループをWeb ACLへ追加する

構造

AWS WAFでは、Web ACLの一つのルールとしてManaged Rule Groupを参照する。

Web ACL
└─ Rule
   └─ ManagedRuleGroupStatement
      ├─ VendorName
      ├─ Name
      ├─ Version
      ├─ ScopeDownStatement
      ├─ RuleActionOverrides
      └─ ベンダーが管理する内部ルール

AWS Managed Rulesのほか、AWS Marketplaceのルールグループも同じ概念で扱う。バージョン対応グループでは、特定バージョンを固定するか、既定バージョンへ追随するかを選べる。AWS公式：マネージドルールグループ

作り方

典型的な初期構成は次になる。

Web ACL
├─ AWSManagedRulesCommonRuleSet
│  ├─ 全体をCountで検証
│  └─ 誤検知する内部ルールだけCountへ上書き
├─ AWSManagedRulesKnownBadInputsRuleSet
├─ AWSManagedRulesSQLiRuleSet
└─ Default action: Allow

ルールグループ全体の評価対象を限定したい場合は、ScopeDownStatementを使う。たとえば特定ホスト、パス、国、ヘッダーに一致するリクエストだけを有料ルールグループへ渡せる。Scope-downは前処理ではなく、グループへ渡すリクエストの選別である。AWS公式：Scope-down statement

チューニングの強み

内部ルールのアクションはRuleActionOverridesで上書きできる。Countだけでなく、そのルールで有効なBlock、Allow、CAPTCHA、Challengeなどへ変更できる。上書きは参照先のルールグループ自体を変えず、そのWeb ACLでの使い方だけを変える。AWS公式：ルールグループのアクション上書き

もう一つの重要な差はラベルである。AWS Managed Rulesはラベルをサポートし、後続のLabel match ruleでURI、IP、国、別ラベルなどと組み合わせられる。AWS公式：AWS Managed Rules一覧

SQLiルールが一致してラベルを付与
          ↓
管理画面のパスならBlock
          ↓
その他のパスならCountで観測

検知と最終判断を分離できるのが、AWS WAFの設計上の強みなのだ。

注意点

ルールグループ、内部ルール、ラベル依存、優先順位が増えると全体像を追いにくい
Scope-downは内部シグネチャの検査フィールドを変更しない
バージョン更新時は新規・変更・廃止ルールと有効期限を確認する
Countへ上書きした内部ルールは遮断しないため、ログだけでなく後続ルールも確認する

Google Cloud Armor：攻撃カテゴリを一致条件として呼び出す

構造

Cloud Armorでは、Security PolicyルールのCEL式からevaluatePreconfiguredWaf()を呼び出す。

Security Policy
├─ Priority 1000
│  ├─ Match: evaluatePreconfiguredWaf('sqli-v422-stable', ...)
│  ├─ Action: deny-403
│  └─ Preview: true / false
├─ Priority 1010
│  ├─ Match: evaluatePreconfiguredWaf('xss-v422-stable', ...)
│  └─ Action: deny-403
└─ Default rule: allow

2026年8月3日時点では、CRS 4.22系にSQLi、XSS、LFI、RFI、RCE、メソッド強制、スキャナー検知などのstableとcanaryルールがある。Google Cloudは、ワークロードが対応できるなら古いCRS 3.0を避け、CRS 4.22を使うことを推奨している。Google Cloud公式：事前構成WAFルール

作り方

SQLiルールセットを感度1で作る最小例は次になる。

evaluatePreconfiguredWaf(
  'sqli-v422-stable',
  {'sensitivity': 1}
)

sensitivityは1から4で、指定値以下の感度に属するシグネチャを有効にする。0では自動選択を止め、opt_in_rule_idsで指定したシグネチャだけを有効にできる。基本集合から例外を外す場合はopt_out_rule_idsを使う。Google Cloud公式：事前構成WAFルールの設定

基本集合を使う
  sensitivity: 1

基本集合から一部を外す
  sensitivity: 1 + opt_out_rule_ids

許可リスト方式で始める
  sensitivity: 0 + opt_in_rule_ids

Google Cloudは、一つのSecurity Policyルールにつき一つの事前構成WAF式を使うことを推奨している。論理ORで複数カテゴリを束ねることはできるが、式の最大サイズと運用上の追跡性を考えると、SQLiとXSSを別優先度へ置く方が読みやすい。

チューニングの強み

感度で基本集合を段階的に選び、signature IDで追加または除外できる。さらに、特定ヘッダー、Cookie、クエリパラメータなどを検査対象から外すリクエストフィールド除外を設定できる。

CEL条件と組み合わせれば、ホスト、パス、送信元などで適用範囲を明示できる。カテゴリごとにSecurity Policyルールが分かれるため、「どの攻撃カテゴリを、どの範囲へ、どのアクションで適用したか」は画面やIaC上に展開されるのだ。

AWSより詳細なのか

一律には言えない。

調整	Cloud Armor	AWS WAF
一括感度	1〜4のsensitivity	同形式の共通感度はない
シグネチャ選択	opt-in／opt-out	内部ルールの除外・アクション上書き
適用範囲	CEL式とポリシー優先度	Scope-down statement
内部検知ごとのアクション	ルールを分けて外側のアクションを変える	RuleActionOverridesで変えられる
検知結果の再利用	AWSのラベル型と同じ多段処理ではない	ラベルを後続ルールで評価できる

Cloud Armorは感度とフィールド除外が分かりやすい。AWS WAFは内部アクションと後続処理が強い。「詳細」という一語では、異なる方向の柔軟性を取り違える。

注意点

SQLi、XSS、RCEなどを分けるため、優先度と命名の管理が必要になる
事前構成WAFルールの変更反映には通常数分かかる
リクエストボディは先頭64 KBまでが評価対象になる
フィールド除外を使う事前構成WAFルールではallowアクションを使えない
stableとcanaryの役割を分け、本番遮断へcanaryを直結しない

最後の制約は誤検知回避だけでなく安全性に関わる。除外されたフィールドは、そのルールの検査を受けないからだ。

Azure WAF：DRSを追加し、異常スコアで判断する

最初に二つの実装を区別する

Azure WAFには、主にApplication Gateway WAFとAzure Front Door WAFがある。

Application Gateway WAF：リージョナルなApplication Gateway v2へWAF Policyを関連付ける
Azure Front Door WAF：グローバルエッジのFront DoorへSecurity Policy経由でWAF Policyを関連付ける

マネージドルールの基本階層は似ているが、利用可能なルールセット、アクション、関連付け単位、機能提供時期は完全には同じではない。構築時は「Azure WAF」という総称だけでなく、どちらの実装かを固定する必要がある。

構造

WAF Policy
├─ Policy settings
│  ├─ Detection / Prevention
│  └─ Body inspectionなど
├─ Custom rules
└─ Managed rules
   ├─ Microsoft_DefaultRuleSet 2.2
   │  ├─ Rule group
   │  │  └─ Individual rule
   │  ├─ Rule override
   │  └─ Exclusion
   └─ Bot Manager rule set

DRS 2.2はOWASP CRS 3.3.4を基礎とし、Microsoft Threat Intelligenceチームの独自保護を加える。Application Gateway向けDRS 2.2には18のルールグループがあり、SQLi、XSS、RCEなどに加えて、Microsoft独自のCVE、Web shell、AppSecルール群を含む。Microsoft公式：Application GatewayのDRSルール

Front DoorでもDRS 2.2とBot Manager 1.1などを利用できる。Microsoft公式：Front DoorのDRSルール

作り方

基本は、WAF PolicyへMicrosoft_DefaultRuleSetのバージョンを追加し、Detectionモードでログを確認する。その後、ルール状態、アクション、除外を調整してPreventionへ移す。

AWS WAFと概念を対応させると次になる。

AWS WAF	Azure WAF
Web ACL	WAF Policy
Managed Rule Group	Managed rule set
内部ルール	Individual rule
RuleActionOverrides	Rule／Rule group override
検査フィールドの調整	Exclusion
Countで導入	DetectionモードまたはLogアクションで観測

ただし、最後の行は完全な同義ではない。AzureのDetection／Preventionはポリシーの動作モードであり、個別ルールのLog設定とは適用範囲が異なる。

異常スコアリング

Azure WAFをAWS WAFと同じ感覚で読むとき、最も見落としやすいのが異常スコアである。

Application GatewayのCRSまたはDRS 2.1以降では、ルール一致が直ちにリクエスト遮断を意味しない。各一致は重大度に応じて点数を加算する。

重大度	加算値
Critical	5
Error	4
Warning	3
Notice	2

合計5以上になると、Preventionモードでは別の異常スコアルールがBlockを記録して遮断する。DetectionモードではDetectedとして記録し、バックエンドへ通す。たとえばCritical一件は単独で5になるが、Warning一件だけなら3で閾値へ届かない。Microsoft公式：Application Gateway WAF概要

個別シグネチャAが一致（Warning: +3）
個別シグネチャBが一致（Notice: +2）
                    ↓
             合計5へ到達
                    ↓
Preventionなら異常スコアルールがBlock

ログ調査では、Matchedを記録した個別ルールと、最終的にBlockedまたはDetectedを記録した異常スコアルールを関連付ける必要がある。個別ルールのログだけを見て「この一件が遮断した」と判断すると原因を取り違えるのだ。

チューニング

DRS 2.2は既定でParanoia Level 1相当となり、PL2ルールは無効である。PL2を使う場合は対象ルールを有効化し、まずLogで分析してから調整する。Azure WAFはPL3とPL4を現在サポートしない。

誤検知には次の順で対処する。

WAFログから一致ルールと対象フィールドを特定する
そのフィールドだけを狭いスコープで除外できるか確認する
個別ルールまたはルールグループのアクション上書きを検討する
無効化が必要なら、そのシグネチャが失われる範囲を記録する
再現リクエストと攻撃テストの両方で確認する

Front Doorの除外は、ルールセット、ルールグループ、個別ルールの各スコープへ設定できる。指定属性だけを評価から外し、リクエストの残りは検査される。Microsoft公式：Front Doorの除外

注意点

Application GatewayとFront Doorの資料や設定例を混ぜない
DRSのバージョン変更時に、既存の上書きとルール単位除外を引き継ぐ
Azure Portalで新しいルールセットを割り当てると、既存カスタマイズが既定値へ戻る場合がある
無効化したルールは異常スコアへ加算されず、ログも残らない
DRS、Bot Manager、HTTP DDoS rulesetの対応状況を実装別に確認する

Microsoftは2026年2月から、マネージドルールセットの最新3世代を積極サポートする方針を示している。更新を放置せず、テスト環境で差分を検証する運用が必要になる。Microsoft公式：Managed Ruleset Support Policy

3製品を同じ要件へ当てはめる

例として、/api/searchへSQLi対策を適用し、正規のfilterパラメータが誤検知する状況を考える。

AWS WAF

SQLiを含むManaged Rule GroupをWeb ACLへ追加する
Scope-downで対象ホストや/api/searchを絞る
全体または対象内部ルールをCountで観測する
誤検知した内部ルールをCountへ上書きする
必要なら検知ラベルとパスを後続ルールで組み合わせる

AWSでは「内部ルールを検知器として残し、最終判断を後続へ移す」という選択がしやすい。

Cloud Armor

sqli-v422-stableを呼ぶSecurity Policyルールを作る
CEL条件または別ポリシー設計で対象範囲を絞る
Previewで観測する
sensitivityとsignature IDを確認する
必要最小限のsignature opt-outまたはfilterフィールド除外を設定する

Cloud Armorでは、SQLiカテゴリの式と適用範囲が一つのポリシールールとして見える。

Azure WAF

DRS 2.2をWAF Policyへ追加する
Detectionモードで個別一致と異常スコアを確認する
filterだけを対象ルールの除外へ設定できるか検討する
必要なら個別ルールのアクションまたは状態を上書きする
Preventionへ移し、最終遮断ログまで再確認する

Azureでは、誤検知した個別ルールだけでなく、リクエスト全体のスコアが遮断へ至った経路を見る。

「どれが最も細かいか」ではなく、調整方向を見る

観点	AWS WAF	Cloud Armor	Azure WAF
初期のまとまり	ルールグループ単位	攻撃カテゴリ単位	DRS単位
基本感度	グループごとの構成に依存	sensitivity 1〜4	PL1、手動でPL2を有効化
個別検知の選択	内部ルール単位	signature ID単位	Individual rule単位
個別検知のアクション	上書き可能	外側のPolicyルールを分ける	上書き可能
適用範囲	Scope-down	CEL条件	Policy関連付け、Custom ruleなど
検知の合成	ラベルで後続評価	Policy優先度で終端評価	異常スコアを合算
フィールド除外	ルール仕様と構成による	preconfigured WAF exclusion	Exclusion
更新管理	バージョン固定または既定追随	stable／canaryとCRS世代	DRS世代と上書き引継ぎ

AWS WAFは、検知結果を部品として再利用する設計に向く。Cloud Armorは、攻撃カテゴリと適用条件を明示的に並べる設計に向く。Azure WAFは、CRS系の複数検知をスコアとして評価する設計に向く。

この差は、単なる管理画面の違いではない。ログの読み方、例外の作り方、IaCのモジュール境界、更新テストの単位まで変えるのだ。

安全な導入手順

製品にかかわらず、最初から全マネージドルールを遮断へ置くべきではない。

対象トラフィックと保護範囲を定義
              ↓
推奨ルールセットを非遮断で有効化
              ↓
正常系と攻撃系のログを収集
              ↓
ルールID・フィールド・適用範囲を特定
              ↓
最小単位で除外またはアクション調整
              ↓
遮断へ移行し、更新差分を継続検証

最低限、次を記録する。

ポリシー名、関連付け先、優先順位
ルールセット名とバージョン
Count、Preview、Detectionなど非遮断状態の意味
誤検知したルールID、対象フィールド、再現リクエスト
除外によって検査されなくなる範囲
攻撃テストで残る検知または遮断
更新時に比較するログ、メトリクス、IaC差分

「正常通信が通った」だけでは調整成功とは言えない。除外後も、同じフィールド以外の攻撃を検知できるかを確認する必要がある。

まとめ

3製品の違いを一文ずつにすると、次になる。

AWS WAFは、Managed Rule Groupを追加し、内部アクション、Scope-down、ラベルで組み立てる
Google Cloud Armorは、攻撃カテゴリ別の事前構成WAFルールをCEL式から呼び、感度とsignature IDで組み立てる
Azure WAFは、DRSを追加し、ルール上書きと除外を行い、複数一致を異常スコアとして評価する

Cloud ArmorはAWSより手作業が増えやすい。ただし、それだけで「AWSより詳細」とは言えない。AzureはAWSに近い階層を持つ。ただし、遮断理由は個別一致ではなく異常スコアまで追う必要がある。

移行やマルチクラウド標準化では、製品名を対応させるだけでは足りない。適用範囲、感度、個別検知、アクション、検知結果の合成、フィールド除外の六つへ分解して読み替える。それが、3大クラウドのマネージドルールを同じ設計書で扱うための基準なのだ。

先に結論​

まず共通部分を押さえる​

AWS WAF：マネージドルールグループをWeb ACLへ追加する​

構造​

作り方​

チューニングの強み​

注意点​

Google Cloud Armor：攻撃カテゴリを一致条件として呼び出す​

構造​

作り方​

チューニングの強み​

AWSより詳細なのか​

注意点​

Azure WAF：DRSを追加し、異常スコアで判断する​

最初に二つの実装を区別する​

構造​

作り方​

異常スコアリング​

チューニング​

注意点​

3製品を同じ要件へ当てはめる​

AWS WAF​

Cloud Armor​

Azure WAF​

「どれが最も細かいか」ではなく、調整方向を見る​

安全な導入手順​

まとめ​

先に結論

まず共通部分を押さえる

AWS WAF：マネージドルールグループをWeb ACLへ追加する

構造

作り方

チューニングの強み

注意点

Google Cloud Armor：攻撃カテゴリを一致条件として呼び出す

構造

作り方

チューニングの強み

AWSより詳細なのか

注意点

Azure WAF：DRSを追加し、異常スコアで判断する

最初に二つの実装を区別する

構造

作り方

異常スコアリング

チューニング

注意点

3製品を同じ要件へ当てはめる

AWS WAF

Cloud Armor

Azure WAF

「どれが最も細かいか」ではなく、調整方向を見る

安全な導入手順

まとめ