Tweet

第4回 “セキュアなWebアプリ”に立ちはだかる課題

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

　私は前職で、Webアプリケーションの脆弱（ぜいじゃく）性による個人情報の漏えいの脅威を広く知ってもらうために実在のサイトの脆弱性を公開する、ということをしていました。最初のレポートが2001年10月で、恐らく日本で最初ではないかと記憶しています。

　それから何年もたちましたが、相変わらずWebアプリケーションの脆弱性はなくならず、いまもさまざまな対策ソリューションが発表されています。

　Webアプリケーションの脆弱性対策は、おおむね以下のように分類できます。

1. 開発時に脆弱性を作り込まないようにする
2. 開発後の脆弱性検査を行う
3. ネットワーク攻撃防御／検知システム（IDS／IPS／WAF）と関連サービスを利用する
4. ログ取得および関連サービスを利用する

　今回は、この4点の現状をお話ししていきましょう。

　「開発時に脆弱性を作り込まない」をどう実現するのか

　開発時からセキュリティを考慮すればいい、というのは私が前職にいたときからずっと考えていたことです。私自身がプログラマ出身であることと、前職の会社が当時はシステム開発部門と情報セキュリティ部門の両方を持っていたことから、初めからセキュリティを考えていればセキュリティにかけるコストは激減できるはずなのに、と常に考えていました。

　しかしながら、現在でも開発時に脆弱性を埋め込まない手法やプロセスは、必要性だけが繰り返し叫ばれていながらも実装は確立されていません。

　現在、開発段階でのセキュリティ対策としては主に以下のようなソリューションが有効であるとされています。

• システム設計へのセキュリティ要件の盛り込み
• セキュアコーディング基準作成
• セキュアプログラミング教育
• セキュアプログラミング
• ソースコード検査
• セキュリティ監査ログ
• アプリケーション利用ログ
• システムテストにおけるブラックボックス検査
  　：
  　：

　まずここで分かるのは、システム開発という段階で、セキュリティだけでこれだけのことを考える必要があることです。セキュリティの専門家からすれば「当たり前」というかもしれませんが、システム開発の現場においてはこのようなことを吸収する体力はほとんどありません。

　システム開発というのは何十年という歴史の中で、その手法や文化が形成された、いわば成熟しつつある産業の1つでもあります。そしてシステム開発の現場は余裕のあるものではなく、多くの場合徹夜の連続であったり、経営的にも利益が出にくい構造になっています。これは、末端のプログラミングを請け負う会社になればなるほどその傾向は強くなります。

　いい換えるなら、最も脆弱性が作り込まれる現場が最も過酷な労働条件の場所なのです。そんなところに「セキュリティを考えましょう」などといったところで「そんな余裕はない」と聞き入れてもらえないことでしょう。

　この「余裕がない」とはどういうことでしょうか。時間の余裕がない、スキルを向上させるための教育をする余裕がない、などであると思われますが、根本的には「経営上の問題」です。つまり、厳しい受注単価が決められている中で、経営的に余裕がありません。

　では、なぜ経営的に余裕がないのでしょうか。それは長い歴史の中で常にコスト削減の要求にさらされてきたからです。人月単価での見積もりではその単価だけが勝負です。それをギリギリまで削りながらプログラミングが行われています。ときには無理な単価で受注してプロジェクトが炎上することもあります。

　私が前職の会社に入ったのはちょうどメインフレームからEUC（End User Computing）にパラダイムシフトし始めたころで、その後オープンシステムへと大きく時代が変わっていきます。その根本には「安くできるから」という考えがありました。つまり、時代の進歩はコスト削減とともにあったのです。

　その中で「大きなコスト増大の原因」ともなり得るセキュリティの実装が進まないのは当たり前のことです。発注者がセキュリティ確保こそ品質向上ととらえて「セキュリティ管理コスト」を例えば20〜50％上乗せしてくれればいいのですが、そんな数字ははっきりいって「天文学的」です。

　それでも現在多くのシステム開発会社がセキュアプログラミングに取り組み始めましたが、その動きや取り組み方、レベルはバラバラで、そのほとんどが自力での取り組みです。つまり、発注者負担にはしないで自分たちの努力で頑張ろう、というものです。

　確かに、セキュリティの確保されたシステムの開発ができることは他社との競合において有利であると思われますが、セキュアかどうかが確認できないのでは、明確な差にはなり得ませんし、もし、セキュアプログラミングができる複数企業が競った場合に、発注者は戸惑うでしょう。

　また、セキュアプログラミングができる技術者、というスキルが明示的に個人のスキルとして示すことができないうえに、それで就職や転職に有利かというと、そこまで社会的な受け皿の機運は高まっていません。従って、技術者の中でも特に先進的な人たちだけのものになっているのも残念なことです。

　今後は、セキュアな開発の手法だけでなく、求められるセキュリティ基準の定義と評価する方法、評価主体、発注者によるセキュリティ管理コストの容認と受け入れ基準の明確化など、開発だけでなく、受発注、運用に至るまでの一連のプロセスの構築をしていかないとこの問題は根本的な解決の方向へは向かわないと考えています。

　とはいえ、現在有志によってさまざまな活動が行われています。ソースコード検査による脆弱性発見のコスト削減の実証やセキュアプログラミング教育、ログの標準化への取り組みなどがやがて開発プロセスの中に自然に取り込まれていくことを願っています。

1/3

Index
“セキュアなWebアプリ”に立ちはだかる課題
	Page1 「開発時に脆弱性を作り込まない」をどう実現するのか
	Page2 ブラック・オア・ホワイト――開発後の脆弱性検査 防御や検知システム設置が必要な理由
	Page3 ログ取得の意味

セキュリティ、そろそろ本音で語らないか 連載インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード