WAF とは？仕組みや種類、AWS WAF での導入手順を徹底解説
インターネットを通じたビジネスがインフラとして定着した現在、 Web アプリケーションを狙うサイバー攻撃は企業規模を問わず増加の一途をたどっています。従来のファイアウォールだけでは防ぎきれない高度な脅威に対抗するため、アプリケーション層に特化した防衛策の導入が急務となっています。
本記事では、 WAF の基本概念から検知の仕組み、自社に最適な導入形態の選び方、 具体的な対策、そして AWS 環境における実践的な活用方法までを体系的に解説します。
WAF の定義と基本概念
WAF は Web Application Firewall の略称であり、 Web アプリケーションに対する不正なアクセスやサイバー攻撃を検知し、遮断するセキュリティシステムです。
従来のファイアウォールが IP アドレスやポート番号を基準にネットワーク層での通信制御を行うのに対し、 WAF はアプリケーション層で動作します。具体的には、ブラウザとサーバー間でやり取りされる HTTP および HTTPS の通信内容を詳細に解析し、SQL インジェクションやクロスサイトスクリプティングといった Web アプリケーション特有の脆弱性を突く攻撃パターンを識別してブロックします。
ユーザーが Web サイトにアクセスする際、そのリクエストに含まれる URL やクエリ文字列、HTTP ヘッダーなどを WAF が受け取り、あらかじめ定義された攻撃パターンと照合します。パターンに合致した場合は通信を遮断し、正常なリクエストのみをサーバーへ到達させる門番として機能します。
WAF が求められる背景
Web アプリケーションへの攻撃手法は自動化・巧妙化が進んでおり、大企業だけでなく中堅・中小企業のコーポレートサイトや EC サイトも無差別に狙われています。攻撃者は専用のツールを用いてインターネット上の脆弱なシステムをスキャンし続けるため、知名度の低さは防御の理由になりません。
さらに、クラウドサービスの普及によって Web アプリケーションの公開が容易になった反面、設定の不備がセキュリティホールとなるケースが急増しています。個人情報保護の観点からも、企業にはアプリケーション層に特化した強固な防衛策の実施が強く求められています。
WAF の仕組みと検知方式
WAF が攻撃を検知・遮断する技術的なアプローチを理解することは、適切な製品選定と運用につながります。
HTTP 通信の検査フロー
WAF は Web アプリケーションとユーザーの間に配置され、すべてのトラフィックを中継して検査します。ユーザーのブラウザから送信されたリクエストはまず WAF を経由し、パスや送信データなどの内容が解析されます。
事前に定義されたルールセットと照合し、不正なパターンを検出した場合はリクエストを破棄して攻撃者にエラーを返します。正常と判断されたリクエストのみが Web サーバーへ転送され、リアルタイムな処理によってユーザーの体感速度への影響を最小限に抑えます。
攻撃を識別する2つのアプローチ
検知方式は大きくブラックリスト方式とホワイトリスト方式に分かれます。
ブラックリスト方式は、既知の攻撃パターンを禁止リストとして登録し、一致する通信を遮断します。正常な通信を誤って止めてしまう誤検知が少ない利点がありますが、リストにない未知の攻撃には対応できません。
一方、ホワイトリスト方式は正常なリクエストのパターンのみを許可リストとして登録し、それ以外をすべて遮断します。未知の攻撃にも対応できる高い防御力を持ちますが、多様なシステムの利用パターンをすべて登録・管理する運用負荷がかかります。
実際の運用では、ブラックリスト方式で既知の攻撃を効率的に弾き、中核となるシステムにホワイトリスト方式を組み合わせる多層的な設定が一般的です。
検知エンジンの技術
検知の核となるエンジンには、シグネチャベースと機械学習型のアプローチが存在します。
シグネチャベースは、セキュリティベンダーが提供する既知の攻撃パターンデータベースとリクエストを照合します。導入直後から高い防御力を発揮しますが、公開されたばかりの脆弱性を狙うゼロデイ攻撃には対応が遅れるという課題があります。
これを補うのが機械学習型のアノマリ検知です。通常の通信パターンを継続的に学習し、そこから逸脱した異常な通信を未知の攻撃として検知します。近年はこれら両方の技術を組み合わせたハイブリッド型の製品が主流となっています。
防御できる攻撃と WAF の限界
WAF はアプリケーション層の脅威に特化していますが、万能ではありません。対応範囲と限界を把握し、システム全体の設計に組み込む必要があります。
代表的な攻撃への対応
WAF は以下のような頻出する攻撃手法に対して高い防御効果を発揮します。
- 入力フォームに不正な SQL 文を紛れ込ませてデータベースを操作する SQL インジェクションを検知し、情報漏洩やデータ改ざんを防ぎます。
- Web ページに悪意のあるスクリプトを埋め込むクロスサイトスクリプティングのパターンを識別し、ユーザーのセッション情報の窃取を阻止します。
- 特定の URL に対してディレクトリ階層を遡る文字列を含ませるパス・トラバーサル攻撃を遮断し、システムファイルへの不正アクセスを防止します。
- 一定時間内に異常な回数のリクエストを送信する IP アドレスを制限し、 DDoS 攻撃によるサービス停止のリスクを軽減します。
また、近年増加している生成 AI を組み込んだ Web アプリケーションの保護にも WAF は有効です。 AI は必ずしも正解を教えるものではなく、 AI が（特定のソースに基づき）回答を生成・提示しますが、プロンプトインジェクションなどの攻撃から AI モデルを守る層として機能します。あわせて、 RAG（検索拡張生成）などの仕組みでハルシネーションを抑制しつつ、 AI の出力品質を定量的・継続的に評価することで、安全で高品質なサービスを提供できます。
WAF では防げない領域と補完策
WAF は HTTP リクエストの検査に特化しているため、管理コンソールへの単純なパスワード推測による不正ログインや、クラウド環境の設定ミスによるデータ公開を防ぐことはできません。また、権限を持つ内部関係者による意図的なデータ持ち出しも、正規の通信として処理されるため検知が困難です。
これらの限界を補うため、管理コンソールへのアクセスには IAM による最小権限の付与と多要素認証（MFA）を徹底し、セキュリティグループやネットワーク ACL によるネットワーク層の制御を組み合わせてください。 WAF 単体ではなく、複数のセキュリティレイヤーで防御する設計が重要です。
WAF の種類と選定基準
WAF の導入形態は、インフラ環境や運用体制に合わせて選択する必要があります。
3つの導入形態
ホスト型 WAF は、Web サーバーの OS 上にソフトウェアとして直接インストールします。ネットワーク構成を変更せずに導入でき、サーバーごとの細かなチューニングが可能ですが、サーバー台数に比例して管理工数とシステム負荷が増大します。
ゲートウェイ型 WAF は、Web サーバーの前段に専用のネットワーク機器として設置します。多数のサーバーを一台で保護できるため大規模環境に適していますが、ハードウェアの初期費用が高額になり、機器の障害がシステム全体の停止につながるリスクへの対策が求められます。
クラウド型 WAF は、 DNS の設定を変更してトラフィックをサービスプロバイダーのインフラ経由にするだけで導入できます。専用機器が不要で初期費用を抑えられ、トラフィックの増減に柔軟に対応できるスケーラビリティを備えています。シグネチャの更新も自動で行われるため、運用負荷を大きく軽減できます。
選定時のポイント
自社のシステムが AWS などのパブリッククラウド上で稼働している場合は、環境と親和性の高いクラウド型 WAF が第一の選択肢となります。また、社内にセキュリティ専任の担当者がいない場合は、マネージドルールが充実しているクラウド型を選ぶことで、継続的なチューニングの負担を軽減できます。
AWS WAF によるクラウドセキュリティの最適化
AWS 環境を利用している企業にとって、AWS WAF はインフラに組み込みやすい有効な防衛手段です。
AWS WAF の機能
AWS WAF は、Amazon CloudFront（CDN） によるオリジン保護や Application Load Balancer と統合して動作するマネージドサービスです。通信を制御する Web ACL に複数のルールを設定し、トラフィックを検査します。
AWS や専門ベンダーが提供するマネージドルールグループを適用するだけで、一般的な Web 攻撃に対する防御体制が整います。シグネチャは自動で更新されるため、最新の脅威にも追随可能です。
さらに、独自の要件に合わせて特定の IP アドレスや URL パターンを制御するカスタムルールを作成でき、異常な頻度のアクセスを自動で遮断するレートベースルールも備えています。
高度な脅威に対しては、悪意のあるボットを識別する AWS WAF Bot Control や、盗まれた認証情報によるアカウント乗っ取りを防ぐ AWS WAF Fraud Control などの拡張機能を組み合わせることで、強固な保護を実現します。
参照：AWS WAF の機能
失敗を防ぐ段階的導入アプローチ
WAF の導入において最も警戒すべきは、正常な通信を遮断してしまう誤検知による業務への影響です。以下の3フェーズによる安全な導入手順を推奨します。
Phase 1：カウントモードによる安全な効果検証
まずは Web ACL を作成し、 AWS Managed Rules の基本的なルールグループを適用します。この際、ルールのアクションを通信を遮断するブロックではなく、記録のみを行うカウントモードに設定します。実際のトラフィックを流しながら、正常なユーザーのアクセスが誤って検知されていないかをログで確認し、ルールの適合性を評価します。
Phase 2：例外処理の設定とブロック化
カウントモードでの検証結果に基づき、誤検知が発生している場合はスコープダウンステートメントを利用して特定の URL や IP アドレスをルールの適用外とする例外設定を追加します。誤検知が解消されたことを確認した上で、アクションをブロックモードへ切り替え、本格的な防御を開始します。
Phase 3：継続的なログ監視とチューニング
運用開始後は、 Amazon CloudWatch のダッシュボードを活用してブロックされたリクエストの傾向を定期的に分析します。新しい攻撃手法の兆候や、アプリケーションの改修に伴う新たな誤検知が発生していないかを監視し、ルールの追加や除外設定のチューニングを継続的に実施して防御精度を維持します。
また、誤設定による大規模な通信遮断に備え、 WAF ルールのバックアップや切り戻し手順を事前に確立してください。
最後に
WAF は、SQL インジェクションやクロスサイトスクリプティングといったアプリケーション層への攻撃を防ぐための重要な防衛ラインです。自社のインフラ構成に合わせた導入形態を選択し、カウントモードを活用した慎重な検証を経て運用を開始することが、ビジネスへの影響を最小限に抑えつつセキュリティを強化する鍵となります。
cloudpack では、 AWS WAF をはじめとするセキュリティサービスの導入および運用最適化を支援しています。
Amazon CloudFront や AWS Shield などのサービスと組み合わせた多層防御のアーキテクチャ設計から、運用中の誤検知対応やログ監視体制の構築まで、トータルでサポートいたします。
クラウド環境のセキュリティ強化でお困りの点がありましたら、お気軽に cloudpack へご相談ください。