今こそ見直す「Webセキュリティ対策」【最終回】
危険なWeb攻撃から身を守る「Webアプリケーションファイアウォール(WAF)」の全て
相次ぐWeb攻撃にどう対処すべきか。対策を支援するセキュリティ製品は幾つかあるが、特にWebアプリケーションの保護に焦点を当てたのが「WAF」だ。その機能や選び方のコツを解説する。
本連載ではこれまで、Webサイトやその中核要素となるWebアプリケーションに対する最新の攻撃手法やその対策について説明してきた。最終回となる本稿では、Webセキュリティの決定打の1つとなる「Webアプリケーションファイアウォール(WAF)」について詳細に解説する。
連載:今こそ見直す「Webセキュリティ対策」
今更聞けない、「WAF」とは何か
今やインターネットを介したサイバー攻撃の大半がWebを標的にしている。このことから、WebサイトやWebアプリケーションの保護に特化したセキュリティ製品であるWAFに対する認知度が急速に高まっている。
認知度は向上しているものの、従来型のネットワークセキュリティ製品と比較して、具体的に機能レベルでどのような差異があるのかについては、意外と知られていない。また一部同様の機能を持つ「次世代型ファイアウォール」と混同されるケースも多いのが現状だ。WAFとは何かについて、ここで整理しておこう。
WAFに求められる機能
機能面で見ると、WAFに分類される製品は、以下のような機能を特に備えるものとして捉えることができる。
HTTP解析機能
WAFの中心的な機能がHTTP解析機能だ。この機能を理解するために、HTTPによる通信の仕組みを簡単に説明していこう。
Webアプリケーションと、Webブラウザなどのクライアントとの通信は、一対のクライアントからの通信要求である「リクエスト」と、Webアプリケーションからの応答である「レスポンス」が多数発生することで成り立っている。
インターネットのプロトコル仕様を記載したRFCでは、クライアントからのリクエストは「URL」と「送信データ(パラメータ)」を含み、「GET」「POST」などのコマンドを使うといった、データの送信手順が定められている。Webアプリケーションやクライアントは、RFCが定めるこうした手順に従って、データを送受信している。
データの送受信時には、ヘッダ情報も合わせて送信される。特に重要なヘッダ情報として、要求の転送元を示す「referrer」、サーバ側から割り当てられた情報を保持する「cookie」などがある。
サーバからの応答レスポンスに必ず含まれるのが「レスポンスコード」だ。レスポンスコードは、リクエスト要求が成功したかどうか、また失敗した理由などを判断する材料を提供する。
膨大なトラフィックの中から、リクエストやレスポンスを識別して論理的に理解する――。これがWAFの最も基本的な処理内容である。
SSL復号機能
Webでは、重要な情報を含むデータの送受信にはSSL暗号化を利用することが一般的であり、トラフィックをそのまま解析しても、送受信データの中身を識別できない。
WAFの配置方法に目を向けると、
- WAFをL2ブリッジとして動作させ、既存環境に透過的に設置する「透過モード」
- 外部からのTCPセッションを一度WAFで終端し、別セッションでWebサーバと通信する「リバースプロキシモード」
- L2/L3スイッチのモニターポート(監視用ポート)に接続する「スニフィングモード」
など複数ある。どの配置方法を取るにしても、性能を落とさずにSSL通信の復号や解析ができることが必須要件である。
ユーザーセッション追跡機能
HTTPでは、上述したcookieという識別子をリクエストに付与することで、個別のユーザーセッションの状態を保持できる。最近は、こうしたセッション管理の仕組みを悪用する「クロスサイトリクエストフォージェリ(CSRF)」「セッションフィクセーション」といった攻撃が盛んだ。こうした中、WAFにはHTTPのユーザーセッションを追跡する機能が求められている。
ブラックリスト検知、シグネチャ更新機能
連載第2回「“危ないWebアプリ”を生む『既存コードの脆弱性』の怖さ」で紹介した、CMSの既知の脆弱性を狙った攻撃を防御するには、シグネチャを利用した「ブラックリスト検知」が非常に有効だ。脆弱性は日々新しいものが報告されるので、シグネチャの更新頻度は高い方が望ましい。
学習によるホワイトリスト機能
Webアプリケーションの構造はWebサイトによって異なる。そのため、画一的な防御の仕組みでは攻撃に対処できない場合も多い。そのため、各Webアプリケーションが日常的に利用するURLやパラメータを学習し、通常のWebアプリケーション利用から逸脱した疑わしいアクセスを遮断できるホワイトリスト機能が重要になる。
相関分析機能
Web攻撃はますます巧妙化しており、セキュリティ対策製品による検知を回避する手法も確立している。上述したブラックリスト検知などの単一の検知手段だけで判断するのではなく、複数の検知手段で得た検知結果の相関をとり、総合的に危険度を判断する仕組みが重要だ。
カスタムポリシー作成機能
連載第4回「“パスワード使い回し”を悲劇に変える『アカウントリスト型攻撃』とは」で紹介したように、アカウントリスト型攻撃などをブロックする手段として有効なのが、カスタムポリシーの作成機能だ。時間によって制御のしきい値を変えたり、発信元のアドレスやURL/パラメータなどの制御条件を柔軟に変更できることが望ましい。
レピュテーション機能
IPアドレスや地理情報といったリクエストの発信元情報は、攻撃を判断する際の重要な情報となる。ただし、匿名プロキシや踏み台となるボットサーバなどを経由して発信元を隠蔽し、攻撃源の特定を難しくすることは多くの攻撃で見られる。こうした手法に対抗する万能な手法はないが、過去の実績や第三者情報を利用したレピュテーションによって判断する方法が有効だ。
上述した全ての機能は、本連載で特に紹介してきた最新の脅威の防御において重要な役割を果たす。他のゲートウェイ/ネットワークセキュリティ製品と比較しても、アプリケーション層の防御においてWAFは全般的な強みを発揮し、かつ柔軟なカスタマイズも可能なのが強みだ。特に、HTTP解析機能やユーザーセッション追跡機能は、アプリケーション層の防御に焦点を当てたWAFならではの機能だといえる。
WAFの選定ポイント
セキュリティ製品を比較する際に広く用いられているのが、脆弱性攻撃の「検知率」や脆弱性の「カバー率」といった指標である。既存の脆弱性にどの程度対処できるか、公開された脆弱性への対応スピードが速いかどうかなどを測るために利用する。
こうした指標を基にした比較は、WAF製品の選定に当たっては必ずしも適切ではない。高い検知率は、逆に高い誤検知率にもつながり、正常な通信を止めてしまう可能性があるからだ。Webアプリケーションの攻撃手法は比較的高度で複雑であり、1つの脆弱性を狙う攻撃手法が多数存在する場合もあることが背景にある。
WAFの検知率や誤検知率を評価するためには、Webサーバに対して診断ツールを仕掛けるだけでは難しく、検知率などのカタログ値に惑わされないようにしたい。できる限り公平にWAFの能力を評価する方法として、以下が挙げられる。
実環境における検証
自社のWebサイトのトラフィックを検査できる箇所にWAFを試験導入し、一定期間の動作確認をすることで、攻撃検知能力や正常トラフィックの処理を確認できる。実環境に導入する場合には、上述したスニフィングモードで導入ができるWAF製品があれば、運用中のWebサイトに影響を与えずにテストできる。
業界団体作成のWAF評価基準書
Webアプリケーションセキュリティに関する業界団体「Web Application Security Consortium(WASC)」が複数のWAFベンダーの意見を集約し、WAFの評価基準書「Web Application Firewall Evaluation Criteria(WAFEC)」を作成している。WAFに求められるさまざまな要件が網羅されているので、製品を比較する際の参考になるだろう。
WAF専用の評価ツール
Impervaの「WAF Testing Framework」など、高度なアプリケーション攻撃からWebサイトが守られていることを検証するための評価ツールも登場し始めている。こうした専用ツールの特徴は、誤検知および検知漏れの双方の指標でWAFを評価可能なことだ。攻撃を防御できるかどうかという視点だけではなく、攻撃と誤認しやすい正常なトラフィックもシミュレーションできるからである。
WAFの提供パターンはさまざま
現在、さまざまなタイプのWAF製品/サービスが存在する。提供形態で分類すると、(A)専用アプライアンスをネットワークに設置する「オンプレミス型」、(B)WebサービスとしてWAFを提供する「クラウド型」に大きく分類できる。それぞれの特徴を以下にまとめた。
| 導入形態 | 特徴 |
|---|---|
| オンプレミス型 | ・透過モード、スニッフィングなどさまざまなネットワーク構成が選択可能 ・環境に合わせたきめ細かなポリシーの作成やカスタマイズが可能 ・高度な攻撃手法にも対応可能 |
| クラウド型 | ・インターネットを介したリバースプロキシ構成が一般的 ・サーバのロケーションを気にせず導入が可能 ・短時間での導入が可能 ・分散型サービス妨害(DDoS)攻撃からの防御に大きな効果を発揮 |
高度な利用方法として、オンプレミス型とクラウド型双方のいいとこ取りをした「ハイブリッド型」で利用するケースもある。大量のネットワーク/サーバリソースを占有するDDoS攻撃の対策を例に取ってみよう。トラフィック全体をクラウド型のWAFでいったんフィルタリングすることで、DDoS攻撃のトラフィックを自社サイトの外部で止めることが可能となる。その上で、オンプレミス型のWAFは、より綿密にカスタマイズしたポリシーで運用し、多層的な防御を実施できる。
6回の連載を通して、Webアプリケーションに関する脅威のトレンドや対策法を紹介してきた。Webアプリケーションは今後もますます発展していくだろう。利便性と安全性は常にトレードオフの関係にある。「ユーザーにとっていかに便利なシステムを作るか」という議論はもちろん重要だが、セキュリティについても同じぐらいの時間を費やして議論しなければならない。本連載が、今後のWebアプリケーションセキュリティ対策を検討する一助となれば幸いである。
執筆者紹介
桜井勇亮(さくらい ゆうすけ) 株式会社Imperva Japan
Imperva Japanテクニカル・ディレクターとして、ユーザー企業のニーズに合わせた情報システム堅牢化策を提案している。また、さまざまな現場経験を踏まえ、機密情報保護をはじめ、新たな局面を迎えているデータセキュリティに関する国内ユーザーの知識向上を後押ししている。
Copyright © ITmedia, Inc. All Rights Reserved.
今こそ見直す「Webセキュリティ対策」
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー