「脆弱性根絶なんてできっこない」と嘆く前に：セキュリティ、そろそろ本音で語らないか（13）（2/3 ページ）
バグをなくせ、脆弱性を作るな――そんな精神論はもう飽き飽き。でもあきらめる前に、この現状でもできることを考えよう（編集部）
セキュリティ対策に必要なもの、それは「余裕」
バグを山のように作り込んで、そのまま結合テストに持ち込んで作り直すやり方はムダが多いものです（実際には炎上しているプロジェクトの多くはそんな状態ですが）。これを「初めからバグがないように作ればいいじゃないか」といっても、何も現実は変わりません。
最初に述べたように、プログラマにはいろいろな性格やタイプがありますから、おっちょこちょいな人や、モチベーションがそれほど高くない人であっても実行できる手法でないと現実的ではありません。給料が高くて職場全体のモチベーションが高い優良企業で、しかも正社員だけで固定メンバーで開発する、品質管理の面からは理想的な環境であれば「カイゼン」も可能です。しかし、現実にはそんな企業はごく一部しかないでしょう。
これまでも繰り返し指摘されていますが、システム開発の現場は過酷な環境に置かれています。低い給料、あり得ない短納期、仕様変更の繰り返し、計画とかけ離れた進ちょく、何階層にもわたる下請け構造、などの劣悪な実態からすると、設計、教育だけでは脆弱性がなくなりません。
もっと決定的なことは「セキュリティをやっても高く売れない」という問題です。発注段階でセキュリティを盛り込みたいと思っても、セキュリティ要件を詳しく発注仕様書に書き込むと、高い見積もりが出てきます。そのため、発注側の都合で「セキュリティには十分に注意すること」「組織が認証取得していること」などの文言でお茶が濁されています。つまり、発注側が及び腰である以上、受注側はセキュリティを積極的に取り組んだからといって、請求金額に反映できないのであれば頑張りようがないのです。
「余裕のある優良企業」しかセキュリティ対策に取り組めない――そこには、こんな現状があるのです。
現状を考えた“実行できる”あるべき論
しかしながら「上流工程でセキュリティ対策を行うべき」は理論的には間違っていません。課題は「悲惨な現状にどうフィットさせるか」です。
私は、もし前述の状況が現実であるならば、システム的に対策を講じていくことが効果的であると考えています。日本の場合、精神論での対応が根強いのですが、これは世界的に見れば少数派でしょう。対策を考えるなら精神論ではなく、いかに自動化するか、セキュリティを意識させずにセキュリティ効果を高めるか、そんな取り組みを行うべきです。そうすれば、システム開発の工程の一部としてのセキュリティチェックも有効に機能するでしょう。
システム開発といっても、Webアプリケーションの場合にはセキュアプログラミングの要素が大きいでしょう。業務アプリケーションの場合は、認証や暗号化といったシステム設計の領域であったり、バックアップデータの取り扱い、そして端末や部屋の物理的なセキュリティなど、広い範囲についてセキュリティを考慮しなければいけません。
セキュアプログラミングの観点からすれば、ソースコード検査を開発環境の中に取り入れることが最も効果的でしょう。自動的にアラートが出ますから、プログラマは自然にアラートに引っかからないコーディングをします。このシステムとともに、セキュアプログラミングの教育に取り組むことが、さらに効果を高めると思われます。
やはり考えるべき「最終工程でのセキュリティ対策」
ミスをしたり忘れたり、そしてさぼったりするのが人間の特性です。そして脆弱性の根絶は、品質改善の中では最も難易度の高い領域です。バグの根絶という「永遠の課題」も解決していません。
例えば、試験項目不足、デバッグコードを本番移行するなどのミスは、大規模なシステムでもなくなりません。その中で、脆弱性の混入を防ぐことや発見することは、相当に高度な技術力やマネジメント力が要求されるはずです。当分の間、開発段階での脆弱性の根絶は実現しそうにはありません。
従って、引き続きセキュリティリテラシーの向上や、セキュリティの重要性の啓蒙を続けながらも、運用段階における最終工程でのセキュリティ対策が、現実解として比重を高めざるを得ません。
もちろん、先に述べた条件（高いモチベーション、ほぼ固定のメンバーによる開発、教育コストの負担）を満たす企業であれば、先進的な取り組みが可能です。そのような企業では、一般企業でも取り組めるカリキュラムの開発や、開発工程におけるセキュリティ品質の管理手法を確立して世に広めていただきたいと思います。
Copyright © ITmedia, Inc. All Rights Reserved.