WAFとは? ― 一般的なファイアウォールとの違い、公開Webサイトに必要な理由
一般的なファイアウォールは送信元、宛先、ポートしか見ておらず、中身までは確認しません。WAFが公開サイトに必要な理由をやさしく丁寧に解説します。
WAFとは? ― 一般的なファイアウォールとの違い、公開Webサイトに必要な理由
一般的なファイアウォールは、玄関で「誰が、どの入口から入ってくるか」を確認する警備員のようなものです ― 送信元、宛先、ポートしか見ておらず、実際に何を持ち込んでいるかまでは確認しません。問題は、WebサイトやAPIは設計上ポート80/443を誰にでも開放していることです。そのため一般的なファイアウォールは、正しいポートに届いたHTTPリクエストであれば、それが本物の顧客であってもSQLインジェクションの試みであっても、そのまま通してしまいます。
WAF（Web Application Firewall） は、実サーバーに届く前に各HTTPリクエストの「中身」を検査する層です ― 身分証を確認するだけでなく、カバンの中身まで開けて確認する警備員のようなものです。
WAFと一般的なファイアウォールの違い
| 一般的なファイアウォール | WAF |
|---|
| 見ている層 | ネットワーク層 ― IP、ポート、プロトコル | アプリケーション層 ― HTTPリクエストの実際の中身 |
| 防ぐもの | ネットワークレベルの不正アクセス | OWASP Top 10、ボット、異常な高頻度リクエスト、ブルートフォース |
| 検知できる例 | ポートスキャン、許可リスト外のIP | SQLインジェクション、クレデンシャルスタッフィング、パストラバーサル |
| 設置場所 | ネットワークの境界 | Webサイト・APIの手前、オリジンサーバーの前 |
簡単に言えば、ファイアウォールは「誰がノックしたか」で判断し、WAFは「ノックした後に何を言ったか」で判断します。この2つは代替関係ではなく補完関係です ― 一般的なファイアウォールしかない組織は、アプリケーション層の攻撃をそのまま通してしまう状態のままです。
WAFがトラフィックをフィルタする仕組み ― 4ステップ
1) リクエストを検査 ― 届いた各HTTPリクエストのヘッダー、パラメータ、ペイロードの内容を検査します
2) ルールと照合 ― 既知のシグネチャ（OWASP Top 10、ボットパターン）や、通常のベースラインから外れた挙動と照合します
3) ブロックまたは許可 ― そのリクエストをブロックするか、CAPTCHAでチャレンジするか、通常どおり通すかをリアルタイムで判断します
4) ログを記録 ― 後から確認できるようすべてのイベントを記録し、攻撃タイプを自動分類します
公開WebサイトやAPIになぜWAFが必要か
一般公開されているWebサイトやAPIは、肉眼では実際のユーザーと区別しづらい脅威にさらされています。
- OWASP Top 10 ― SQLインジェクション、XSS、Broken Access Controlなど、最も一般的なWeb攻撃パターン
- ボット・自動化スクリプト ― 他所から漏えいしたパスワードリストを実際のアカウントに対して試すクレデンシャルスタッフィングボットやスクレイパー
- 異常なリクエストの急増 ― 実際の攻撃とクライアント側の不具合の両方から起こり得て、専用のツールなしでは区別が困難
- パストラバーサルと脆弱性スキャン ― 外部からアクセスできてはならないファイルやエンドポイントへの侵入試行
zcrWAFダッシュボードでの実際の見え方
zcrWAFのデモのダッシュボードはこれをライブで追跡します ― リクエストの総数・許可数・ブロック数、国別の主要な攻撃元IPの内訳、そしてリアルタイムQPSカウンター。日次サマリーを待たずにチームがその場で状況を把握できます。このデモはプラットフォーム自体のサンプルトラフィック上で動作しているため、ダッシュボードが何を追跡できるかを示すものであって、導入組織が実際に経験する数値を保証するものではありません。
重要なのは許可とブロックの比率そのものです ― トラフィックが少ないサイトでも大部分は実際のユーザーですが、ブロックされる分こそ、一般的なファイアウォールなら正しいポートに届いたというだけでそのまま通してしまっていたはずのものです。
自社にWAFが必要なサイン
- 一般公開されているWebサイトやAPIを運用している、特にログインフォームや顧客データを扱っている場合
- 説明のつかないトラフィックの急増を見たことがある、あるいはログインページにボットがパスワードを試している疑いがある
- 開発チームがすべての脆弱性を期限内にパッチできず、実際の修正が完了するまでの間の追加の防御層が必要
- 顧客データがWebフォームの背後にある業界にいる（Eコマース、金融）― Web脆弱性経由の漏えいはPDPAの義務に直結する
- 実際のユーザートラフィックと、弱点を探るボット・スキャナーを区別する手段がない
2〜3個当てはまるなら、zcrWAFはまさにこの層のために作られています。
zcrWAFがカバーする範囲
zcrWAFはオリジンに到達する前にトラフィックを検査し、以下をカバーします。
一般公開のWebサイトやAPIを運用しており、現在のトラフィックにこうしたシグナルがないか確認したい場合は、zcrWAFのプランをご覧ください。
お問い合わせ
運用中のWebサイトやAPIに異常なトラフィックが潜んでいないか、気になりませんか。お気軽にご相談ください。無料でご相談いただけます。
出典