EU一般データ保護規則(GDPR)への対応に向けたやるべき事まとめ
EU一般データ保護規則(GDPR)への対応に向けたやるべき事まとめ
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
で、良さそうな記事を見つけた：
自分のようなウェブサービス業者がやらなければならない事が具体的に分かりやすくまとまっている。これを書いた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パーセント
桁がすごい。破産確実。
以降よりやるべきことを列挙する。
ユーザがアカウントを削除する際、 deleted フラグを付けたりするだけでは足りない。全ての個人情報をデータベースその他サードパーティー製サービスから抹消しなければならない。
データベースの都合上Foreign Key制約で削除できない場合は、nullableにするとかで対処する必要がある。または関連データを全削除。
クレジットカード情報や購入履歴なども削除。IPアドレスも忘れずに。
自サービスのデータベースを削除するだけでは足りない。サードパーティーのSaaSなどを経由して格納した個人情報も削除義務の対象となる。例えば、Salesforce, Hubspot, twitter, Mixpanel, Stripeなど。APIを使って削除する。
当然、AWS S3などにアップロードしたファイルなどもユーザに関連するものは全て削除する必要がある。
Googleは検索結果から削除する方法をAPIで提供していない。この場合、対象のページで404を返すようにする。
管理ツールなどでユーザ一覧表示する機能があれば、ユーザの設定画面などに ”Restrict processing” ボタンが無ければならない。ユーザがもし望めば、バックオフィス担当者が管理ツールを経由して個人情報にアクセスするのを制限できるようにする必要がある。
これは、むやみやたらとアクセス権限を担当者に与えないようにするためのルールだと思われる。自分の場合管理者は自分しかいないので、無視してよさそう。
ユーザがサービスに格納された自分に関わるデータを全て受け取れるようにする必要がある。これは通常 “forget me”で削除されるデータを指すが、例えば購入履歴なども範囲に含まれるだろう。
自分のサービスには既にノートのデータを全エクスポートする機能があるのでカバーしているはず。ユーザ情報はアカウントページで見れるし。
明白なルールだが、たまに許可されていない。ユーザに関わるプロフィールのデータは原則変更可能でなければならない。
“I accept the terms and conditions”だけでは足りない。それぞれのデータ処理に対して個別のチェックボックスが、ユーザ登録画面やプロフィール画面に設けられなければならない。チェックボックスに最初からチェックを入れるのは禁止。
例えばアプリでのユーザ行動をトラッキングする事は割とよくやられているが、事前に明示的に許可を取る必要がある。何をどのように取ってどこに保存するのかも、プライバシーポリシーなどに明記する。
機械学習などで集めるデータについても許可を得る必要がある。ただし、科学研究の目的は例外。
これは”Export data”の項と似ているが、JSON,XMLなどの機械的なフォーマットというよりは、UIで閲覧できる機能を指す。この機能は「必須(mandatory)」ではないが、「望ましい(desirable)」。
例えばGoogle Mapsはロケーション履歴を表示出来たりする。
最小限の対処法としては、Email通知がある。何かデータを受け取ったらユーザにメールする。メールにはそのデータが何に使われるのかを記す。
ユーザが16歳未満の場合は親の同意が必要となる。親の確認フローはルールに設けられていないが、メール経由などが考えられる。
自分のサービスは大人向けなので、16歳以上を確認するチェックボックスをユーザ登録時に設ければよさげ。
もしデータを特定の目的で使用したなら、必要なくなり次第それを削除するか匿名化しなければならない。例えば、eコマースサイトで「ユーザ登録せずに商品を購入する」機能で取り扱った情報などは、取引を行っている間しか必要ないのでcronなどで定期的に削除される必要がある。
Cookieの取り扱いはGDPRでも変更が加えられているのではっきりしない。Bozho氏の関連記事を参照：
以上が主要な「すべきことリスト」だ。
これ以外にも、法律によって要求される必須事項ではないが、ベストプラクティスとして推奨されるものが挙げられる。
- 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のやつをテンプレにして作れるかな。
以上、参考まで。
