“セキュアなWebアプリ”に立ちはだかる課題：セキュリティ、そろそろ本音で語らないか（4）（2/3 ページ）

SQLインジェクションによる情報漏えい事件がクローズアップされています。対策は簡単なこと……と言われ続けているのですが、なぜWebアプリケーションの脆弱性は無くならないのでしょうか。第4回ではその理由に迫ります（編集部）

LINE

Hatena

ブラック・オア・ホワイト――開発後の脆弱性検査

　開発後に脆弱性検査が行われることは珍しくなくなってきましたが、開発コストを考えた場合にはこれは効率のいい方法ではありません。多くの場合システムとして組み上げられた最終段階で検査が行われ、そのほとんどが納期直前の時間のない中で行われます。そして、必ずといっていいほど脆弱性が発見され、その改修に多くの時間をさらに要することになります。

　また一般的にはブラックボックス検査が行われることが多く、脆弱性の問題の個所の特定にプログラマは追われます。ブラックボックスではソースコードのどこに問題があるかは分かりません。また、ブラックボックス検査はシステム全体が組み上げられてからでないと検査できないことも開発コストの増大につながっています。

　一方、ソースコード検査に代表されるホワイトボックス検査では、脆弱性の問題がある場所をピンポイントで示してくれます。しかしながら、基本的にはソースコードをトレースしていく仕組みになっているので、認証の甘さなどのシステム上の問題や、ソースコードを静的に解析する技術的な限界もあります。今後はデバッガと連携した半動的ホワイトボックス検査の仕組みが実用化されていかなければ解決しないと思われます。システムを連結しない単体テストの段階、あるいは、コンパイルなどのコーディング段階でプログラマに知らせてくれるのはセキュリティコストの増大を抑えてくれるメリットがあるでしょう。

　大ざっぱにいってしまうと、ブラックボックス検査はここ数年の市場の広がりの中で検査技術者も育成され、実績や経験も積まれてきたのである程度の品質とサービス価格が期待できますが、ホワイトボックス検査はこれからの市場であるので、検査ツールの熟成や技術者の育成やサービス品質の均一化、言語やセキュリティレベルのバリエーションなど、期待も大きいですが課題も多いといえるでしょう。

防御や検知システム設置が必要な理由

　さて、開発も終わり検査も終わりいよいよサービスインとなるわけですが、多くのサイトでIDSやIPS、WAFが使われるようになってきています。検査を行っていれば脆弱性はないはずなのですが、なぜ、このような防御や検知のシステムが必要になるのでしょうか。それは、これまでに作ったシステムへの信頼性が低い、という理由や、検査でつぶしても全部でない可能性がある、今後修正が繰り返されるシステムに新たに脆弱性が潜んでいるかもしれない、ということが考えられます。

　いい換えれば、検査が十分でなかったり、検査漏れがあったりする、ということなのです。では、ブラックボックス検査を常に完全に受け続ければいいかといえば、実際にはそのような運用をしているサイトは極めてまれです。なぜなら、膨大なコストがかかるからです。場合によっては開発コストを超えるセキュリティコストがかかることにもつながります。

　従って、ある程度のセキュリティを検査で確認して、やっぱり運用では防御や検知でカバーする、という手法がとられることが多いのです。

　ここで問題となるのが、IDSやIPS、WAFそのものの性能です。本来であれば、設置すれば攻撃を止めてくれる、と期待されるものなのですが、現実はそうではないのです。ファイアウォールやウイルスゲートウェイ程度の精度を期待してはいけないのです。ここまでいうとベンダさんからおしかりや抗議を受けるかもしれませんが、少なくとも私がこれまで見てきた製品は「そのまま置けばピタリと止まる」を満足するものではありませんでした。

　また、IPSやWAFなどのインラインタイプのものは、攻撃も止めるがユーザーの正常なアクセスも止める、という障害にもつながるので、巨大なトラフィックのあるサイトでは敬遠されがちであるのも事実です。疑わしいアクセスの取り扱いは非常にセンシティブな技術です。

　従って、まずは、甘めに設定しておいて実際のトラフィックを見ながら徐々に締めこんでいく、というチューニングが必要です。ユーザーのシステムは常にリニューアルされていきますから、それに追従してルールを緩めたり厳しくしたりチューニングの連続となります。これには経験を積んだベテランの技術者が対応しなければいけません。

　このようなサービスを24時間365日提供するためにはコストがかかります。そのコストはユーザーが支払うことになるのですが、「できの悪いシステム」を守るのはそれくらい大変です。

　余談ですが、私が前職でセキュリティサービスをしていたときに、当時のIDSの性能はそれはひどいものでした。誤報、見逃しは当たり前で購入したユーザー企業の期待を見事に裏切っていたものです。それを目の当たりにして、「それならチューニングがサービスになるかも」と考えて日本で最初のネットワーク監視センターができたのです。

【関連記事】

川口洋のセキュリティ・プライベート・アイズ（5）
ネガティブか、ポジティブか……それが問題だ

http://www.atmarkit.co.jp/fsecurity/column/kawaguchi/005.html