AWS WAFで「プリセットルール」と呼ばれることが多い機能は、実務上はAWS Managed Rules（マネージドルールグループ）として理解すると整理しやすくなります。
マネージドルールグループは、SQLインジェクションやXSSなどの一般的な攻撃、既知の悪性IP、ボット由来の不要なトラフィックなどに対応するため、AWSがあらかじめ用意しているルール群です。
Web ACLに追加すると、CloudFrontやApplication Load Balancerなどに届くリクエストをAWS WAFが評価し、条件に一致した通信をBlock、Count、CAPTCHA、Challengeなどのアクションで処理できます。
ただし、マネージドルールは「追加すれば終わり」の設定ではありません。
アプリケーションの仕様によっては、正規ユーザーのリクエストまで検知されることがあります。
まずはCountモードで挙動を確認し、ログやメトリクスを見ながら段階的に調整する運用が必要です。
AWS WAF全体の役割から確認したい場合は、AWS WAFとは？機能・設定手順・活用シーンをわかりやすく解説もあわせて参照してください。
AWS WAFのプリセットルールでできること
AWS WAFのプリセットルールとは、一般的な呼び方としては「最初から用意されている防御ルール」を指します。
AWS WAFの画面や公式ドキュメントでは、これをAWS Managed Rules、つまりマネージドルールグループとして扱います。
Web ACLは、AWS WAFで使うルールをまとめ、保護対象のリソースに関連付ける設定単位です。
ここにマネージドルールグループを追加すると、リクエストのパス、ヘッダー、本文、接続元などをルールに照らして評価できます。
評価結果に対して選べる主なアクションは、次のように使い分けます。
| アクション | 役割 | 導入時の使いどころ |
|---|---|---|
| Count | 一致したリクエストを記録する | 本番影響を見極める検証段階で使います。 |
| Block | 一致したリクエストを遮断する | 誤検知の影響を確認できたルールから適用します。 |
| CAPTCHA | 利用者にCAPTCHAを求める | 人間の操作と自動化されたアクセスを分けたい場面で検討します。 |
| Challenge | クライアントにチャレンジを返す | 明示的なCAPTCHAより摩擦を抑えたいボット対策で検討します。 |
導入の目的は、基本的な防御を短時間で整えることです。
一方で、どのルールを有効にするか、どの順序で評価するか、どの条件だけに絞って検査するかは、保護対象のアプリケーションに合わせて設計する必要があります。
代表的なマネージドルールグループ
マネージドルールグループは、攻撃の種類や用途ごとに分かれています。
最初からすべてを入れるのではなく、保護したい画面、入力項目、公開範囲、アクセス傾向に合わせて選ぶほうが運用しやすくなります。
| 種類 | 主な用途 | 導入時の見方 |
|---|---|---|
| Core Rule Set（CRS） | 一般的なWebアプリケーション攻撃への基本対策 | 最初に検討しやすい基礎ルールです。まずCountモードで誤検知を確認します。 |
| SQL database | SQLインジェクションに関連する疑わしい入力の検出 | 検索フォーム、管理画面、APIなど、入力値が多い箇所ではログ確認が欠かせません。 |
| Known bad inputs | 既知の危険な入力パターンの検出 | 汎用的に使いやすい一方、アプリケーション独自の文字列やURL構造と衝突しないか確認します。 |
| IP reputation、Anonymous IP | 既知の悪性IP、匿名化サービス、疑わしい接続元の制御 | 海外アクセスやVPN利用者が多いサービスでは、業務上必要な通信を除外できるか確認します。 |
| Bot Control | ボットトラフィックの可視化、制御、不要なアクセスの抑制 | 検索エンジンや監視サービスなど、許可したいボットまで止めないように検知結果を見ます。 |
より細かなWAFルールの挙動を知りたい場合は、個別ルールの例としてAWS WAFにおける「NoUserAgent_HEADER」ルールとは？も参考になります。
マネージドルールの選び方
ルール選定では、「有名なルールだから入れる」よりも、「どのリクエストを、何から守るのか」を先に決めます。
たとえば、一般公開された問い合わせフォームでは入力値の検査が重要になります。
ログインや会員登録を持つサービスでは、ボットや不審な接続元の扱いも検討対象になります。
管理画面のように利用者が限られる領域では、IP範囲やパスで検査対象を絞るほうが、誤検知とコストを抑えやすい場合があります。
判断に迷う場合は、次の順序で整理すると設計しやすくなります。
- 守る対象を決める
公開サイト、管理画面、APIなど、通信の性質が異なる部分を分けて考えます。 - 防ぎたいリスクを決める
一般的なWeb攻撃、SQLインジェクション、悪性IP、ボットアクセスなど、優先するリスクを明確にします。 - 最初は検知に寄せる
Countモードで一致状況を確認し、業務上必要な通信が含まれていないかを見ます。 - 影響が読める範囲から強める
誤検知の少ないルールや、対象を絞ったルールからBlockやChallengeへ切り替えます。
設定の基本手順
設定作業では、ルールを追加すること自体よりも、検証と調整の手順を先に組み込むことが重要です。
本番環境でいきなり遮断すると、通常のフォーム送信、API連携、管理画面の操作が止まる可能性があります。
- 保護対象とWeb ACLを決める
どのリソースを守るのかを先に決め、Web ACLを作成します。対象が複数ある場合は、同じWeb ACLで管理できる範囲と、分けたほうがよい範囲を整理します。 - 必要なマネージドルールグループを選ぶ
まずはCRSやSQL databaseなど、リスクに直結する基本的なルールから検討します。Bot ControlやFraud Control系の機能は、必要性と費用を見て追加します。 - Countモードで検証する
いきなりBlockにせず、まずはCountで一致状況を確認します。正規ユーザーの操作、API通信、管理画面、外部連携が誤って検出されないかを確認します。 - 除外、スコープダウン、優先順位を調整する
特定のパス、HTTPメソッド、ヘッダー、IP範囲などで検査対象を絞ると、誤検知や不要な処理を減らせます。ルールの優先順位も、許可とブロックの意図が明確になるように整理します。 - BlockやChallengeへ段階的に移行する
ログとメトリクスで影響を確認したうえで、必要なルールからBlock、CAPTCHA、Challengeなどに切り替えます。リリース後も定期的に検知傾向を見直します。
料金の考え方
AWS WAFの料金は、固定的に発生しやすい要素と、アクセス量に応じて変わる要素に分けて見ると整理しやすくなります。
主な課金要素は、Web ACL、ルールまたはルールグループ、処理したWebリクエスト数です。
そのうえで、使う機能や検査量によって追加費用が発生することがあります。
| 確認項目 | 見積もり時の確認内容 |
|---|---|
| Web ACL | 保護対象ごとにいくつ作成するかを確認します。 |
| ルール、ルールグループ | 追加するルール数とマネージドルールグループの数を確認します。 |
| Webリクエスト数 | 月間アクセス数、API呼び出し、ボット由来のアクセスを含めて見積もります。 |
| 追加機能 | Bot Control、Fraud Control、CAPTCHA、Challenge、AWS Marketplace提供ルールなどの利用有無を確認します。 |
| 検査量とログ | WCU超過、リクエストボディ検査サイズ、ログ出力量が請求に影響しないか確認します。 |
料金はリージョンや構成によって変わります。
導入前には、対象リソース、月間リクエスト数、使うルールグループ、ログ出力をまとめて見積もる必要があります。
導入後も、アクセス増加やボット対策の範囲変更によって請求が変わるため、月次で実績を確認します。
導入時に確認したいポイント
マネージドルールの導入で失敗しやすいのは、防御を強めることだけを見て、通常通信への影響を後回しにするケースです。
次の点を確認しておくと、セキュリティと運用のバランスを取りやすくなります。
- 誤検知への備え：ログ、サンプルリクエスト、CloudWatchメトリクスを見ながら、正常な通信が止まらないように調整します。
- アプリケーション側の対策との役割分担：WAFは入口の防御層です。入力検証、認証、認可、権限設計、監査ログ、脆弱性修正の代わりにはなりません。
- ボット対策の粒度：検索エンジンや監視サービスなど必要なボットまで止めないよう、Bot Controlの検知結果を確認してから適用します。
- コストの継続監視：アクセス増加、Bot Controlの検査対象、ログ量、追加機能の利用によって請求が変わります。導入後も月次で確認します。
- 多層防御との組み合わせ：DDoS、脅威検知、セキュリティ統制まで含める場合は、AWS Shield・AWS WAF・GuardDuty・Security Hubの使い分けと組み合わせ方も確認すると設計しやすくなります。
よくある疑問
マネージドルールだけで十分ですか？
マネージドルールは、Webアプリケーションに防御層を追加する手段です。
ただし、アプリケーション側の入力検証、認証、認可、権限管理、脆弱性修正の代わりにはなりません。
WAFは入口で攻撃らしい通信を減らし、アプリケーション側の対策はシステム内部で正しい処理を保証する役割を持ちます。
最初からBlockにしてもよいですか？
まずはCountモードで確認するのが安全です。
正規のリクエストがルールに一致していないことをログとメトリクスで確認してから、対象を絞ってBlockやChallengeへ移行します。
Bot Controlは必ず必要ですか？
Bot Controlは、ボットトラフィックを可視化し、不要なアクセスを抑えるための選択肢です。
ただし、検索エンジン、監視サービス、業務上必要なクローラーまで止めると運用に影響します。
アクセス傾向と費用を確認し、必要な範囲から適用します。
まとめ
AWS WAFのプリセットルールにあたるマネージドルールグループは、Webアプリケーションに基本的な防御をすばやく追加するための有効な選択肢です。
CRS、SQL database、IP reputation、Bot Controlなどを組み合わせることで、一般的な攻撃や不要なトラフィックへの備えを整えやすくなります。
一方で、適切な運用には検証と調整が欠かせません。
まずCountモードで影響を見極め、必要なルールを段階的にBlockやChallengeへ切り替えます。
そのうえで、ログ、誤検知、料金を継続的に確認することが、安定したWAF運用につながります。