Webサイトを守るには

資料ダウンロード

Webサイトを守るには

ファイアウォールやIPSでWebサイトは保護できる？

Webサイトの攻撃をファイアーウォールやIDS・IPSは防御してくれるでしょうか。答えはNOです。インターネット上でサービスを提供する以上、ファイアウォールは外部からのHTTP(S)リクエストを拒否するわけには行きません。従って、ファイアウォールはWebサイトへの攻撃にはまったく無力なのです。IDS・IPSはシグネチャによるパターンマッチングによって不正パケットを検知・防御しますが、独自に開発されるWebアプリケーションの場合、不具合を起こすパターンが千差万別なため、Webサイトへの悪用パターンをシグネチャとして定義することは事実上不可能です。また、Webサイトへの攻撃はRFCに違反しない正規のHTTP(S)リクエストによって引き起こされるので、アノマリ（異常）検知機能でも検知・防御することは困難なのです。

対策１ Webアプリケーション開発段階からはじめるセキュアコーディング
そもそもWebサイトへの攻撃は、Webアプリケーションに脆弱性が存在するために成功してしまいます。ならば、Webアプリケーションに脆弱性を作り出さないことが、根本的な対策といえます。設計・開発段階からセキュアコーディングを実施していけば、ひとつひとつ確実に脆弱性を排除していけるので、余計な修正が発生しません。

対策２出荷前までにおこなうセキュリティチェック
Webサイトが本運用を迎えたあとに脆弱性を修正するとなると、莫大なコストとビジネス機会の損失となります。それを避けるための最低限の対策が、出荷前に機能テストや負荷テストとともにセキュリティテストを実施し、その時点で脆弱性の修正を済ませてしまうことです。この場合、限られた時間の中での対策となるので、すべて手作業でまかなうよりも脆弱性検査用ツールを利用することが有効な手段となります。

AppScan使用例

<マメ知識>
[対策1]と[対策2]は共にWebアプリケーション自体をセキュアにしようとする試みです。一般的に、Webアプリケーションの脆弱性はその発見が遅れるほどに修正コストが飛躍的に増大してしまいます。仮に設計段階での修正コストを１とすると、実運用後の修正コストは100倍に達するといわれています。そのため、できるだけ早い段階で対策をはじめることがプロジェクトの全体コストを抑えることにつながります。

修正コストグラフ

対策３ Webサーバの前にWebアプリケーションファイアウォールをたてる
Webサーバの直前にWebアプリケーションファイアウォールを設置することで、不正なHTTPリクエストを遮断します。Webアプリケーションに脆弱性が存在しても、不正なパケットが届かなくなるので、強固な防御策となりえます。通してもよい正規のパターンを定義して、それ以外はすべて拒否する「ポジティブセキュリティ」の考え方を採用しているため、セキュリティの強度は非常に強くなりますが、その分、誤検知をなくすためにきめ細かいチューニングが必要となります。

Webアプリケーションファイアウォール設置例