SQLインジェクション脆弱性の有無が重過失の判断に影響を与えた判決

 投稿日時
2015/02/09 19:34:48
 最終更新日時
2016/01/27 13:45:40

ソフトウェア製作者に衝撃が走った判決

2015年1月中旬、北海道大学の町村先生、HASHコンサルティングの徳丸先生による下記のエントリが話題になりました。

これは東京地裁平成23年(ワ)32060号、東京地判平成26年1月23日の損害賠償請求事件です。
システム開発における判例は増えてきていますが、具体的に根拠として経産省やIPAの文書を出した上で「SQL文の組み立てにバインド機構を使用し、又はSQL文を構成する全ての変数に対しエスケープ処理を行うこと等により、SQLインジェクション対策をすることが必要である旨を明示していたことが認められ(略)SQLインジェクション対策として、バインド機構の使用又はエスケープ処理を施したプログラムを提供すべき債務を負っていた」と判決にあるのは非常に特徴的と言えるのでは無いでしょうか。
本件については上記のお二人のブログが非常に参考になりますが、法律業界にいるエンジニアとして、自身の確認のためにこちらに判例メモを残しておこうと思います。

本件の分析の前に

まずこの記事を読む方に覚えておいていただきたいのは、「この判例は『稼働中のシステムから情報が流出したら全て開発者の責任である』というものでは無い」ということです。
本件は地裁の判決が確定していますが、高裁で争えば別の結論になる可能性だってありましたし、あくまでこの事件の時系列上で、被告と原告がこの裁判で出した争点に基づいて検討した場合でしかありません(また、判決に出てきていない事情もあることでしょう)。この判決は、判例時報の言葉を借りればあくまで「情報のセキュリティ対策、法的なリスク管理対策上参考になる事案」となります。
ベンダが過去に作ったものにSQLインジェクションがあるからと言って、それを今から無償で全て対応しなければいけないというものではありませんので、誤解無きようにお願いします。(ただし本件の結論から考えると、平成19年4月以降に開発したものについて、重要な情報の有無についての誤認があり、SQLインジェクション等が混入しているならば見直した方が安全かもしれません。あと本件に限ったことではありませんが、契約書にリスクがないかどうかは専門家に見てもらうべきでしょう。)
詳しくは、弁護士の方か会社の法務部に相談されるのがいいでしょう。

登場人物

本件の主な登場人物として、インテリア商材の販売を行っていた法人(原告)と、システム開発を行っていた法人(被告)が登場します。

時系列

まず、事件に関係する事柄を時系列順に見ていきます。前半の事柄は関係なさそうに見えますが、後々関係してきます。
なおこれらの年月日は判例やインターネットから取得しておりますが、当方の誤解などにより誤りが混在している可能性があります。

平成18年(2006年)

月日 主体 事柄
2/20経済産業省個人情報保護法に基づく個人データの安全管理措置の徹底に係る注意喚起」を公表。SQLインジェクション攻撃によりデータベースのデータ流出があること、SQLインジェクション対策を行うことなどを注意喚起。

平成19年(2007年)

月日 主体 事柄
3/30厚生労働省、経済産業省個人情報の保護に関する法律についての経済産業分野を対象とするガイドライン」を改正し、講じることが望ましい安全管理措置を例示。
4月IPA(独立行政法人 情報処理推進機構)大企業・中堅企業の情報システムのセキュリティ対策~脅威と対策」を公表し、SQLインジェクション攻撃を紹介し、対策としてバインド機構、エスケープ処理を紹介。

平成21年(2009年)

月日 主体 事柄
1/30被告原告と業務委託基本契約を締結する。
2/4被告原告とウェブ受注システムの発注契約を締結する。
4/?原告被告が作成したシステムの検収を完了する。
4/15被告ウェブ受注システムの稼働を開始する。
4/末原告被告に初年度利用料(翌年1月までの保守サービス料及びサーバー利用料)を支払う。

平成22年(2010年)

月日 主体 事柄
1/26原告被告に各カード会社に対する毎月の売掛金額を個別に把握できるようにする仕様変更を発注する。
1/29原告上記の仕様変更について検収し、システムが稼働開始する。(これ以降、クレジットカード情報がデータベースに保存されるようになった。)
5/1原告被告と本件ウェブサイトのデザイン変更作業を定額制とする内容のウェブサイトメンテナンス契約を締結する。
9/27原告被告に顧客の個人情報を取得しないシステム構築の可否及び当該システム変更の費用をメールで問い合わせする。(詳細は不明だが、前後から鑑みるにカード番号をどこにも保存しないようにする変更を意図していると思われる。)
9/29被告上記の変更について、費用は20万円程度であると回答する。
9/30原告通常は見えないが、システムのどこかにカード番号を保管してしまっていることを被告に確認する。他の会社はどう管理しているか問合せする。

平成23年(2011年)

月日 主体 事柄
4/11原告システムに対し、IPアドレスによる接続制限を実施する。(これ以降、管理機能には許可されたIPアドレスからのみ接続可能になった。)
4/20三菱UFJニコス原告にクレジットカード漏えいの可能性を伝える。(4/12から4/20までに25件確認されていた。)この際、原告はカード番号を保存していない旨を回答。
4/20ジェーシービー原告にクレジットカードの不正利用が確認された旨を警告する。
4/20被告ウェブサイトのサービスを停止。(ベライゾンの報告書では4/21に行ったとも読める。)
4/21被告データベースに保存されていたカード番号データを確認後、バックアップしてから削除する。
4/22ラックサーバー内のディスクの保存作業(おそらくフォレンジック)を実施を行う。
4/30被告ラックのサーバーへの仮移行作業を行う。
5/1被告クレジットカード決済機能を無くし、ウェブ受注を再開させる。
8/23サーバーを野村総合研究所へ移行し、別会社開発のプログラムでクレジットカード決済を行うウェブ受注を再開する。
10/14訴状が送達される。

平成26年(2014年)

月日 主体 事柄
1/23判決が言い渡される。

判決の目次

次に判決を見ていきたいところですが、先に判決の構造を明らかにしたいため、目次にしてみました。(CSSのせいで見にくいかも知れません。すいません。)

まず理由だけを見たいならば「主文」は無視してください。「事実及び理由」のみでいいです。更に「事実及び理由」の中に「第一 請求」、「第二 事案の概要」、「第三 当裁判所の判断」、「第四 結論」がありますが、「第二 事案の概要」、「第三 当裁判所の判断」のみを見れば分かるはずです。

そしてそれぞれの中で、「争点○」とあるのが分かるでしょうか。次はここに注目します。

  • 主文
  • 事実及び理由
    • 第一 請求
    • 第二 事案の概要
      • 一 前提事実
        • (1) 当事者
        • (2) 基本契約
        • (3) ウェブ受注システムの発注
        • (4) 本件システムの利用
        • (5) 本件システムの完成及び引渡し
        • (6) クレジットカード情報の保存開始
        • (7) ウェブサイトメンテナンス契約
        • (8) 顧客のクレジットカード情報等の流出
        • (9) SQLインジェクションの意義等
      • 二 争点及びこれに関する当事者双方の主張
        • (1) 争点1(本件流出の原因及び程度)
          • 原告の主張
            • ア SQLインジェクション
            • イ サーバーへのリモートログイン
            • ウ 管理機能への不正ログイン
            • エ クロスサイトスクリプティング
          • 被告の主張
            • ア SQLインジェクション
            • イ サーバーへのリモートログイン
            • ウ 管理機能への不正ログイン
            • エ クロスサイトスクリプティング
        • (2) 争点2(被告の債務不履行責任の有無)
          • 原告の主張
            • ア 債務不履行一(適切なセキュリティ対策が採られたアプリケーションを提供すべき債務の不履行)
              • (ア) SQLインジェクション
              • (イ) サーバーへのリモートログイン
              • (ウ) 管理機能への不正ログイン
              • (エ) クロスサイトスクリプティング
            • イ 債務不履行二(ネットワークやサーバーのセキュリティ対策を講ずべき債務の不履行)
            • ウ 債務不履行三(カード情報を保存せず、保存する場合には暗号化すべき債務の不履行)
            • エ 債務不履行四(サーバー、データベース及び管理機能へのログインID及びパスワードを管理すべき債務の不履行)
            • オ 債務不履行五(被告によるセキュリティ対策の程度についての説明義務違反)
          • 被告の主張
            • ア 債務不履行一(適切なセキュリティ対策が採られたアプリケーションを提供すべき債務の不履行)
            • イ 債務不履行二(ネットワークやサーバーのセキュリティ対策を講ずべき債務の不履行)
            • ウ 債務不履行三(カード情報を保存せず、保存する場合には暗号化すべき債務の不履行)
            • エ 債務不履行四(サーバー、データベース及び管理機能へのログインID及びパスワードを管理すべき債務の不履行)
            • オ 債務不履行五(被告によるセキュリティ対策の程度についての説明義務違反)
        • (3) 争点3(原告の過失と因果関係の断絶)
          • 被告の主張
          • 原告の主張
        • (4) 争点4(損害)
          • 原告の主張
          • 被告の主張
        • (5) 争点5(損害賠償責任制限の合意の成否等)
          • 被告の主張
            • ア 損害賠償金額制限の合意の成否
            • イ 本件基本契約二九条二項の適用の有無
            • ウ 責任期間制限条項の適用の有無
          • 原告の主張
            • ア 損害賠償金額制限の合意の成否
            • イ 本件基本契約二九条二項の適用の有無
            • ウ 責任期間制限条項の適用の有無
    • 第三 当裁判所の判断
      • 一 前提事実
        • (1) 原告と被告との間での契約の概要
        • (2) 本件システム等の概要
        • (3) 金種指定詳細化に関する経緯
        • (4) 本件流出発覚の経緯
        • (5) ラック報告書 *1
          • ア 本件流出の発生日
          • イ 原告の内部調査により判明した本件流出時の本件サーバー内での個人情報保持件数
          • ウ SQLインジェクションの痕跡
          • エ 管理機能への不正ログイン
          • オ ウェブアプリケーションへの攻撃
          • カ ウェブアプリケーション診断結果 (ア) 問題点一(個人情報が記載されたファイルの閲覧が可能) (イ) 問題点二(SQLインジェクション) (ウ) 問題点三(クロスサイトスクリプティング)
        • (6) ベライゾンビジネス報告書 *1
          • ア 漏洩/侵害の決定的な証拠の有無
          • イ 侵入日
          • ウ SQLインジェクション攻撃
          • エ 悪意のあるソフトウェアのダウンロード試行
          • オ 操作ログ
          • カ 流出のリスクのあるクレジットカード・データ
        • (7) 本件流出後の本件ウェブサイトの状況
      • 二 争点1(本件流出の原因及び程度)
        • (1) 本件流出の原因
            • (ア) サーバーへのリモートログイン
            • (イ) 管理機能への不正ログイン
            • (ウ) クロスサイトスクリプティング
        • (2) 本件流出の程度
      • 三 争点2(被告の債務不履行責任の有無)について
        • (1) 原告と被告との間の契約関係
        • (2)
          • ア 債務不履行一(適切なセキュリティ対策が採られたアプリケーションを提供すべき債務の不履行)
            • (ア)
            • (イ)
            • (ウ)
          • イ 債務不履行三(カード情報を保存せず、保存する場合には暗号化すべき債務の不履行)
          • ウ 債務不履行五(被告によるセキュリティ対策の程度についての説明義務違反)
      • 四 争点3(原告の過失と因果関係の断絶)
        • (1) 因果関係の断絶について
        • (2) 原告の過失について
      • 五 争点4(損害)について
        • (1) 本件ウェブ受注システム委託契約に関連して支払った代金
        • (2) 顧客への謝罪関係費用
          • ア QUOカード及び包装代
          • イ お詫びの郵送代
          • ウ お詫び郵送に係る資材費及び作業費
          • エ 告知郵送代
          • オ 告知の封筒第
          • カ お詫びのメール配信の外注費
          • キ お詫び及びQUOカードの書留郵便代
        • (3) 顧客からの問合せ等の対応費用
        • (4) 調査費用
        • (5) ラックデータセンター使用料
        • (6) 事故対策会議出席交通費
        • (7) リクナビネクスト応募フォーム変更
        • (8) 売上損失
        • (9)
      • 六 争点5(損害賠償責任制限の合意の成否等)について
        • (1) 損害賠償責任制限の合意の成否
        • (2) 本件基本契約二九条二項の適用の有無
            • (ア)
            • (イ)
        • (3) 責任期間制限条項の適用の有無
    • 第四 結論

*1は当方がタイトルをつけたもの。

争われた争点

今回争われた争点は5つあります。

  • 争点1(本件流出の原因及び程度)
  • 争点2(被告の債務不履行責任の有無)
  • 争点3(原告の過失と因果関係の断絶)
  • 争点4(損害)
  • 争点5(損害賠償責任制限の合意の成否等)

これらの争点について、「第二 事案の概要」の中で原告と被告の意見が、「第三 当裁判所の判断」の中で裁判所の判断が述べられています。(これらの争点は裁判中の攻防の結果、どちらかから出てきた項目であると考えられます。)

この中で、争点1、2、3、5について詳細に見ていきます。争点4については省略しますが、項目が並ぶだけなので読んでいただければ分かると思います。

あとこれを読む上で一つ気をつけていただきたいのは、被告、原告の意見には採用されていないものも含まれているということです。中には突飛なものも含まれているように見えますが、裁判所がそれを採用したとは限りません。重要なのは裁判所の判断であるということを念頭に見てみてください。

争点1(本件流出の原因及び程度)

流出の原因を4つとし、それが本当に原因なのかが争われています。

原告と被告の主張

ポイント 原告の主張 被告の主張
SQLインジェクション
  • 調査により、SQLインジェクション攻撃が行われ、アクセスログにコードがあることが判明している。
  • 本件システムにはSQLインジェクションに対する脆弱性がある。
  • 以上により、SQLインジェクション攻撃によって本件流出が発生したことが裏付けられている。
  • 本件の調査をしたラック、ベライゾン共に、流出の原因を特定できていない。
  • 原告が指摘するコードは別のエラー画面によるものである可能性がある。(注:HTTPステータスコードの5xxのことと思われる。)
  • 原告はSQLインジェクションによりどのような情報が流出したかは特定していない。
サーバーへのリモートログイン
  • 外部から本件サーバーにリモートログインした上で、更にデータベースにログインすれば顧客の個人情報を読み出すことができた。(注:telnetやSSHのことと思われる。)
  • 本件サーバーへのログインIDが不正に使用されたことを裏付ける証拠は無い。
管理機能への不正ログイン
  • 管理機能にアクセスすれば、データベースにアクセスして顧客の個人情報を読み出すことができた。不正ログインが行われたことは判明しており、可能性は否定できない。
  • 被告は2011/4/11までにIPアドレスによる接続制限を行ったが、それよりも前に不正ログインが行われたことが判明している。
  • 管理機能へのログインIDが不正に使用されたことを裏付ける証拠は無い。
  • 流出発生前の2011/4/11までにIPアドレスによる接続制限を実施しており、不正ログインは原因ではない。
  • 管理機能にログインしても、クレジットカード情報の閲覧及び操作はできなかった。
クロスサイトスクリプティング
  • 本件ウェブサイトに偽のページが用意され、それを閲覧した顧客からCookie情報が漏洩してCookieに含まれる個人情報が流出した可能性がある。
  • クロスサイトスクリプティングが本件流出の原因であることを示す証拠は無い。

いかがでしょうか。原告は考え得る全ての可能性を提示し、被告はそれを否定していきますが、さすがにクロスサイトスクリプティングは無いのでは、と私は思います。(ページを設置できる権限があればもっと他のことやりそう。)

裁判所の意見

ポイント 裁判所の意見
SQLインジェクション
  • 確認できる事実から、SQLインジェクション攻撃が成功しクレジットカード情報が読み取られたことが推認される。
  • 他に本件流出の原因が認められない。
  • 商品の色選択画面にSQLインジェクションの脆弱性が存在している。
  • ラック報告書は信用性を欠くという被告の主張は採用できない。(注:理由が興味深いのでいつか詳しく書きたい。→追記:ラックについて書きました
  • プログラムの専門家も加わる調停員会では立証は尽くされていないとしているが、流出が発生した事実から見ると可能性が高い。
  • カード会社の対応は流出を裏付けるものである。
  • 以上より、SQLインジェクション攻撃により本件流出が発生したと認めることができる
サーバーへのリモートログイン
  • 裏付ける証拠はなく、認められない。
管理機能への不正ログイン
  • 不正ログインは認められるが、そこでカード情報が閲覧できたことを裏付ける証拠はなく、認められない。
クロスサイトスクリプティング
  • 裏付ける証拠はなく、認められない。

以上のように、4つあるうちの「SQLインジェクション」が原因であると認めています。

争点2(被告の債務不履行責任の有無)

「債務不履行」。難しい言葉ですよね。
「債務」と言ってもお金のことではなく、契約で約束した業務のことです。「仕事を頼んでたけど、こんな仕事ぶりじゃ仕事してないよね。」という意味になります。
ここでは、「○○について頼んだのに仕事していない!」という事柄が5つ争われています。

以下で、どのように主張しているか見てみましょう。

原告と被告の主張

ポイント 原告の主張 被告の主張
契約について
  • 基本契約、ウェブサイトメンテナンス契約や個別契約があるが、これらは一連の契約で一体として考えるべきである。
  • システムには脆弱性があったため、専門業者として債務を履行していない。一から五の債務不履行の責任を負う
  • 流出原因がSQLインジェクションの場合は一、三、五の責任を負う。サーバーへのリモートログイン又は管理機能への不正ログインの場合は全て。(主張していないが、クロスサイトスクリプティングの場合は一。)
  • 契約は個別のものであり、包括的な契約は締結されていない。
  • 債務不履行の有無は個々の契約に基づき検討すべきである。
  • 債務不履行があったとしても、予見可能性が無かった。
債務不履行一(適切なセキュリティ対策が採られたアプリケーションを提供すべき債務の不履行)
  • 個人情報は最初からサーバーに保存されていたが、外部からの攻撃で情報が流出する危険性があった。
  • システムが十分なセキュリティレベルとなるように、提供後も管理/運用すべきだった。
  • 流出の原因はいずれも一般的な攻撃方法であり、被告には予見可能性があった。
  • (注:これ以外にもSQLインジェクション等の攻撃について債務不履行があったと述べていますが、省略します。)
  • 適切なセキュリティ対策が講じられたシステムを提供すべき債務を負っていたことは認めるが、整備し続ける義務はなかった。
  • システムは品質、セキュリティ水準に照らし問題なかった。
  • セキュリティ対策はコスト面と実用面との相関関係で対策レベルが検討されるべきで、当初クレジットカード情報を取り扱うことはなかった本件システムでは問題ない。
  • 本件調査にあたった大手調査会社ですら侵入経路及び侵入手法は解明できていないのだから、専門業者の技術レベルを超える想定不可能な方法によって行われ、侵入行為について予見可能性はなかった。
債務不履行二(ネットワークやサーバーのセキュリティ対策を講ずべき債務の不履行)
  • IPアドレスの制限、ファイヤーウォールの設置、サーバーの空きポートチェックなどを行うべきだった。
  • 流出の原因はいずれも一般的な攻撃方法であり、被告には予見可能性があった。
  • IPアドレスの制限、ファイヤーウォールの設置をしていなかったことは認める。
  • 被告はウェブサイトの変更権限を有しておらず、契約にも規定されていなかったので、セキュリティ対策を講じる債務は負っていなかった。
  • IPアドレスの制限も途中で行っており、ラック作成の報告書でもサーバーには問題がなかったとされている。
  • 債務不履行一と同じ理由で、予見可能性は無かった。
債務不履行三(カード情報を保存せず、保存する場合には暗号化すべき債務の不履行)
  • クレジットカード情報の流出防止措置、悪用防止措置を講じる義務があった。
  • 被告は原告にクレジットカード情報を保存することを依頼されていない。また保存する必要も無かった。もし保存するなら削除するか、暗号化すべきであった。
  • 原告は被告にクレジットカード情報を保存して利用できるように依頼した。カード情報を保存しない、削除する義務は負っていなかった。
  • 契約で暗号化が要求されていない以上は、暗号化すべき債務を負っていなかった。
債務不履行四(サーバー、データベース及び管理機能へのログインID及びパスワードを管理すべき債務の不履行)
  • IDやパスワードは推測しにくいものとし、定期的に変更したり、複数人で共有しないようにすべきであった。
  • ID、パスワードの変更方法を知らせずに推測されやすいものにしていたのは債務不履行を構成する。
  • 初期のID、パスワードは原告の主張する通りであり、後に原告が変更することを前提としていた。
  • 後に不正アクセスを受けたことにより管理機能パスワードを変更しており、管理に問題は無かった。(注:個人的には違和感が残る主張です。)
  • 本件ウェブアプリケーションにはデータベースのID、パスワードが埋め込まれており、アプリケーションを操作できるようになれば、データベースのID、パスワードは流出とは無関係である。
債務不履行五(被告によるセキュリティ対策の程度についての説明義務違反)
  • ウェブ受注システムは流出すると悪用される危険性があるため、開発及び運用時のセキュリティ対策を備えていることが求められる。また、情報システムの知識を有しない企業に対して、情報サービスを提供する専門家として十分な配慮と注意を払う必要がある。
  • 被告は原告に対し、セキュリティ対策の程度、情報流出の危険性を認識し、セキュリティ対策について選択できるよう説明すべきだった。
  • SQLインジェクション対策不足、システムセキュリティの脆弱性、契約したレンタルサーバーがセキュリティを考慮していないこと、カード情報を暗号化していないことなど説明していない。
  • 説明義務の発生根拠及び説明すべき内容は明確でないし、原告は企業であって消費者でないため、説明義務はない。
  • サーバーの契約プランは通常のものであり、セキュリティレベルが低い契約を選んだのではない。
  • カード情報がデータベースに保存されるようになったことは被告も認識していた。

ここでも具体的に争われています。個人的には、各項目の被告の主張は弱く見えます。次はこれらに対する裁判所の意見です。

裁判所の意見

ポイント 裁判所の意見
契約関係について
  • 基本契約二条により、個別契約ごとに債務を負うものと認められる。
  • 原告は全て一体の契約とみるべきと主張するが、別の時期に締結され、内容も異なるためこの主張は採用できない。
  • 本件流出の原因はSQLインジェクションであると認められるため、個別契約と基本契約に基づき、被告に債務不履行一、三、五が認められるかを検討する。(注:原告が主張している通りです。)
債務不履行一(適切なセキュリティ対策が採られたアプリケーションを提供すべき債務の不履行)
  • H21/2/4にシステム発注契約を受けており、当時の技術水準に沿ったセキュリティ対策を施したプログラムを提供することが黙示的に合意されていたと認められる。
  • カード番号は途中からだが、最初から個人情報は保存していたため、必要なセキュリティ対策を施したプログラムを提供すべき債務を負っていたを解すべきである。
  • H18/2/20に経済産業省はSQLインジェクション攻撃による個人データ流出を紹介しSQLインジェクション対策の注意喚起を行っており、H19/4にIPAはSQLインジェクション攻撃とその対策としてバインド機構の使用とエスケープ処理を示していた。
  • H21/2/4の時点で、被告はデータ漏洩防止のため、SQLインジェクション対策として、バインド機構の使用又はエスケープ処理を施したプログラムを提供すべき債務を負っていた。
  • それらのいずれも行われていなかったため、債務不履行一の責任を負うと認められる。
  • 被告は調査会社ですら侵入経路が分からないために予見可能性がなかったと主張している。
  • しかし、契約時点で流出事件が相次いでいること、SQLインジェクション対策が広く指摘されていた。
  • SQLインジェクション対策を講じなければSQLインジェクション攻撃により個人情報が流出しうることは予見可能性であったと言える。
  • また、侵入経路を予見できなかったとしても予見可能性が否定されるものではない。
  • 予見可能性がなかったために過失がない旨の被告の主張は理由がない。
債務不履行三(カード情報を保存せず、保存する場合には暗号化すべき債務の不履行)
  • IPAの文書ではデータベース内に格納される重要なデータは「暗号化することが望ましい」とされていたが、「望ましい」レベルのものである。
  • 全てを暗号化することは負荷から見ても現実的ではなく、暗号化の設定内容は暗号化の程度によって異なる。
  • 暗号化して保存すべき債務を負っていたとは認められず、債務不履行三の責任は認められない。
債務不履行五(被告によるセキュリティ対策の程度についての説明義務違反)
  • 原告はセキュリティ対策について選択できるように説明すべき信義則上の義務を負うと主張している。
  • だが原告が指摘している具体的内容は、他の債務不履行に当たるものや認められないものなどであり、説明義務違反は認められず、債務不履行五の責任は認められない。

争点3(原告の過失と因果関係の断絶)

原告と被告の主張

ポイント 被告の主張 原告の主張
全般
  • システムは当初、顧客のクレジットカード情報が保存されていなかったが、原告が仕様変更を委託した。(原告は利用したカード情報を識別、取得するよう求めたが、クレジットカード情報を全て保存する方法でしか行えなかった。)
  • 安全性、改善方法について被告が質問した際、被告は具体的な費用と改善方法を指摘したが原告は放置した。
  • 流出の直接的原因は原因の要望によるシステム変更と、指摘に対して対応しなかったことにある。
  • 被告の債務不履行と本件流出との間の因果関係は、原告の行為によって断絶されている。
  • 原告は毎月の売掛金額を把握できるようにする旨の仕様変更を依頼したにすぎず、クレジットカード情報の取得及び保存を被告に依頼したものではない。
  • 変更の際、データベースにクレジットカード情報を保存する設定とする旨の説明はなかった。
  • その後のやり取りの中でクレジットカード情報を保存する設定となっていることは認識したが、暗号化しないで保存すること、また保存すること自体の危険性を認識できなかった。
  • この経緯からすると、原告の行為により被告の債務不履行と本件流出との因果関係が断絶するものではない。

裁判所の意見

ポイント 裁判所の意見
因果関係の断絶について
  • システム変更前から顧客のクレジットカード情報以外は保存されていたため、システム変更とクレジットカード情報を含まない顧客の個人情報の流出は無関係であり、クレジットカード情報の流出との関係でのみ因果関係が断絶するか否かが問題となる。
  • 原告はクレジットカード情報のうち会社名だけを送信するように依頼をしたが、原告はカード情報をすべてを保存する方法を選択した(カード番号を保存するにしても、先頭6桁を保存すれば足りる)。
  • 被告はデータベースに保存する必要性は認められないにも関わらず、保存する設定を選択した。よって、被告の債務不履行一と本件流出との因果関係が断絶するものと解することはできない。
  • 原告担当者は被告取締役よりデータベースにカード情報のデータはあるが直接見る手法を用いなければ見ることはできないと伝えられた。
  • 本件流出により流出したのは被告の債務不履行一による危険が現実化したものである。
  • 原告がカード情報を保存しないよう、暗号化するよう指示しなかったことは、被告の債務不履行一と本件との条件関係を否定するものでは無い。よって、被告の債務不履行一と本件流出との因果関係が断絶するものと解することはできない。
原告の過失について
  • 原告のシステム担当者が「カード情報がデータベースにあること」、「セキュリティ上はカード情報を保持しない方が良いこと」を認識していた。
  • 被告からシステム改修の提案を受けていながら放置した。
  • 上記二点はカード情報漏えいの一因となったことは明らかである。
  • 原告の過失を考慮し、三割の過失相殺をするのが相当である。(注:七割が請求できると結論づけている。)

争点4(損害)

省略します。

争点5(損害賠償責任制限の合意の成否等)

原告と被告の主張

原告と被告の主張を見る前に、ここで問題となる基本契約二五条と二九条を見てみましょう。なお、「甲」が原告、「乙」が被告です。

第二五条 〔損害金〕
 甲若しくは乙が本契約内容に違反した場合には、その違反による相手方が被る全ての損害を賠償するものとする。

第二六条 〔補償〕
 乙は、委託業務の完了の後その成果物に瑕疵が発見されたとき、乙の責任において無償で速やかに補修のうえ納入を行うものとする。(一項)
 乙の補償期間は、特に定めるものを除き委託業務の完了の後一年間とする。ただし、乙の責に帰すべきものでない場合はこの限りではない。(二項)。

第二九条 〔損害賠償〕
 乙が委託業務に関連して、乙又は甲の技術者の故意又は過失により、甲若しくは甲の顧客又はその他の第三者に損害を及ぼした時は、乙はその損害について、甲若しくは甲の顧客又はその他の第三者に対し賠償の責を負うものとする。(一項)
 前項の場合、乙は個別契約に定める契約金額の範囲内において損害賠償を支払うものとする。(二項)

ポイント 被告の主張 原告の主張
ア 損害賠償金額制限の合意の成否
  • 二五条は当事者双方が民法の原則通り損害賠償義務を負うことを確認している。
  • 二九条二項で被告が損害賠償義務を負う金額を制限している。
  • 二五条と二九条二項は矛盾しており、二九条二項が二五条の特則である旨は明記されていない。
  • 民法の原則及びウェブサイトメンテナンス契約一六条と同様と解すべきで、損害賠償金額を制限する旨の合意は成立していない。
  • 損害賠償金額を制限する特約を契約とするための個別的合意がなされておらず、成立していない。
イ 本件基本契約二九条二項の適用の有無
  • 二九条二項は被告に重過失がある場合に排除される旨は規定されていないため、重過失があっても摘要される。
  • 本システムにSQLインジェクションは存在しない。
  • 製作時にEC-CUBEに関して公開されている修正プログラムは全て適用して納品、検収を受けており、契約をしていない以上はその後に修正プログラムを適用する義務を負わないため、被告に重過失はない。
  • 従って、被告の損害賠償義務は、「個別契約に定める契約金額の範囲内」が限度となる。
  • 二九条二項により損害賠償金額を制限する旨の合意が成立するとしても、被告に重過失がある場合には二九条二項は適用されない。
  • 契約時にはSQLインジェクション攻撃への対策を講ずべきことが周知されていた。被告はソースコードが公開されて第三者からの攻撃が容易なたEC-CUBEをベースとしていたのだから、納品後も修正プログラムを修正プログラムを適用するか、又は原告に適用を推奨すべきだった。
  • 被告には重過失が認められ、二九条二項は適用されない。
  • 特に今回のようにASP形態を取っていた場合、業者がセキュリティ対策を講じることが通常であり、原告は対策が取られていると誤信していた。またクレジットカード情報をデータベースだけでなくログにも記録するなどセキュリティレベルは低いため、被告が賠償すべき金額を制弁することは極めて不合理な結果となるために許されない。
ウ 責任期間制限条項の適用の有無
  • 二六条二項は被告の責任期間を一年間と定めている。本件請求も瑕疵担保責任の規定に従った請求であり、本件請求についても二六条二項が適用される。
  • 従って、仮に被告に債務不履行が認められるとしても、H21/2/4発注のシステムは(一年間を過ぎているため)被告は損害賠償責任を負わない。
  • H22/5/1締結のウェブサイトメンテナンス契約については二六条二項は適用されないが、ウェブサイトに表示される内容の変更作業を受託したに過ぎず、セキュリティ対策は含まれないため、債務の不履行はない。よって損害賠償責任を負わない。
  • 二六条二項は被告が行うべき無償補償期間を定めたものであり、債務不履行期間を制限したものではない。
  • 本委託契約は委任契約としての性質を有するから、瑕疵担保責任の規定が適用されるものではない。

裁判所の意見

ポイント 裁判所の意見
(1) 損害賠償責任制限の合意の成否
  • 合理的に解釈すれば、二九条二項で損害賠償金額を個別契約に定める契約金額の範囲内とし、二五条は二九条二項の例外として、対象情報を第三者に開示又は漏洩した場合の損害賠償金額については制限しないものとしていると解するのが相当である。
  • 基本契約書は原告及び被告が記名押印しており、その成立に争いはなく、規定されたとおりの契約が成立したものと認めるべきである。
(2) 本件基本契約二九条二項の適用の有無
重過失がある場合に二九条二項は適用されるのか
  • 二九条二項は損害賠償金額を多額に上る可能性がある損害額について、契約金額の範囲内に収めることで、原告が支払う料金を低額にすることができるものである。個人情報管理に注意を求める場合は一七条の「対象情報」とすることができるため、一定の合理性がある。
  • しかし、権利・法益侵害の結果について故意を有する場合や重過失がある場合にまで被告の損害賠償義務の範囲が制限されることは、著しく衡平を害し、当事者の通常の医師に合致しない。(民法五七二条、六四〇条。売主又は請負人が悪意の場合は担保責任を免れることができない。)
  • 従って、被告に故意又は重過失がある場合は二九条二項は適用されない。
被告に重過失が認められるか
  • 被告はプログラムに関する専門的知見を活用した事業を展開しており、原告もその専門的知見を信頼して契約を締結したと推認でき、被告に求められる注意義務の程度は比較的高度なものと認められる。
  • SQLインジェクション対策がされていなければ、個人情報が流出する事態があったことは、注意喚起から考えると容易に予見できた。
  • バインド機構の使用又はエスケープ処理を行うことに多大な労力や費用がかかることをうかがわせる証拠はなく、回避することは容易であった。
  • そうなると、被告には重過失が認められるというべきである。
  • 一七条の対象であるとは言えない。
  • 以上より、被告には重過失が認められ、二九条二項は適用されない。
(3) 責任期間制限条項の適用の有無
  • 二六条二項は無償補償をする義務を一年間と定めたものと解することができ、損害賠償請求権の期間制限を定めたものと解することはできない。
  • 個別契約の性質が請負契約に当たるか、瑕疵担保責任に基づく請求といえるかという点は関係ない。

結論

これまで、この判決について、目次を作成して全体を掴んでから、その中で争点1(本件流出の原因及び程度)争点2(被告の債務不履行責任の有無)争点3(原告の過失と因果関係の断絶)争点5(損害賠償責任制限の合意の成否等)について見てきました。ここでいったん考えをまとめたいと思います。

SQLインジェクションはどう影響を与えたか

まず見てきた通り、SQLインジェクション対策をすべきだったかどうか、「契約がいつだったか」というところがポイントになっていました。契約時点で、SQLインジェクション攻撃による個人データの流出を伝える経済産業省の文書が、そしてその対策を知らせるIPAの文書が出ていたことがポイントでした。

流れとしては、以下のような流れです。

  1. 【争点1】流出の原因はSQLインジェクションと認められる。
  2. 【争点2】技術水準に沿ったセキュリティ対策を施したプログラムを提供するべきだったが、その契約時点で経済産業省やIPAが出した文書でSQLインジェクション攻撃と対策は周知されていた。対策していなかったということは債務不履行が認められる。
  3. 【争点5】被告はプログラムに関する専門的知見を活用した事業を展開しており、被告に求められる注意義務の程度は比較的高度なものと認められる。
  4. 【争点5】SQLインジェクション対策がされていなければ、個人情報が流出する事態があったことは、注意喚起から考えると容易に予見できた。つまり、重過失が認められる。
  5. 【争点5】被告には重過失が認められ、二九条二項は適用されないため、損害賠償額に制限は無い。

SQLインジェクションが認められたことが、重過失に繋がっており、大きな額の損害賠償に繋がったと言っていいでしょう。

説明義務違反は認められなかった

SQLインジェクションが指摘された反面、争点2の中で債務不履行五(被告によるセキュリティ対策の程度についての説明義務違反)は認められませんでした。これは個人的には意外なポイントでした。というのは、システム開発に関する判決で東京地裁平成16年3月10日のものがありまして、この中でユーザーが要件変更を出した際、それがどう影響するかは専門家であるベンダが説明すべきであるという判断がされていたためです。

今回の事案で言うならば、クレジットカード情報変更時には「クレジットカード番号を保存すること」について説明されたことは伺えません。
ただし、導入から約8か月後のH22/9/27、原告から問合せをしたことで説明がなされ、原告はやっと事情を知ったということになります。この説明がなければこの債務不履行も認められたかも知れませんし、他が認められたから争われなかったものの、もし高裁で「説明は導入時になされるべきだ」との主張があれば通っていたかも知れません。

エンジニアはどうすべきか

いい加減長く書きすぎてしまいました。本当はラックについて書きたいところなのですが、それは別の機会に譲ることにして、エンジニアはこの判決をどう受け止めるべきか私の意見を書きたいと思います。

我々エンジニアはコードを書くことが商売であり、顧客からも求められています。裁判所の言葉を借りるなら我々の「専門的知見を信頼して」顧客は依頼しているわけです。私たちの作成するシステムは大きなお金を生む可能性もありますが、大きな損害を引き起こす可能性があります。だからこそ専門的知見を常に磨き、アップデートしていく必要があるのでしょう。

問題ばかり考えるのはエンジニアとして少し窮屈な気持ちもありますが、顧客や利用者の損害を生み出さないことを第一に、常に専門的知見を磨いていきたいものです。

ラックについて

かわいそうな書き方をされているラックについていつか書きます。

2015/03/19追記。書きました。
ラックの扱われ方に見る脆弱性調査のあり方