2001 年からマネージド コードとアンマネージド コード両方のアプリケーション コードのレビューに数多く参加してきました。 マイクロソフトのアプリケーション コンサルティング & エンジニアリング (ACE) のサービス チームの一員としてマイクロソフト社内の IT アプリケーションのレビューもしますし、外部のマイクロソフトのお客様 (独立系ソフト ベンダーや、企業のお客様、公共部門など) のためにもコンサルティングに加えて、アプリケーションのレビューをします。 レビューにあたって、アプリケーションのセキュリティを確認するときに必ずチェックするのは、開発の段階でまずどのようなセキュリティを施したかということです。
セキュア コードについて書いた本は沢山ありますから、ここでは割愛します。 そのかわりに、アプリケーション開発ライフサイクルにおいて、セキュリティの牽引力としてのセキュリティ ポリシーについてお話しましょう。 例えば、みなさんがドリーム ハウスを建てるとして、セキュリティのことなどまったく考えなかったとしましょう。 警報装置をつけないどころか、出入り口の強化すら考えなかったとしたら、ドリーム ハウスは外からの侵入に対して脆い家になってしまいます。 同様に、ビジネス ソフトウエアを開発するのにしっかりしたセキュリティ プランを立てていなかったらアプリケーションは安全性を欠くことになります。
セキュリティ ポリシーの役割は何を守るのか、どう守るのかをはっきりとさせることです。 アプリケーション開発ライフサイクルのなかで、セキュリティ ポリシーは設計者と開発者とにどのようなセキュリティ機能が必要でそれをどのように実装するのかを指示するものです。
みなさんは開発チームが良かれと思って考えたセキュリティで納得しますか、それともみなさんのチームでじっくり考え、しっかり作ったセキュリティ プランで自分のアプリケーションを守るほうがいいですか?
ISO 17799 の定義では、セキュリティ ポリシーとは情報セキュリティの管理と支援の方針を明らかにする文書であり、その内容にはそれぞれのビジネス分野で従うべき法令やビジネス要件などを考慮に入れたものです。 ソフトウエアの開発プロセスで大事なことは これから開発するセキュリティ機能のすべてにこのセキュリティ ポリシーをガイドラインとして使用していくということです。
些細なことのようですがこの点を十分理解しておくのはとても重要です。 アプリケーションのセキュリティ ポリシーは開発プロセスで定義すべきではないのです。開発の場はその組織ですでに定めた安全要件を実装するだけの場であるべきなのです。 みなさんが開発するアプリケーションは、アプリケーションのユーザーがみなさんの会社であろうとお客さまであろうとユーザーのセキュリティ モデルに適合していなければいけないのだということをしっかりと覚えておいてください。
売り上げをソフトウエアという知的所有権に依存しているにもかかわらず、その保護のためにはろくに何もしていない会社がとても多いというのは気になるところです。 アプリケーション セキュリティの仕事をしていると、多くの会社が物と情報のインフラのためならセキュリティ ポリシーに手間暇かけるのに同じだけの労力をアプリケーションの開発プロセスにはかけていないということに気づくことがよくあります。
ソフトウエアのアプリケーション層とそれに付随した知的所有権を保護するためにもセキュリティ ポリシーがいるということを多くの会社が忘れています。 セキュリティを考慮に入れずに開発したアプリケーションはそのアプリケーションを展開する環境にとって危険な存在になる可能性があります。 言うまでもなく、その結果、開発側の企業だけでなくエンド ユーザー側もセキュリティ面で弱い立場にたたされます。
アプリケーションの設計でセキュリティ部分を構築するのに、セキュリティ ポリシーで要求されていることを的確に組み込むためには設計者はまずセキュリティ ポリシーを十分に理解していなければにはなりません。
ソフトウエア開発の際、セキュリティは補足的に実装されることがよくあります。 実際、開発の段階ではセキュリティのことなどまったく考えられていないことがよくあります。 その理由の 1 つに、安全性の高いソフトウエアを開発することの重要性を低くみる傾向があることがあげられます。 恐ろしいことにそのことに気付いてさえいない会社が少なくないのです。 どういう理由であれ、アプリケーションの設計段階ではまだセキュリティ ポリシーが入手できないというのはいつものことなのです。 その結果アプリケーション層にセキュリティ機能が組み込まれなかったということがよくあります。 次によくあるケースは、アプリケーションの設計者がその企業のポリシーを使わずにセキュリティを実装しようとしてしまうことです。 このようにセキュリティを組み込んでしまうと、せっかくの効果が薄れてしまい、本当に対処されなければならない危険にきちんと対処されているのか保証できません。
多くの開発組織になぜセキュリティを機能として設計、実装しないのか幾度となく聞いてきました。 理由の 1 つは開発担当者にポリシーが渡されていないことがあげられます。 組織によっては、コンピュータのセキュリティは OS のベンダーの責任だと思われていることもよくあります。
セキュリティは一般的にお金がかかると考えられていて、時間と費用という制限の点からセキュリティ面が省かれることもよくあります。 セキュリティというのはすべての人の責任だと思っていますから、こういうことには反対です。 企業内でも他社でもソフトウエアの開発者はそのアプリケーションが動作環境にリスクを増やしてしまうなどということがないように厳重に気をつけなくてはなりません。 OS の安全性は向上し続けていますから、ソフトウエアを悪用する人たちは次の狙いやすい標的を探しているのです。 困ったことに、その標的は大抵アプリケーション層なのです。
企業がアプリケーションのセキュリティ ポリシーの必要性を認識するというのは大変重要なことです。ポリシーがなければ組織内でセキュリティ計画を確実に定義し、実装し、強化する方法がないことになってしまいますから。 みなさんの会社の物理的なセキュリティ計画には出入り口や、火器の所持、出入りの制限された場所へのアクセス管理などに関して方法と手順が書かれているでしょうか。 アプリケーションを物理的な環境に例えてみると、たとえば給与や会計の情報を扱うようなソフトウエアにも会社の有形資産のための安全策と同じようなセキュリティが必要だということがよくわかってもらえると思います。
開発チームがセキュリティ ポリシーを知っていれば、アプリケーションに機能の一環としてセキュリティを組み込むことが簡単にできます。 みなさんがアプリケーションを購入する立場なら、アプリケーション開発時に組み込まれたセキュリティ ポリシーがセキュリティ機能を規定しますから、そんなセキュリティ機能があることで皆さんの企業に満足してもらえるソフトウエア パッケージとなるでしょう。
ポリシーにセキュリティ要件があれば、開発チームは最小特権の見地からソフトウエア開発ができ、限定された動作環境でソフトウエアを展開するのに攻撃される可能性を最小限に抑えることができます。 さらに、ユーザーもその企業のセキュリティ ポリシーに適した設定にしてセキュリティ機能を有効にすることができるのです。
企業のセキュリティ ポリシーは会社の資産を守るために重要なことです。 情報セキュリティは企業のセキュリティ プログラムに欠くことのできないものです。 セキュリティ対策とその手順をソフトウエアの開発に組み込むことは大切です。
マイクロソフト アプリケーション脅威モデル ブログ
http://blogs.msdn.com/threatmodeling/archive/2007/08/27/threat-modeling-sdl-it.aspx (英語情報)
Michael Howard 著 “How Do They Do It? A Look Inside the Security Development Lifecycle at Microsoft”
http://msdn.microsoft.com/msdnmag/issues/05/11/SDL/ (英語情報)
セキュリティ啓発プログラム 開発ガイド
http://www.microsoft.com/japan/technet/security/understanding/awareness.mspx
Noopur Davis 著 “Secure Software Development Life Cycle Processes,”
米国国土安全保障省
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/sdlc/326.html (英語情報)
この記事は、マイクロソフト セキュリティ ニュースレターで配信しました。