業務システム構築でのライブラリ使用に伴うリスクと対策

現代において、業務システムの構築では「ライブラリ」というシステムの部品が必須となっています。しかし、ライブラリの使用にはリスクもあります。リスクに無頓着なまま利用することはトラブルを誘発し、最悪の場合は情報流出など深刻な被害に見舞われる危険さえあります。本記事ではライブラリの利用に潜むリスクとその対策について、解説していきます。

ライブラリとは何か

業務システムの構築にあたり、システム会社は必要なプログラムを全て自社で作成するということはほとんどありません。かわりに、「既製のソフトウェアの部品」で土台をつくり、不足する部分を自社で作成するというような形をとるのが一般的です。この、既製のソフトウェアの部品のことは、「ライブラリ」と呼ばれます。汎用的な機能はライブラリを利用して開発するのが一般的です。汎用的とは「ログインする機能」や「データベースからデータを取得する機能」のような、どの業界、どの国のシステムでも需要の高い機能のことをいいます。こうした需要の高い機能は、対応するライブラリが存在します。一方、顧客独自の要望を満たすなど、汎用的でない機能は、既製のライブラリが存在しませんのでシステム会社が自社で作成することになります。

なお、ライブラリと似た意味でフレームワークという言葉もあります。また、OSS（オープンソースソフトウェア）という言葉もあります。業務システムの文脈でいうOSSとはシステムの部品であり本記事でいうライブラリと同じものですが、より耳馴染みがある言葉かもしれません。しかし本記事ではライブラリという言葉で統一します。

ライブラリのメリット：早くて安全である

システム会社が自作よりもライブラリの利用を優先する理由は2つあります。

• 自作よりも早く作れること
• 自作よりもセキュリティが高くなること

早くなることは既製品を使う以上当然ですが、セキュリティ面でも優れていることが大きな特徴です。これはなぜかというと、著名なライブラリは世界中の優れたエンジニアと企業が開発・検証・本番環境での利用を継続して行っているため、既知の攻撃手法への対策がなされており、新しい攻撃手法が発見された場合でもすばやい更新が期待できるためです。反対に、ライブラリを用いずに、自前で作ろうとする場合には、セキュリティ面での課題を検討するために別途専門家のレビューを挟ませるなどの手間がかかることもあるでしょう。その場合には、結果としてセキュリティを向上させようとするとコストがかかってしまうということもありえます。そうした諸々の事情により、より早く・より安全にシステム開発を進めようと思えば、ライブラリの使用が重要になってくるのです。

ライブラリのデメリットとは

ライブラリの利用は、早く安全にシステムを作れるため顧客とシステム会社の双方にメリットが大きいといえます。反面、ライブラリの利用には一定のコストも存在します。また、アップデートをしない場合「脆弱性」が混入する可能性、アップデートをする場合システムが動かなくなる可能性があるというジレンマも存在します。

アップデートしなければ脆弱性がある

個人情報やクレジットカード情報、企業秘密を盗むことを目論む犯罪者は、日々ライブラリ（を含むあらゆるソフトウェア）のセキュリティ上の欠陥を探しています。こうしたセキュリティ上の欠陥は、IT用語では「脆弱性」と呼びます。利用したライブラリに潜む脆弱性を突かれ、被害を受けた例は多数あります。例えば、国土交通省のアンケートサイトで利用していたStruts2というライブラリの脆弱性を攻撃され約20万件の顧客情報が流出した事例、同じくStruts2を利用するチケット販売サイトがクレジットカード情報3万2187件を流出した可能性があるとみられる事例があります。システムの納品時点では未知であったライブラリの脆弱性が、後に発覚するということもあります。

アップデートにはシステム停止リスクが伴う

現場では、脆弱性があるにもかかわらずアップデートが出来ない場合があります。それは、アップデートでシステムが一時的に動かなくなるリスクが存在するためです。ライブラリはシステム会社が書いたプログラムではないため中身をすべて把握しきることは、現実的にも困難です。そのため、アップデートでシステムに予期せぬ不具合が発生し、システムが一時的に動作しなくなるといったリスクはどうしても排除しきれないのです。顧客としては、納品したシステムの中身を把握していないとは何事かとシステム会社への憤りを感じるかもしれません。しかし、現代のシステムで利用するライブラリは質、量ともに一介のシステム会社で対応しきれるものではないものも事実なのです。たとえば、ユーザーインターフェース構築のためのライブラリの中でトップクラスの人気がある「React」というライブラリがあります。このライブラリは質の面ではFacebook社のエンジニアが作成した非常に高度なもので、量の面でも コード行数にして195486行(※1)と膨大なものです。

脆弱性が裁判となった事案

ライブラリに起因する脆弱性で被害が出た場合、責任は誰が負うのかという問題があります。その参考になるのが東京地裁平成26年1月23日判決です。原告は、被告であるシステム会社に販売システムの構築を委託しました。しかし、システムの稼働後、システムの脆弱性のためエンドユーザーのクレジットカード情報が流出し、原告は謝罪や調査などで約3200万円の被害を受けたことで争いに発展しました。原告と被告が締結した契約では、被告の過失で損害が発生した場合、損害賠償額を契約金額までとする免責条項がありました。この免責条項を適用できるか否かが争点となりました。判決は、被告に重過失があり、重過失がある場合は免責条項は適用できないとして被告に契約金額を超えた賠償を命じました。

被告は，情報処理システムの企画，ホームページの制作，業務システムの開発等を行う会社として，プログラムに関する専門的知見を活用した事業を展開し，その事業の一環として本件ウェブアプリケーションを提供しており，原告もその専門的知見を信頼して本件システム発注契約を締結したと推認でき，被告に求められる注意義務の程度は比較的高度なものと認められるところ，前記のとおり，ＳＱＬインジェクション対策がされていなければ，第三者がＳＱＬインジェクション攻撃を行うことで本件データベースから個人情報が流出する事態が生じ得ることは被告において予見が可能であり，かつ，経済産業省及びＩＰＡが，ウェブアプリケーションに対する代表的な攻撃手法としてＳＱＬインジェクション攻撃を挙げ，（中略）注意喚起をしていたことからすれば，その事態が生じ得ることを予見することは容易であったといえる。また，バインド機構の使用又はエスケープ処理を行うことで，本件流出という結果が回避できたところ，（中略：回避のための処理の技術的な対策の意）を行うことに多大な労力や費用がかかることをうかがわせる証拠はなく，本件流出という結果を回避することは容易であったといえる。
そうすると，被告には重過失が認められるというべきである。

東京地判平成２６年１月２３日

この判例をライブラリの脆弱性の文脈に当てはめて解釈したのが、以下の一般財団法人ソフトウェア情報センターの資料の記述です。

この判例の考え方を前提とすると、仮に OSS の不具合（脆弱性等）により、ユーザに損害が発生した場合でも、ベンダが脆弱性対応を怠ったことについて、故意・重過失が認められる場合、本件と同様、免責条項（責任制限条項）の適用が制限され、免責の効果を得ることができない可能性が高いといえます。ただし、OSSの脆弱性の対策情報が公開された直後に攻撃を受けた場合には、結果回避の容易性が否定される等、重過失まで認められない可能性も十分にあります。

IoT時代におけるOSSの利用と法的諸問題 Q&A集[PDF] （84頁）

このように、ライブラリに起因する脆弱性であってもそれが既知の脆弱性であり攻撃を予見することが容易と認められる場合には、システム会社の責任と扱われる可能性が高いと思われます。

より現実的な脆弱性対策はなにか

システム会社の故意・重過失によって情報流出が発生した場合、法的には訴訟により補償が得られると見込まれます。しかし実務の面からいえば、そもそも流出をおこさないことが肝要といえます。訴訟で補償を受けたとしても、情報流出で失ったエンドユーザーからの信頼は回復できないためです。そのためには以下の2つが重要です。

1. ライブラリアップデートを含めた保守契約の締結
2. 脆弱性診断

ライブラリアップデートを含めた保守契約の締結

業務システム構築の契約には、開発のみを委託する場合と保守まで委託する場合がありますが、自社に保守が可能な専門家を抱えていない場合は、保守契約を締結するのが適切です。契約では、ライブラリのアップデートを含めた脆弱性対策をシステム会社に依頼し、システム会社の対応義務とそれに応じた顧客の支払い義務を明確にしておくことでトラブルを防止できます。システム会社に専門家としての対応を義務付ける一方で、顧客も専門家に依頼するに充分なコストを負担する契約とする必要があるといえるでしょう。

脆弱性診断

システムが扱うデータ量やUIへの要求の高さは日々増大する一方で、新規に発見される脆弱性の数が増加し続けています。そのため、システム会社だけでは脆弱性の混入を完全に防ぐのは困難な現状があります。そこで必要となってくるのが脆弱性診断です。IPAによれば、全体で5割以上、大企業等で8割の事業者が脆弱性診断を実施しています。

脆弱性診断は、無料のツールから、高額な手動診断まで様々なものがあります。特に流出することが致命的な情報などを扱う場合は、脆弱性診断を専門に行う事業者に委託し十分なコスト割いて対策することは必須といえるでしょう。また脆弱性は日々発見されるため、納品時だけでなく納品後にも継続的に脆弱性診断 (P15) を行うことが重要となるでしょう。

まとめ

本記事では、ライブラリの使用に伴うリスクと、その対処法について解説しました。ライブラリは非常に便利な反面で、アップデートをしないと脆弱性が生じ情報流出といった被害が発生するなど、リスクもあります。法的にはシステム会社の重過失がある場合には情報流出の補償を受けられる可能性が見込まれるものの、実務的にはそもそも情報流出がおきないような対策が重要です。そのためには、ライブラリのアップデートの工数や、脆弱性診断について契約で合意しておくべきでしょう。ライブラリ利用をしない場合、納期と機能のいずれも必要な水準に達することはほとんど不可能です。トラブルを避けつつライブラリのメリットを享受するには、システム会社との間でアップデートのコストや脆弱性への対策について合意形成が必要であると考えられます。情報流出でビジネスに致命的な打撃をうけないためにも、機能や画面レイアウト、価格といった要素だけではなく、セキュリティに対しても契約時から十分な注意を払うことが重要であると考えられます。