AWS WAFとは？Webアプリケーションを守る仕組みと導入のポイント
Webサービスを運営していると、SQLインジェクションやクロスサイトスクリプティングといった攻撃への対策は避けて通れません。
特にAWS上でサービスを展開している企業にとって、AWS WAFは心強い味方となります。
本記事では、AWS WAFの基本から実践的な活用方法まで、実務で役立つ知識を詳しく解説していきます。
AWS WAFとは？Webアプリケーションを守る盾
AWS WAF（Web Application Firewall）は、Amazon Web Servicesが提供するクラウド型のWebアプリケーションファイアウォールです。CloudFront、Application Load Balancer（ALB）、API Gateway、AppSyncといったAWSサービスと連携し、Webアプリケーションへの悪意ある通信を検知・遮断する役割を担います。
WAFの本質的な役割
ファイアウォールという言葉を聞くと、ネットワーク層での通信制御を思い浮かべる方も多いでしょう。しかし、WAFはOSI参照モデルにおける第7層、つまりアプリケーション層で動作する点が特徴的です。
通常のファイアウォールがIPアドレスやポート番号といったネットワーク情報をもとに通信を制御するのに対し、WAFはHTTPリクエストの中身まで精査します。リクエストヘッダー、ボディ、クエリ文字列、さらにはCookieの内容まで確認できるため、アプリケーション固有の脆弱性を狙った攻撃に対して効果を発揮するのです。
ここで重要なのは、WAFが従来のセキュリティ対策を置き換えるものではなく、多層防御における一つの層として機能する点です。ネットワークファイアウォールやIDS/IPSと組み合わせることで、より堅牢なセキュリティ体制を構築できます。
AWS WAFの設計思想
AWS WAFは「pay as you go」というAWSの料金体系を踏襲しており、大規模な初期投資なしに導入できる点が評価されています。オンプレミス型のWAF製品では、ハードウェアの購入やライセンス費用で数百万円単位のコストが発生することも珍しくありません。
また、AWS WAFはAPI経由での制御が可能なため、Infrastructure as Code（IaC）との親和性が高いのも特徴です。TerraformやCloudFormationを使えば、ルール設定をコード化し、バージョン管理やCI/CDパイプラインに組み込めます。
Webアプリケーションが直面する脅威の実態
AWS WAFの価値を理解するには、現代のWebアプリケーションがどのような脅威に晒されているかを知る必要があります。
アプリケーション層への攻撃が増加している背景
2024年の各種セキュリティレポートによると、Webアプリケーションへの攻撃トラフィックは前年比で40〜50%増加しています。この背景には、攻撃ツールの高度化と低価格化があります。かつては専門的な知識が必要だった攻撃手法も、今ではGUIベースのツールで実行できてしまうのです。
特に深刻なのが、脆弱性が公表された直後の攻撃です。CVE（Common Vulnerabilities and Exposures）データベースに新たな脆弱性が登録されると、わずか数時間で自動化された攻撃が始まることも珍しくありません。
SQLインジェクションの現在形
データベースに不正なSQL文を送り込むSQLインジェクションは、古典的な攻撃手法として知られています。しかし、「古典的」だからといって無視できるわけではありません。OWASP Top 10では依然として上位にランクインしており、実際の被害も後を絶ちません。
近年のSQLインジェクション攻撃は、WAFの検知を回避するために様々な難読化技術を使います。文字コードの変換、コメントアウトの悪用、複数のエンコーディングを組み合わせた攻撃など、手口は巧妙化しています。だからこそ、継続的にルールを更新し、新たな攻撃パターンに対応できる仕組みが求められるのです。
クロスサイトスクリプティング（XSS）の進化
XSS攻撃も依然として主要な脅威の一つです。攻撃者は正規のユーザーのブラウザ上で悪意あるスクリプトを実行させ、セッション情報の窃取やフィッシングサイトへの誘導を行います。
特にSingle Page Application（SPA）の普及により、フロントエンド側でのDOM操作が増えたことで、DOM-based XSSと呼ばれる新たな攻撃手法も登場しています。これらに対しても、Content Security Policy（CSP）とWAFを組み合わせた多層的な防御が有効となります。
AWS WAFの主要機能を深く理解する
AWS WAFには、様々な攻撃パターンに対応するための機能が実装されています。それぞれの機能を正しく理解し、適切に組み合わせることが効果的な防御につながります。
Web ACL：防御ルールの中核
Web ACL（Web Access Control List）は、AWS WAFにおける防御ルールの集合体です。一つのWeb ACLには複数のルールを設定でき、各ルールは順番に評価されていきます。
ここで注意したいのが、ルールの評価順序が結果に影響を与える点です。例えば、特定のIPアドレスからのアクセスを許可するルールを先頭に配置し、その後にSQLインジェクション検知ルールを配置すれば、許可されたIPからのアクセスは後続のルールで検証されます。この順序設計が不適切だと、意図しない動作を引き起こす可能性があります。
マネージドルールの実力と限界
AWS Managed Rules（AMR）は、AWSやAWSパートナーが提供する事前設定済みのルールセットです。一般的な脆弱性への対策がすぐに適用できる点は魅力的ですが、実運用では誤検知（False Positive）が発生することもあります。
例えば、Core Rule Set（CRS）を有効にした際、正規のクエリパラメータが攻撃として誤検知されるケースがあります。こうした場合、カウントモードでルールを動作させ、実際のトラフィックを観察してから本番適用する段階的なアプローチが推奨されます。
また、業界特化型のマネージドルールも提供されています。WordPress向けのルールセット、SQLデータベース保護用のルールセット、Linux/Windows OS保護用のルールセットなど、環境に応じた選択が可能です。
レートベースルールによるDDoS対策
レートベースルールは、特定のIPアドレスからの5分間のリクエスト数を監視し、閾値を超えた場合にブロックする機能です。アプリケーション層のDDoS攻撃やブルートフォース攻撃への対策として有効に機能します。
実務では、正規ユーザーの通常利用パターンを分析し、適切な閾値を設定することが重要です。閾値が低すぎると正規ユーザーをブロックしてしまい、高すぎると攻撃を防げません。CloudWatch Logsと連携してアクセスパターンを可視化し、データに基づいた閾値設定を行うべきでしょう。
Bot Controlで巧妙なボット攻撃に対抗
AWS WAF Bot Controlは、ボットトラフィックを検出・管理するための機能です。検索エンジンのクローラーのような有益なボットと、スクレイピングやアカウント乗っ取りを試みる悪意あるボットを区別できます。
Bot Controlは機械学習モデルとシグネチャベースの検出を組み合わせており、User-Agentの偽装やヘッドレスブラウザを使った攻撃にも対応します。ただし、この機能は別途料金が発生するため、費用対効果を見極めた上での導入判断が必要です。
Fraud Control：アカウント乗っ取り防止の切り札
Account Takeover Prevention（ATP）とAccount Creation Fraud Prevention（ACFP）は、認証エンドポイントやアカウント作成フォームを保護する機能です。
ATPは、ログイン試行のパターンを分析し、クレデンシャルスタッフィングやパスワードスプレー攻撃を検出します。複数のIPアドレスから同一アカウントへのログイン試行が行われた場合や、通常とは異なる地理的位置からのアクセスなど、不審なパターンを機械学習で識別するのです。
実際の運用では、これらの機能を段階的に導入し、誤検知の影響を最小限に抑えながら最適化していく必要があります。
AWS WAFを導入するメリット
AWS WAFの技術的な側面を理解したところで、ビジネス観点でのメリットも確認しておきましょう。
スピーディーな展開と柔軟な変更
オンプレミス型のWAF製品では、ハードウェアの調達から設置、初期設定まで数週間から数ヶ月を要することがあります。一方、AWS WAFはマネジメントコンソールやAPIから数分で有効化でき、ルールの追加・変更も即座に反映されます。
この俊敏性は、新たな脆弱性が公表された際の緊急対応において大きな強みとなります。例えば、Log4Shell脆弱性のような深刻な問題が発覚した場合、数時間以内にカスタムルールを作成して防御態勢を整えられます。
可視化による継続的な改善
AWS WAFはCloudWatch Metricsと統合されており、ブロックされたリクエスト数、許可されたリクエスト数、カウントされたリクエスト数などのメトリクスをリアルタイムで確認できます。
さらに、Kinesis Data Firehose経由でログをS3に保存し、Amazon Athenaで分析することも可能です。これにより、攻撃の傾向分析や、誤検知の原因特定といった高度な分析が実現します。セキュリティは「設定したら終わり」ではなく、継続的なモニタリングと改善のサイクルが重要なのです。
マルチリージョン展開への対応
グローバルにサービスを展開する企業にとって、複数リージョンでの統一的なセキュリティポリシー適用は課題の一つです。AWS WAFでは、AWS Firewall Managerを使うことで、組織全体に渡るポリシーの一元管理が可能になります。
新たなAWSアカウントが作成された際も、自動的に標準のWAFルールが適用されるよう設定できるため、ガバナンスの観点でも優れています。
コスト効率の高さ
従量課金制のため、小規模なサービスでも手の届く価格で導入できます。トラフィックが増加すれば費用も増えますが、それはビジネスの成長と連動しているため、投資対効果の説明がしやすい構造です。
また、CloudFrontと組み合わせることで、キャッシュヒットしたリクエストはWAFの処理対象外となり、コスト削減につながります。CDNの活用とセキュリティ対策を同時に最適化できる点も見逃せません。
AWS WAFの料金体系を正しく理解する
AWS WAFの料金は、Web ACL数、ルール数、処理されるリクエスト数の3要素で決まります。
基本料金の構造
Web ACL：月額5ドル
ルール：Web ACLあたり月額1ドル
リクエスト処理：100万リクエストあたり0.6ドル
一見シンプルですが、マネージドルールを利用する場合は追加料金が発生します。例えば、AWS Managed Rules Core Rule Setは無料ですが、Bot Controlは10,000,000リクエストあたり10ドルの従量課金に加えて月額10ドルの基本料金がかかります。
コスト最適化の実践テクニック
実際の運用では、不要なルールを削除することでコストを削減できます。開発初期に設定したテスト用のルールが本番環境に残っている、といったケースは意外と多いものです。定期的なルール棚卸しを行いましょう。
また、CloudWatch Logsへのログ出力も費用が発生します。全てのリクエストをログに記録するのではなく、ブロックされたリクエストやカウントモードのリクエストのみをログに残す、といったフィルタリングが有効です。
さらに、S3へのログ保存においては、ライフサイクルポリシーを設定して古いログを自動的に削除またはGlacierに移行させることで、ストレージコストを抑えられます。
AWS WAFの設定方法：実践的なアプローチ
理論を理解したら、実際の設定手順を見ていきましょう。
事前準備：保護対象リソースの確認
まず、どのAWSリソースにWAFを適用するかを明確にします。CloudFrontディストリビューション、ALB、API Gateway、AppSyncが対象となりますが、リソースの種類によって制約があります。
例えば、CloudFrontに適用するWeb ACLは米国東部（バージニア北部）リージョンで作成する必要があります。一方、ALBに適用する場合は、ALBと同じリージョンでWeb ACLを作成します。この地域的な制約を理解していないと、設定時に混乱することになります。
Web ACLの作成と基本設定
マネジメントコンソールからWAF & Shieldサービスに移動し、「Create web ACL」を選択します。名前と保護対象リソースを指定した後、CloudWatch metrics名を設定します。このメトリクス名は後で変更できないため、命名規則を事前に決めておくことをお勧めします。
デフォルトアクションの設定では、「Allow」と「Block」を選択できます。ホワイトリスト方式で運用する場合は「Block」を、ブラックリスト方式の場合は「Allow」を選択しますが、一般的にはブラックリスト方式（デフォルトAllow）が採用されます。
ルールの追加と優先順位設定
ルールには優先度（Priority）が設定され、数字が小さいものから順に評価されます。一般的には、以下の順序で配置すると効率的です。
IPアドレスベースの許可ルール（信頼できるIPからのアクセスを早期に許可）
レートベースルール（異常なトラフィックを早期に遮断）
マネージドルール（一般的な攻撃パターンの検出）
カスタムルール（アプリケーション固有の要件に対応）
各ルールには「Allow」「Block」「Count」のアクションを設定できます。新しいルールを導入する際は、まずCountモードで数日間運用し、誤検知がないことを確認してからBlockモードに切り替える慎重なアプローチが推奨されます。
カスタムルールの作成：実例から学ぶ
特定のクエリパラメータに「admin」という文字列が含まれるリクエストをブロックしたいとします。この場合、ルールステートメントで以下のように設定します。
Inspect: Query string
Match type: Contains string
String to match: admin
Text transformation: Lowercase
Text transformationは、攻撃者が大文字小文字を変えて検知を回避する手法に対応するためのものです。複数の変換を適用することも可能で、URLデコード、HTMLエンティティデコード、正規化などを組み合わせられます。
テストとロールバック計画
本番環境に適用する前に、ステージング環境で十分なテストを行います。負荷テストツールを使って様々なリクエストパターンを送り、意図した動作をするか確認しましょう。
また、問題が発生した際の切り戻し手順も準備しておきます。Web ACLの設定はバージョン管理されないため、変更前の設定をJSON形式でエクスポートしておくと安心です。
AWS WAFの運用で直面する課題と対策
導入後の運用フェーズでは、いくつかの課題に直面することがあります。
誤検知への対応プロセス
正規のリクエストが攻撃として誤検知されると、ユーザー体験に悪影響を及ぼします。誤検知が報告された場合、まずCloudWatch Logsを確認し、どのルールがトリガーされたかを特定します。
次に、該当するルールを一時的にCountモードに変更するか、例外条件を追加します。例えば、特定のUser-Agentやリファラーを持つリクエストは検証をスキップする、といった柔軟な対応が可能です。
ルールメンテナンスの自動化
マネージドルールは自動的に更新されますが、カスタムルールは手動でメンテナンスする必要があります。新たな脆弱性情報をモニタリングし、必要に応じてルールを追加・更新する体制を整えましょう。
AWS Systems Managerのパラメータストアにルール設定を保存し、Lambda関数で定期的に適用する仕組みを構築すれば、GitOps的なワークフローも実現できます。
パフォーマンスへの影響
AWS WAFはリクエストを検証するため、わずかながらレイテンシが増加します。通常は数ミリ秒程度ですが、複雑なルールを大量に設定すると影響が大きくなる可能性があります。
CloudWatch Metricsで「SampledRequests」を監視し、処理時間の増加傾向がないか定期的に確認することをお勧めします。必要に応じて、ルールの統合や最適化を検討しましょう。
セキュリティイベントへの対応体制
WAFがリクエストをブロックした場合、それが本当に攻撃だったのか、誤検知だったのかを判断する必要があります。Amazon EventBridgeとLambdaを組み合わせ、特定の条件でSlackやメールに通知を送る仕組みを構築すると、迅速な対応が可能になります。
また、定期的なセキュリティレビューを実施し、ブロックされた攻撃の傾向を分析することで、より効果的な防御戦略を立てられます。
まとめ：AWS WAFを活用した持続可能なセキュリティ体制
AWS WAFは、Webアプリケーションを多様な脅威から守る強力なツールです。しかし、導入しただけで安心できるわけではありません。継続的なモニタリング、ルールの最適化、新たな脅威への対応といったサイクルを回し続けることが、真のセキュリティ向上につながります。
特に重要なのは、セキュリティを開発プロセスに組み込む「Shift Left」の考え方です。WAFは最後の防御線として機能しますが、アプリケーション側でのセキュアコーディング、脆弱性診断、ペネトレーションテストといった取り組みと組み合わせることで、多層防御が実現します。
また、AWS WAFの機能は日々進化しています。新しいマネージドルールの追加、機械学習ベースの検出機能の向上など、最新情報をキャッチアップし続ける姿勢が求められます。AWSの公式ブログやセキュリティ公告を定期的に確認し、組織のセキュリティレベルを維持・向上させていきましょう。
最後に、セキュリティは技術だけの問題ではありません。組織文化としてセキュリティ意識を根付かせ、開発者からマネジメント層まで全員が当事者意識を持つことが、持続可能なセキュリティ体制構築の鍵となります。AWS WAFは、その実現を技術面から支える重要な基盤なのです。
