システム開発裁判例２：システム開発におけるベンダーのセキュリティ義務

Q.ベンダーにECサイトの作成を注文し、完成したものを運用していたのですが、先日、SQLインジェクションというサイバー攻撃を受け、利用客のクレジットカード情報等が漏えいしてしまいました。ベンダーが作成したプログラムに脆弱性があったことが原因なのですが、取引先に損害賠償を請求できないでしょうか。また、どこまで請求できるのでしょうか。 A.ユーザーとベンダーとの間では、「契約当時の技術水準に沿ったセキュリティ対策を施したプログラムを提供すること」が黙示的に合意されている場合には、システム開発契約の不履行として、顧客対応費用、調査費用などの賠償が認められる場合があります。ただし、情報漏洩に関してユーザー側に落ち度があった場合には過失相殺により、また、損害賠償制限特約がある場合には、賠償金額が制限されることがあります。

紹介裁判例

・東京地判平成26・1・23判時2221・71

第１　問題の所在

　　　昨今、日本の企業に限らず、海外の企業においても、ハッカー集団から自社のシステムがハッキングされ、クレジットカードや個人情報の情報漏えいが生じてしまうという事案が頻発しています。このような場合、本来であれば、当該ハッキングを行ったハッカーに対してユーザー企業が被った損害の賠償を請求するのが原則ですが、ハッカーを特定することは、相当な困難を伴います。このような場合には、次善の策として、ユーザー企業は、ハッキングを許すようなシステムを作ったベンダーに対し、損害賠償を請求することが考えられます。

第２　東京地判平成26年1月23日判例時報2221号71頁以下

　１　事案の概要

被告との間で原告のウェブサイトにおける商品受注システムの設計、保守等の委託契約を締結した原告が、被告製作のアプリケーションの脆弱性により本件サイトで商品を注文した顧客のクレジットカード情報が流失したとして、債務不履行に基づく損害賠償を求めた事案です。

　　　本件での情報漏洩の原因は、SQLインジェクション攻撃であるという認定がなされています。

SQLインジェクションとは、ウェブサイトに不正なSQL（データベースを操作するための言語です。）を注入することで、運用されているデータベースから情報を抜き出すなど、不正な挙動をさせるサイバー攻撃です。本件サイトに関するシステム開発契約が締結された平成21年ごろまでに、経済産業省や、IPA（独立行政法人情報処理推進機構）などから、SQLインジェクション攻撃に対する対策を施すよう注意喚起がなされていました。被告は、本件サイトにつき、このSQLインジェクション攻撃に対する対策をしていなかったことが認定されています。

　２　裁判所の判断

　　⑴　被告が負っていた債務

　　　　「被告は，平成２１年２月４日に本件システム発注契約を締結して本件システムの発注を受けたのであるから，その当時の技術水準に沿ったセキュリティ対策を施したプログラムを提供することが黙示的に合意されていたと認められる。そして，本件システムでは，金種指定詳細化以前にも，顧客の個人情報を本件データベースに保存する設定となっていたことからすれば，被告は，当該個人情報の漏洩を防ぐために必要なセキュリティ対策を施したプログラムを提供すべき債務を負っていたと解すべきである。

そこで検討するに，証拠（甲１４，２５，２９）によれば，経済産業省は，平成１８年２月２０日，「個人情報保護法に基づく個人データの安全管理措置の徹底に係る注意喚起」と題する文書において，ＳＱＬインジェクション攻撃によってデータベース内の大量の個人データが流出する事案が相次いで発生していることから，独立行政法人情報処理推進機構（以下「ＩＰＡ」という。）が紹介するＳＱＬインジェクション対策の措置を重点的に実施することを求める旨の注意喚起をしていたこと，ＩＰＡは，平成１９年４月，「大企業・中堅企業の情報システムのセキュリティ対策～脅威と対策」と題する文書において，ウェブアプリケーションに対する代表的な攻撃手法としてＳＱＬインジェクション攻撃を挙げ，ＳＱＬ文の組み立てにバインド機構を使用し，又はＳＱＬ文を構成する全ての変数に対しエスケープ処理を行うこと等により，ＳＱＬインジェクション対策をすることが必要である旨を明示していたことが認められ，これらの事実に照らすと，被告は，平成２１年２月４日の本件システム発注契約締結時点において，本件データベースから顧客の個人情報が漏洩することを防止するために，ＳＱＬインジェクション対策として，バインド機構の使用又はエスケープ処理を施したプログラムを提供すべき債務を負っていたということができる。」

　　　→同義務の違反を認め、被告の債務不履行責任を肯定。

　　⑵　主な損害賠償費目

項目	請求額（円）	認容額（円）
ウェブ受注システム委託契約に関連して支払った代金	20,741,175	275,625
顧客への謝罪関係費用	19,021,798	18,637,440
調査費用	3,937,500	3,937,500
売上損失	60,414,833	4,000,000

　　⑶　賠償額制限特約

「本件基本契約２９条２項は，ソフトウェア開発に関連して生じる損害額は多額に上るおそれがあることから，被告が原告に対して負うべき損害賠償金額を個別契約に定める契約金額の範囲内に制限したものと解され，被告はそれを前提として個別契約の金額を低額に設定することができ，原告が支払うべき料金を低額にするという機能があり，特に原告が顧客の個人情報の管理について被告に注意を求める場合には，本件基本契約１７条所定の「対象情報」とすることで厳格な責任を負わせることができるのであるから，一定の合理性があるといえる。しかしながら，上記のような本件基本契約２９条２項の趣旨等に鑑みても，被告（その従業員を含む。以下，この(2)項において同じ。）が，権利・法益侵害の結果について故意を有する場合や重過失がある場合（その結果についての予見が可能かつ容易であり，その結果の回避も可能かつ容易であるといった故意に準ずる場合）にまで同条項によって被告の損害賠償義務の範囲が制限されるとすることは，著しく衡平を害するものであって，当事者の通常の意思に合致しないというべきである（売買契約又は請負契約において担保責任の免除特約を定めても，売主又は請負人が悪意の場合には担保責任を免れることができない旨を定めた民法５７２条，６４０条参照。）。

したがって，本件基本契約２９条２項は，被告に故意又は重過失がある場合には適用されないと解するのが相当である。」

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

 　         　そうすると，被告には重過失が認められるというべきである。」

　　⑷　過失相殺

「原告のシステム担当者が，顧客のクレジットカード情報のデータがデータベースにあり，セキュリティ上はクレジットカード情報を保持しない方が良いことを認識し，被告から本件システム改修の提案を受けていながら，何ら対策を講じずにこれを放置したことは，本件流出によるクレジットカード情報の漏洩の一因となったことは明らかであるから，原告に損害が認められるとしても，上記原告の過失を考慮し，３割の過失相殺をするのが相当である」

第３　検討

　　　この裁判例は、サイバーセキュリティやシステム開発の分野ではかなり有名で、参考になる部分は多々あります。

　１　債務の内容

　　　判旨からもわかるように、裁判所は、

①その当時の技術水準に沿ったセキュリティ対策を施したプログラムを提供する黙示的合意→

②（本件システムの特徴を踏まえ、）当該個人情報の漏洩を防ぐために必要なセキュリティ対策を施したプログラムを提供すべき債務→

③本件データベースから顧客の個人情報が漏洩することを防止するために，ＳＱＬインジェクション対策として，バインド機構の使用又はエスケープ処理を施したプログラムを提供すべき債務　

　と段階的に債務を認定しています。

　①の黙示的合意を認定する上では特段事実を引用していないため、システム開発における、契約当時のセキュリティ水準を満たすことは、もはや当然の前提となっていると裁判所は評価したと考えられます。同部分は、他のシステム開発紛争との関係でも汎用性を持つため、積極的に引用すべき部分かと考えます。

　②では、本件システムの性質を踏まえたうえで、どのような意味でのセキュリティ対策を施すべきなのかを特定しています。

　③では、②で特定した債務について、その違反を論じることができるような、さらに具体的な義務に昇華しています。ここで参考にされているのは、本件システム発注契約締結時（平成21年2月4日）までに発せられた、経産省（平成18年2月20日）や、IPA（平成19年4月）等の発した注意喚起です。

　　③の義務もあくまで当事者の合意に基礎づけられていることを踏まえれば、システム開発契約の締結時点で、サイバーセキュリティについてどのような水準が一般的だったかを確定する事情として、上記注意喚起が利用されていると考えると、❶契約締結日からどれくらい前に公表されているか、❷誰が発した事実か、❸どのような注意喚起が発せられているか　等が、義務の内容確定の上で重要となるのではないかと思います。

　２　認められる損害費目と、認められない損害費目

　　　情報漏えいが生じた際の、顧客対応費用と、フォレンジック費用はほぼ満額認められている一方で、システム開発費用と、売上損失（逸失利益）は、厳しめの判断がなされています。

システム開発費用については、曲がりなりにも一定期間、当該システムが稼働している以上、全額賠償を求めるのはやはり難しいのだろうと思います。

売上損失は、主に立証困難が問題となっており、上記の事案でも、400万円を認定する際にも、民訴法248条が適用されています。そのため、こちらについては、証拠を組み立てることで、一定対処する余地はあるのかもしれません。

そのほか、本件では問題となっていませんが、情報漏えいが生じたことにより、ユーザーが負うこととなったクレジットカード会社からの不正利用に関する損害賠償費用については、ＱＵＯカードの購入費用（≒個人情報漏洩による本人への損害賠償費用）として、認められるのではないかと思われます（山口地裁平成21年6月4日自保ジャーナル1821号145頁も参照。）。

　３　損害賠償制限特約の有効性

　　　一般に、債務者に故意又は重過失が認められる場合には、無効ないしは適用がないと判断されることが多く、本件事案であっても、同様です。

　　　ちなみに、本件においてその効力が問題となった条項は、全部免責条項ではなく、賠償金額の上限を、各個別契約の代金額に限る旨の条項でしたが、そのような条項であっても、故意又は重過失免責が認められると判断していることもポイントといえます。

　　　重過失を具体的に認定するに際しては、経産省やIPAのSQLインジェクション攻撃についての注意喚起の状況、SQLインジェクション攻撃への対策（エスケープ処理等）の容易性を踏まえて、割とあっさり重過失を認定している印象です。そのため、同種の事案においては、どの程度ベンダー内で周知された攻撃手法で、その対策にどの程度の負担を要するかが主な争点となると考えられます。

　４　過失相殺（ユーザーの落ち度）

　　　クレジットカード情報を、データベースに記録する設定となっていたことについて、3割の過失が認められています。

　　　前提としての、「クレジットカード情報を、データベースに記録すべきではなかった」という価値判断には、当時の「個人情報の保護に関する法律についての経済産業分野を対象とするガイドライン」が、クレジットカード情報等（クレジットカード情報を含む個人情報）について特に講じることが望ましい安全管理措置として、利用目的の達成に必要最小限の範囲の保存期間を設定し、保存場所を限定し、保存期間経過後適切かつ速やかに破棄することを例示していたことなどが影響したものと考えられます。

　　　この点、本記事執筆時点では、一般社団法人日本クレジット協会「クレジットカード・セキュリティガイドライン【2.0版】」（以下「ガイドライン」といいます。）が発行されており、これは、割賦販売法35条の16及び35条の17の15の定める「必要な措置」の実務上の指針とされ、同条の適用のある事業者は、ガイドラインに掲げられた措置を講ずるか、あるいはそれと同等以上の措置を講ずることが求められています[1]。

　　　同ガイドラインの中で、クレジット加盟店がとるべき措置として、クレジットカード番号の非保持化（相当）か、PCI-DSS（クレジットの国際ブランドが共同で策定した、データセキュリティの国際基準）準拠が定められていますので、今現在、カード情報を保持する設定にしていた場合には、より大きな過失割合が認定される可能性が高いと言えます。

　５　その他　

　　　上記ガイドラインとの関連でいれば、上記の事案において、原告は、本件システムを構成するサーバーおよびそのログに、クレジットカード情報を保存せず若しくは保存していたとしても削除する設定とし、又はクレジットカード情報を暗号化して保存すべき債務を、被告が負っていたと争っていました。

　　　最終的に、システム開発契約当時の経産省ガイドラインなどにおいて、非保持ないしは暗号化が「望ましい」と記載するにとどまっていたことを理由の一つとして、被告会社は同債務を負わない旨判示しましたが、現時点では、ガイドライン上でも、非保持ないしはPCI-DSS準拠（≒高度の暗号化等）が遵守すべき義務として定められています。そのため、今後ECサイトのシステムを構築するベンダーは、クレジットカード情報の非保持化ないしはPCI-DSS準拠が黙示的にも契約上の義務となっていたと評価されるリスクも十分にあるため、注意が必要です。

第４　最後に

　　　改めて振り返ってみて、今なお学ぶべき点の多い裁判例ですので、法曹実務家は特に、時間があるときには、一度目を通してみるとよいかと思います。

[1]https://www.meti.go.jp/policy/economy/consumer/credit/kappuhanbaihoatobaraibunyanogaiyofaq.html（特に問10）。