https://news.mixi.jp/view_news.pl?id=6623038&media_id=39
シェアしました。
2021年08月09日 07:11 ＠IT
写真 |
ソフトウェアの開発契約には時々、ポテンヒットのような抜け漏れがある。発注者と受注者の役割分担を考える際に一通りの作業を網羅したのに、データ移行やテストデータの作成などをどちらが行うのか判然とせずにもめてしまい、結果、紛争にまでなってしまう例が実は珍しくない。
今回取り上げるのも、セキュリティに関するポテンヒットの例だ。発注者が第三者と契約をして提供を受けたソフトウェアにセキュリティ上の不備があった。受注者はその設定とインストールを請け負ってはいたが、当然、ソフトウェアそのものの品質やセキュリティには責任がない。
ところが、それを含めたシステム全体は受注者の責任で構築されるものであり、発注者がITの素人であることを考えると、セキュリティの不備への対応は現実的に受注者しかできない。そんな中で発生した情報漏えいの責任を裁判所がどのように考えるのか、そして、そこからベンダーが学ぶべきことはどんなことなのだろうか。
●受注者と発注者の間のポテンヒット
まずは事件の概要から見ていただきたい。
---
東京地方裁判所 令和2年10月13日判決から
額縁の製造、販売や画材などの販売を行う企業（以下、サイト運営者）が、自らが運営するECサイトの製作と保守をITベンダーに発注し、ベンダーがこの構築を行ったところ、このサイトに第三者が侵入して顧客のクレジットカード情報、最大約6500件が流出した可能性があることが判明した。
これについてサイト運営者は、この情報流出は、このサイトの運営に使用する代金の決済モジュールが、クレジットカード情報を内包するトランザクションログをサーバ内に保存する仕組みであることなど、セキュリティ上の義務を怠ったために発生した事象であり、その責任はサイトを構築したベンダーにあるとして損害賠償を求めたが、ベンダーがこれに応じなかったために裁判となった。
尚、問題となった決済サービスモジュールは、サイト運営者と決済サービスの契約を結んだ決済代行企業から提供されたもので、ベンダーは、このモジュールのインストール、設定を請け負っていた。トランザクションログの保存に関しては、このモジュールの仕様ではあったが、本モジュールはソースコードも公開されており、一般的なソフトウェア技術者であれば更新可能なものだった。
---
●契約にはないが、ベンダーにしかできなかった仕事
概要だけを見ると、サイト運営者が持ち込んだソフトウェアの不備を、インストールを請け負っただけのベンダーの責任として押し付けているようにも見える。
ただ、このソフトウェアの利用についてはサイト運営者とベンダーの間で相談も行われていたし、契約においては、「締結当時の技術水準に沿ったセキュリティ対策を施したソフトウェアを提供する義務」がベンダーの義務としてうたわれていた。ベンダーはサイト全体の構築を請け負っており、そこに部品として組み込まれるモジュールについてセキュリティ上の問題があるなら、それを検出し、たとえサイト運営者が契約した後であっても、その修正を自ら行うか、モジュール提供者に依頼することはできたかもしれない（実際、モジュールの修正は技術的にも契約的にも問題なくできるものではあった）。そう考えると、ベンダーが専門家として十分な義務を果たしていないというサイト運営者の論にも一理あるかもしれない。
しかしベンダーにしてみれば、自分たちが持ち込んだソフトウェアモジュールでもないものを修正することは契約範囲外であるし、修正によって何らかの新しい不具合が生まれる可能性もある。こちらの考え方も、ある意味立派な正論である。契約の範囲と専門家としての責任の対立。裁判所はどのように結論付けたのだろうか。
●「契約になければ責任はない」が法律上の判断
---
東京地方裁判所 令和2年10月13日判決から（つづき）
ベンダーは（中略）クレジットカード決済機能を「導入」するものとされ、同機能を開発し、又は同機能を提供するプログラムを製作するものとはされていなかった。
（中略）
本件決済モジュールを用いてクレジットカード決済を行った場合、本件決済ログにクレジットカード情報が保存される実装になっていたことは、本件情報漏えいの判明後に発覚したもので、被告が原告に本件サイトを引き渡すまでの間に、当該不具合の存在が公になっていたものではない。
（中略）
本件決済モジュールのソースコードや、同モジュールが生成するログを調査し、同モジュールがセキュリティ脆弱（ぜいじゃく）性を有しないか、異常処理を生じさせないかといった点を確認する義務を負うとの合意をしていたことを認めることはできない。
---
裁判所の判断は、サイト運営者との契約に基づいて第三者から提供されたソフトウェアの改修は、「締結当時の技術水準に沿ったセキュリティ対策を施したソフトウェアを提供する義務」とまではいえず、契約の範囲外というものだった。
確かに、契約論としては正論である。この裁判には他にも争点はあったが、それらも含めてサイト運営者の訴えはことごとく退けられた。
改めて考えると、サイト運営者が訴えるべき相手は、本当にこのベンダーだったのだろうか。もし決済モジュールを提供した会社の方であったなら、結果は多少違ったかもしれないとも思う。
ただ、それはあくまで、裁判に勝つか負けるかという視点での話だ。結局、サイト運営者が多額の費用を費やし、ベンダーも契約に沿った仕事をしたにもかかわらず、情報漏えいが発生したのだ。情報漏えいを起こさないためには、あるいは漏えいへの対応をベンダーがきちんと行って顧客満足度を向上させるには、どうしたらよかったのだろうか。
●守備範囲外でも拾いにいけばメリットも
まずベンダーは、たとえ顧客が契約して持ち込んだソフトウェアであっても、その品質やセキュリティについて十分に検証することだ。
それを自身の作業として見積もりに入れてもいい。無論、他人が作ったソフトウェアの全てを保証することはできないが、一般的なセキュリティのチェック、正常系動作の性能や機能についての一通りのチェックは行い、そこで見つからない問題については、責任を負わないという契約を結んだ方が、後々安全であるし、顧客の期待を超える価値を提供できるかもしれない。
本件においても、運営サイトは、そういうことまでするのがプロとしての仕事ではなかったかと訴えている。裁判ではあくまで契約外であると退けてしまったが、実際のプロジェクトでは、誰かがやらなければいけない作業だ。
このベンダーは、「提供されたソースコードを調べ上げることなど、労力的に見て現実的ではない」と述べているが、これも恐らく裁判上の言葉であろう。ソースを解析などしなくても、トランザクションログにクレジットカード情報が書き込まれることなど、テストをしてみればすぐに分かる。そして、それを自分たちで修正するか、開発元に対応を依頼するかを発注者に提言するのは、それほど難しいことではないように思う。この事件のベンダーは、その辺りが少しドライ過ぎたのではあるまいか。
確かに、裁判はベンダーが勝った。しかし、ITのプロではないサイト運営者に、それほどの責任があったとは私は思っていない。契約そのものに一種の抜けがあったのだ。そこを埋めて、有償であっても品質や安全性を向上させることをやっておけば、ベンダーにもメリットの大きな仕事になったのではないかと思う。
このベンダーには良いシステムに対する「貪欲さ」が、欠けていたのではないだろうか。
●細川義洋
政府CIO補佐官。ITプロセスコンサルタント。元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員NECソフト（現NECソリューションイノベータ）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまでかかわったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わる
0 コメント:
コメントを投稿