概要
原著者の許諾を得て翻訳・公開いたします。
- 英語記事: Adding GDPR Compliance to My Rails App and Technical Blog
- 原文公開日: 2018/05/14
- 著者: Paweł Urbanek
画像は元記事の引用です。
Railsアプリと技術ブログにGDPRコンプライアンスを追加する（翻訳）
EU一般データ保護規則（GDPR EU）が後2週間もしないうちに施行されます。本記事では、私が自分のRails SaaSアプリに加えたGDPRコンプライアンス対応とこのブログ自身について解説します。
アプリは、たとえEU圏内に配置されていないとしてもこの新しい規則に準拠しなければなりません。アプリにヨーロッパのユーザーがいれば該当します。
免責事項: 私は法律の専門家ではありません。また本記事は法的な助言に基づいたものではありません。
GDPRコンプライアンスが必要なもの
GDPRでは、いわゆる個人識別情報（PII: Personally Identifiable Information）を問題にします。これは、ユーザーの身元を直接または間接的に特定できるあらゆる情報断片です。
自分のアプリ群を監査した結果、これらのアプリが収集する以下のデータ片がPIIに類別され、対応すべき対象であることが判明しました。
- アプリケーションログに保存されているIPアドレス
- Google Analyticsが集めるIPアドレス
- メーリングリスト登録者のメールアドレス
- Abotサブスクリプション購入者のメールアドレス
私の取った対応をデータの種類ごとに説明します。
ログとGDPR
NGINXログのローテーション
NGINXのアクセスログにはユーザーのIPアドレスが含まれます。規則によると、これはユーザーの特定に利用可能な情報断片となるため、保護および不要時の削除を行うべきです。
新しい規則に準拠するため、ユーザーのIPアドレスがメンテナンス目的で収集及び保存される旨を周知する情報をAbotのプライバシーポリシーに追加しました。
アクセスログは、アプリで問題が生じた場合の調査が行えるよう、2週間保存することにしました。14日経過したNGINXログを自動的に削除するため、VPSサーバーの/etc/crontabファイルに以下を追加しました。
@daily root find '/var/log/nginx/' -mtime +14 -type f -delete
アクセスログの保存期間は個別のユースケースによります。新しい規則では「正しい保持期間」というものは指定されていません。
NGINXアクセスログの匿名化
NGINXアクセスログの匿名化（anonymize）をオプションとして検討してもよいでしょう。これを確かめるためにGDPR侵害の罰金2百万ユーロを費やすつもりはありませんが、IPアドレスを含まないログが個人識別情報と解釈されることはなくなるでしょう。
アクセスログからユーザーのIPアドレスを削除するために、http設定コンテキストで以下のNGINXディレクティブを使えます。
log_format anonymized '127.0.0.1 - [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" $request_time';
access_log /var/log/nginx/access.log anonymized;
Railsアプリのログ
標準のアプリケーションログには、ユーザーを特定できる情報が含まれている可能性があります。
Railsアプリの場合、イニシャライザファイルを1つ追加することでアプリケーションログに含まれる内容を制限できます。
config/initializers/filter_parameter_logging.rb
Rails.application.config.filter_parameters += %i(
password text
user_name user_id
token payload
)
明らかに、ログの利便性と匿名化は常にトレードオフの関係にあります。
Railsのアプリケーションログのストレージの場所は、インフラの設定に依存します。私はDokkuを使っており、この場合ログは次のパスに保存されます。
/var/lib/docker/containers/[CONTAINER_ID]
このCONTAINER_IDを取得するには、以下のコマンドを実行しなければなりません。
dokku ps
特定のユースケースでログをより長期間保存する必要が生じている場合、おそらくログをAmazon S3バケットにエクスポートしていることでしょう。この場合、バケットがEU圏内のAWSデータセンターに配置されているかどうかをダブルチェックしましょう。GDPRではEU圏内に配置されているサーバーをよりセキュアなものとして取り扱います。バケットの内容が暗号化されていることも確認しておきましょう。
なお、詳しくは別記事「AWS S3バケットをよりセキュアに動かす方法」でもご覧いただけます。
Google AnalyticsのプライバシーとGDPR
Google Analyticsのデフォルト設定ではユーザーのIPアドレスが含まれます。Google Analyticsトラッキングのプライバシーをより高めるには、以下のコードを追加します。
ga('set', 'anonymizeIp', true);
これによりリクエストのIPが匿名化され、ユーザーを特定できなくなります。この設定を追加すると、分析データの地理情報の精度が落ちることもお忘れなく。
静的なランディングページ
私のiOSアプリ向けに、ランディングページ（LP）でGoogle Analyticsを使い続けています。
これらのサイトでのユーザートラッキングは私にとってほとんど価値がないので、すべて取り外すことに決めました。トラッキングコードを削除し、Google Analyticsのパネルでデータの削除をスケジューリングしました。この程度の静的ページのために規約やポリシーを追加する必要は感じられません。
このブログとAbotのランディングページ
このブログや、Rails SaaS製品であるAbotのランディングページのトラフィックは引き続きトラッキングしたいと考えています。そのため、Abotの利用規約とプライバシーポリシーの変更と、このブログへの利用規約の追加が必要になりました。
どの情報がどこに保存されているかという正確な情報を追加し、ユーザーが自分のデータをすべて削除するリクエストを出せる連絡先についても利用規約に記載しました。Slackチームからbot統合を削除したチーム向けに、Abotにデータの自動削除も追加しました。
ブログやAbotに保存されている個人データはさほど複雑ではありません。より高度なソフトウェアプロジェクトではどうなるかについては、Konfeoオンラインイベント登録システムの規約をご覧いただくとよいでしょう。
利用規約の明示的または暗黙の受諾について
GDPRによる重大な変更点は、有効なプライバシー規約を用意するだけでは不十分だという点です。ユーザーは規約を明示的に受諾しなくてはなりません。たとえば、受諾のチェックボックスは事前に選択済みにしてはならず、ユーザー自身の操作でチェックボックスをオンにしなければなりません。
JavaScriptをちょっぴり使って、Abotのログインボタンの隣にチェックボックスを追加しました。ユーザーはログイン前に利用規約を受諾することが求められます。
月毎のサブスクリプション支払い
Abotでは2週間の試用期間終了後にサブスクリプションベースの支払いが行われます。支払いのプロバイダはPaddleを使っており、ここはGDPRコンプライアンスのチェックアウトフォームを用意しています。
Paddleからのマーケティング情報送信をユーザーが許可する場合はオプションでチェックボックスをオンにできます。私のメーリングリストではこの属性を元に扱いを分けています。
Paddleのチェックアウトフォームでは、マーケティングの許諾を明示的に選択できます。
ブログのメーリングリスト
このブログのメーリングリスト構築にはMailchimpを使っています。ここが提供しているGDPRコンプライアンスフォームは、ユーザーからのマーケティング情報収集をオプションで許可します。Paddleの場合と同様、許諾があったかどうかに応じてユーザーの扱いを分け、適切にメールを送信しています。
Mailchimpでは、従来の登録ユーザー向けにGDPR許諾メールのテンプレートを提供しています。これを使って、マーケティングの許諾やサブスクリプションの解除の設定更新をユーザーに行ってもらうことができます。
皆さんもおそらくこうしたメールをいくつも受け取っていることでしょう。
— I Am Devloper (@iamdevloper) May 3, 2018
まとめ
GDPRコンプライアンスを私のすべてのプロジェクトに追加する作業はまだ終わっていません。何しろ一人でやってるので少々面倒ではあります。皆さんにご紹介した私の施策にGDPR関連の重大な抜け穴がありましたら、ぜひ修正方法をお知らせください。