GDPRでは、アプリケーションログファイルにメールアドレスを表示できますか？
ユーザーの操作に完全に基づいて構築されたアプリケーションに取り組んでいます。私のアプリケーションログでは、各対話を記録し、電子メールアドレスを印刷して、どのユーザーがどの対話を行ったかを一意に識別します。
このアプリケーションログは、次のユーザー以外には表示されません。
- わたし
- プロジェクトを販売する場合のアプリケーションの次の所有者
- ワークロードが大きくなりすぎた場合に雇う可能性のある管理者
ログレコードの例は次のようなものです。
2019-01-24 14：27：20.954 INFO 32256 --- [whatever-info] s.p.s.t.d.m.s.SomeClassThatPrintsTheLog：メールアドレス[email protected]でユーザーを登録しています。
これはGDPRの下で許可されますか、それとも印刷された電子メールアドレスを何らかの方法でマスクする必要がありますか？または別のソリューションを使用しますか？
GDPRの目標は、個人を特定できる情報（PII）を可能な限り保護することです。特定のユーザーとアプリケーションとの相互作用は、そのようなPIIであると確信しています。
この情報を本当にログに記録する必要がある場合は、ユーザーにこのプロセス、つまりデータ収集の目的、情報が保存される期間、データへのアクセス権を誰に与えるかを通知する必要があります。また、あなたやあなたがアプリケーションを販売する人は誰でも、ユーザーが同意した他の目的でデータを使用してはなりません。そしてもちろん、情報を誤用から適切に保護する必要があります。つまり、指定された目的以外で使用します。具体的には、誰かがアプリケーションまたはサーバーにハッキングしてこのデータを盗んだ場合も含まれます。
データの使用が制限され、保護（および罰金）が高額になる可能性があるため、これらの情報を最初から保存しない方が簡単な場合があります。もう1つの方法は、少なくともPIIを可能な限り仮名化することです。つまり、ログに記録されたデータは引き続き使用できますが、すべてのログに記録されたデータがある場合でも、特定のユーザーへの関連付けを行うことはできません。しかし、これらのログを何に使用するかは明確ではないため、そのような仮名化の特定のプロセスに対して推奨を行うことはできません。
ただし、各一意の電子メールアドレスを別の一意の識別子に単に置き換えるだけでは、十分な仮名化ができない場合があることに注意してください。ログに記録するデータによっては、ユーザープロファイルを作成し、プロファイル内の特定の特性に基づいて、これらを実際のユーザーに関連付けることができます。このような単純な仮名化の試みがうまくいかなかった例については、 AOL検索データのリーク を参照してください。
GDPRでは、データのロギングは問題ではありません。重要なのは、ログがどうなるか、誰が見ることができるか、どのくらいの期間保存されているか、どのようにログが使用されているか、そしてデータを処理して保存した後にデータ主体の権利を満足できるかどうかです。
サービスを提供するためにメールをログに記録する必要がある場合、それをログに記録しても問題はありません。ただし、データをログに記録する場合は、最初から自分自身とデータのサブジェクトの両方について非常に明確にする必要があります。
GDPRの第5条は、データを処理するための基本原則を規定しています。
第5条「個人データの処理に関する原則」
（1）個人データは次のとおりです。
...（b）特定の明示的かつ合法的な目的で収集され、それ以上処理されないこれらの目的と互換性のない方法で公益、科学的または歴史的研究目的でのアーカイブ目的のためのさらなる処理または統計上の目的は、第89条（1）に従い、当初の目的（「目的の制限」）と互換性がないと見なされないものとします。
アプリケーションの問題を診断する目的で個人情報ログファイルを保存することは、元の目的と互換性がありませんが、「適切な技術および組織的対策...リスクに応じて」。
ただし、ログを永久に保存しないでください。例えば。データ主体（個人のGDPR用語）には、忘れられる権利があります。つまり、最終的にはログやバックアップなどから削除する必要があるということです。過去90日間データを保持していれば、問題ないはずです。
最後に、EU市民に関する個人情報を処理するシステムを構築している場合は、この問題について1〜2日間のコースを受講して、コントローラー、プロセッサー、データ主体、個人情報との違いを学ぶことを強くお勧めします。機密個人情報など.
これは、GDPRからの引用です（強調が追加されています）。
リサイタル78：
個人データの処理に関する自然人の権利と自由の保護には、この規則の要件が確実に満たされるように適切な技術的および組織的対策が必要です。この規制の遵守を実証できるようにするために、管理者は内部ポリシーを採用し、特に設計によるデータ保護およびデフォルトでのデータ保護の原則を満たす措置を実施する必要があります。このような措置は、とりわけ、処理を最小限に抑える個人データの個人データの偽名化できるだけ早く、個人データの機能と処理に関する透明性で構成されます。データ主体がデータ処理を監視できるようにし、コントローラーがセキュリティ機能を作成および改善するできるようにします。
第25条（設計およびデフォルトによるデータ保護）、パラグラフ1：
技術の現状、実装のコスト、処理の性質、範囲、状況、目的、および処理によってもたらされる自然人の権利と自由に対するさまざまな可能性と重大性のリスクを考慮に入れて、管理者は、処理手段の決定時と処理自体の時点の両方で、pseudonymizationなどの適切な技術的および組織的対策を実装します。 データ保護原則を効果的に実装し、必要なsafeguardsを処理に統合して、この規則の要件を満たし、データ主体の権利。
これは何を意味するのでしょうか？メールアドレスをログに含める正当な理由がない場合は、おそらくそれを行うべきではありません。代わりに、より高いレベルの仮名化を持つユーザーIDをログに記録し、必要に応じてユーザーを特定することもできます。 GDPRに関係なく、IDはおそらくユーザーを一意に識別するためにとにかく適切なものです。なぜなら、ユーザーは常に同じIDを持っていると予想でき、電子メールアドレスは通常変更できるからです。
とは言っても、私は弁護士ではありませんが、すべてが十分に安全に保管および処理されていることを証明できれば、メールアドレスのログ記録にそれほど苦労することはないと思います。一方、適切な設計の選択は、セキュリティとプライバシーのベストプラクティスに従っていること、およびユーザーの個人データを不必要に処理してユーザーのデータを危険にさらしていないことを実証するのに役立ちます。