今こそ見直す「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
-
製品資料
[株式会社インターネットイニシアティブ] 人材不足と属人化が深刻に 「攻められない情シス」を変革する一手とは? -
製品資料
[株式会社イトーキ] 会議室が「空いてるのに使えない」問題の解決策とは? -
事例
[株式会社イトーキ] 製造現場を取り巻く経営課題 「持続的な現場力」を強化する方法とは? -
製品資料
[株式会社イトーキ] 社員の力を引き出す、「ABW(Activity Based Working)」を実現する秘訣とは? -
製品資料
[株式会社BREXA Technology] 「インシデント初動対応」が遅れる3つの構造的要因とは?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
企業が「Microsoft Azure」を選ばざるを得ない理由
-
2
Microsoft 365侵害企業の9割はMFA導入済み 1002人調査で見えた盲点
-
3
なぜノートPCの更新が「4年→6年」に? AIインフラ急拡大の余波
-
4
NVIDIA、フアンCEO辞任で揺らぐ“AI帝国” IT調達計画への影響は?
-
5
無課金から要課金まで AIの基本や応用がマスターできる“学習コース”9選
-
6
「リモートアクセスセキュリティ」に成功する企業、そうでない企業の違い
-
7
「営業・マーケティングの悩みと企業データの活用」に関するアンケート
-
8
「Active Directory」復旧で“詰む”企業が続出 ランサムウェアに備える4対策
-
9
脱VMwareの真実:データセンター大手がNutanixを選んだ「コスト以上の理由」
-
10
なぜMicrosoftは「Rust」を標準言語に? AIで進むC/C++書き換えの課題
ホワイトペーパーランキング PR
-
1
「IT史に名を残すシステム障害」8選
-
2
AIが苦手な「汚いデータ」になっていない? AI投資を無駄にしないための注意点
-
3
急増する高度なフィッシング詐欺 先回りしてブロックするには何が必要?
-
4
法人向け光回線のプランはどう選ぶ? 機能面/保守体制/コストを一覧で比較
-
5
サイバー脅威「トップ50」完全解説ガイド、新たな攻撃手法に対抗するには
-
6
SNMPより詳細で、パケット解析より簡単な「トラフィック可視化・分析」の方法
-
7
三井ホームに学ぶ「無線LAN環境」構築 快適なオフィスと高度なIT運用の両立法
-
8
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
-
9
自社のメール環境は本当に安全? チェックシートですぐ分かる“今必要な対策”
-
10
「RPA導入の成果が出ない」を防ぐ、成果につながる自動化対象業務の選び方
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー