デザインによるプライバシー

デザインによるプライバシー（GDPR）

1）それは何についてであり、なぜですか

Privacy by Design （PbD）は、ビジネス要件、アーキテクチャ、コード、プロセス、操作など、最初から製品にプライバシーが埋め込まれている原則です。GDPRに関しては、これは「設計とデフォルトによるプライバシー」（手数料を最小限に抑え、デフォルト設定は可能な限りプライベートで、透明性と説明責任）で示されています。

• 個人データ（PD）の収集と処理を最小限に抑えます。
• 合法性、透明性、正確性、目標と期限の制限を確保します。
• リスク（技術的および法的）を軽減し、監査を簡素化し、コンプライアンスを証明します。

2） GDPRの役割、法的枠組み、原則

2.1つの役割

Controller-処理の目標/手段を定義します。
プロセッサ-DPA契約の下でコントローラに代わって個人データを処理します。
データ主体：個人データが所属する個人。
DPO（データ保護責任者）：オンデマンド-独立した監視と相談。

2.2法的根拠（選択および文書）

同意、契約、正当な利益、法的義務、重要な利益、公共の仕事。それぞれ-目標、データ、保持、失効（同意のため）。

2.3処理の原則（Art。 5）

合法性、公平性、透明性

目標の制限

データの最小化

正確さ（Accuracy）

ストレージの制限

完全性と機密性

説明責任-コンプライアンスを証明する能力。

3） SDLCにおけるPbDプロセス（参照フレームワーク）

1.開始：処理目標と法的根拠の策定、データおよびDPOポイントの所有者の割り当て。
2.データのマッピング（データマッピング）：ソース→フィールド→機密モデル→flow→who reads→where are stored→term。
3.リスクアセスメント/DPIA：プライバシーの脅威、影響評価、緩和措置のLINDDUNモデル。
4.アーキテクチャソリューション：最小化、仮名化、暗号化、区別スキームの選択。
5.UX/同意/通知の要件：クリアテキスト、詳細な同意、デフォルト設定。
6.実装：プライベートデフォルト、セキュアテレメトリ、シークレットフリーロギング/PII。
7.検証：プライバシーテスト、静的分析、プライベートユニットテスト、DPIAプロトコル。
8.操作：DSARプロセス、保持と廃棄、インシデント監視、ベンダーのレビュー。
9.定期的なレビュー：目標/技術を変更する際の再DPIA。

4）エンジニアリングPbDパターン

4.1最小化と分解

必要なフィールドのみを収集します。プログレッシブプロファイリングを適用します。
別々のIDとコンテンツ：リンクキーを別々に保存します（トークン/参照）。

4.2エイリアシングと匿名化

Aliasing-実際のIDを別々に保存します。作業レイヤーにはトークンが表示されます。
匿名化：k-anonymity、 l-diversity、 t-closureを使用する。analytics-差分プライバシー（ε -budget）。

4.3アクセス制御および役割の分離

PoLP、 ABAC/RBAC、職務の分離、管理者とアナリストのための個別の輪郭。
それは……対策：mTLS、 SSO/OIDC、スコープトークン、個人データへのアクセスのための一時的なアカウント。

4.4暗号化と分離

Transit： TLS 1。3/mTLS；残りで：AEAD/Envelope+KMS/HSM。
テナント/データセットのキーを分離します。「忘れられる権利」のための暗号削除。

4.5保持および取り外し

フィールド/目標ごとの明示的なTTLポリシー;パイプラインの自動パージ；「2相」削除（論理→物理）。
バックアップの場合-個人用スナップショットのキーと短いストレージウィンドウを分離します。

4.6プライベートテレメトリとロギング

デフォルトはPIIではありません。塩でトークン/ハッシュを使用します。
プロデューサーの機密フィールドのマスキング/トークン化。

4.7 UXプライバシーと同意

カテゴリー別の詳細な同意（分析、マーケティング、パーソナライゼーション）。
「プライベートデフォルト」：すべてが重要ではありません-同意するまでオフにします。
新しい使用時に「同意を撤回」とジャストインタイム通知オプションをクリアします。

5） DPIAおよびLINDDUN（短い）

DPIA （Data Protection Impact Assessment）：高リスク（大規模監視、評価、新技術）で要求される。これは、処理、必要性/比例、リスク評価、緩和措置の説明で構成されています。
LINDDUN：リンク性、識別可能性、否認防止、検出可能性、情報の開示、無意識、非コンプライアンス。各脅威-対策（最小化、仮名化、DP、透明性、同意管理、監査）。

6）国境を越えた移動

ベンダーのストレージ/アクセス場所を特定します。
SCC（標準契約条項）を使用し、移転影響評価を実施します。
技術的対策：エンドツーエンドの暗号化、特に機密データのためのクライアント暗号化、リモートアクセスの制限。

7）ベンダーおよびプロセッサ（ベンダー管理）

DPA/ネストされたプロセッサ、技術的および組織的措置、サブプロセッサ-制御下。
定期的なレビューと監査；点検する権利；データのエクスポート計画。

8）データ主体権（DSAR）

アクセス、修正、削除、制限、移植性、異議、AADM（プロファイリング/オートメーション）オブジェクトではありません。
SLAとオートメーション：リクエストトラッキング、識別証明、レスポンスログ。
プロダクトの技術的なホック：IDによる速い調査そして輸出；保持によるカスケード除去。

9）自動化された解決およびプロファイリング（Art。 22）

「重大な影響」を伴う決定が自動的に行われた場合-人間の介入への権利を確保するために、説明可能性、兆候の透明性。
ログパスとモデルバージョン;アピールのメカニズム。

10）セキュリティ（32条）とインシデントの処理（33条/34条）

リスク指向の対策：暗号化、整合性、回復力、回復計画（RTO/RPO）。
PDインシデント：→トリアージ検出プロセス→リスクアセスメント→レギュレータの通知≤ 72時間（必要な場合）と被験者（高リスクの場合）。
別々のプレイブック、DPO/弁護士の連絡先リスト、通知テンプレート。

11）プライバシーとML/アナリティクス

データガバナンスセット：データライン、ライセンス/根拠、同意。
テクニック：差分プライバシー、フェデレーション学習、安全な集約、機能の最小化。
攻撃に対する保護：メンバーシップ/モデルの反転-定期的なリーク評価、ε設定、ノイズ/クリップ。
合成データ-唯一の人の復元の不在の検証と。

12）建築図（パターン）

12.1「デュアルループ」IDアーキテクチャ

ループA （PDS-パーソナルデータストア）：実際の識別データ（RID）、アクセス-厳密には、キー/暗号化/監査。
概要B（運用）：トークンを含むビジネスデータ；限界と監査を持つトークンブローカーを通じたコミュニケーション。

12.2同意サービス

同意したバージョンと履歴を保存する集中型サービス。
SDK： 'can_use （category、 purpose）'-即座に解決します。すべてが記録されています。

12.3コードとしての保持ポリシー

YAML設定-エンティティ→フィールド→TTL→有効期限アクション（Anonymize/Delete/Coarse）。
スケジューラはジョブを実行し、レポートはDPOで利用できます。

13）ミニレシピ

def collect(field, purpose):
if not is_required(field, purpose):
return None # do not collect v = read_input (field)
return truncate(v, policy. max_length(field))

yaml dataset: users fields:
email: { ttl: P18M, on_expire: pseudonymize }
phone: { ttl: P12M, on_expire: delete }
session_logs: { ttl: P3M, on_expire: aggregate }
consent: { ttl: P7Y, on_expire: archive }

analytics:
default: deny legal_basis: consent scope: anonymous_metrics marketing:
default: deny legal_basis: consent scope: email,push

GET /privacy/export? subject_id=... -> zip:
- profile. json (metadata, legal basis)
- activity. ndjson (events, aggregates)
- consents. json (consent history)
- processors. json (list of processors and transfers)

14）ドキュメントと説明責任

ROPA（処理活動の記録）-業務の登録：目的、法的根拠、データ/主題のカテゴリ、転送、保持期間、対策。
ポリシー：プライバシー、クッキー、製品内の情報通知（平易な言語で）。
スタッフのトレーニングと年間レビュー。

15）頻繁なエラー

コレクション「念のために」とストレージ「永遠に」。
契約/正当な利益は適切ですが、唯一の根拠としての同意。
実際のスイッチなしで「空の」クッキーバナー。
データマッピングがなく、DSARの準備ができていません。
PII、保護されていないバックアップ、REEDと運用データの混在でログを記録します。
サプライヤーとクロスボーダー転送の制御はありません。

16）チェックリスト

• 処理の目的および法的根拠が決定される。ROPAによって更新されました。
• データマッピングとDPIAを実行しました（必要に応じて）。
• 最小化、エイリアス、暗号化（途中/残り）を実装。
• 同意は、明確なUXで、粒状です。デフォルトは非公開です。
• 保存ポリシーをコードとして設定していること。削除/匿名化がチェックされました。
• ログ/テレメトリー-PIIなし；マスキングが有効になっています。
• DSARフックと輸出準備。
• チームトレーニングとDPO承認が完了しました。

• 四半期ごとの再検討と法的根拠。
• 定期的なプロセッサ/サブプロセッサ監査。
• インシデントの監視と72時間≤の通知の準備。
• プロセス/技術の変更に伴うDPIAの改訂。
• コンプライアンス成果物（DPIA、 ROPA、テストレポート）の保管).

17） FAQ

Q：同意から完全に「逃げる」ことは可能ですか？
A：時にははい（契約/法的義務/法的利益）が、厳密に必要な場合にのみ、利益のバランスを評価します。マーケティングと非クリティカル分析-ほとんどの場合、同意が必要です。

Q：エイリアシングは十分ですか？
A：いいえ、それはまだ個人データです。GDPRスフィアを終了するには、信頼性の高い匿名化（再同定が不可能であることを確認）が必要です。

Q： MLとパーソナライゼーションはどうですか？
A：機能を最小限に抑え、DP/フェデレーションアプローチを使用し、意思決定をログ化し、人間の介入とプロファイリング以外の権利を確保します。

Q：ビジネスとプライバシーの競合時に何をすべきか？
A：コレクション（プログレッシブプロファイリング）を再設計し、集計/合成に切り替え、法的根拠を再評価し、追跡することなくオプションを提供します。

• 「秘密管理」
• 「At Rest Encryption」
• 「In Transit Encryption」
• 「監査ログと不変ログ」
• 「Sign and Verify Requests」
• 「キー管理とローテーション」