「Webサイトの改ざんが不安」「ECサイトで買い占めボット対策をしたい」「ISMAP要件への対応方法がわからない」──そんな悩みを抱えていませんか？
AWS WAFは、こうした課題に対応できるクラウド型のWebアプリケーションファイアウォールです。特に近年は、サイバー攻撃の巧妙化とコンプライアンス要件の厳格化により、AWS WAFの重要性が高まっています。
本記事では、AWS WAFの基礎から実践的な導入手順、コスト最適化のポイントまでを実例を交えて解説します。具体的なユースケースや設定例も交えながら、実務に活かしやすい形で整理しました。
AWS WAFはISMAP要件対応の中でも重要な構成要素です。制度の全体像については、ISMAPとは？の記事で整理しています。
WAFの基本機能
WAFとは
WAF（Web Application Firewall）は、Webアプリケーションの脆弱性を狙った攻撃を防ぐためのセキュリティ対策です。従来のファイアウォールがネットワーク層（L3/L4）で通信を制御するのに対し、WAFはアプリケーション層（L7）でHTTPリクエストの内容を検査し、不正な通信を防御します。
AWS WAFが提供する基本的な防御機能
-
SQLインジェクション、XSSの防御
-
CSRF攻撃への軽減策（※WAFのヘッダ検査やカスタムルールでリスク低減は可能ですが、完全防御にはアプリ側でのCSRFトークン実装が必要です）
-
正規表現やシグネチャベースの攻撃検知
-
IPアドレスやジオロケーションベースのアクセス制御
AWS WAF特有の強み
上記の基本機能に加えて、AWS WAFならではの以下のような追加メリットがあります。
- マネージドルール：AWSやサードパーティが提供する事前定義済みのルールセットにより、設定の手間を大幅に削減
- Shield連携：DDoS攻撃に対する多層防御を簡単に実現
- CloudFront/ALB/Cognitoとのネイティブ統合：追加のハードウェア不要で、認証基盤の保護も可能
- 従量課金制：初期投資不要で、リクエスト数に応じた柔軟な料金体系
AWS WAFの構成
AWS WAFは単体では動作せず、CloudFront、ALB、API Gateway、Cognito などのサービスと連携して利用します。
以下は典型的な構成例です。
重要な注意点
- CloudFront用WAF（scope=CLOUDFRONT）とALB用WAF（scope=REGIONAL）は別々のWeb ACLとして管理します
- 同一のWeb ACLを共有することはできません
- 二段構えで防御レイヤーを追加する場合は、本番適用前にCount運用とチューニングを行い、それぞれ個別に設定する必要があります
ユースケース
ここからは、現場でよくある4つの課題と、その解決策を見ていきます。各ユースケースごとに、具体的な設定方法と期待できる効果を紹介します。
WordPress改ざん対策
| 課題：WordPressの脆弱性を突いた改ざん被害が頻発 |
多くの企業サイトで採用されているWordPressは、その人気ゆえに攻撃の標的になりやすく、特に管理画面（/wp-admin）への不正アクセスが後を絶ちません。
AWS WAFでの対策
管理画面へのアクセスを特定のIPアドレスからのみ許可するルールを設定します。具体的には、WAFコンソールで「カスタムルール」を作成し、以下のような条件を設定します。
- まず、信頼できる管理者IPを「IPセット」として登録
- 次に、管理画面へのアクセスを制御するカスタムルールを作成
- 条件1：URIパスが「/wp-admin」で始まる
- 条件2：送信元IPが管理者IPセットに含まれない
- アクション：ブロック
この設定により、管理者以外からの「/wp-admin」へのアクセスはすべて遮断されます。
設定の参考（ルールの構造）
ルール名：BlockWPAdminFromInternet
条件：URIパスに「/wp-admin」を含む AND 送信元IPが許可リストにない
アクション：Block（ブロック）
ECサイトボット対策
| 課題：限定商品の買い占めボットによる一般顧客からのクレーム増加 |
人気商品の発売時には、自動化されたボットによる買い占めが発生し、正規の顧客が購入できないケースが問題となっています。
AWS WAFでの対策
以下3つの機能を組み合わせた多層防御を実施します。
- レートベースルール（カスタムルールとして設定）
- 同一IPアドレスから短時間に大量のリクエストが来た場合に自動でブロック
- 最小レート制限は10、評価ウィンドウは1/2/5/10分から選択可能（2024年3月以降の更新機能）
- 例：60秒間に100リクエスト以上で自動ブロック
- CAPTCHA統合
- 疑わしいアクセスに対して人間確認を要求
- ボットと人間を自動判別
- ※CAPTCHA利用時は$0.40/1,000試行の追加課金があります
- ボット制御ルールグループ（マネージドルール）
- 既知のボットシグネチャを自動検知
- AWS側で常に最新の脅威情報に更新
- ※Bot Control利用時は$10/月＋リクエスト課金が発生します
Cognito認証基盤保護
| 課題：ユーザー認証への総当たり攻撃やアカウント乗っ取り試行の増加 |
会員制サイトやSaaSアプリケーションでは、ログイン画面への総当たり攻撃（ブルートフォース攻撃）が増加しています。
AWS WAF + Cognitoの連携（2025年6月のアップデート）
- CognitoマネージドログインへのWAF適用が可能に（2025年6月の機能追加）
- ユーザープールはレート制限、CAPTCHA、一般マネージドルールで防御（※ATPは非対応）
重要な制約事項
CognitoユーザープールにAccount Takeover Prevention（ATP）を含むWeb ACLは関連付けできません（2025年10月時点）。代替として、レートベースルール、CAPTCHA、一般マネージドルールで保護します。
設定例：レートベースルールの設定
ログインエンドポイントに対して、以下のようなレート制限を設定します。
- 同一IPアドレスから60秒間に10回以上のログイン試行があった場合、そのIPを自動的にブロック
- これにより、パスワード総当たり攻撃を効果的に防ぎます
設定の参考（ルールの構造）
ルール名：RateLimitLogin
条件：60秒間に同一IPから10回以上のリクエスト
アクション：Block（ブロック）
集約キー：送信元IPアドレス
ISMAP要件への対応
| 課題：ISMAP（政府情報システムのためのセキュリティ評価制度）登録に必要な技術的統制の実装 |
政府系システムや公共分野向けサービスでは、案件によってISMAPへの対応が求められることがあります。
補足：ISMAPとAWS WAFの関係
ISMAPはクラウドサービスの登録制度であり、AWS WAFは技術的統制の一部として位置づけられます。WAF導入だけでISMAP要件を満たすわけではなく、以下の組織的対策も必要です。
AWS WAFが担う技術的統制
- アプリケーション層での攻撃防御
- ログの長期保存（CloudWatch Logs）
- インシデント対応の自動化
追加で必要な組織的対策
- ログ保全手順の文書化
- 監査体制の構築
- 運用手順書の整備
- インシデント対応体制の整備
AWS WAF + Shieldでの実装
- マネージドルールグループで主要な攻撃を防御
- CloudWatch Logsへの詳細ログ出力
- AWS Security Hub（Firewall Manager/Config連携）での検出統合（※WAF単体の全イベントが直接流れるわけではありません）
ShieldとWAFの関係
ここまでAWS WAFの機能を見てきましたが、実際の運用ではAWS Shieldとの併用が一般的です。AWS Shieldは主にDDoS攻撃（ネットワーク層の大量攻撃）を防ぐサービスであり、WAFとは防御する階層が異なります。
両者を組み合わせることで、ネットワーク層からアプリケーション層まで、包括的なセキュリティ対策を実現できます。
比較表で見る違い
| 項目 | AWS Shield | AWS WAF |
| 防御対象 | DDoS攻撃（L3/L4層） | Webアプリケーション攻撃（L7層） |
| 料金体系 | Standard：無料 Advanced：$3,000/月 |
従量課金制 Web ACL：$5/月 ルール：$1/月 リクエスト：$0.60/100万 |
| 主な防御 | ボリューム攻撃、プロトコル攻撃、リソース枯渇攻撃 | SQLインジェクション、XSS、ボット攻撃 |
| 設定難易度 | 低（自動適用） | 中～高（ルール設定が必要） |
| 推奨用途 | すべてのAWSリソース | Webアプリケーション、API |
| 連携効果 | WAFと併用で多層防御を実現 | Shieldと併用でL3～L7まで包括的に保護 |
選び方のポイント
- 基本はShield Standard（無料）+ AWS WAFの組み合わせ
- 高トラフィックサイトやミッションクリティカルな場合はShield Advancedの追加を検討
導入手順
ここからは、実際にAWS WAFを導入する際の具体的な手順を、4つのフェーズに分けて解説します。いきなり本番環境に適用するのではなく、段階的にリスクを管理しながら進めることが重要です。
Phase 1：PoC環境構築
目的：WAFの基本動作確認と効果測定
まずはテスト環境で、WAFがどのように動作するかを確認します。
手順：
- Web ACL作成
- AWSコンソールのWAFサービスから「Web ACLの作成」を選択
- スコープをCloudFrontまたはRegional（ALB用）から選択
- デフォルトアクションは「Allow（許可）」に設定
- マネージドルール追加
- AWS Core Rule Set（基本的な攻撃防御）
- Known Bad Inputs（既知の悪意ある入力）
- Countモードで影響確認
- まずは「Count（カウント）」モードで2～3日運用
- このモードでは、ルールに該当するリクエストをブロックせず、ログに記録のみ行います
- 誤検知（正常なアクセスが誤ってブロック対象になること）の確認と調整を行います
Countモードは、ルールに該当するリクエストを実際にはブロックせず、「もしブロックしていたら何件該当したか」をログに記録するモードです。本番適用前に、正常なトラフィックへの影響を確認するために使用します。
Phase 2：本番適用
目的：業務影響を最小限に抑えつつ、防御力を向上させる
PoC環境での検証が完了したら、本番環境に段階的に適用します。
手順
- 優先度の高いルールから有効化
- SQLインジェクション：最優先でBlock（ブロック）モードに変更
- XSS：次に有効化
- レート制限：トラフィック分析後に設定
- ホワイトリスト設定
社内からのアクセスや、特定の外部サービスからの正規アクセスをホワイトリストに登録します。
- AWSコンソールで「IPセット」を作成
- 信頼できるIPアドレスを登録
- Web ACLで、これらのIPセットからのアクセスを優先的に許可するルールを追加（Priority 0で最優先）
- アラート設定
- CloudWatch Alarmsで異常検知を設定
- SNS連携でSlack通知やメール通知を構成
- ブロック件数が急増した場合の通知など
Phase 3：運用自動化
目的：運用負荷の削減と防御力の継続的向上
手動での運用から、自動化された運用体制へと移行します。
実装内容
- ログ分析の自動化
WAFのログをS3に保存し、Lambda関数で定期的に分析します。
- 攻撃パターンの傾向を把握
- 特定のIPアドレスから繰り返し攻撃がある場合、自動的にブロックリストに追加
- 誤検知が多いルールの自動調整
- 定期的なルール見直し
- 月次でマネージドルールの更新確認
- 四半期でカスタムルールの効果測定
- 不要になったルールの削除（コスト最適化）
Phase 4：コスト最適化
目的：セキュリティレベルを維持しながら、運用コストを適正化する
WAFの運用が安定してきたら、コスト面での最適化を進めます。
コスト最適化
マネージドルール選定
必須ルール（多くの企業で採用）
- AWS Core Rule Set：$1/月（基本防御）
- Known Bad Inputs：$1/月（既知の脅威）
業種別推奨ルール
- EC・小売：Bot Control（$10/月）
- 金融・保険：Anonymous IP List（$1/月）
- メディア：WordPress/PHP Application（$1/月）
ログ保存コスト削減
課題
WAFログは大量になりやすく、S3コストが膨らみやすい傾向があります。
WAFは大量のリクエストを処理するため、すべてのログを長期保存するとストレージコストが高額になる可能性があります。
対策
- S3ライフサイクルポリシー設定
ログの保存期間に応じて、自動的にストレージクラスを変更します。
- 最初の30日間：標準ストレージ（頻繁なアクセス用）
- 31～90日：低頻度アクセスストレージ（アクセス頻度が下がる）
- 91～365日：Glacier（アーカイブ用、取り出しに時間がかかる）
- 365日以降：自動削除
これにより、古いログほど安価なストレージへ自動的に移動できます。
- ログフィルタリング
- 正常通信のログは除外
- Block/Countアクションのみ保存
- セキュリティ調査に必要な情報だけを記録
削減効果
- ログ保存コストを約70%削減
- 必要な情報は確実に保持
料金シミュレーション
中規模ECサイト（月間1000万PV）の場合（例示）
|
項目 |
数量 |
単価 |
月額費用 |
|
Web ACL |
1 |
$5 |
$5 |
|
ルール（マネージド） |
5 |
$1 |
$5 |
|
ルール（カスタム） |
3 |
$1 |
$3 |
|
リクエスト処理 |
1000万 |
$0.60/100万 |
$6 |
|
基本料金合計 |
- |
- |
$19 |
※この料金は一例です。ルール数やリクエスト量により変動します。
重要な追加課金の注意事項
- Bot Control利用時：$10/月＋リクエスト課金（$1.00/100万リクエスト）
- Fraud Control/Account Takeover Prevention：$10/月＋リクエスト課金
- CAPTCHA：$0.40/1,000試行
- Challenge：レスポンスごとに課金対象。最新の料金表を参照してください（地域・更新に依存）
- ALB 1クリック保護パック：ALB作成時の「統合」から「1クリック」でWAFを有効化できるオプションです。標準のWAF料金が適用されますが、Anti-DDoSルール等の自動選択構成では追加料金が発生する可能性があります
総コストの目安（Bot Control追加時）
- 基本料金：$19
- Bot Control：$10（月額）＋ $10（リクエスト）
- 合計：約$39/月
ポイント
- 従来のアプライアンス型WAF（月額10万円～）と比較して大幅なコスト削減が見込めます
- トラフィック増加に応じた柔軟なスケールが可能です
- 必要な機能だけを選択して利用できます
運用自動化ツール
AWS WAFの設定や運用に不安がある、または専任のセキュリティエンジニアがいない場合は、運用自動化ツールの活用も検討できます。
WafCharmとは
WafCharmは、AWS WAFの運用を自動化するサービスです。AWS公式のサービスではありませんが、日本国内で多くの導入実績があります。
主な機能
- AIによる攻撃パターン学習
- 世界中の攻撃データを分析
- 新たな脅威に自動対応
- 誤検知の自動調整
- 正常通信を学習
- ルールの自動チューニング
- レポート機能
- 攻撃統計の可視化
- コンプライアンス報告書の自動生成
- 日本語サポート
- 国内ベンダーによる手厚いサポート
- 日本の攻撃パターンへの特化対応
導入効果
- 運用工数の大幅削減：月間約30時間の作業時間削減事例あり（環境により変動）
- 誤検知の継続的改善：機械学習による自動チューニング
- 24時間365日の自動防御：新規脅威への迅速な対応
- 専門知識不要：セキュリティエンジニアがいなくても高度な防御を実現
|
注意事項： 実際の削減効果は環境や運用体制により異なります。導入前に自社要件とのフィット＆ギャップ分析を行うことをおすすめします。 |
まとめ
AWS WAFは単なる防御ツールではなく、適切に設定・運用することで、セキュリティ強化と運用効率化の両立に役立ちます。
ビジネス価値
- 顧客体験の向上：ボット排除により、正当な顧客へのサービス品質を向上
- コンプライアンス対応：ISMAP、PCI DSS などの技術的統制要件への対応（※組織的対策と組み合わせて実施）
- 運用効率化：自動化による24時間365日の防御
技術的メリット
- スケーラビリティ：トラフィック増加に自動対応
- 最新脅威への対応：マネージドルールの自動更新
- 可視化：詳細なログとメトリクスによる状況把握
- 多様な連携：CloudFront、ALB、API Gateway、Cognito など主要サービスとの統合
次のアクション
- まずはPoC環境でCountモードから開始
- 段階的にルールを有効化（CloudFront用とALB用は別々に設定）
- 必要に応じてBot Controlなどの高度な機能を追加
- 運用の自動化・最適化を推進
コスト管理のポイント
- 基本的なマネージドルールから始めて段階的に拡張
- Bot ControlやCAPTCHAなどの追加機能は、費用対効果を検証してから導入
- ALBの1クリック保護パックは作成時に選べるオプションであり、構成により料金が変動することに注意
AWS WAFは、多くのWebサービスや業務システムにおいて、検討優先度の高いセキュリティ対策の一つとなっています。本記事の実践例を参考に、自社環境に合った導入・運用を進めてみてください。
セキュリティは「コスト」ではなく「投資」です。AWS WAFを活用し、ビジネスを守りながら成長を支える基盤を整えましょう。
