Security&Trust トレンド解説

Webアプリケーションのセキュリティを
後回しにするな

岡田大助
2005/8/19


 個人情報の保護に関する法律(個人情報保護法)が全面施行されてから4カ月が経過したが、依然として情報漏えい事故/事件は続発している。むしろ、法律が施行されたことによって情報漏えいに関するニュースが以前よりも目に入るのかもしれないが、企業はそれなりに個人情報保護法対策を施しているはずだ。

 2005年5月から6月にかけて、Webアプリケーションの脆弱性を突かれた情報漏えい事件がメディアでさかんに取り上げられた。世間一般のイメージに比べて、外部からの犯行による情報漏えいというのは実際のところ少数派だ。それ故、Webアプリケーションのセキュリティ対策は後手に回っていたのかもしれない。

 数字のうえでは5件に1件は外部犯による情報漏えい

 「情報漏えいの原因の8割は内部から」というフレーズは非常によく使われている。コンピュータ・アソシエイツがまとめたところによれば、2004年の個人情報漏えい事故は366件、1件当たりの平均被害者数は3万1057人、想定損害賠償額は4666億円にも達した。このうち、100万件以上の個人情報が漏えいした事件は2件あり、どちらも原因は内部からの漏えいだったという。

 そこで企業は、アクセスコントロールやポリシー管理といった内部セキュリティの充実に力を入れてきた。しかし、残りの2割、あえて強引にいえば5件に1件の割合で発生する外部犯による情報漏えい対策がおろそかになっていなかっただろうか?

 外部からの攻撃に対して、ほとんどの企業がファイアウォールを設置し、クライアントPCレベルでのウイルス対策ソフトを導入している。しかし、穴はまだ残っていた。Webアプリケーションに、である。

 ラックの西本逸郎氏がF5ネットワークス主催のセミナーで面白い例え話をしていた。「悪意を持つものは、攻撃対象となる家の玄関と勝手口に鍵が掛かっていなければ玄関から入ってくる。最近ではどこも玄関(=ファイアウォール)の戸締まりをしっかりしているので、勝手口(=Webアプリケーション)が狙われる」

 Webアプリケーションの穴をふさぐには、そもそもプログラミングの段階で穴のないWebアプリケーションを作ればいい。いわゆるセキュアプログラミングという概念だ。セキュアプログラミングは理想であり王道であるのだが、実際には穴の開いたWebアプリケーションがたくさん存在している。

 ラックが2005年5月24日に発表した「ホームページからの情報漏洩に対する脅威の現状」というレポートによれば、2004年に調査した大手企業122社のほとんどすべてのWebサイトにおいて何らかの脆弱性が存在しているという。そのうち、クロスサイトスクリプティングが67%、セッション管理不備が61%、インジェクション系が37%と情報漏えいにつながる穴が開いている。

 また、三井物産セキュアディレクションが2005年6月3日に出した調査レポートでは、BtoC、BtoBなどのメンバー制サイトの約9割で情報漏えいやWebページ改ざんなどを含む問題を抱えているとしている。

 そこでWebアプリケーションファイアウォール(WAF)が登場した。これは、セキュアプログラミングの限界に対するインフラ側からのソリューションと位置付けられて注目され始めている。だが本当にセキュアプログラミングは限界なのだろうか。

 セキュアプログラミングは本当に限界なのか

 セキュアプログラミングについては、IPA/ISECの「セキュア・プログラミング講座」が詳しいのでぜひ参考にしてほしい。あらかじめ言及しておくが、限界といってもセキュアプログラミングそのものが欠点を抱えているのではない。現状ではセキュアプログラミングの知識を備えた開発者が少ないというのが問題なのだ。

 Webアプリケーションの開発は、プロジェクトという形で複数の開発者の共同作業となるため、個々の開発者のセキュリティに関する能力(もしくは意識)に依存することになる。開発者は納期までの限られた日数の中で、必要な機能とパフォーマンスの向上を実現しなくてはならない。このため、Webアプリケーションがセキュリティ対策を施さなくても動作するのであれば、セキュリティが後回しにされてしまうこともある。

 また、Webアプリケーションの開発者と運用者が同じであることは少ない。運用者が提出した提案依頼書(RFP)に従って要件の洗い出しや仕様書の作成を行う。Webアプリケーションの脆弱性を突いた攻撃が注目を浴びた今日において、RFPにセキュリティに関する項目がないというのは少なくなったと思うが、どこまで厳密に定義されているかはあやふやだという。

 NTTデータビジネスソリューション事業本部セキュリティサービスユニットの武井洋介氏は、「RFPでセキュリティ対策を要求された場合、要件の洗い出し、実装のための設計、実装、テストと開発工数やコストは増えます。また、対策として何を、どこまでやればいいのかという基準もないので、発注者と開発者の描く性能に差が生じることも多いと聞きます」と現場の声を語る。

 そこで、ソフトウェア側の問題をインフラ(ハードウェア)側で解決しようとするWAFが登場したのだが、WAFだけですべてが解決されるというものでもない。そもそもWAF自体が高価であるというのもさることながら(個人情報が漏えいした場合の損害額を考えれば、それこそ金子の多寡ではないのだが)、WAFを管理運用することによって生じるコストも念頭に置かなくてはならない。

 武井氏は、「WAFを導入した場合でも、Webアプリケーションごとにネットワーク管理者と協力してチューニングすることが必要となりメンテナンスという運用負荷が生じます。Webアプリケーションの運用者がWebサイトの構成を把握しきれていないこともありますし、パラメータ(シグネチャ)が増加すればWAFそのものの性能も落ちてしまいます」という。

 このような運用者、開発者双方の不満を解決すべく「Webアプリケーションの脆弱性は、本来、開発段階で潰しておくべき」というスタンスから生まれたのがNTTデータの「SecureBlocker」だ。

 
1/2


Index
Webアプリケーションのセキュリティを後回しにするな
Page1
数字のうえでは5件に1件は外部犯による情報漏えい
セキュアプログラミングは本当に限界なのか
  Page2
Webアプリケーションの脆弱性対策機能をパッケージに

Security&Trust記事一覧


Security&Trust フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Security & Trust 記事ランキング

本日 月間