AWS WAFで「プリセットルール」と呼ばれることが多い機能は、実務上はAWS Managed Rules（マネージドルールグループ）として理解すると整理しやすくなります。SQLインジェクションやXSSなどの一般的な攻撃、既知の悪性IP、ボット由来の不要なトラフィックなどに対し、あらかじめ用意されたルール群をWeb ACLに追加して利用します。
ただし、マネージドルールは入れれば終わりの万能な防御ではありません。アプリケーションの仕様によっては正規のリクエストが検知されることもあるため、まずはCountモードで挙動を確認し、ログやメトリクスを見ながら調整する運用が重要です。AWS WAF全体の基本を先に確認したい場合は、AWS WAFとは？機能・設定手順・活用シーンをわかりやすく解説もあわせて参照してください。
AWS WAFのプリセットルールでできること
マネージドルールグループは、よくある攻撃パターンや不審なリクエストを検出するためのルールをまとめたものです。Web ACLに追加すると、対象のCloudFrontやApplication Load Balancerなどに届くリクエストをAWS WAFが評価し、ルールに一致した通信をBlock、Count、CAPTCHA、Challengeなどのアクションで扱えます。
導入の目的は、基本的な防御を短時間で整えることです。一方で、どのルールを有効にするか、どの順序で評価するか、どの条件だけに絞って検査するかは、保護対象のアプリケーションに合わせて設計する必要があります。
代表的なマネージドルールグループ
| 種類 | 主な用途 | 導入時の見方 |
|---|---|---|
| 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」ルールとは？も参考になります。
設定の基本手順
- 保護対象と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、ルール、100万リクエスト単位のリクエスト処理が課金要素として示されています。
注意したいのは、マネージドルールグループを追加した場合、通常のAWS WAF料金に加えて、Bot Control、Fraud Control、CAPTCHA、Challenge、AWS Marketplace提供ルール、WCU超過、検査するリクエストボディサイズなどで追加費用が発生することがある点です。料金はリージョンや構成によって変わるため、導入前に対象リソース、月間リクエスト数、使うルールグループ、ログ出力を含めて見積もる必要があります。
導入時に確認したいポイント
- 誤検知への備え：ログ、サンプルリクエスト、CloudWatchメトリクスを見ながら、正常な通信が止まらないように調整します。
- アプリ側の対策との役割分担：WAFは入口の防御層です。入力検証、認証・認可、権限設計、監査ログ、脆弱性修正の代わりにはなりません。
- ボット対策の粒度：検索エンジンや監視サービスなど必要なボットまで止めないよう、Bot Controlの検知結果を確認してから適用します。
- コストの継続監視：アクセス増加、Bot Controlの検査対象、ログ量、追加機能の利用によって請求が変わります。導入後も月次で確認します。
- 多層防御との組み合わせ：DDoS、脅威検知、セキュリティ統制まで含める場合は、AWS Shield・AWS WAF・GuardDuty・Security Hubの使い分けと組み合わせ方も確認すると設計しやすくなります。
まとめ
AWS WAFのプリセットルール、つまりマネージドルールグループは、Webアプリケーションに基本的な防御をすばやく追加するための有効な選択肢です。CRS、SQL database、IP reputation、Bot Controlなどを組み合わせることで、一般的な攻撃や不要なトラフィックへの備えを整えやすくなります。
一方で、適切な運用には検証と調整が欠かせません。まずCountモードで影響を見極め、必要なルールを段階的にBlockやChallengeへ切り替え、料金とログを継続的に監視することが、安定したWAF運用につながります。
参考情報
- AWS Managed Rules for AWS WAF
- AWS Managed Rules rule groups list
- Managing rule group behavior
- AWS WAF Pricing