「脆弱性根絶なんてできっこない」と嘆く前に：セキュリティ、そろそろ本音で語らないか（13）（2/3 ページ）

» 2010年02月02日 10時00分公開

セキュリティ対策に必要なもの、それは「余裕」

　バグを山のように作り込んで、そのまま結合テストに持ち込んで作り直すやり方はムダが多いものです（実際には炎上しているプロジェクトの多くはそんな状態ですが）。これを「初めからバグがないように作ればいいじゃないか」といっても、何も現実は変わりません。

　最初に述べたように、プログラマにはいろいろな性格やタイプがありますから、おっちょこちょいな人や、モチベーションがそれほど高くない人であっても実行できる手法でないと現実的ではありません。給料が高くて職場全体のモチベーションが高い優良企業で、しかも正社員だけで固定メンバーで開発する、品質管理の面からは理想的な環境であれば「カイゼン」も可能です。しかし、現実にはそんな企業はごく一部しかないでしょう。

　これまでも繰り返し指摘されていますが、システム開発の現場は過酷な環境に置かれています。低い給料、あり得ない短納期、仕様変更の繰り返し、計画とかけ離れた進ちょく、何階層にもわたる下請け構造、などの劣悪な実態からすると、設計、教育だけでは脆弱性がなくなりません。

　もっと決定的なことは「セキュリティをやっても高く売れない」という問題です。発注段階でセキュリティを盛り込みたいと思っても、セキュリティ要件を詳しく発注仕様書に書き込むと、高い見積もりが出てきます。そのため、発注側の都合で「セキュリティには十分に注意すること」「組織が認証取得していること」などの文言でお茶が濁されています。つまり、発注側が及び腰である以上、受注側はセキュリティを積極的に取り組んだからといって、請求金額に反映できないのであれば頑張りようがないのです。

　「余裕のある優良企業」しかセキュリティ対策に取り組めない――そこには、こんな現状があるのです。

現状を考えた“実行できる”あるべき論

　しかしながら「上流工程でセキュリティ対策を行うべき」は理論的には間違っていません。課題は「悲惨な現状にどうフィットさせるか」です。

　私は、もし前述の状況が現実であるならば、システム的に対策を講じていくことが効果的であると考えています。日本の場合、精神論での対応が根強いのですが、これは世界的に見れば少数派でしょう。対策を考えるなら精神論ではなく、いかに自動化するか、セキュリティを意識させずにセキュリティ効果を高めるか、そんな取り組みを行うべきです。そうすれば、システム開発の工程の一部としてのセキュリティチェックも有効に機能するでしょう。

　システム開発といっても、Webアプリケーションの場合にはセキュアプログラミングの要素が大きいでしょう。業務アプリケーションの場合は、認証や暗号化といったシステム設計の領域であったり、バックアップデータの取り扱い、そして端末や部屋の物理的なセキュリティなど、広い範囲についてセキュリティを考慮しなければいけません。

　セキュアプログラミングの観点からすれば、ソースコード検査を開発環境の中に取り入れることが最も効果的でしょう。自動的にアラートが出ますから、プログラマは自然にアラートに引っかからないコーディングをします。このシステムとともに、セキュアプログラミングの教育に取り組むことが、さらに効果を高めると思われます。