導入: WAF とは何か —— Web への通信を入口で検査する仕組み
WAF (Web Application Firewall) は、Web サイトや Web API に届く HTTP/HTTPS 通信を検査し、あらかじめ定めたルールに照らして、通信を通す・記録する・遮断するといった制御を行うセキュリティ機能です。Web サイトの前段に設置する「通信の検問所」と考えると分かりやすいでしょう。
インターネットに公開された Web サイトには、SQL インジェクションやクロスサイトスクリプティング (XSS) など、よく知られた攻撃を狙う通信が届きます。WAF は、こうした通信に含まれる特徴を検査し、既知の攻撃パターンに合致するリクエストを検知・遮断することで、Webアプリケーションに攻撃が届く可能性を下げます。製品や契約内容によっては、アクセス頻度の制限、ボット対策、通信ログの可視化なども担います。[1]
経営者・管理者層が押さえるべきWAF の役割は、次のように整理できます。
| WAF が担える役割 | 組織にとっての効果 | 留意点 |
|---|---|---|
| 既知の攻撃パターンの検知・遮断 | 不審なWeb リクエストをアプリケーションに到達する前に止める | ルールが認識できる通信が対象。すべての攻撃を識別できるわけではない |
| 一部の脆弱性への仮想パッチ | 恒久修正までの間、特定の攻撃リクエストを一時的に遮断できる場合がある | 脆弱なプログラム自体は修正されない。適用範囲と回避可能性の確認が必要 |
| アクセス頻度・ボットの制御 | 大量アクセスや自動化されたリクエストを抑制できる場合がある | 正常な自動処理との区別や業務影響の検証が必要。機能は製品により異なる |
| 通信の記録・可視化 | 攻撃の傾向や遮断状況を把握する手掛かりになる | ログを分析し、対応する運用がなければ十分に活用できない |
つまり WAF は、Web への入口で通信を検査し、既知の攻撃や不審なアクセスを減らすための対策です。Web サイトを安全にするために有用ですが、サーバー、ミドルウェア、アプリケーション、データそのものを包括的に守る仕組みではありません。
WAF が守れるのは、基本的に WAF を通過する通信、すなわち WAF 製品が検査できる通信です。下記のものなどは WAF だけでは解決できません:
- 正規のログイン状態を使った不正操作
- アプリケーション内部の認可不備
- 未修正のミドルウェアの弱点
- 侵害後のサーバー内部の活動
WAF は「完全な鎧」ではなく、多層防御を構成する一つの防御点です。 製品を導入した事実で安心するのではなく、自組織の脅威と事業リスクを把握し、基盤・アプリケーション・運用を含めた対策を継続する必要があります。
インシデントから学ぶ —— WAF と異なるレイヤーで起きた問題
WAF の限界を考えるうえでは、WAF そのものや設定に関係する事例だけでなく、WAF とは異なるレイヤーの不備が原因となった事例も参考になります。ここでは、WAF / クラウド設定と、アプリケーションの API 権限設定という、異なる二つの事例を取り上げます。
事例 1: Capital One —— WAF の設定不備がデータへのアクセス経路になった (2019 年)
2019 年、米国の金融機関 Capital One で、クレジットカード申込者や顧客に関する情報への不正アクセスが発生しました。米国司法省の事件概要によると、侵入は、データへのアクセスを可能にする設定不備のある WAF を経由して行われました。
この事例は、WAF が存在すれば安全というわけではなく、WAF やその周辺の設定が不適切であれば、意図しないアクセス経路になり得ることを示しています。境界で通信を検査するだけでは不十分であり、クラウド上の認証情報やアクセス権限、データ保管領域へのアクセス制御も独立して適切に設計・検証する必要があります。
ここから得られる教訓は、WAF の導入有無だけを確認するのではなく、保護対象への通信経路、WAF の設定、クラウドの権限、データへのアクセス制御を一体として管理することです。WAF が通過させた通信や、WAF の設定不備によって生じた経路の先で、どこまでの操作が可能になるのかを考えなければなりません。[4]
事例 2: T-Mobile —— API のアクセス権限設定不備 (2023 年)
2023 年 1 月、米国の通信事業者 T-Mobile は、単一の API を通じて顧客情報が不正に取得されたと公表しました。米国連邦通信委員会 (FCC) の調査資料によると、人的な設定ミスによって API の権限設定が不適切になり、攻撃者が API にクエリを送信して顧客アカウント情報を取得できる状態になっていました。影響したのは約 3,700 万件の現行のポストペイドおよびプリペイド顧客アカウントで、取得された情報の項目はアカウントごとに異なっていました。
この事例の中心は、典型的な攻撃文字列やサーバーの脆弱性ではなく、API がどの情報へのアクセスを許可してよいかという権限管理でした。リクエストの形式が正しく、API 自体も正規の機能であっても、サーバー側の認可確認が不十分であれば、本来許可されていない情報取得が成立してしまいます。
なお、公開資料からは、この API に WAF が導入されていたか、あるいは WAF を迂回したのかまでは確認できません。したがって、この事件を「WAF が突破された事例」と説明することは適切ではありません。ここでの教訓は、 WAF が通信を検査していても、利用者がそのデータを取得する権限を持つかどうかは、アプリケーション側で検証しなければならない という点です。[5]
二つの事例から分かること
| 事例 | 問題があったレイヤー | 経営・管理上の教訓 |
|---|---|---|
| Capital One (2019 年) | WAF の設定と、クラウド上のアクセス経路・権限管理 | WAF の設定だけでなく、その先のクラウド資産やデータへのアクセス権限も検証する |
| T-Mobile (2023 年) | API のアクセス権限・アプリケーションの認可管理 | 正規の API 通信であっても、利用者ごと・データごとの認可をサーバー側で確認する |
二つの事例は、異なる場所にある設定や制御の不備が、情報漏えいにつながり得ることを示しています。WAF は入口の通信を検査する重要な防御点ですが、クラウドの権限管理やアプリケーションの認可判断まで代行するものではありません。組織は、各レイヤーに適切な責任者と検証手順を置き、それぞれの対策が機能していることを確かめる必要があります。
要点: まず押さえるべきこと
| 要点 | 経営・管理上の意味 |
|---|---|
| WAF は有効だが、完全な防御ではない | WAF が検査する通信と、設定されたルールで捉えられる攻撃に防御範囲は限られる |
| WAF は脆弱性そのものを直さない | 仮想パッチとして一時的に攻撃を抑えられる場合はあるが、恒久対策はソフトウェア更新や設計修正である |
| 正規のログイン状態を悪用する攻撃がある | 通常の通信に見えるAPI操作や業務ロジックの悪用は、一般的なWAF だけでは判断しにくい |
| 導入後の運用が必要 | ルール更新、誤検知調整、ログ監視、適用範囲の確認、回避経路の検証が欠かせない |
| セキュリティは経営上の継続課題 | 資産把握、パッチ管理、アプリケーションの認可設計、監視・復旧に予算・責任者・期限を割り当てる必要がある |
次の記事ではこれらを掘り下げます。
参考資料・出典
- AWS, “AWS WAF Documentation” — WAF が保護対象へ転送される Web リクエストを検査し、条件に応じてカウント、遮断、許可、チャレンジを行う機能の説明。製品ごとに機能・対応範囲は異なる。 https://docs.aws.amazon.com/waf/
- U.S. Department of Justice, “United States v. Paige Thompson” — Capital Oneの情報への侵入が、データへのアクセスを可能にする設定不備のあるWeb Application Firewallを経由して行われたとする事件概要。また、Capital Oneの2019年7月29日付公表資料は、同社が設定上の脆弱性を悪用した不正アクセスを確認したことを説明している。 DOJ case summary · Capital One incident announcement
- Federal Communications Commission (FCC), “In the Matter of T-Mobile US, Inc.”, DA 24-860 (2024) — 2023年1月に発覚したAPI経由の情報取得について、人的な設定ミスによる権限設定不備と、約3,700万件の顧客アカウントへの影響を記録した調査・同意命令。補足として、T-Mobileの2023年1月19日付公表資料も参照。 FCC document · T-Mobile announcement
本記事は、WAF を否定するものではありません。WAF の有効性を認めたうえで、その防御範囲と限界を明確にし、他の対策と組み合わせる必要性を論じています。製品の具体的な機能・対応プロトコル・検知範囲は、利用するWAF の仕様と設定を確認してください。