Railsアプリと技術ブログにGDPRコンプライアンスを追加する(翻訳)

概要

原著者の許諾を得て翻訳・公開いたします。

画像は元記事の引用です。

参考: EU一般データ保護規則 - Wikipedia

Railsアプリと技術ブログにGDPRコンプライアンスを追加する(翻訳)

GDPR EU規則を表すハンマー

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のログインボタンの隣にチェックボックスを追加しました。ユーザーはログイン前に利用規約を受諾することが求められます。

PaddleのAbotチェックアウトフォーム

月毎のサブスクリプション支払い

Abotでは2週間の試用期間終了後にサブスクリプションベースの支払いが行われます。支払いのプロバイダはPaddleを使っており、ここはGDPRコンプライアンスのチェックアウトフォームを用意しています。

Paddleからのマーケティング情報送信をユーザーが許可する場合はオプションでチェックボックスをオンにできます。私のメーリングリストではこの属性を元に扱いを分けています。

GDPR regulations meme funny

Paddleのチェックアウトフォームでは、マーケティングの許諾を明示的に選択できます。

ブログのメーリングリスト

このブログのメーリングリスト構築にはMailchimpを使っています。ここが提供しているGDPRコンプライアンスフォームは、ユーザーからのマーケティング情報収集をオプションで許可します。Paddleの場合と同様、許諾があったかどうかに応じてユーザーの扱いを分け、適切にメールを送信しています。

GDPR regulations meme funny

Mailchimpでは、従来の登録ユーザー向けにGDPR許諾メールのテンプレートを提供しています。これを使って、マーケティングの許諾やサブスクリプションの解除の設定更新をユーザーに行ってもらうことができます。

Mailchimp GDPR consent email

皆さんもおそらくこうしたメールをいくつも受け取っていることでしょう。

まとめ

GDPRコンプライアンスを私のすべてのプロジェクトに追加する作業はまだ終わっていません。何しろ一人でやってるので少々面倒ではあります。皆さんにご紹介した私の施策にGDPR関連の重大な抜け穴がありましたら、ぜひ修正方法をお知らせください。

関連記事

RailsのCSRF保護を詳しく調べてみた(翻訳)

Ruby製Webアプリのcookie-onlyセッション破損でセキュリティリスクの可能性(翻訳)

デザインも頼めるシステム開発会社をお探しならBPS株式会社までどうぞ 開発エンジニア積極採用中です! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版の半分ほど、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れてそれぞれ一部を翻訳。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好き。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。

hachi8833の書いた記事

週刊Railsウォッチ

インフラ

ActiveSupport探訪シリーズ