契約実務

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

2021.11.03更新

第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】

A社はEC事業を行なっており、顧客から各種の個人情報を取得している
B社は企業に対してチャットボットの導入サービスを提供している
A社のECサイトに、B社のチャットボットが導入されることになった
ユーザーは、A社のECサイト内に設置されたポップアップから、チャットボットに対して問い合わせができるようになった

——————-

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

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

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

——————-

【ケース2】

A社はEC事業を行なっており、顧客から各種の個人情報を取得している
B社は企業に対してチャットボットの導入サービスを提供している
A社のECサイトに、B社のチャットボットが導入されることになった
ユーザーは、A社のECサイト内に設置されたリンクからB社ドメインのサイトに遷移した上で、チャットボットに対して問い合わせができるようになった

——————-

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

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

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

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

イベント予約サイトに事前に登録されたユーザー情報
- イベント予約サイトがcontroller
具体的な個別イベントについての申込情報
- 具体的な個別イベントの主催企業がcontroller
- イベント予約サイトがprocessor

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

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

controllerになっているにも関わらず、そのことに無自覚であるケース
processorになっているにも関わらず、controllerであると誤解し、委託の範囲を超えて個人データを利用しているケース

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

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

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

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

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

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

契約条項によって当該外部事業者がサーバに保存された個人データを取り扱わない旨が定められており
適切にアクセス制御を行っている場合
等

と定められています。

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

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

IaaSであれば「取り扱わないこととなっている場合」に該当し得るが、SaaSの場合預けたデータを全く取り扱わないことなど考えられないとして保守的に運用しているケース

もあれば

「等」をある程度柔軟に解釈し、一定の限定的な状況においては「取り扱わないこととなっている場合」として許容する

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

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

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

令和2年改正法

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

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

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

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

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

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

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

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

本人の同意
基準に適合する体制を整備した事業者
我が国と同等の水準国（EU、英国）

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

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

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

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

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

企業：あなたの個人データをA国にある第三者に提供（委託）します、同意してください。
ユーザー：同意します。
ユーザー：やっぱり同意を撤回します。
企業：わかりました。しかし我々は相当措置を講じているので「相当措置」に基づいてA国への提供（委託）を継続します。
ユーザー：…。

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

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

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

同意
契約の履行
管理者が服する法的義務
生命に関する利益
公共の利益
正当な利益

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

根拠は事前に設定すること(established prior to the processing activity)
「同意」を根拠とした場合には、別の根拠に乗り換えることはできないこと(cannot swap from consent to other lawful basis.)

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

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がテンプレートを公開していましたので共有します（リンク）。

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

EU SCC Transfer Impact Assessment（TIA） https://iapp.org/media/resource_center/eu_scc_transfer_impact_assessment.xlsx

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

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

———————-

グループA：EU,英国など比較的安全であるとされる国
- 提供が可能
グループB：グループA,C以外の国
- ○○部門の承認を得れば提供が可能
グループC：ガバメントアクセスに関してリスクが高いと定義した国
- 提供不可

———————-

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

同意取得時の情報提供

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

法第 24 条（第 2 項）

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

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

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

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

to CのEC事業を行っているA社（Controller）
to Bのチャットボット導入事業を行っているB社（Processor）
to BのSaaSをB社に提供しているC社（Subprocessor）

を想定してください。

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

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

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

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

委託元（国内）→委託先（国内）→再委託先（国外）のケース

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

説明のしやすさから、

委託元である国内企業A社（Controller）
委託先である国内企業B社（Processor）
再委託先である国外企業C社（Subprocessor）

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

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

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

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

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

監督義務違反を回避するため、（パブコメの記載に反して）あえて委託元で同意を取ってしまったり、委託先の「相当措置」の確認にかなり踏み込んで関与する企業
「義務を負っているのはB社だから」と、殆ど24条の義務履行に殆ど関与しない企業

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

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

安全管理措置の開示

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

安全管理措置（法27条1項4号、政令8条1号）

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

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

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

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

基本方針の策定
個人データの取扱いに係る規律の整備
組織的安全管理措置
人的安全管理措置
物理的安全管理措置
技術的安全管理措置
外的環境の把握

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

外的環境の把握

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

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

A国（サーバの運営事業者が存在する国）の名称
B国（サーバが所在する国）の名称
A国、B国の制度等
必要な安全管理措置

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

単純に大変だ
パブコメだとクラウドサービス事業者が日本企業の場合にも、一応全てサーバの所在国を確認しなければいけないように読めるが本当にするのか
とりわけ大手プラットフォーマーなど、クラウドサービス事業者側が開示に消極的な場合どうするのか

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

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

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

個人情報の定義が怪しい方（これは第4回でも言及したことでした）
自社としての利用状況を把握されていない方

も散見されます。

ここで問題になっているのは、「個人情報データベース等」ではなく「個人データ」を外国に所在するサーバに保存する場合である
「個人データ」に該当する事例として、ガイドラインでは以下が挙げられている
- 個人情報データベース等から外部記録媒体に保存された個人情報
- 個人情報データベース等から紙面に出力された帳票等に印字された個人情報

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

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