このブログでの連載開始にあたり、Webアプリケーションを発注する立場でのセキュリティに対する責任や、なすべきことを説明したいと思います。
Webアプリケーション発注者に脆弱性に対する責任はあるか
そもそも非常に基本的な前提として、Webアプリケーションの脆弱性(SQLインジェクションなど)に対する最終的な責任は誰(どの会社)にあるかを考えてみます。具体的には、インターネット上のWebサイトを運営している、あるいはWebアプリケーションョンをパッケージソフトウェアとして市販しているが、開発は外部の開発会社に委託しているケースで、セキュリティ事故などが発生してお客様(Webサイトのユーザ、パッケージソフトの購入者)に迷惑を掛けた場合、その責任は誰にあるかということです。
結論から言えば、この責任はWebアプリケーションの発注者にあります。発注者は、Webサイトの運営者あるいはパッケージソフトの販売会社として、顧客と直接契約関係にあるわけですから、責任があるのは当然と言えます。
これはWebアプリケーションに限らず他の分野でも同じことです。かつてマンションの耐震強度偽装が社会的に問題になった際に、強度計算を請け負った一級建築士やマンションを担当した建設会社の責任ももちろん追及はされましたが、マンションの顧客はこれらの建築士や建設会社に責任求めることはできず、マンションの販売会社に保証を求めました。それと同じで、Webアプリケーションのセキュリティ事故が発生した場合、顧客に対して責任を負うのは、Webアプリケーションの発注者であると考えられます。
しかし、このように書くと、発注者には次のような疑問が残ると思います。我々はインターネットのことやシステムのこと、ましてやセキュリティのことは良く分からない。分からないからこそ、大金を投じて専門家に開発を委託しているのだ。専門家なのだから、セキュリティのことについても責任をとってもらってしかるべきではないか、と。
これは心情としてはよく理解できるのですが、現実のビジネスでは通用しない理屈です。以下に、開発会社まかせでは駄目な理由を具体的に説明しましょう。
なぜ開発ベンダーまかせではだめなのか?
セキュリティに関して開発会社には法律上の義務はない
これは食品や建設などの分野とIT分野の大きな違いです。先ほど例にあげた耐震偽装問題では建築基準法や建築士法などがあり、建設会社や建築士に対する法的な規制となっています。一方、IT分野には、これらに相当する法律はありません。製造物責任法(PL法)もソフトウェアには適用されないという解釈が一般的です。
先の耐震偽装問題では、建設会社などの責任も問われたわけですが、それは上記の法律などに違反していたことが問題視されたわけです。一方システム開発では、このような法律がないため、開発会社に責任を求めることは非常に困難となります。
このため、顧客からの要求が唯一の基準となります。言い換えれば顧客からの発注仕様書あるいは請負契約書などに明確に記載されていない限り、開発会社の責任にはならないのです。
セキュリティ要件は発注仕様として見積もりと直結する
しかしこういう疑問も出てくるとと思います。法的な根拠がなくとも、これだけセキュリティ事件が多発している現状であれば、プロの良心として、要求がなくてもセキュリティには万全の備えをしてくれてよいではないか、と。そのような良心的なベンダーもないわけではありません。しかし、現実の商談の現場では、「良心的なベンダー」にも以下のような葛藤があります。
それは、開発者会社の選定は、通常、相見積もり(コンペ)で行われているため、受注をとるためには、できる限り安い見積もりを出す必要があります。これは発注者にとって結構なことなのですが、開発ベンダーの心理としては見積もりを安くするためには顧客から要求されていない要件はできるだけ省略したいという心理が発生します。
このため、開発会社側としても、仮にセキュリティが重要だと分かっていても、顧客の要求事項にない、あるいは要求が非常にあいまいな場合は、できるだけセキュリティ要件を省いて、見積もり金額を安く抑えようという心理が働くのです。
開発ベンダーも実はよく分かっていない
これを書くと身も蓋もないのですが、開発会社もよく分かっていないところがまだまだ多いのが実情です。このため、「おまかせ」とか「よきにはからえ」ではうまくいかないのです。
発注者は何をすればよいか?
このため、発注者側の自衛として、(1)開発会社選定の際にセキュリティについてもよく考慮する、(2)発注時にセキュリティ要件を明確にするということが重要となります。とりわけ、セキュリティ要件の明確化は重要です。
下図はソフトウェアを発注・開発する際の流れを非常に大雑把に示したものです。図に示すように、ソフトウェア開発プロセスの中で発注者が関与できる箇所は、「要求仕様」と「検収」のタイミングしかありません。しかも、検収は「要求仕様どおりにできているかを確認する」ものですから、セキュリティ要件が要求仕様になければ、検収のタイミングで指摘することは困難です。
このため、全ては要求仕様の段階で決まってしまうのです。これは、機能要件や性能要件についても同じことであって、セキュリティだけが特別ではない、ということに過ぎません。
まとめ
Webアプリケーションを外部に委託して開発してもらう場合、セキュリティ上の責任は最終的には発注者側にあります。発注者は開発会社に「安全なシステムを開発させる責務」があることになります。このためには、とくに重要なことが、発注時のセキュリティ要件を明確にすることです。
前述のように、システム開発では要求仕様にない項目は盛り込んでくれないと考えるべきです。発注時にすべてが決まると言っても過言ではありません。
HASHコンサルティングからの提案
HASHコンサルティング株式会社では、発注者の立場で使用するのに適したセキュリティ・ガイドラインの策定や、開発会社選定から納品・検収までの一連の開発プロセスにおける相談を承っております。どうぞお気軽にご連絡ください。
