SaaS利用者/事業者が知っておくべきクラウドセキュリティの確かめ方と高め方 —第6回 クラウドサービスにおける個人情報の考え方

投稿日:

第6回までお読みいただきありがとうございました、今回はいよいよ最終回です。

本連載は「法務部を中心とした管理部門の方」を想定読者に据え、クラウドセキュリティに関する検討を事業者・利用者双方の視点で行ってきました。私として連載開始前に「お伝えしたい」と考えていたことの中心部分は、とりわけ

でお伝えすることができました。

そこで最終回の第6回は番外編的に、改正法の施行が年明けに迫り、多くの企業が対応に追われているであろう個人情報保護法にフォーカスし、クラウドサービスに関連する部分について検討していきます。

検討のベースになる部分については個人情報保護委員会のガイドラインとQ&Aが既に出ており、また多くの先生方が個人情報保護法の解説記事など書かれています。他方で、それらを前提にもう1歩踏み込んだ実務的な部分…例えば、

などについてはあまり表に出てこないと思います。

私自身、複数の企業で改正法対応に関わる中で、現在進行形で色々な点について悩み、議論をしながら前に進めています。この辺りを赤裸々にシェアすることは、それなりに価値のあることかなと思い挑戦することにしました。ややマニアックな話もありますが、そこも含めて楽しんでいただければ嬉しいです。

現行法

令和2年改正法の話をする前提として、現行法から引き続いて問題になる部分について、前捌き的にいくつかの事項を検討しましょう。

‘controller’と‘processor’

クラウドサービス、とりわけtoBのSaaSではサービスの提供に際して複数の主体が関与することになります。その際、

をユーザーにわかりやすく示すことは、ユーザーとの信頼関係を構築する上で重要です。ユーザーとの信頼関係構築の重要性や、その際「わかりやすさ」が大きな影響を与えることは第5回で「トラスト」としてご紹介したところでした。

そして当然のことですが、そのようなユーザーコミュニケーションを行うためには、どの法的主体がどのような立場で個人情報に関与しているのかを、内部の人間が企画段階から明確に理解している必要があります。

これらを整理・理解する上で参考になるのが、GDPRで用いられているcontroller(管理者)とprocessor(処理者)という概念です。日本では直接controllerやprocessorという言葉は定義されていませんが、思考の整理として有用なのでご紹介します。

https://www.ppc.go.jp/files/pdf/gdpr-provisions-ja.pdf

具体的なケースで考えてみましょう。

——————-

【ケース1】

——————-

このチャットボット経由で取得した情報のcontrollerはA社とB社のどちらでしょうか。これは通常はA社と考えられるでしょう。このようなケースでは、A社は「単独で個人データの取扱いの目的及び方法を決定」するのが自然です。

B社はそのサービス提供形態に応じて、以下のどちらかと整理できそうです。 チャットボットのライセンスをA社に提供したもので、そもそもB社としては個人データは取り扱っておらず、controllerでもprocessorでもない チャットボットサービスを提供するために「個人データの取扱いの全部又は一部を委託」を受けたものとして、受け取った情報をcontrollerに代わって取扱うprocessorである

では次のケースはどうでしょうか?

——————-

【ケース2】

——————-

B社ドメインのサイトで入力される情報だから、controller(管理者)はB社でしょうか? これは建て付け次第ではありますが、ユーザーはA社のECサイトを利用する上での疑問を解消するためにチャットボットを利用しているのであり、突然出てきたチャットボット導入企業のB社のことなどは知りません。

ここでも原則的にはcontrollerはA社と考えるのが自然であり、ユーザーにも情報の取得主体はA社であることがわかるように設計をするのが適切です。(もっと言えばA社ドメインのサイトからB社ドメインのサイトに遷移する必要性について別途検討した上、どうしても遷移が必要なのであれば遷移することは事前にユーザーに案内すべきです)。

チャットボット経由で取得した情報をB社の各種製品の学習に利用したいなどの意図から、B社をcontrollerとすることもあり得ない訳ではありませんが、その場合にはより丁寧にユーザーへの説明をすべきです。

また現実に起こった事例として、今から1年位前にイベント予約サイトで起こった情報漏えいがあります。ここでは、

という整理になるのかな…と想像していましたが、この辺りなかなかややこしく、当初公式な説明もなかったことから、対応に苦慮した会社も多いのではないかと思います。

このように、to BのSaaSでは

が多く存在しているというのが私の理解です。状況を正しく理解するためにも、controllerやprocessorといった概念を用いて状況を整理するのは有用だと思います。

取り扱わないことになっている場合

「クラウドサービスの利用」に際してよく言及されるのが、個人情報保護委員会のQ&Aに記載されているQ7ー53です。

「個人情報の保護に関する法律についてのガイドライン」に関するQ&A https://www.ppc.go.jp/files/pdf/2109_APPI_QA_4ejj3t.pdf

「取り扱わないこととなっている場合」には委託先の監督義務(22条)が不要になるほか、後述の24条(外国にある第三者への提供の制限)の義務もかかりません。

「取り扱わないこととなっている場合」の要件は、

と定められています。

日本語の解釈としては、1つ目と2つ目はAND条件で、他にも許容されるケースがあることが3つ目により示されていると読むのだと理解しています。

この要件については各社リスク判断の下で色々な対応を行なっていて、

もあれば

ようなケースもあるようです。

私も以前から「この要件もうちょっと明確にならないかな」という問題意識は思っていて、以前この部分について個人情報保護委員会と議論させていただく機会があったのですが、最終的に何らかの結論に至ることはできませんでした。

民間での議論の高まりを待っておられるような様子もみられたので、この辺りもう少し議論が活発に行われると良いのになとは思っています(議論が活発になるのは得てしてインシデント発生時なので難しいところですが…)。

令和2年改正法

クラウドサービスの利用においては、まさにその利用対象が「クラウド」であることからデータの所在を地理的に限定しない(しにくい)状況が生じ得ます。

このことに関連し、令和2年改正法のうち24条と27条について取り上げます。

24条(外国にある第三者への提供の制限)

24条は改正前から存在した条文で、外国にある第三者に個人データを提供する場合に、原則として本人の同意を得ることを求める条文です(同意以外の方法については以下でご説明します)。

近年の越境移転についてのリスク・関心の高まりを踏まえて、今回の改正により本人への情報提供についての要件が強化されました。

「同意」と「相当措置」の使い分け

まずは以下の個人情報保護委員会の資料をご覧ください。

24条における外国にある第三者への提供の制限については、

  1. 本人の同意
  2. 基準に適合する体制を整備した事業者
  3. 我が国と同等の水準国(EU、英国)

と3つの方法が設定されています。

改正法に関連する政令・規則等の整備に向けた論点について(越境移転に係る情報提供の充実等) https://www.ppc.go.jp/files/pdf/201104_shiryou-2.pdf

この3種類の手段の選択については特段の制限がないので、移転する国によって適法化根拠を使い分けたり、1つの国に重畳的に適法化根拠を設定することも可能であると考えられます。ここで少し気になるのは、「A国とB国に提供します」という内容でユーザーから同意を取っておきながら、裏では相当措置によりC国に提供するということが可能な点です。

相当措置が取られているのであれば適法性には問題がないものの、ユーザー視点では何となく気持ち悪さが残るのではないでしょうか。このような取扱いをしたいのであれば、同意取得時には「列挙した国(A国とB国)以外にも相当措置などにより提供する場合があり得る」旨を記載しておくことも良いユーザーコミュニケーションのように思います。

また、「同意の撤回」を想定した場合さらに気持ち悪いことが起こります。日本の24条の同意に「撤回」が可能だとした場合、

というコミュニケーションも可能ということになります。

類似の話としてGDPRの「第6条 取扱いの適法性」があるので、上記の日本の制度と比較する意味でご紹介します。

GDPRでは個人データを処理する際に、その根拠を明確にする必要があります。少し雑に要約すると、以下の根拠の中から選択をすることになります。

この点についてはガイドラインが定められていて、

が求められています。このように定めることで、上記のような同意撤回時の気持ち悪さを回避することができています。

Guidelines 05/2020 on consent under Regulation 2016/679 https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf

日本は相対的に「同意」を重視する傾向があるとは感じており、一概に同意よりも相当措置が優れているとは思いませんが、上記会話例のようなケースが起こりうることも想定しながら、自社としてのスタンスを決定する必要があると考えます。

リスク評価とTIA

24条(外国にある第三者への提供の制限)については、ガイドラインの中で「リスクを評価」することが求められています。

個人情報の保護に関する法律についてのガイドライン(外国にある第三者への提供編) https://www.ppc.go.jp/files/pdf/210802_guidelines02.pdf

皆さん、ここで述べられているようなリスク評価制度の構築はお済みでしょうか?

ここについてはパブコメが出た時点で、私も「そんなリスク評価制度を組めている会社なんて殆どないのでは」と思っており、同じような危機感をもった方が「フォーマット例をホームページなどで公開していただきたい」と意見を出しておられましたが、個人情報保護委員会には見事に「事業者の責任において」とかわされていました。

「個人情報の保護に関する法律についてのガイドライン(外国にある第三者への提供編)の一部を改正する告示案」に関する意見募集結果 https://public-comment.e-gov.go.jp/servlet/PcmFileDownload?seqNo=0000223335

この点についてはGDPR上の取組みとしてTIA(Transfer Impact Assessment)というものがあります。TIAのためのリスクアセスメントシートとしてiappがテンプレートを公開していましたので共有します(リンク)。

リンク先のエクセルでは、移転先である外国の機関が「個人データにアクセスさせろ」と言ってきたときに、それを防げる確率を定量的に検討しようとしています。

「個人情報の保護に関する法律についてのガイドライン(外国にある第三者への提供編)の一部を改正する告示案」に関する意見募集結果 https://public-comment.e-gov.go.jp/servlet/PcmFileDownload?seqNo=0000223335

正直これは詳細すぎると思いますが、日本でも丁寧にやるのであればこのフォーマットを多少簡略化したものを使うのが良いと思います。

また、より簡易的な運用方法としては

———————-

———————-

のようなグループ分けを事前にした上で、基本的にはグループAに寄せていくという枠組みを「リスク評価」として定義するのはあり得るかなと思います。

同意取得時の情報提供

同意で24条の要件をクリアしようとする場合、情報提供が求められます。

法第 24 条(第 2 項)

個人情報取扱事業者は、前項の規定により本人の同意を得ようとする場合には、個人情報保護委員会規則で定めるところにより、あらかじめ、当該外国における個人情報の保護に関する制度、当該第三者が講ずる個人情報の保護のための措置その他当該本人に参考となるべき情報を当該本人に提供しなければならない。

その際、提供する情報はプライバシーポリシー又はそこからリンクを貼った別ページなどに記載することが考えられます。提供すべき情報についてはガイドラインに記載があり、今後個人情報保護委員会での「外国における個人情報の保護に関する制度等の調査について」のような取組みも期待できるのでそちらを参考にするのが良いと思います。

ここでは、その「プライバシーポリシー又はそこからリンクを貼った別ページ」のイメージを具体化するのに役立ちそうなGDPR上の取組みを紹介します。

冒頭の例を引き継ぎながら、

を想定してください。

GDPRではB社(Processor)が、A社(Controller)から受け取った個人データを、C社(Subprocessor)に処理させるような場合、A社(Controller)から承認を得なければいけません。

https://www.ppc.go.jp/files/pdf/gdpr-provisions-ja.pdf

B社(Processor)がこの28条2項の義務を果たす上での対処方法として、以下のリンク先のようなSubprocessorの開示ページを設ける運用が定着しました。(special thanks: 松浦隼生 @JunkiMATSUURA)

今回の改正個人情報保護法ではSubprocessorに相当する企業の社名まで開示することが求められてはいませんが、情報提供ページのイメージを持つ上ではとりわけzoomのページなんかは参考になるんじゃないかと思います。また、Googleのページにおけるsubprocessorの多さも一度確認してみると良いと思います(驚かれると思います)。

なお、私は「利用するSaaSなんて動的に変化するし、どうやって開示時点と現在時点の差分を吸収するのかな」と最初思ったのですが、例えばzoomでは以下のようなフォームを設けて対応しており面白いなと思いました。

zoomのフォーム例

委託元(国内)→委託先(国内)→再委託先(国外)のケース

次に、自社で取得した個人データを国内企業に対して委託するが、その国内企業が海外の企業に再委託するようなケースについて検討します。

説明のしやすさから、

とします。(ここでは国内/国外の違いが重要なので、ECなどの属性は落とします)

このようなケースにおいて、24条の義務を課されるのはA社でしょうか?それともB社でしょうか?この論点についてはパブコメ結果に4,5件類似のものが出ています。実際にアウトソーシングとしてこのようなスキームを組んでいる企業がそれなりに多いということなのでしょう。

「個人情報の保護に関する法律についてのガイドライン(外国にある第三者への提供編)の一部を改正する告示案」に関する意見募集結果 https://public-comment.e-gov.go.jp/servlet/PcmFileDownload?seqNo=0000223335

このケースでは、(個別の事案ごとに判断されるとはなっていますが)24条の義務はB社に課されることになっています。A社としてはB社に対して、義務を履行させる監督義務を負うということになります。

B社が突然、A社のユーザーに対して24条の同意を取りに連絡してくるのはユーザー視点でかなり違和感がありますし、A社としてもレピュテーションの観点から、そのようなことはやめてほしいと思うでしょう。

そのため、A社の動きとしては

の2極化が進むような気がしています。

27条(保有個人データに関する事項の本人への周知)

安全管理措置の開示

27条における情報開示自体は現行法においても定められていましたが、「本人の適切な理解と関与を可能としつつ、個人情報取扱事業者の適正な取扱いを促す観点」から、いくつか開示事項が増えました。ここではこのうち

の開示について検討します。

個人情報の保護に関する法律についてのガイドライン(通則編) https://www.ppc.go.jp/files/pdf/210802_guidelines01.pdf

皆さんは自社が安全管理措置を適切に講じていることを、どのように説得的に説明するでしょうか?ガイドラインでは釘を刺すように「ガイドライン(通則編)」に沿って安全管理措置を実施しているといった内容の掲載や回答のみでは適切ではない。」との記載もされています。

幸いガイドラインには【安全管理のために講じた措置として本人の知り得る状態に置く内容の事例】の記載もあるので、こちらで採用しているガイドライン(別添)のフレームワークに沿って以下のような枠組みで説明するのは1つの方法です。

私としては連載第3回で述べた通り、総務省ガイドラインなど何らかのより詳細なフレームワークに基づきクラウドサービス事業者がより積極的な開示を行う未来が来ると良いなと考えています。

外的環境の把握

ここでは上記の7項目の中でも、最後の外的環境の把握について取り上げます。

クラウドサービス利用者はクラウドサービス事業者の運営するサーバに個人データを保存する場合、まずこれらのクラウドサービスを網羅的に捕捉した上で

を把握・管理する必要があります。条文の構造など詳細は私の個人ブログのこちらの記事で記載していますのでよろしければご覧ください。

などなど疑問は絶えないのですが、今一番気になっているのはCDN(CDNの概要についてはこちらのレポートなど参考になります)のように全世界的に情報が拡散するサービスの場合どうするんだろうということです。全ての国を列挙して、全ての国の制度等を把握するのはなかなか大変そうです。

(CDNなので)キャッシュは保存に当たらないというのは一つかもしれませんが、説得力に欠ける気もします。「所在する国を特定できない場合」と言えれば簡単なのですが、特定できてしまう場合も多そうです。

「個人情報の保護に関する法律についてのガイドライン」に関するQ&A https://www.ppc.go.jp/files/pdf/2109_APPI_QA_4ejj3t.pdf

この辺りは色々な方と議論しているのですが、明確な結論を持っている方とは今の所私は出会えていません。そもそも

も散見されます。

ため、影響範囲はそれなりに広いんじゃないかと思っています(例えば、「ユーザー登録した上でレビューの投稿が可能なサイト」なんかはおよそ該当するんじゃないでしょうか)。

CDNは(主に可用性の観点から)セキュリティ上重要な取組みの一つです。この利用を制限していく方向性が正しいとは思いません。「個人情報の保護に関する法律についてのガイドライン」に関するQ&Aが上記文言で公開されてしまった現在、反論がなかなか難しくはありますが、現実的な実現可能性も踏まえて私は反対の立場です。「所在する国を特定できない場合」に準じた取扱いに落ち着けることができれば良いのではないかと思います。

終わりに

以上で全6回にわたった「SaaS利用者/事業者が知っておくべきクラウドセキュリティの確かめ方と高め方」を終わろうと思います。

短い期間でしたが、

というサイクルを隔週で繰り返すのはとても充実した期間でした。

どの回も、何度も書き直した記事ばかりだったので、読んでいただいた皆様・コメント下さった皆様にはとても感謝しています。皆様からいただけるリアクションが、連載を続ける一番のモチベーションになりました。

本連載についてのご指摘・アドバイス・ご質問などは、Twitter(@seko_law)やメール(shuhei.seko@inhousehub.tokyo)でいただければと思います。

それでは改めまして、最後までご覧いただきありがとうございました。

参考文献

連載記事一覧

著者紹介

世古 修平(せこ しゅうへい)
インハウスハブ東京法律事務所、インターネットサービス企業 Privacy Counsel、IPA独立行政法人 情報処理推進機構 試験委員。
弁護士(第二東京弁護士会)、CISSP。
Twitter: @seko_law

契約のデジタル化に関するお役立ち資料はこちら