EU一般データ保護規則(GDPR)への対応に向けたやるべき事まとめ

TAKUYA

·

Follow

Published in

週休７日で働きたい

·

10 min read

·

May 10, 2018

--

Share

EUの個人情報保護に関する新しい法律(General Data Protection Regulation)が2018年5月25日から施行される。EUの居住者に対してサービスを提供していて個人情報を取り扱っている業者は、たとえ個人であろうとも遵守義務が課せられる。

最近多くのサービスがプライバシーポリシーの改定を行っているのはそのためである。個人で作っている自分のサービスにもEUのユーザが沢山いるので、そろそろ対応しなければならない(遅い)。

今回はEUの法律によるものだが、内容は至極真っ当な、客観的に見れば当たり前のルールだ。将来的には事実上のデファクトとなり、アメリカや日本もこの法律に倣うのは時間の問題だろう。だから「日本人向けのサービスだから大丈夫」とほったらかしにしている業者は後々痛い目に遭うだろう。

Twitter社がパスワードをログに記録していた件は記憶に新しいが、今これが公にされた背景にはおそらくGDPRがあるのでは。前々から問題は認識していたけど、法律が施行される前に早めに白状しておこうという内情なのではと個人的に邪推している。

本稿は拙作サービスのGDPR対応に向けて必要なことをまとめたメモである。

参考資料

まずは概要をさらっと知るための資料。ググれば日本語でもいろいろ出てくる。

• EU一般データ保護規則（GDPR）の概要と企業が対応すべき事項｜情報センサー2017å¹´2月号 EY Advisory｜EY Japan
• ニッポンの個人情報のいま (2/5)：EnterpriseZine（エンタープライズジン）
• How GDPR Will Change The Way You Develop — Smashing Magazine

他の企業がどのようにGDPRへ対応しているのか。各社のサイトに文書が上げられているので参考にできる。

• DigitalOcean: Cloud computing designed for developers
• GDPR Compliance — Mixpanel Help Center
• GDPR | Evernote
• GDPR FAQs — Todoist Help

で、良さそうな記事を見つけた：

• GDPR — A Practical Guide For Developers — Bozho’s tech blog

自分のようなウェブサービス業者がやらなければならない事が具体的に分かりやすくまとまっている。これを書いたBozhoという人は元 ”advisor to the deputy prime minister of a EU country (EU国家副首相補佐官)” だそうで、この法律に関わっていた人だから情報の信頼性が高いと言える。

基本はこの記事に則って作業を進めると良さそう。

法律の概要

サービスや会社の規模は関係ない

None of the other requirements of the regulation have an exception depending on the organization size, so “I’m small, GDPR does not concern me” is a myth.

…だそうなので規模が小さいからと言って楽観視できない。

個人を特定できる情報全てが対象

any information relating to an identified or identifiable natural person

例：

• 遺伝子データ
• 身体特徴データ（指紋や虹彩など）
• 位置情報
• Pseudonymized data (仮名データ？ようわからん)
• オンラインID

サーバがどこにあろうが関係ない

EU居住者がサービスを利用しているならば、サーバがアメリカや日本にあっても関係なく法律の対象となる。

罰則が超重い

• 軽度の違反 ：1000万ユーロ、または前年売上高の2パーセント
• 権利侵害などの違反 ：2000万ユーロ、または前年売上高の4パーセント

桁がすごい。破産確実。

以降よりやるべきことを列挙する。

“Forget me” — ユーザの情報を全部削除する機能

ユーザがアカウントを削除する際、 deleted フラグを付けたりするだけでは足りない。全ての個人情報をデータベースその他サードパーティー製サービスから抹消しなければならない。

データベースの都合上Foreign Key制約で削除できない場合は、nullableにするとかで対処する必要がある。または関連データを全削除。

クレジットカード情報や購入履歴なども削除。IPアドレスも忘れずに。

Notify 3rd parties for erasure — 他社製サービスに格納したデータの抹消

自サービスのデータベースを削除するだけでは足りない。サードパーティーのSaaSなどを経由して格納した個人情報も削除義務の対象となる。例えば、Salesforce, Hubspot, twitter, Mixpanel, Stripeなど。APIを使って削除する。

当然、AWS S3などにアップロードしたファイルなどもユーザに関連するものは全て削除する必要がある。

Googleは検索結果から削除する方法をAPIで提供していない。この場合、対象のページで404を返すようにする。

Restrict processing — 管理者閲覧制限

管理ツールなどでユーザ一覧表示する機能があれば、ユーザの設定画面などに ”Restrict processing” ボタンが無ければならない。ユーザがもし望めば、バックオフィス担当者が管理ツールを経由して個人情報にアクセスするのを制限できるようにする必要がある。

これは、むやみやたらとアクセス権限を担当者に与えないようにするためのルールだと思われる。自分の場合管理者は自分しかいないので、無視してよさそう。

Export data — データのエクスポート

ユーザがサービスに格納された自分に関わるデータを全て受け取れるようにする必要がある。これは通常 “forget me”で削除されるデータを指すが、例えば購入履歴なども範囲に含まれるだろう。

自分のサービスには既にノートのデータを全エクスポートする機能があるのでカバーしているはず。ユーザ情報はアカウントページで見れるし。

Allow users to edit their profile — プロフィールの編集権限

明白なルールだが、たまに許可されていない。ユーザに関わるプロフィールのデータは原則変更可能でなければならない。

Consent checkboxes — 同意チェックボックス

“I accept the terms and conditions”だけでは足りない。それぞれのデータ処理に対して個別のチェックボックスが、ユーザ登録画面やプロフィール画面に設けられなければならない。チェックボックスに最初からチェックを入れるのは禁止。

例えばアプリでのユーザ行動をトラッキングする事は割とよくやられているが、事前に明示的に許可を取る必要がある。何をどのように取ってどこに保存するのかも、プライバシーポリシーなどに明記する。

機械学習などで集めるデータについても許可を得る必要がある。ただし、科学研究の目的は例外。

“See all my data” — データ閲覧

これは”Export data”の項と似ているが、JSON,XMLなどの機械的なフォーマットというよりは、UIで閲覧できる機能を指す。この機能は「必須(mandatory)」ではないが、「望ましい(desirable)」。

例えばGoogle Mapsはロケーション履歴を表示出来たりする。

最小限の対処法としては、Email通知がある。何かデータを受け取ったらユーザにメールする。メールにはそのデータが何に使われるのかを記す。

Age checks — 年齢確認

ユーザが16歳未満の場合は親の同意が必要となる。親の確認フローはルールに設けられていないが、メール経由などが考えられる。

自分のサービスは大人向けなので、16歳以上を確認するチェックボックスをユーザ登録時に設ければよさげ。

Keeping data for no longer than necessary — 必要以上にデータを保持しない

もしデータを特定の目的で使用したなら、必要なくなり次第それを削除するか匿名化しなければならない。例えば、eコマースサイトで「ユーザ登録せずに商品を購入する」機能で取り扱った情報などは、取引を行っている間しか必要ないのでcronなどで定期的に削除される必要がある。

Cookies — クッキー

Cookieの取り扱いはGDPRでも変更が加えられているのではっきりしない。Bozho氏の関連記事を参照：

• Tracking Cookies and GDPR — Bozho’s tech blog

以上が主要な「すべきことリスト」だ。

やったほうがいい事

これ以外にも、法律によって要求される必須事項ではないが、ベストプラクティスとして推奨されるものが挙げられる。

• Encrypt the data in transit — データ転送の暗号化
• Encrypt the data at rest — 保存データの暗号化
• Encrypt your backups — バックアップの暗号化
• Implement pseudonymisation — ステージングやテスト環境に本番環境のデータをもってきた時に、実名やアドレスのみを改変することをPreudonymisationと呼ぶ。推測されにくいように hash+salt/bcrypt/PBKDF2などを使うことが推奨される。
• Protect data integrity — “have authentication mechanisms for modifying data”
• Log access to personal data — 全ての個人情報へのアクセスを、誰が何に何のためにしたのかログに記録する。
• Register all API consumers — 匿名でのAPIアクセスを許可しない

やらないほうがいい事

• Don’t use data for purposes that the user hasn’t agreed with — ユーザが同意していない用途での情報利用をしない
• Don’t log personal data — 個人情報をログに書き出さない
• Don’t put fields on the registration/profile form that you don’t need — 不要なデータを登録フォームで受け取らない
• Don’t assume 3rd parties are compliant — 他社サービスがGDPR準拠しているだろうと安易に決めつけない

自分の場合、もともとセンシティブなデータを取り扱うサービスのため気をつけていたので、そこまで大きな変更は必要なさそうで良かった。それよりも、GDPR Compliantであることを示す文書の用意の方が大変そうだ。

Data Processing Agreementとか書くべきなのか・・Digital Oceanのやつをテンプレにして作れるかな。

以上、参考まで。