WebプログラマーのためのGDPR入門
2018-06-28

目次

近頃話題の GDPR を 自分なりにまとめてみました。

自分は Webプログラマ なので Webサービス視点の記述が多くなっていますがご了承ください。

備考

当該記事は 複数の記事を参考にしていますが、ベースとしたのは以下の情報です。

その他の情報は記事の末尾にリンクを掲載しています。

備考

  • 免責: 訴えられても責任は持てません。
  • 言い訳: セクション名を英語で書いているのはかっこつけているんじゃなくて、 reSTが生成するアンカーのスラッグが ASCII 文字から採用されるためです。(だれかいい方法知ってる人がいたら教えて)

What is GDPR?

2018/5/25 に施行されたデータ保護( 処理移転 )に関するEUの法律です。 忘れられる権利とか最近良く聞きますよね。

実際のところは 2012年から策定が進んでおり、このあいだ遂に施行されたというわけです。

過去に発足された 欧州人権条約 などが元になっているようです。

General Data Protection Regulation の頭文字をとって GDPR と呼ばれます。

備考

対象地域は EEA(欧州経済領域) ですが、以降はすべて EU とします。

Processing (処理)

個人データの処理はデータを使った分析、集計処理のようなものを思い浮かべるかもしれませんが それ以外にも「収集」「補完」「変更」「削除」「閲覧」などのあらゆる行為が処理に含まれます。

例えば、JETRO の資料では 以下のものが例に挙げられていました。

  • E-mailアドレスの収集
  • クレジットカードの詳細の保管
  • 顧客の連絡先詳細の変更
  • 顧客の名前の開示
  • 上司の従業員業務評価の閲覧
  • データ主体のオンライン上の識別子の削除
  • 全従業員の名前、社内での職務、事業所の住所および写真を含むディレクトリの作成

Transfer (移転)

個人データの移転とは例を挙げると 個人データを含む書面を郵便やEメールで送付する ようなもので、 多くの事業者は関係ないように思えるかもしれませんが、 JETRO の資料には次のように書かれています。

「個人データの移転」の概念は指令とGDPRのいずれにも定義されていない。 あえて定義すると、第三国の第三者に対して個人データを閲覧可能にするためのあらゆる行為である

上記より WebサービスでEUに住む個人データを表示することも該当すると考えられます。

警告

メール送信の際に、送信 , いずれもがEU内だとしても EU外にあるメールサーバを経由した場合、データの持ち出しを行ったと判断されます。

ところで、EU 域外への個人データの移転は原則として違法なんですが、 移転先の国や地域が法整備され、充分に個人データ保護を講じていたり適切な保護措置をとったことが認められた 場合は例外的に適法となります。

これを 十分性認定 というらしく、日本はこの認定を受けることで話が進んでいます。

とはいえ、これで日本の事業者が完全にセーフになるわけではありません。あくまで移転だけですからね。

Characters (登場人物)

詳細な話をする前に GDPR の登場人物を紹介するぜ。

Data subject (データ主体)

なんか仰々しいですが、GDPR において守られる 権利 を持つ 個人 を意味します。

簡単に言えば利用者です。

Administrator (管理者)

個人データを処理する自然人または法人です。(単独とは限らない)

データ主体の権利を守る 義務 があり、GDPR 違反に対する責任を負います。

Processor (処理者)

管理者の代わりに個人データの処理を行う自然人または法人です。

管理者は処理者に個人データを委託する際には予めデータ主体に伝え同意を得る必要があります。

処理者は GDPR違反に対する責任は負いません。 管理者は処理者を監督する責任も負います。

DPO (データ保護責任者)

DPOは利害関係者の仲介および、管理者、処理者を監視する役割を担っています。

組織がデータ主体の監視や特別カテゴリに属するデータ処理を業務内容とする組織では、DPO選任の義務があります。 また公的機関によってデータ処理が行われる場合やその国の法律によって選出が要求される場合も義務があります。

管理者と処理者はDPOの業務を支援する義務があり、その立場を保証されます。

DPO を組織内から専任する場合は 個人データの取扱を決定し利益を追求するような業務(経営など)には就けないとされています。

選任義務がなくてもDPOを選出することは可能です。 しかし、単なるデータ保護に従事する職員というだけで DPO を名乗ってはいけません。

Regulator (監督機関)

GDPR の遵守を監視するための公的機関のことで、 各加盟国ごとに1つ以上存在しますが EU (EEA) に加盟していない日本にはありません。

監督機関は データ主体 の権利を守るため管理者にデータフローなどの是正を求めたり、制裁金を課すことができます。

管理者、処理者は監督機関の要請に応じる義務があります。

警告

監督機関以外から制裁金を賦課されることはないはずなので示談金とかいう名目で第三者に金銭を騙し取られないように注意してください。

その他にもいろいろ注意点:

GDPR 施行直後の対応に伴うリスクや、便乗したサイバー犯罪の可能性とは?

Applicable condition (適用条件)

以下のいずれかに該当する場合、管理者は GDPR の適用対象になります。

  • EU のデータ主体に商品やサービスを提供する
  • EU のデータ主体の行動を監視する

これはデータがそこに保存されているかとか、活動拠点とかではなく、そこにいる人達のデータを扱うか否かがポイントになってきます。

つまり、EU がビジネスの対象として含まれなければ この法律を気にすることはないのです。

Webサービスを提供する人たちにとって重要なのは 「GDPR の適用対象になるのか」ということで、 「EUに対してサービスを提供する意図が明確にあるのかどうか」と言い換えられます。

ただ、この部分は以下のように解釈が分かれているように思えます。

  • インターネット経由で全世界に公開されているのであれば GDPR の適用対象になる (悲観的解釈)
  • 「EUからアクセスできる」「使用言語が英語」というだけでEUのデータ主体に サービスを提供する意図が明白になるわけではない (楽観的解釈)

いろんな情報を漁った限りでは日本語で提供する、または日本国内のローカルな情報を扱うことで 「EUに対してサービス提供する意図はなかったと解釈されるだろう」 という楽観的解釈が多いように感じていますし、私もそう思います。

この解釈をもとに利用規約やプライバシーポリシーを改定することが最もコストの低い対策と言えるでしょう。

とはいえ、これで絶対に安心という保証はないですが。

なお、海外のサービスでは GDPRの対応が完了するまでは EEAからのアクセスは意図的に弾くという事業者もいるようです。

Personal data (個人データ)

では個人データとは何かと言うと、私達の想像よりも範囲が広く、 個人を特定しうる情報すべて です。

つまり、ユーザのニックネーム、Cookie、 IPアドレス(アクセスログ) なども対象となりえます。 Cookie については多くの議論がありますが、基本的には 「Cookieの利用許可をとる」のが無難です。 主に対象となるのは ユーザの動向を記録するための トラッキングCookie だとは思います。

旅行や出張でEEA域内に存在する日本人の情報、一時的にEU を経由する情報もこの法律に該当するらしいので注意が必要です。

特に政治宗教、健康等のセンシティブな情報は特別カテゴリに属し、通常より厳しい規則が設けられています。

なお、法人や故人のデータは対象にはなりません。

Fines (制裁金)

GDPR で取り沙汰されるのは 制裁金の大きさです。中小企業がまともに食らうと破産しかねません。

違反者に対しては最高で 2000万ユーロ (約26億円) か 売上高(世界を対象とする) の 4%、いずれか高いほうが賦課されます。

調査・遵守命令や警告などが下る場合もあり、必ずしも即座に制裁金の賦課が行われるわけではありません。

最高で というのは 違反した項目、被害の大きさ(データ量)や、アカウンタビリティの遵守度によって減額が行われると考えられるためです。

備考

公的機関が違反した場合にも制裁金が課せられるが、売上高という概念がないため制裁金は最大で 2000万ユーロ となります

Calculation method (算出方法)

監督機関は以下の 基準をもとに制裁金を決定するとされています。下記はそのまま PDF を引用しました。

  • a, 問題となる処理の性質、範囲、または目的、影響を受けるデータ主体の数、およびデータ 主体が被った損害のレベルを考慮した、違反の性質、重大さおよび期間
  • b, 違反の故意性または過失性
  • c, データ主体が被った損害を緩和するために管理者または処理者が講じた措置
  • d, GDPR 第 25 条(設計によるまたは初期設定によるデータ保護)および第 32 条(処理のセキュリティ)に基づき実行された技術的および組織的対策を考慮した、管理者または処理者の責任の程度
  • e, 管理者または処理者による関連する過去の違反
  • f, 違反を是正し、違反によって生じ得る悪影響を緩和するための、監督機関との協力の程度
  • g, 違反によって影響のある個人データの種類
  • h, 監督機関が違反を知ることになった経緯、特に、管理者または処理者が監督機関に違反を通知していたかどうか、通知していた場合、どの程度通知を行ったか
  • i, GDPR 第 58 条第 2 項(監督機関の是正権限)に定める方策が、過去に管理者または処理者に対して同じ係争に関して命じられていた場合、当該方策への遵守
  • j, 承認を受けた行動規範、または承認を受けた認証手続きへの遵守
  • k, 違反によって直接または間接に、獲得した金銭的利益、被らずに済んだ損害などの事案に応じたその他の加重、または軽減事由

簡単に言うと情状酌量の余地が制裁金に大きな影響を与えると考えてよいでしょう。

正確な計算方法まではわかりませんでした。(多分書いてないよね?)

Accountability (説明責任)

端的にいうと GDPR を遵守できていることを いつでも証明できること です

もう少し具体的に言うと データ主体の権利を守る義務 をどのように果たしているかを説明できる状態を維持することです。

管理者は個人のデータを処理する際には以下の原則をみたす義務があります。

1. Legality (適法性)

個人データの処理がどのような理由に基づいて処理されているかを適法根拠といい、これらのいずれかを満たしていることが適法性と呼ばれます。

具体的には以下のようなものがあります。

  • 個人データの処理について個人の同意を得られている
    • 過去に同意なしに集められた個人情報は 再同意 をもらえないのであれば削除するべき
    • 抱き合わせで色々なサイトへ登録されるようなものはそれぞれについて別途説明を設け同意を得る必要がある
    • 同意の撤回が容易に行えること
      • また、某通販サイトのように最初からチェックが入っている( オプトアウト )作りでは、同意とみなすことができない。
      • 過去にサービスの内容、データの取扱に同意したとしてもあとから取り消して異議を唱えることが可能 (第21条)
        • たとえば、メールマガジンの購読解除
    • 未成年の場合は、親の同意が必要
  • 契約履行のために必要
    • 販売した商品を届けるための住所や住所や、オンラインサービスがユーザを識別するためにメールアドレスを登録してもらうこと
  • 法的義務履行のために必要
    • 病院が患者の病状を把握するためにカルテをいて長期間保存する義務
    • 給与記録などの一定期間保存する義務(官公庁に開示するため)
  • データ主体の救助に関わる情報
    • データ主体の意識がない、消息不明等で同意を得られないのがあきらかな場合、 本人の意思表示がなくても生命を守るためにデータの開示を許可されることがある
  • 管理者の正当な利益の追求のために必要
    • データ主体の権利と管理者(または第三者)によって追求される 正当 な利益と比較し、後者のほうが大きい場合は該当とする
    • ただしデータ主体が子供の場合、保護を求める基本的権利及び自由のほうが管理者の権利よりも大きい

2. Fairness and transparency (公正性と透明性)

公正性とは Google先生によると かたよりがなく正当なこと ということで、 自分がされたら嫌なことをしないという考えが根底にあります。

具体的には以下のことを守ります。

  • サイトを利用するすべてのユーザが対等に扱われ、特定のユーザが不利益を被るようなことがないこと
  • 利用者を騙したり勘違いさせたりしないこと
    • 同意を求める内容がそれ以外のものと区別が付きやすくなっていること
      • なぜか許可した覚えのないメルマガの購読処理がされていないか?
    • わかりやすい言葉で説明されている
  • 処理や行動の監視が同意に沿った内容になっている
  • 利用者は個人データに関してアクセス、訂正(第16条)、削除(第17条 (1))、利用制限(第18条)を行使できる
    • 特に 忘れられる権利 とあるように、保存されているデータはユーザ自身の意思で削除、 変更、移動可能なこと (データポータビリティの権利:第20条)
    • データ主体は自身のデータに自由にアクセスし移行しやすいフォーマットで持ち運ぶ権利がある
    • 外部サービスにデータが保存されている場合、それも対象
  • ユーザが許可しない場合は管理者であっても見られないようにする

透明性 とは 公正性がどのように遵守されているのかが第三者にもわかるようにすることで、セットで守られるべき性質です。

3. Limit for using to the purpose (目的限定)

利用目的に対し最小限の個人データのみが収集されていることです。

例えば、荷物の配送に性別や年齢の入力は不要なので、入力項目を設けないなどです。

4. Minimize (データ最小化)

利用目的外に個人データが利用されないように規則を設け、遵守することです。

緊急時用に聞いた電話番号に営業電話をかけたりしたらだめですよ。

5. Accuracy (正確性)

正確で最新(ユーザが入力した)の個人データが閲覧できること、 または不正確なデータが残らないような策が講じられていることです。

備考

これは後述する 完全性 とは違い、セキュリティ的な観点ではなく システムとしての正しさが求められているんだと思います。

6. Store (保管)

また、必要な期間以上に個人の特定が可能な状態でデータを保存しないことです。

例えば、売上の統計を取る場合、用いる売上データにユーザ名が含まれている必要はないので、 分析対象のデータから個人を特定できる情報を意味の無い文字列に置き換えて保存するようにします。これを 仮名化 といいます。

備考

暗号化は仮名化の一種です。 復号キーは仮名化されたデータとは別に保存されている必要があります。

また、完全に不可逆な状態にすることを 匿名化 といいます。

また、以下のこともこの項目に該当します。

  • アクセスログをいつまでも保持しない
  • 入力されたデータ(住所やクレジットカード等)の情報をサーバ上に保持しない

7. Confidentiality and integrity (機密性と完全性)

プライバシー保護をセキュリティを切り離して考えることはできません。

機密性 (Confidentiality), 完全性 (Integrity), 可用性 (Availability) が情報セキュリティの三大要素(CIA)と呼ばれ、これらが崩れると セキュリティ侵害 (インシデント)になるわけですが GDPRではこのうちの機密性と完全性が崩れることを データ侵害 としています。

備考

  • 機密性 とは違法なアクセスから情報の漏洩を防ぐこと
  • 完全性 とは期待通りのデータが(改竄されずに)管理されていること

データ侵害発生時は以下のように対応する必要があります。

when a violation occurred (データ侵害発生)

データ侵害が発生した場合、72時間以内に担当する監督機関に以下の内容を届け出る必要があります。

  • 侵害の内容
    • データ主体の種類と概数
  • 保護役(DPOなど)の連絡先
  • 想定される影響
  • 管理者によって取られている、またはこれから取る対策

リスクが小さい場合には届け出なくてもよいが、判断の正当性についてアカウンタビリティを負うとされています。

また、データ主体に対してデータ侵害があった事実を通知する必要もあります。ただし以下の場合は通知不要です。

  • 個人データが判別されないように暗号化などの技術的措置が取られている場合
  • 自然人の権利を侵害するような高いリスクが具現化し得ないことを確実にする事後的措置をとった場合
  • 通知することに過度な労力を要する場合
    • この場合、代替として公的な通信などでデータ主体に伝わる手段を取る必要がある。(SNSとかかな)

届け出や通知の義務に違反した場合も制裁金が課される可能性があります。

Measures (対策)

Not conflict with GDPR (抵触しない)

そもそも EU 向けにサービスを展開しない場合は、そのままでも良いでしょう。

念のために EU向けのサービスでない旨をプライバシーポリシー等に記述しておくのも良いかもしれません。

Conflict with GDPR (抵触する)

基本的に管理者がすべきことは説明責任を果たすことですが、いきなりさぁやれと言われても困ります。

GDPRの対策にはガイドラインがあり、大きく分けて以下の 4ステップ で対応を進めていきます。

  • 対応状況の把握
    • 個人データをどこでどのように扱っているかの把握
    • 現在所持している個人データの種類と量の把握
  • ギャップ分析
    • 要求事項と現状を比較し、できていないものを洗い出す
    • できていないものに優先順位をつける
  • 対応方針の策定
    • 対象組織や拠点の決定
    • 対応担当者の選出
    • スケジュール
  • 対応策の実施
    • 対応策の展開
    • 状況のモニタリング

組織によって対応することは違うので、抽象的な感じになってしまいますが 多くのWebサービス運営者にとって共通するのは以下の項目です。

  • 事前に同意を得ること (オプトインと呼ばれます)
    • 所有する個人データの扱い方
      • すでに所有していて、データ主体に伝えていないものがある場合、同意を求める必要がある
      • 同意が得られない個人データは削除する
    • Cookie でユーザの動向をトラッキングしている場合、同意を求めるようなダイアログを表示する
  • ユーザに対して適切な権限を付与する
    • ユーザが登録したデータを正しく表示する
    • ユーザが登録したデータを訂正、削除できる

これらの項目はユーザが直接表示するため問題が表面化しやすいです。

裏での個人データの取扱は必要に応じて段階的に仮名化などをしていけばよいでしょう。

Conclusion (終わりに)

いかがだったでしょうか。

ユーザの立場では当たり前に感じることも、 管理者の立場で考えてみると意外と守られていなかったりしませんか?

GDPRの決めごとをすべて守るのは大変なことかもしれませんが、管理者にとってすべてがデメリットではない事に気づきます。 たとえばデータの匿名化や最小化はデータ流出時の被害軽減に繋がりますし、事業に対するクリーンなイメージを作り出します。

公正で快適なインターネットをみんなで作っていきましょう。

間違っているところがあったらやさしめにつっこみください。

その他参考