WebサイトセキュリティはなぜWAF(Web Application Firewall)でなくてはいけないのか?近年では、Webサイトを対象にしたサイバー攻撃の増加により多くの運営者がその危険性を認識していることから、Webサイトセキュリティを強化するWAF市場が拡大しています。
皆さんの周囲(取引先や友人が務める会社)でも、WAFを導入したという企業が多いのではないでしょうか?本稿は、そんなWAFの仕組みを解説し、Webサイトセキュリティにおける重要性を伝えていきます。
何となくWAFが必要だということは分かっているけれど、なぜ必要なの?何ができるの?という疑問を持っている方は、ぜひ参考にしてください。
WAFが無いWebサイトセキュリティの限界
あらゆる情報やサービスがWebサイトを通じて提供される中、ユーザーの利便性は格段に向上しています。しかし、それと同時に拡大したのが、Webサイトが攻撃されるリスクです。Webサイトは常に改ざんや情報漏えいなどの脅威の中にあり、運営者はさまざまな観点からWebサイトセキュリティを実施する必要があります。では、WAFが注目される以前の対策はどういったものだったのでしょうか?
まず1つは「セキュアコーディング」です。これは、開発しているWebアプリケーションに脆弱性が発生しないように、セキュリティを意識しながら開発を進める対策手法になります。要するに、「脆弱性のないセキュアな開発、実装」の作成を目指します。それにはいくつかの条件があります。
開発にかかわる技術者のほとんどが同等のスキルを持つこと、厳格にルール化された状況下でコーディングにあたること、レビューとテストを何度も繰り返し脆弱性を排除するための時間が十分にあること、そこに伴うコストを惜しみなく投資できることです。セキュアコーディングは基本中の基本であるものの、完璧にこなすことは非常に困難であると言われています。
たとえ自社開発のWebアプリケーションだとしても、そこにかかる労力・手間・コストなどの面から費用対効果を考慮して、完璧なプログラムを実現するのが不可能なのです。加えて、人の手でコーディングする限り脆弱性を無くすことはほぼ不可能であると言われています。開発時点で脆弱性を100%排除できたとしても、プログラムを改修する際に新たな脆弱性が生まれる可能性もあります。
そしてもう1つの対策が「ファイアウォールやIPSといったセキュリティ製品」です。これらのセキュリティ製品は、ネットワークへのアクセスを監視し、不審な通信を遮断するものですが、Webアプリケーション層に対する攻撃の防御を目的とした製品ではありません。従って、Webアプリケーションの脆弱性を突かれれば、ファイアウォールやIPSでもそれを防げないのです。
これが、WAFが無いWebサイトセキュリティの限界です。
WAFの仕組み
多くのWAFは、Webサイトセキュリティを強化するために「シグネチャ検査」による防御を行っています。(※)これは、WAFベンダーが定義した検出パターンにもとづいて、Webアプリケーションへの通信(HTTPリクエスト、HTTPレスポンス)に含まれる各種データを検査して、サイバー攻撃を検出するというものです。シグネチャの方式には「ブラックリスト」と「ホワイトリスト」という、2つのタイプが存在します。
ブラックリスト
サイバー攻撃のパターンを定義したもので、リストに一致したアクセスを不正と判断し、防御または監視の対象とする。
ホワイトリスト
正しいパターンや通信など、許可したいアクセスを定義したもので、リストに一致しないものは不正とみなし、防御または監視の対象とする。
多くのWAFはブラックリストを主体として、ユーザー側で必要に応じてホワイトリストを調整できる機能を備え、それぞれの利点を生かす運用形態が増えています。
<ブラックリスト・ホワイトリストの利点と弱点>
|
ブラックリスト |
ホワイトリスト |
---|---|---|
利点 |
パラメーターを限定せずに既知のサイバー攻撃を検出できる。Webアプリケーションの作りに依存しないことから、導入負担及び運用負担が小さい。 |
適切なパラメーターが設定されている条件下において、未知のサイバー攻撃にも対応できる。 |
弱点 |
誤検出が発生する可能性がある。未知のサイバー攻撃に対応できない可能性がある。 |
ページやパラメーターごとにパターンを定義する必要があり、運用負担が大きい。正しいパターンの定義が難しい場合がある。 |
※WAF製品によっては他の検査方式を採用していたり、独自の検査ロジックを組み合わせることで検出精度を高めるなど、製品毎に特長があります。
実際に深刻な被害をWAFが防いだ事例
2017年に脆弱性が公開され、国内でも多数の被害が発生した「Apache Struts2」の脆弱性。Apache Struts2は幅広く利用されているWebアプリケーションフレームワークです。日本時間の3月6日に脆弱性が公開されると、短時間でPoC(Proof of Concept)が確認され、多くのWAFベンダーは3月7日時点で脆弱性を悪用する攻撃に対するシグネチャをリリースしています。
Webサイトで使用しているWebアプリケーションは、脆弱性に対応するための更新プログラムが公開されたとしても、すぐにバージョンアップ対応が難しいという運用上の課題が多く残されています。そうしたケースにおいてWAFは有効であり、Webアプリケーション自体の脆弱性が排除できない状況においても、脆弱性を突いた攻撃を効果的に防ぐことができます。
WAFの種類
WAFにはいくつかの種類があります。①ホスト型、②ゲートウェイ型、③クラウド型という3つのタイプです。各種にはそれぞれの特徴とメリット・デメリットがあり、どのWAFが一番優れているということはなく、WAFを導入するWebサイトの特性や要件に合ったものを導入するのがベストな選択です。
①ホスト型
WebサーバーにインストールするソフトウェアタイプのWAFです。最もシンプルな構成なので、専用ハードウェアは不要であり、ネットワーク構成に影響を与えないのが大きな利点です。昨今ではハードウェア性能が向上していることから、Webサーバーに与える影響度は少なくなっています。ただし、Webサーバーごとにインストールする必要があり、環境によってコストが割高になります。
②ゲートウェイ型
ネットワーク上において、Webサーバーの前段で独立した機器として設置するWAFです。リバースプロキシやインライン構成で設置されるケースが多く、アプライアンス機器の場合はネットワーク機器のミラーポートを使用することで、通信をミラーさせて検査だけを行う構成も取れます。また、仮想基盤向けの仮想アプライアンスもあります。リバースプロキシは拡張性が高いのが特徴で、インライン構成は導入しやすいという特徴があります。ただし、専用機としてハードウェアを購入したり、ネットワーク構成を変更したりする負担があります。
③クラウド型
DNS設定を変更することで、WAFベンダーが提供するサービスをネットワーク経由で利用します。専用ハードウェアを用意する必要や、物理的なネットワーク構成を変更する必要がなく、WAF運用をベンダーに任せられるのがメリットです。ただし、FQDNの数や通信料によってサービス料金が上がることや、組織外の通信障害などの影響を受ける可能性があります。
いかがでしょうか?本稿ではWAFの仕組みと、加えて各種の特徴についてご紹介しました。詳しく技術情報やWAFの選定、導入のポイントなどをご紹介したダウンロードコンテンツもご用意していますので、合わせてご利用ください。
- カテゴリ:
- WAF
- キーワード:
- WAF
この記事に関する製品のご紹介
ホスト型WAF「SiteGuard Server Edition」
SiteGuard Server Editionは、ウェブサーバーのモジュールとして動作するホスト型WAF製品です。Webサーバー自体にインストールするため、専用ハードウェアが必要ありません。ネットワーク構成を変更せず、できるだけシンプルに導入したいお客様に最適な製品です。
詳細はこちら