Why It Fits
選ぶ理由
- L7 のアプリ攻撃を遮断(SQLi / XSS)
- 既知脆弱性を“仮想パッチ”で緩和
- クラウド型は導入が容易
Web アプリ防御
Web アプリへの通信を検査し、SQL インジェクションや XSS などアプリ層(L7)の攻撃を遮断する防御。FW が通す HTTP の中身を見るのが役割で、クラウド型・アプライアンス型・ホスト型がある。
Core Facts
Introducing
Decision Guide
採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。
Why It Fits
Trade-offs
Deep Dive
WAF(Web Application Firewall)は、Web アプリケーションへの通信内容を検査し、アプリ層(L7)を狙う攻撃を遮断する仕組みです。守る対象は Web サイトや Web API そのもので、外部からの不正なリクエストを入口で止めます。
代表的に防ぐのは、SQL インジェクションやクロスサイトスクリプティング(XSS)といった、入力値を悪用してアプリを操る攻撃です。
WAF は、やり取りされる HTTP リクエストやレスポンスの「中身」を読み取り、攻撃パターンや不正な入力を判定して通すか遮断するかを決めます。提供形態はいくつかあります。
ファイアウォール(FW)と名前は似ていますが、見ている層が違います。
つまり FW が建物の入退館ゲートなら、WAF は持ち込まれた荷物の中身を検査する役割です。両者は競合せず、重ねて使います。
WAF は導入後のチューニングが肝心です。ルールが厳しすぎると正規の通信まで止めてしまい(誤検知)、緩すぎると攻撃を見逃します。実際のトラフィックを見ながら調整し続ける運用が前提になります。
もう一つ重要なのは、WAF は攻撃を「遮断」するもので、アプリ自体の欠陥を直すものではない点です。脆弱なコードはそのまま残るため、根本的にはアプリ側の修正が必要で、WAF はその間や万一の備えとなる防御層と捉えるのが適切です。
Decision Context
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
公開 Web / API の保護
OSI 層: L7(アプリ) / 守る対象: Web アプリ / API / 主な脅威: SQLi / XSS / 不正リクエスト
既知脆弱性を“仮想パッチ”で緩和
誤検知で正常通信を弾くことがある
Landscape
製品名から個別の解説ページへ移動できます。
Use Cases