システム開発裁判例４ ECサイトのハッキングに関する責任

Ｑ．弊社は、注文会社から注文を受けて、ECサイトを作成したのですが、先日、そのECサイトがサイバー攻撃を受けて、クレジットカード情報が漏洩しました。このため、注文会社から損害賠償請求を受けたのですが、漏えいの直接の原因は、クレジットカード決済のための決済モジュール（第三者作成）に不具合があったことです。このような場合でも、弊社が損害賠償責任を負わなければならないのでしょうか？ Ａ．必ずしもECサイトベンダーが責任を負うわけではなく、ECサイト作成時及び漏えい発生時、当該不具合がどの程度広く知られていたものだったか、決済モジュールの導入に支払われた報酬金額、決済モジュールの修正範囲など、諸般の事情を考慮して、責任が否定される場合があります。

紹介裁判例

・東京地判令和2年10月13日ウェストロー・ジャパン

第１　問題の所在

　　　1つのＥＣサイトを作る上では、自前で1からすべてをコーディングするのではなく、複数のシステムベンダーが提供する既存プログラムを組み合わせて方法もあります。特に、ECサイトでは、ECサイトシステムとクレジットカード決済のための特別のシステム（以下「本件決済モジュール」といいます。）は別の会社が提供しているということも一般的です。そのような中で、ECサイトの構築の依頼を受けたベンダーが使用した本件決済モジュールに不具合があった場合、ベンダーは常に責任を負うのでしょうか。

　　　結論から言えば、そうではありません。

第２　東京地判令和2年10月13日ウェストロー・ジャパン

　１　事案の概要

　　　注文主である原告は，ベンダーである被告との間で、原告が運営する電子商取引を行うウェブサイト（以下「本件サイト」といいます。）の製作に係る請負契約を平成25年12月1日に、同本件サイトの保守管理契約を平成25年12月20日に締結しました（以下それぞれ「本件請負契約」、「本件保守契約」といいます。）。本件サイトは、平成26年4月2日から稼働を開始しました。両当事者の間では、本件請負契約締結前から、同本件サイトのシステムにECCubeを使用し、本件決済モジュールは、被告とは別の会社が作成したものを利用することが前提とされていました。なお、本件請負契約の代金総額は543万6000円（税別）でしたが、その内訳で、本件決済モジュールの導入にかかわる「クレジット決済・後払い決済機能導入」の項目は、4万円（税別）と記載されていました。

　　　被告は、本件サイトに本件決済モジュールを導入するに際し、デザイン部分のソースコードを修正し、本件サイトを作成しました。なお、当該本件決済モジュールは、原告が加盟店契約を締結した決済代行会社から提供を受けたものだが、その加盟店契約において、本件決済モジュールのソースコードのうち、デザイン部分の修正を行うことは認められていたが、カード情報の処理にかかわるシステム部分については禁止されていました。

　　　原告は、平成27年2月6日、決済代行会社から、情報漏えい懸念の連絡を受けたため、調査をしたところ、最大で6581件のクレジットカード情報の漏えい可能性があることが判明しました。その原因は、本件決済モジュールが生成し、サーバ内に保存されていたトランザクションログ（取引履歴のようなもの）に暗号化された利用客のクレジットカード情報が含まれており、同サーバ内に存在した復号化鍵を用いて第三者が容易に復号化することが可能だったことが理由でした。なお、同本件決済モジュールは、利用客のクレジットカード情報を保存しない設定となっている旨公式にアナウンスされており、上記のような仕様となっていたことは、本件サイト稼働時点では、原告及び被告は当然知らず、今回の情報漏えいを機に、一般に明らかとなりました。

　　　原告は、以上の事実関係を前提として、①本件請負契約に基づく，同本件サイトの顧客のクレジットカード情報を保持しない仕様でソフトウェアを製作する義務，②本件請負契約に基づく，その締結当時の技術水準に沿ったセキュリティ対策を施したソフトウェアを提供する義務，③本件保守管理契約に基づく，上記①及び②と同様の義務を負っていたところ，被告が当該①～③の義務の少なくとも一つを怠ったことから，同本件サイトに第三者が侵入して，原告の顧客のクレジットカード情報が漏洩する結果となった旨を主張して，被告に対し，損害賠償請求を求めました。

　　　以下では、主な争点となった、

　　⑴　情報漏えいの原因

　　⑵　被告の義務①違反の有無

　　⑶　被告の義務②違反の有無

　　⑷　被告の義務③違反の有無　

　　　についての裁判所の判断を確認します。

　２　裁判所の判断

　　　結論として、裁判所は被告の義務違反を認めず、原告の請求を全部棄却しました。

　　⑴　情報漏えいの原因

　　　　原告は、フォレンジックレポートに基づき、ブルートフォースアタックにより、本件サイトが格納されているサーバのRoot権限を攻撃者が取得したことが原因だと争いました。原告は、その証拠として、サーバ内のシステムログが消滅しているとの事実を指摘し、システムログを削除するには、Root権限がなければならないことを主張しましたが、裁判所は、システムログが存在しないのは、漏えい懸念の発覚直後、対応策について決済代行会社から指示を受けた被告社員が、サーバのRootパスワードを変更して本件サイトのシステムを再起動した結果によるところが大きいこと、クレジットカード情報の復号化は、Root権限が必ずしも必須ではないことを指摘し、フォレンジックレポートの信用性を否定したうえで、「攻撃者による侵入経路及び本件情報漏洩の原因は、判然としないものといわざるを得ない」と結論づけました。

　⑵　被告義務①違反の有無（本件請負契約に基づく，同本件サイトの顧客のクレジットカード情報を保持しない仕様でソフトウェアを製作する義務）

　　　　まず裁判所は、

　　ア　本件決済モジュールは、被告ではない第三会社が作成したものであること

　　イ　本件請負契約により被告が具体的に請け負っていたのは、「クレジット決済・後払い決済機能」の「導入」であって、文言上、同機能を開発し、又は同機能を提供するプログラムの制作は含まれておらず、かつ、4万円（税別）の代金に相当する作業を請け負わせたにとどまり、その他に被告が本件サイトにクレジットカード決済機能を提供する何らかのプログラムを開発する旨の記載は存在しないこと

　　ウ　被告は、本件決済モジュールを本件サイトにインストールし、原告から提供を受けたアカウント情報を用いて設定を行い、テスト環境において正常な決済ができることを確認したにとどまり、かつ、本件決済モジュールのソースコード修正も、デザイン部分の変更にとどまり、クレジットカード情報の処理を行うシステム部分の修正を行っていないこと

　　　の大きく３点を根拠に、被告は本件決済モジュールの設計・カスタマイズを行う開発者には該当しないと判断しました。

　　　　その上で、

エ　本件決済モジュールのトランザクションログにクレジットカード情報が保存される実装になっていたことは、本件情報漏えいの判明後に発覚したもので、被告が原告に本件サイトを引き渡すまでの間に当該不具合が公になっていたものではないこと

オ　ソフトウェアのどの部分にいかなる不具合やセキュリティ脆弱性が潜んでいるかを調査するためには、高度の専門的知見と相当のコストを要することが通常であること

　を述べ、最終的に、本件サイトに顧客のクレジットカード情報を保存しないことが、原告及び被告の共通認識となっていたとみられることを考慮しても、　被告が、本件決済モジュールの設計、開発及びカスタマイズを行う開発者に該当しないにも関わらず、相当額の対価の支払を受ける約定もないのに、高度の専門的知見と相当のコストを要する作業を進んで請け負うことは考え難いとして、「本件請負契約に関し、原告と被告との間で、被告が、本件決済モジュールのソースコードや、同モジュールが生成するログを調査し、同モジュールが、セキュリティ脆弱性を有しないか、異常処理を生じさせないかといった点を確認する義務を負うとの合意をしていたことを認めることはできない」と判断しました。

　⑶　被告義務②違反の有無（本件請負契約に基づく、その締結当時の技術水準に沿ったセキュリティ対策を施したソフトウェアを提供する義務）

ア　原告は、まず、本件請負契約において、個人情報を取り扱う場合には、善良なる管理者の注意をもって取り扱わなければならないなど、原告が保有する個人情報を保護するための基本的なセキュリティ対策を行う義務を被告が契約書上負っていたことをその根拠として主張しました。しかし、裁判所は、そのような契約書上の条項について、「被告において請負業務の実施に当たって取り扱うことを認識している，原告管理下の顧客の個人情報を適切に取り扱わせるため，被告に善管注意義務を課した規定と解され」、トランザクションログ「に暗号化された状態で保存されていた本件サイトの顧客のクレジットカード情報は，被告において，これを取り扱うことを認識していなかった原告顧客の個人情報であるから」、契約書上の条項の対象に含まれるものとはいえず、同条項を根拠に、「被告が本件決済モジュールに関し何らかの義務を負うということはできない。」と判断しました。

イ　加えて、原告は、被告義務②には、本件決済モジュールについて、サーバ内にクレジットカード情報を保存しない仕様を実装させ、仮にこれと異なる実装になっている不具合があった場合には、そのような不具合を取り除いて、サーバ内にクレジットカード情報を保存しないものへと修正する義務が含まれていたと主張して争いました。

　　これに対し、裁判所は、上記⑵のとおり、被告が本件決済モジュールの開発者に該当しないこと、及び、クレジットカード業界のセキュリティ基準であるPCI－DSSに準拠した体制を確保すべき義務を負っていたのは原告であることを指摘した上で、「加盟店が，ECサイトの構築を第三者に請け負わせるに当たり，自ら準拠すべきっセキュリティ基準に沿ったものとすることについては，注文主である加盟店から請負人に指示すべきものであり，注文主がそのような指示をしていないのに，請負人が黙示の合意の存在を理由に上記基準に沿ってECサイトを構築する義務を負わされるとすれば，請負人の合理的な期待に反することになるというべきであるから，原告が一定のセキュリティ基準に沿って本件サイトを構築することを被告に指示して否本件において，被告に対し，当該基準に沿って本件サイトを構築する義務を負わせることは，相当ではない。」としました。この判断につき、補足して、原告締結していた加盟店契約上、決済代行会社に無断で本件決済モジュールの決済機能に関するソースコードを改造し又は変更することはできず、原告はその承諾を決済代行会社から取得していなかった点を指摘しました。

　　以上の点から、「本件モジュールは、本件請負契約の締結当時の技術水準に沿ったセキュリティ対策を施したソフトウェアの対象外であった」として、義務②違反を否定しました（その他、原告は義務②から派生する義務として、安全なRootパスワードを設定する義務及び本件サイトへのＳＳＨ接続につき、ファイアウォールを設定し、ＩＰアドレスによるアクセス制限を行う義務を主張していましたが、いずれ身も原告が明示的に支持していなかったことなどを指摘し、義務違反を否定しました。）。

　⑷　被告義務③違反の有無（本件保守管理契約に基づく，上記①及び②と同様の義務）

　　　裁判所は、大要、「原告は、被告が低コストで本件サイトの安定稼働に必要な保守及び運営に係るサービスを提供することがあることを認識しつつ、１か月５万円（税別）という体額の料金に相当する作業を委託したことが認められることから、本件サイトおよび本件決済モジュールにつき新たな不具合等が判明したなどの事情もないのに、被告において、本件請負契約に基づき負うことがなかった義務を、本件保守管理契約に基づき新たに負うものとは解されない」と判示し、被告の義務③違反を否定しました。

第３　検討

大まかにいえば、原告は、「本件決済モジュールはECサイトの一部なんだから、システムベンダーがすべて責任を持て」と主張し、被告が、「いやいや、本件決済モジュールについてはうちは関与してないから知らないよ。報酬もその前提でやってるし」と反論した結果、裁判所は被告に軍配を上げたという流れです。本事案の判断に関しては、以下の点は参考になるかと思います。

　１　情報セキュリティ義務違反の有無における対価額の重要性

本事案において、裁判所は、本件請負契約・本件保守契約中でセキュリティに関連しうる項目にいくらの費用が支払われていたのかを重視しています。他の請負事件でも同様かとは思いますが、事前にどこまでのセキュリティ業務をベンダーに委託するかどうかは、事前に相談のうえ、適切な費用をかけて行い、かつそれを契約書上明確化しておくことが重要です。

　２　注文者の指示の重要性

　　　裁判所は、主に義務②（契約締結当時の技術水準に沿ったセキュリティ対策を施したソフトウェアを提供する義務）違反において原告が主張した種々の派生的な義務違反を検討する際に、原告がそのようなセキュリティ対策を施すように指示をしたかどうかを重視しています。この点は、セキュリティ対策には様々な方面のものがあり、かついずれについても相当額の費用を要することが一般的であり、注文主の指示なくベンダーが無償ですべてのセキュリティ対策を施すことは現実的ではないという価値判断が裏側にあるのではないかと思われます。とはいえ、注文主側から、事前に必要なセキュリティ対策をベンダーに指示するのは通常困難ですから、この点を適切に配慮した判断になっているのかは疑問の余地があります。セキュリティ対策についての知見を有しているのはやはりベンダーですから、ECサイト開発を注文しようとする際には、注文しようとしているベンダーに対して事前にセキュリティ対策について相談し、その経過を書面化しておくことで、紛争化した際に有利にふるまうことができるのではないかと思われます。

　３　情報漏えいの原因特定の重要性

　　　本件では、最終的に、情報漏えいの原因は不明との認定で責任判断がなされています。情報漏えいの経路は様々であり、その手法によってとるべきセキュリティ対策は異なります。したがって、原告が有利に責任追及をする上では、漏洩の原因を特定することが最重要課題です。この点、本事案では、フォレンジックレポートで記載された漏えい原因が否定されてしまったことで、原告に不利に傾いた一因であることは間違いないと思います。したがって、訴訟に踏み切る際には、フォレンジックレポートを読み込み、訴訟手続中でその内容が覆されることがないかを入念に確認することが重要です。

　４　決済モジュールの開発業者・それを利用している決済代行業者への責任追及の可能性

　本件は、本件決済モジュールに不具合があったが、その責任を負うのは本件決済モジュールを利用してＥＣサイトを作ったシステムベンダーではない、という判断がなされたにとどまります。そのため、本件決済モジュールを作成した会社又は、本件決済モジュールを利用している決済代行業者に対して責任追及の余地があるものと考えられます。

　もっとも、決済モジュールの開発者とＥＣサイト運営者との間には契約関係がないことが通常と考えられるため、民法７０９条に基づく責任を追及することが考えられます（決済モジュールであることから、「動産」に当たらず、製造物責任の追及は難しいのではないかと思います。）。

　加えて、決済代行業者との間では加盟店契約が締結されているため、その条項次第では、加盟店契約上の責任追及がありうるのかもしれません。もっとも、当該不具合の知名度によって、本事案と同様に免責される可能性は否定できないかと思います。

　　　いずれにしても、時効期間との関係で、慎重に提訴の相手を選択することが重要です。