WAFは「とりあえず入れておけば安心」というものではありません。実際には、未導入のまま運用していたWebサービスで、ログイン試行が1日数万〜数十万件に達し、アカウント乗っ取り寸前までいったケースも珍しくありません。
AWS WAFはそうした攻撃を防ぐ有効な手段ですが、「どこに配置するか」「どうルールを設計するか」を誤ると、十分な効果が出ないどころか、正規ユーザーをブロックしてしまうリスクもあります。
本記事では、AWS WAFの基本に加えて、CloudFrontとALBの使い分け、ルール設定の具体例、実際の運用負荷まで踏み込み、「導入して終わりにしないための判断軸」を整理します。
AWS WAFとは
AWS WAFとは、その名の通り、Amazon Web Services (AWS)が提供するウェブ アプリケーション ファイアウォール (WAF)のサービスです。
AWS WAFの設定箇所
AWS WAFの設定箇所
次に連携可能なAWSサービスについて紹介します。「AWS WAF」は、WEBアプリケーションに関連する、3つのサービスへデプロイが可能です。自社の構成に応じて設定していきましょう。
■Amazon CloudFront
CDNサービスである、CloudFrontへ設定します。ユーザーからアクセスされるすべてのリクエストが防御対象となります。
■Application Load Balancer（ALB）
CloudFrontを利用しない場合は、ALBにも適用が可能です。
CloudFrontと併用する場合は、ALBにAWS WAFを適用することで、WAFを経由するリクエスト数を減らすことができます。ただし、接続元のIPアドレスをもとに攻撃をブロックするため、利用時には注意が必要です。
また、CloudFrontのキャッシュヒットが原因で、レートベースのルールが意図しない動作になる可能性もあります。
■Amazon API Gateway
APIを作成する場合に活用可能な、API gateway上にも設定が可能です。
対応可能な攻撃内容
対策可能な攻撃
「AWS WAF」で防ぐことができる主要な攻撃をいくつか紹介します。
■SQLインジェクション
SQLインジェクションは、データベースを操作するSQL文をWEBリクエストに含めることで、意図しないSQL実行を行います。通常アプリケーションで対策が可能ですが、対策できていないとデータの削除や非公開データの閲覧、改ざんなどの被害を引き起こします。
■ブルートフォースアタック
ログイン機能があるサイトで、ユーザーとパスワードの組み合わせを総当たりで試し、不正ログインを試みる攻撃をブルートフォースアタックといいます。不正ログインが成立してしまうと、個人情報の漏洩や金銭的な被害、Webサイト改ざん、攻撃の踏み台などに悪用される可能性があります。
■クロスサイトスクリプティング(XSS)
クロスサイトスクリプティングは、攻撃者が不正なスクリプトを信頼性のあるウェブサイトに注入し、他のユーザーのブラウザでそのスクリプトを実行することで発生します。
AWS WAFの料金体系
AWS WAFの料金は、以下の要素によって決定されます：
- WebACLの数
- 利用するルールの数
- リクエストの数
AWS WAFの利用方法
AWS WAFを利用する際の推奨される手順は以下の通りです：
- 1.AWS WAFの構築
2.カウントモードでのテスト運用
3.ブロックモードでの本番運用
AWS WAFの運用に必要な要素
AWS WAFの運用フェーズに移行すると、次のような要素について継続的な管理が必要となります。いずれも専門的な知識をもったエンジニアの継続的な確保が必要になります。
WAF自動運用ツールの利用も一つの選択肢
Cloudbric WMSやWAFCharmなど、WAFの自動運用をサポートするツールも存在します。WAFの運用業務をクラウド化するこれらのツールを利用することで、最新の脅威情報に基づいた自動ルール更新や適用範囲の自動調整など、運用に必要なプロセスを大幅に簡素化することが可能です。自社で運用しようとすると、高度な専門知識を持った人材が必要になるため、リソース不足の企業は検討してみるとよいでしょう。
関連するFAQ
Q. AWS WAFだけでSQLインジェクション対策は十分ですか？
A. 不十分です。WAFはあくまで「入口での防御」であり、アプリケーション側のバリデーションやORM利用などの対策と併用する前提です。WAF単体に依存すると、回避されるリスクが残ります。
Q. CloudFrontとALB、どちらにWAFを置くべきですか？
A. 基本はCloudFront側での防御が推奨されます。全リクエストをエッジで遮断できるため効率的です。ただし、ALB側でのみ判定したい条件（内部向け制御など）がある場合は併用も有効です。構成によっては二重管理になるため設計が重要です。
Q. レート制限はどのくらいに設定すればよいですか？
A. サイト特性によります。例えば一般的なログイン機能であれば「5分間に100リクエスト」などが初期目安になりますが、ECやキャンペーン時は正規トラフィックも急増するため、ログを見ながら段階的に調整する必要があります。
Q. CloudFrontのキャッシュはWAFのレート制限に影響しますか？
A. はい、影響します。キャッシュヒット時はリクエストがオリジンに到達しないため、ALB側のWAFでは正確なレート把握ができないケースがあります。この違いを理解せずに設計すると、意図通りに制御できません。
Q. AWS WAFのデメリットは何ですか？
A. 主に「誤検知」と「コスト増」です。ルールが厳しすぎると正規ユーザーをブロックする可能性があり、逆に緩いと防御が不十分になります。また、ルール数やトラフィック増加に伴い料金も増えるため、継続的な最適化が必要です。
Q. 運用はどのくらい大変ですか？
A. 軽くはありません。最低でも週次でログ確認、誤検知の分析とルール調整が必要です。攻撃が増えたタイミングでは一時的に対応工数が増えることもあります。運用リソースが不足する場合は自動運用ツールの検討も現実的です。
まとめ
「AWS WAF」を利用することで、ウェブアクセスの脆弱性対策を実施することが可能となります。
開発時のアプリケーションの設計と実装で防げる攻撃も多くありますが、その中でも対策の抜け漏れや新たに発生する脆弱性に対するリスクを軽減することができます。ただし、AWS WAFの導入だけで終わりではなく、導入後の運用フェーズでの対策と維持も重要となります。そのため、それらを考慮した利用が必要となるでしょう。