IDCFクラウドのランサムウェア被害を弁護士解説、「データが戻らない」「うちは使っていない」企業の責任は、損害賠償請求できるか

仮想サーバーごと暗号化、「漏えい」ではなく「毀損」型の被害

今回のIDCFクラウドの事案を、どのように受け止めていますか。

10月27日時点の公表資料を見る限り、個々の利用企業のデータベースなどが「盗まれた」というよりは、仮想サーバー全体が暗号化されて使えなくなったという事案のようです。つまり、「漏えい」ではなく「毀損」にあたり、最近多発している情報漏えい事案とは種類が異なります。

本件のようにデータベース等が外部に流出していない場合でも、その基盤となる部分を守れなければ、自社の環境のセキュリティ対策とは関係なく、丸ごと暗号化されて使えなくなってしまいます。こうした事案は起こり得るものではありますが、実際に利用している企業にとってはなかなか難しい事案だったと感じています。

データが戻らない企業に問われる法的責任

本件では、スナップショット機能を使用しておらず自前のバックアップも用意していない利用企業の場合、データが戻らない可能性がありそうです。クラウド基盤に起因する問題ではありますが、利用企業にはどんな法的責任が発生しうるでしょうか。

まず、個人情報保護法上の安全管理措置が問題になり得ます。安全管理措置は、漏えい・滅失・毀損を防止するための措置です。漏えいだけではなく、滅失と毀損に対する安全管理も必要です ⁴。

それから、内部統制システム整備義務の1つである損失危険管理体制（会社の損失につながるリスクを管理する体制）の観点も重要です。この体制が整備できていなかったと判断されると、取締役の善管注意義務違反にもなり得ます ⁵。

クラウド障害の損害賠償請求、SLA・免責条項・責任上限と重過失

データが戻らなかった場合、利用企業はクラウド事業者に損害賠償を請求できるのでしょうか。

各サービス事業者はそれぞれ、SLA（Service Level Agreement）や免責条項、債務不履行または不法行為があれば、それらの条項の範囲内で損害賠償を請求できるでしょう。ただし、これらは各サービス事業者の故意または重過失がない場合に限り有効です。逆に言えば、重過失があれば免責は効きませんし、責任の上限もなくなります。本事案においても、重過失があったかどうかが大きな論点になってくるでしょう。

なお、重過失は、予見が可能かつ容易であって、結果の回避が可能かつ容易だった場合に認められます。平たく言うと、やるべきことをやっていたかという話です。

過去に重過失の有無が問題となったSQLインジェクション事件では、当時の技術水準でセキュリティ対策を施していたかが問題になりました ⁶。本事案はランサムウェア攻撃が原因とのことですので、IDCフロンティアが現時点での技術水準で適切なランサムウェア対策を施していたかが問われ、施していなかったと判断された場合に重過失が認められる可能性が出てくるでしょう。

「IDCFクラウド」のSLAは、稼働率99.999%を掲げる一方、免責事項として「外部からの攻撃妨害などによる場合」は品質保証の対象外としています。この記載により、本件も免責されるのでしょうか。

前提として、SLAの記載内容は、サービスの債務の内容を定めているのか、そうであるとして契約上の義務としているのか努力義務に過ぎないとしているのか、さらには債務不履行があった場合の免責について定めているのかなど、その記載内容の法的位置づけが問題になります。本件の具体的な条項の解釈については立ち入りませんが、債務不履行があったときの免責を定めた趣旨の条項であれば、先のとおり、重過失がある場合は認められません。つまり、SLAで「外部からの攻撃については免責」としていても、重過失があれば責任追及できる可能性はあることになります。

SLAに「対象外」と書かれていたら一律に責任を問えない、というわけではないということですね。

利用企業が自前のバックアップを取っていなかった場合、クラウド事業者への損害賠償請求にも影響しますか。

影響し得るでしょう。被害を受けた側にも落ち度があると、その分だけ賠償額が減らされる過失相殺が認められることがあるためです。過去の裁判例では、ユーザー側がバックアップを取っておらずにクラウド事業者側がデータを紛失したという状況で、50%の過失相殺を認めている事件があります ⁷。

過失相殺は当然に認められるとは限りませんが、それを避けるためにも、自社でバックアップを取っておくべきでしょう。

「うちは使っていない」企業も他人事ではない、直接契約のないクラウド障害への備え

直接契約のないクラウド事業者に損害賠償請求できるか

ここからは、自社で直接契約していない企業について伺います。業務委託先や利用中のSaaSの事業者が基盤として使うクラウドサービスが原因で業務が止まった場合、直接の契約関係がないクラウド事業者に損害賠償を請求できますか。

理論上はもちろん、不法行為責任を追及できます ⁸。しかし、クラウド事業者がその利用企業に対してどういう注意義務を負っていたのかが重要です。

つまり、直接契約をしているベンダーは、サービスを提供する義務があります。一方で、直接契約を締結していない基盤の提供ベンダーが、基盤上のサービスの利用者に対して注意義務を直接負っているとは、なかなか考えづらいといえます。実際に、同様の論点について争われた裁判例もありますが、不法行為上の善管注意義務を事業者に認める根拠は見出しがたいとして認められませんでした ⁹。

委託先・SaaS事業者が使うクラウドは平時から把握を

委託先やSaaS事業者が使っているクラウドサービスを、利用企業は平時からどこまで把握しておくべきでしょうか。

法律家としては、「自社の委託先や利用サービスがどんなクラウド基盤を使っているのかは把握する必要がある」と返答せざるを得ません。

ただ、実務的には「それは開示できません」というベンダーも多いです。なので、法律家としては把握すべきと返答しつつ、教えてくれない企業も割とあって「困ったな」という話ではありますね。

開示を拒まれた場合にとれる対策はあるでしょうか。

まったく教えてくれない場合は、そもそもその委託先やSaaSに個人データを預けていいのかを考えるべきです。たとえば、個人情報保護法の観点でも、データを保管・処理している国を把握する義務があります ¹⁰。データの保存先がアメリカなのか、はたまた中国、ロシアなのかでリスクが異なります。把握しないまま進めた結果として、情報漏えいや今回のようなデータの消失といった問題が発生してしまうと、自社の顧客・取引先に対する責任を負う必要が生じる、ということです。

他社のクラウド基盤の上でSaaSなどを提供する企業側では、何を注意すべきでしょうか。

基盤となるクラウドサービスの規約とSLAをしっかり確認して、その範囲内でサービスを提供すること、およびそれに準じたSLAを用意することが必要です。基盤となるクラウドサービスを「親亀」、その上で提供する自社のサービスを「子亀」とすると、子亀のSLAは親亀のSLAを超えてはいけない、というイメージです。本事案でたとえれば、IDCフロンティアの基盤の上でサービスを提供する企業は、自社サービスの提供条件をIDCフロンティアの提供条件以下とする必要があるでしょう。