今こそ見直す「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
-
製品資料
[NTTPCコミュニケーションズ株式会社] 「回線速度不足」だけが原因ではない? Web会議の遅延を解決する方法とは -
製品資料
[東京エレクトロン デバイス株式会社] 工場の可用性向上に重要な「7つの領域」と対策 OTセキュリティ強化の基礎知識 -
製品資料
[リコージャパン株式会社] 問い合わせ対応で本来の業務が進まない、総務や情シスの負担をどう減らす? -
製品資料
[リコージャパン株式会社] 自社データから高精度な回答を生成、簡単に生成AIチャットボットを構築する方法 -
技術文書・技術解説
[アトラシアン株式会社] IT運用や従業員サポートは生成AIでどう変わる? 使い方や導入の流れは?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
全社標準Copilotに絶望? MS Copilotで問い合わせ6割減できた企業は何が違った
-
2
「Copilot」はなぜ放置される? “議事録要約止まり”を脱する処方箋
-
3
「AI活用を前提とした業務PCへの移行」に関するアンケート
-
4
「データストレージの活用方法」に関するアンケート
-
5
身代金支払いは逆効果 情シスのためのランサムウェア対策ガイド2026
-
6
多要素認証導入済みでもランサムウェア被害に 復旧費用は平均2億7000万円
-
7
DXを阻む「動くだけ」のレガシーシステムに決別するための生成AI活用術
-
8
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
9
「ITインフラとデータ保護・バックアップ対策」に関するアンケート
-
10
自社を守る「SCS評価制度」活用法 7割の企業が取引先起点の情報漏えいに直面
ホワイトペーパーランキング PR
-
1
5回聞くだけじゃ足りない? トヨタ式「なぜなぜ分析」の正しい実践方法
-
2
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
3
生成AIで文書活用を進めるには? 効率化と安全性をどう両立する
-
4
Windows PCとMacの選択制で生産性向上 LINEヤフーが実践する運用管理方法とは
-
5
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
6
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは?
-
7
「スクラム」と「カンバン」の違いとは? アジャイル型開発手法を徹底比較
-
8
AI時代に成功するための「ナレッジマネジメント」ベストプラクティス
-
9
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
10
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー