TOP
＞
プロジェクト管理
＞ 開発プロセス全体での取り組み
プロジェクトを成功に導くキーファクター
第３回：誰が「セキュリティリスク」を考えるのか
著者：
日本総研ソリューションズ 足羽 崇
2007/5/17
前のページ
1
2
3
次のページ
開発プロセス全体での取り組み
では、どうすればセキュリティ上の問題を引き起こすような不具合をなくせるのだろうか。セキュリティが品質における1つの側面である以上、冒頭のように「テストフェーズで脆弱性スキャンツールを使ってさえいれば大丈夫」といったお手軽なことではいかない。なぜなら、セキュリティ上の問題を引き起こすような不具合も、開発過程で生まれる様々な不具合と同様に、仕様やロジックの「考慮漏れ」や対策の「実施漏れ」、「ミス」などにより、どこからでも発生しうるからだ。
しかも、セキュリティ上の問題を引き起こすような不具合は、定義外・想定外のオペレーションにより引き起こされることが多い。つまり正常動作に関する設計やテストだけで問題を検出し切ることは不可能である。
これらのことは
開発プロセス全体に、セキュリティを取り入れなければならない
ことを意味している。
開発プロセスにおいて、セキュリティ確保のフェーズが独立して存在するわけではない。図1のように、すべてのフェーズにおいてセキュリティ面の品質を向上させるためのアクティビティが（他の側面の品質を向上させるためのアクティビティ同様に）存在する。
図1：開発プロセスにおけるセキュリティ向上のためのアクティビティ
（画像をクリックすると別ウィンドウに拡大図を表示します）
このような開発プロセスを経ることによって、はじめてセキュリティリスクを管理することができ、結果的にセキュリティの向上がはかれるのである。
キーとなる「要員確保」
先のような開発プロセスを実現するための最重要ファクターの1つが「要員確保」だ。セキュリティリスクについても他のリスク同様、開発プロジェクトに参画する「人」に依存するところが大きい。
当たり前と思われるかもしれないが、アプリケーションにおけるセキュリティの問題について理解しているメンバーをアサインする必要がある。もし組織内で確保できないのであれば、外部のセキュリティ専門家を投入することも考えるべきだ。少なくとも計画作成時やレビュー時など、重要なマイルストーンだけでも、こうした人材を参画させることが重要である。
攻撃者は1ヶ所でも高リスクな脆弱性を見つけてしまえば、それで自身の目的を達してしまう。攻撃者対開発者の勝負は「1勝」さえすればよいのだ。それに対し防御する側は、常勝が義務付けられる。従って考慮漏れがあってはならないし、実施漏れや実施ミスは確実に発見する必要がある。
特に設計時の考慮漏れは後フェーズでの発見も困難である上に、発見したとしても修正コストが跳ね上がる。そのためプロジェクトの品質だけでなく、コストやデリバリーの面で致命傷になる可能性が高い。
だが実際に、セキュリティ専門家やセキュリティチームが体制に組み込まれるようなプロジェクトが世の中で大勢を占めているだろうか。おそらく「予算が足りない」「セキュリティ技術者が足りない」などが直接的な理由となり、実現されていないのではないだろうか。
しかし根本的な理由の1つとして、セキュリティの確保はセキュリティ専門家に「任せてしまおう」という考えで、セキュリティ専門家を「活用しよう」と考えていないことがあげられる。
前のページ
1
2
3
次のページ
著者プロフィール
株式会社日本総研ソリューションズ 足羽 崇
2003年 慶應義塾大学大学院修了（基礎理工学専攻、物理学専修）。同年、株式会社日本総合研究所入社。プラットフォームのセキュリティ検査業務、Webアプリケーションの開発・保守業務を経て、現在は、株式会社日本総研ソリューションズにて、アプリケーション開発業務、Webアプリケーションのセキュリティ教育などに従事。
INDEX
第3回：誰が「セキュリティリスク」を考えるのか
最後に実施する「セキュリティ対策」とは
開発プロセス全体での取り組み
開発者自身がセキュリティ専門家へ
