privacy-engineering

プライバシーエンジニアリング — GDPR / CCPA の技術的な実装

コード、データ、インフラストラクチャの各層にプライバシー管理を実装します。このスキルは、法令遵守を装うためのものではありません。法的要件を、掲げたとおりに実際に機能するシステムへと変えるエンジニアリング作業です。

プライバシーとセキュリティには重なる部分がありますが、同じものではありません。セキュリティは不正アクセスから保護し、プライバシーは正当な権限があっても不適切な利用から保護します。すべてのキーストロークを記録し、そのログをベンダーと共有する、完全に安全なシステムは、プライバシーの観点では大惨事です。このスキルでは、その違いのうちプライバシー側を扱います。

相互参照：セキュリティ側については owasp-audit、個人データへのアクセス制御については iam-audit、認証情報の取り扱いについては secrets-audit、プライバシー侵害発生時の対応については incident-triage（GDPR の72時間以内の通知期限は、調査を終えた時点ではなく、侵害を把握した時点で始まります）、顧客への開示文案については security-comms を参照してください。

権限

ユーザーの組織が所有するシステム、またはレビューを依頼されたシステムを確認してください。実際の個人データを取得せずに、スキーマ、コード、設定、合成レコードを通じてデータフローを追跡してください。本来あるべきでない場所に個人データを見つけた場合は、値をコピーせず、その場所とカテゴリを記録してください。法的判断（適法な根拠や、侵害に通知義務があるかどうか）は、DPO と法律顧問が行います。

規制の概要（エンジニアリングに関連する範囲）

このスキルでは、規制に準拠した技術実装を作成します。最終的なコンプライアンス判断は法律顧問が行い、このスキルは技術的な実行レイヤーを担います。

規制	適用範囲	主なエンジニアリング上の要点
GDPR（EU）	EU／EEA 居住者の個人データを処理するすべてのケース	第5条（原則）、第6条（適法な根拠）、第7条（同意）、第15～22条（データ主体の権利）、第25条（プライバシー・バイ・デザイン）、第30条（処理記録）、第32条（セキュリティ）、第33条（侵害通知 — 72時間以内）、第35条（DPIA）
CCPA / CPRA（カリフォルニア州）	基準値を超えるカリフォルニア州居住者のデータを処理する企業	知る権利、削除、訂正、販売／共有のオプトアウト。機微な個人情報（PI）のカテゴリ。年次プライバシー通知。サービスプロバイダーとの契約
LGPD（ブラジル）	ブラジル居住者	GDPR に似た枠組みですが、地域固有の違いがあります
PIPEDA（カナダ）	連邦レベルの商業活動	合理的な期待に基づく同意、侵害通知
州法（米国）	州によって異なります — VA、CO、CT、UT など	おおむね CCPA に似ています。通常、GDPR と CCPA を満たすエンジニアリング慣行で州法にも対応できます

エンジニアリングの実情：適用される最も厳しい規制に合わせて構築し、それ以外は気にしないようにします。ほとんどの側面で GDPR が最も厳しく、CCPA は「販売／共有のオプトアウト」と機微な PI のカテゴリを追加します。

プライバシー・バイ・デザイン — エンジニアリングの実践

プラクティス 1：データの分類

分類されていないデータのプライバシーは徹底できません。すべてのデータストアに分類が必要です。

最低限の分類（これ以上は構いませんが、これ未満にはできません）：

クラス	定義	エンジニアリング上の取り扱い
公開	公開済み、または自由に共有できる情報	特別な取り扱いは不要
内部	PI を含まない社内業務データ	標準的なアクセス制御
個人	自然人を特定するデータ（メールアドレス、氏名、IP、デバイス ID、アカウント ID）	アクセスログの記録、保持期間の制限、削除手段
機微な個人データ	GDPR 第 9 条の特別カテゴリ（健康、生体情報、政治的見解、性的指向、人種、宗教）、CCPA SPI（正確な位置情報、人種、宗教、生体情報、遺伝情報、性生活、郵便物の内容、政府発行の ID、金融口座、市民権、労働組合への加入）	より厳格なアクセス制御（知る必要がある場合に限定）、別個の KMS キーによる保存時の暗号化、読み取りごとの監査
規制対象	HIPAA に基づく PHI、PCI のカード会員データ、GLBA に基づく NPI	規制ごとの制御。この範囲では対象外です。hipaa-audit と pci-audit を参照してください

**監査手順：**各データストア（データベース、S3 バケット、BigQuery データセットなど）について、分類が文書化され、実際のデータと一致していることを確認します。「内部」から始まった多くのシステムは、誰かがメールアドレスの列を追加したことで、いつの間にか「個人」になります。

プラクティス 2：データの最小化

サービスの提供に必要な最小限のデータを収集し、価値の提供に必要な最小限の期間だけ保持し、ベンダーと共有するデータを最小限にします。

よくある最小化の指摘事項：

• レート制限にしか使わないのに、すべてのリクエストで IP アドレスを記録している（レート制限の判定後に /24 まで切り詰める）
• デバイスの種類だけが必要なのに、ユーザーエージェント全体を保存している（切り詰める）
• 「13 歳以上／18 歳以上／21 歳以上」の判定だけでよいのに、年齢確認のために生年月日を収集している（日付ではなく真偽値を保存する）
• 「任意」の通知のために電話番号を収集し、オプトアウト後も保持している
• 運用上必要な期間を何年も過ぎた後もバックアップデータを保持している
• 注文 ID／ユーザー ID を含む完全な URL パスを分析プラットフォームに送信している

監査用 grep パターン：

• DB スキーマ内の個人データの列名：email、phone、name、address、ssn、dob、birth、gender、ip、user_agent、device_id、ip_address
• これらを出力するログ記録文：log\..*\$\{user\.email\}、console\.log\(.*user\.、logger\.info\(.*email
• 必要以上のデータを送信する分析連携：analytics\.identify\(.*email、ページ全体の URL パラメーター

プラクティス 3：適法な根拠（GDPR）／利用目的（CCPA）

すべての処理活動について、GDPR 第 6 条に基づく適法な根拠を文書化する必要があります。CCPA では、利用目的の開示が求められます。

一般的な根拠と適用されるケース：

• 契約（第 6 条 1 項 (b)） — ユーザーが登録したサービスを提供するために必要な場合
• 同意（第 6 条 1 項 (a)） — オプトインであり、自由意思に基づき、具体的かつ十分な情報に基づいたもので、撤回可能であること。求められる基準は高く、機微なデータでは特に厳格です（第 9 条では、適法な根拠に加えて明示的な同意が必要です）
• 正当な利益（第 6 条 1 項 (f)） — セキュリティ、不正防止、社内分析などに用いる包括的な根拠です。どこかに文書化された利益衡量テストが必要です
• 法的義務、重大な利益、公的任務 — 適用範囲は限定的です

**エンジニアリングへの組み込み：**アプリケーションは、適法な根拠とともにすべての処理活動を記録します（data_processing_log または同等のものに挿入します）。DSAR が届いたとき、開示すべき情報を確認するための信頼できる情報源になります。

実践 4：同意管理

同意は、プライバシーにおいて最も過剰に複雑化されている一方で、最も整備が不十分な部分です。重要なのは、シンプルで証明可能な状態を保つことです。

同意記録：

• ユーザー ID（認証前の場合はデバイス ID）
• 具体的な目的（マーケティングメール ≠ プロダクト分析 ≠ サードパーティ広告）
• タイムスタンプ
• 表示した同意文のバージョン
• 取得元（フォーム／バナー／API のいずれか）
• 同意したか、拒否したか
• 同意を撤回した場合は撤回のタイムスタンプ

同意の撤回は、同意するのと同じくらい簡単でなければなりません（GDPR 第 7 条 3 項）。Cookie バナーで「すべて承諾」がワンクリックなら、「すべて拒否」もワンクリックでなければなりません。拒否するために 5 つのパネルをたどらなければならないバナーは、法令に準拠していません。

よくある監査指摘：

• ユーザーがクリックする前にトラッキングスクリプトを読み込む Cookie バナー
• 必須ではない Cookie のデフォルトとして設定された「正当な利益」
• 同意のタイムスタンプが保存されていないため、アプリが同意をいつ（または同意があったかどうか）取得したのか証明できない
• マーケティングへの同意を利用規約への同意と一括りにしている（同意は具体的でなければなりません）
• ユーザーが同意履歴を確認したり、同意を撤回したりする手段がない

実践 5：データ主体の権利（DSAR パイプライン）

ユーザーは GDPR 第 15～22 条および CCPA に基づく権利を有します。技術的な実装では、しばしば同じ箇所で問題が発生します。

アクセス権（第 15 条／CCPA の「知る権利」）： ユーザーは、自身について保有されている個人データのコピーを受け取ります。実装方法：

• ユーザー ID に紐付く個人データを含むすべてのデータストアを列挙する
• 要求に応じて、各ストアからデータを取得する
• 機械可読な形式（JSON／CSV）でエクスポートする
• 開示前に本人確認を行う — 確認の基準はデータの機微性に応じたものでなければならず、「登録済みのメールアドレスにメールを送った」だけでは不十分です
• 30 日以内に提供（GDPR）／45 日以内に提供（CCPA）

削除権（第 17 条／CCPA の「削除する権利」）： ユーザーはデータを削除してもらえます。技術的な実態は、見た目よりも複雑です。

• プライマリデータベース： DELETE または保持期間付きのソフト削除で対応できます
• レプリカ／スタンバイ： レプリケーションが反映されたことを確認するか、削除をスケジュールします
• バックアップ： 保持期間があるため、期限が切れるまでバックアップには削除済みデータが残り続けます。保持期間を文書化し、復元のたびに再削除する場合、GDPR 上は問題ありません
• キャッシュ： Redis、CDN、アプリケーションレベルのキャッシュは削除時に無効化します
• 検索インデックス： Elasticsearch／Algolia／Meilisearch は再インデックスします。ソースを削除するだけでは不十分です
• 分析： Mixpanel、Amplitude、Segment、GA は、ベンダーごとに異なる削除 API を使用します
• データウェアハウス： BigQuery／Snowflake／Redshift には別のパイプラインが必要です。通常はバッチ処理になります
• ログ： ユーザーの PII を含むアプリケーションログは、保持期間の経過とともに削除されます。ログの保持期間が、ユーザーが合理的に想定する期間より短いことを確認してください
• サードパーティ／サブプロセッサー： お客様に代わって個人データを処理するすべてのベンダーに対し、削除を一斉に伝播させる仕組みが必要です

監査時の grep パターン：

• PII の流出箇所を検索します：analytics\.track、segment\.identify、sentry\.setUser、mixpanel\.people\.set、datadog.*user、posthog\.identify
• ベンダー SDK の初期化箇所を検索します：Sentry\.init、analytics\.load、LogRocket\.init、FullStory\.init
• それぞれが削除を一斉に伝播させる対象です

データポータビリティ権（第 20 条）： ユーザーが提供したデータを機械可読な形式でエクスポートします。アクセス権とは異なり、対象はユーザーが提供したデータのみで、構造化形式でなければなりません。JSON／CSV で問題ありません。

訂正権（第 16 条／CCPA の「訂正する権利」）： 不正確なデータを更新します。エンジニアリング上の対策：サポートへのメールを必須とせず、訂正手段をプロダクトに組み込んでください。

異議を申し立てる権利（第 21 条）： ダイレクトマーケティングやその他の特定の目的での処理を停止します。エンジニアリング上の対策：処理が行われるすべての箇所で適用される抑止リスト／オプトアウトフラグを用意してください。

監査手順： 実際のユーザーが行う前に、自分のアカウントを使って DSAR を最初から最後までシミュレーションしてください。ほとんどのチームは、初回の試行で問題箇所を見つけます。

プラクティス 6：ベンダー／サブプロセッサー管理

個人データを処理するベンダーはすべてサブプロセッサーです。GDPR では、各ベンダーとのデータ処理契約（DPA）を締結し、ユーザーが確認できるサブプロセッサーの一覧を文書化する必要があります。

エンジニアリング監査：

• ユーザーデータに触れるコードベース内のすべての SaaS／API 連携を洗い出します
• 各連携について、DPA が締結済みであることを確認します（法務に確認できます）
• 各連携について、送信されるデータが必要最小限であることを確認します
• 各連携について、削除 API または削除プロセスがあることを確認します
• 各連携について、データレジデンシー（データの保存場所が EU、米国、その他のどこか）と、越境移転の仕組みが整っていることを確認します（EU 域外への移転には標準契約条項を使用します）

よくある指摘事項：

• Sentry／Datadog／LogRocket／FullStory が、エラーレポートやセッション録画で PII を取得している
• 顧客データに関する議論に Slack を使用している（DM／チャンネルで PII が共有されると、Slack はサブプロセッサーになります）
• 2024 年以前の分析ツールによる越境移転（EU-US データプライバシーフレームワークに基づく米国の十分性認定後も、利用しているベンダーがリストに掲載されていることを確認してください）
• DPA の対象になっていないベンダーへの Webhook 配信

プラクティス 7：侵害の通知

GDPR 第 33 条：個人データ侵害を認識してから 72 時間以内に監督機関へ通知します。第 34 条：侵害によって高いリスクが生じる場合、不当な遅延なく影響を受ける個人に通知します。

エンジニアリング上の対応（このスキルの対象は技術的な検知／範囲特定です。実際の通知は法務が担当します）：

• 検知：個人データの持ち出し／不正アクセスのパターンに対する SIEM ルール（siem-detection を参照）
• 範囲特定：関係したレコード／フィールド／個人を迅速に特定できるようにします（監査ログ、アクセスログ、クエリー履歴）
• 封じ込め：アクセスを取り消し、認証情報をローテーションします（secrets-audit、incident-triage を参照）
• 文書化：認識時点からの時間の計測は、経営陣への報告時ではなく、チームの誰かが認識した時点で始まります。検知から経営陣への報告までの遅延は、72 時間の期限に直接影響します

プラクティス 8：DPIA（データ保護影響評価）

高リスクの処理には必須です（第 35 条）。たとえば、機微データの大規模な処理、体系的な監視、個人に影響を及ぼす自動意思決定が該当します。

DPIA に向けたエンジニアリング側の情報：

• データフロー図（threat-modeling の成果物を再利用します）
• 個人データのカテゴリ
• データ主体のカテゴリ
• 提供先（社内およびベンダー）
• カテゴリごとの保持期間
• セキュリティ対策（owasp-audit、iam-audit、crypto-audit の出力へのリンク）
• リスク評価と軽減策

このスキルはエンジニアリング側の情報を作成します。DPIA 自体は法務／プライバシー担当の顧問が作成します。

検証してから記録する

必須義務に対する不備（ストアの一部を対象外にしている第 17 条の消去経路、同意前に実行されるトラッキング、明示された目的を超えてベンダーに送信される個人データ）は指摘事項です。義務そのものが意図された統制だからです。想定される罰金の額ではなく、個人データにもたらすリスクに基づいて重大度を評価してください。リスクがない不備（処理記録に法的根拠が記載されていない、または文書化されていないものの保持期間が適用されている）は文書化の不備であり、多層防御に関する不備は強化に関するメモです。どちらも findings.json には記載しません。候補をすべて、references/findings-format.md に定義されているとおり、1 つの判定で確定してください。

• confirmed：個人データが流入する箇所から、義務に違反した状態で最終的に行き着く箇所までの追跡であり、その間に制御がない状態です。例：DELETE /accountでusers行を削除しますが、Segmentの削除APIを呼び出す処理もAlgoliaレコードを削除する処理もないため、ユーザーのプロフィールが引き続き検索可能です。Sentry.init({ sendDefaultPii: true })とsetUser({ email })により、すべてのユーザーのメールアドレスとIPアドレスがエラートラッカーに送信されます。分析用スニペットがページのhead内で、同意バナーが選択内容を記録する前に読み込まれます。
• needs_validation：コードは主張を裏付けていますが、事実の確認先が法務部門またはコンソールである状態です。例：個人データを受け取るベンダーとのDPAが締結済みかどうか、ベンダーのダッシュボードで設定されたデータ保持設定、クラウドコンソールで設定されたバックアップの保持期間、CDNが認証済みプロフィールページをキャッシュするかどうかです。説明したものの実行していないDSARまたはCookieの確認も、needs_validationです。
• rejected：特定の場所にある明示的な制御が、すべての経路を網羅している状態です。例：jobs/erase-user.tsが、インベントリで見つかったすべてのベンダーSDKに処理を振り分けます。SentryのbeforeSendフックが、イベント送信前にuser.emailとCookieをすべて削除します。依存関係内の制御も該当します。デフォルトがsendDefaultPii: falseで、上書きされていないSDKの場合、ruled_out_by.locationにはSDKを固定しているロックファイルの行を指定し、controlにはデフォルト値とバージョンを記載します。「到達不能」（インストール済みだが初期化されていないベンダーSDK）の場合は、依存関係の宣言箇所を指定します。

1. 何かを確定する前に、references/verification.mdに従って反証の確認を行います。プライバシー通知、DPA、「法務部門が承認済み」という説明があっても、コードが実行するデータフローを否定することにはなりません。保持期間が文書化されていても、一度もパージされないストアの存在は否定できません。

2. references/severity-calibration.mdに従って重大度を調整します。影響を受ける主体はデータ主体です。機微な個人データ（Practice 1）が広告ベンダーに渡る場合は、DPAのあるエラートラッカーにメールアドレスが渡る場合より重大度が高くなります。静的な追跡による確信度はmediumが上限です。highにするには、テストアカウントでのDSARのエクスポートまたは削除を確認するなど、再現した確認（"reproduced": true）が必要です。

3. フィンガープリントはprivacy-engineering/<class>/<file or resource>/<symbol or name>の形式にし、<class>にはclassification、minimization、logging-pii、consent、lawful-basis、dsar-access、deletion-fanout、retention、vendor-sharing、transfer、breach-scopingのいずれかを指定します。例： privacy-engineering/deletion-fanout/src/routes/account.ts/deleteAccount、 privacy-engineering/vendor-sharing/src/lib/sentry.ts/Sentry.init、 privacy-engineering/retention/aws/rds/prod-users-db/backup-retention。行番号は含めず、ARNとhost:portはスラッシュ区切りで記述します。該当する場合はcweを使用します（個人のプライベート情報の漏えいにはCWE-359、ログ内の個人データにはCWE-532、転送前に削除されていないデータにはCWE-212）。

4. ドメイン固有のフィールドはextの下に配置します。

   extキー	値	例
   obligation	ギャップの根拠となる規制と条項またはセクション	"GDPR Art. 17(1)"、"CCPA 1798.105"、"GDPR Art. 7(3)"
   data_class	Practice 1による分類	"personal"、"sensitive_personal"
   processor	該当する場合、関与するベンダーまたはサブプロセッサー	"Segment"、"Sentry"

5. ファイルではなくデプロイ済みリソース（クラウドのバックアップポリシー、ベンダーのダッシュボード設定、同意前にステージングページが設定するCookieなど）に関する指摘では、読み取り専用の出力を秘匿化し、<audit dir>/evidence/<name>.jsonまたは.txtに保存して、locationとevidence[]でそのファイルと行を指定します。個人データの値やシークレットは決して保存せず、内容ではなくフィールド名とカテゴリを記録します。

6. findings.jsonをフィンガープリント順に並べて作成し、検証します。

   node references/validate-findings.mjs findings.json
   

   必要に応じて、SARIFをエクスポートできます：node references/to-sarif.mjs findings.json -o findings.sarif。

出力形式

まず findings.json を作成し、検証してください。レポートはこれをもとに生成され、JSON に記載されている判定や重大度を変更することはありません。

# Privacy Engineering Audit / Implementation Report
## Scope: [system / product / data flow]   ## Regulation context: [GDPR / CCPA / both / other]   ## Date: [date]
## findings.json: [path] — validated: [yes]

### Summary
- Confirmed: [N] (Critical [n] | High [n] | Medium [n] | Low [n])   Needs validation: [N]   Rejected: [N]

### Confirmed findings
#### [SEVERITY] [Title]  `fingerprint`
**Location:** `path:line`   **Obligation:** [ext.obligation]   **Data class:** [ext.data_class]   **Processor:** [ext.processor]
**Confidence:** [medium | high (reproduced)]
**Data flow:** [where the personal data enters → where it ends up]
**Exposure:** [whose data, which fields, who can now see or keep it]
**Fix:** [concrete change]
**Verify the fix:** [the DSAR, deletion or consent check that proves it]

### Needs validation
| Finding | Blockers | Check for the owner (engineering or legal) to run |
|---|---|---|

### Hardening notes (not findings)
- [gap] — [why it isn't a finding] — [effort]

### Documentation gaps (not findings)
- [record of processing, retention schedule, or DPIA input that's missing, with no exposure in the code]

### Rejected (do not re-raise)
| Fingerprint | Ruled out by | Location |
|---|---|---|

### Data inventory
| Data store | Classification | Categories of PI | Lawful basis | Retention |
|------------|----------------|------------------|--------------|-----------|

### DSAR pipeline status
- [ ] Access — implemented and tested end-to-end
- [ ] Deletion — implemented with full fan-out (DBs, caches, search, analytics, vendors)
- [ ] Portability — implemented in machine-readable format
- [ ] Rectification — self-service path exists
- [ ] Objection / opt-out — honored in all processing paths

### Vendor / sub-processor inventory
| Vendor | Purpose | Data shared | DPA | Deletion path | Data residency |
|--------|---------|-------------|-----|---------------|----------------|

### Consent records (if applicable)
[State: present / partial / missing. Storage location. Fields captured.]

### Remediation plan
| Priority | Item | Owner | Deadline |
|---|---|---|---|

確認済みの指摘事項に対する処置（通常は後で finding-triage によって設定）：修正済み／延期／リスク受容／ 軽減済み（プラットフォーム／設定）／大規模な移行が必要。プライバシーに関する指摘事項でリスクを受容する判断には、エンジニアリングだけでなく法務の承認も必要になることが多いため、報告書にその旨を記載してください。

範囲

• このスキルでは技術的な実装と監査結果を扱います。最終的なコンプライアンス判断には、法務／プライバシーの専門家による助言が必要です
• データ侵害の通知については、このスキルでは技術的な範囲とタイムラインを提示します。通知そのものには法務レビューが必要であり、security-comms を通じて行います
• ダークパターンを用いた同意フロー、マーケティング目的の監視、適法な保持期間を超えた PI の蓄積など、プライバシー法違反を目的とするシステムの構築には協力しません
• 「匿名化」には高い基準が求められます。仮名化（直接識別子を代替キーに置き換え、再識別できる状態を維持すること）は、匿名化（識別可能性を不可逆的に除去すること）とは異なります。再識別のリスクを深刻に受け止めてください
• 十分性が認められていない管轄区域への越境移転には、標準契約条項または同等の仕組みが必要です。法的な仕組みはこのスキルの範囲外ですが、準拠したパイプラインを通じてデータをルーティングするエンジニアリング作業は範囲に含まれます

参考資料

• GDPR — 規則全文：eur-lex.europa.eu/eli/reg/2016/679
• EDPB ガイドライン — 欧州データ保護会議が GDPR の解釈に関する拘束力のあるガイダンスを発行しています
• ICO（英国）— 分かりやすく、実務者向けのガイダンス：ico.org.uk
• CCPA / CPRA — カリフォルニア州司法長官：oag.ca.gov/privacy/ccpa
• IAPP — 国際プライバシー専門家協会（研修、認定、リソースライブラリ）
• NIST プライバシーフレームワーク — CSF の補完資料であり、セキュリティ管理策とプライバシー管理策の対応付けに役立ちます
• ISO/IEC 27701 — ISO 27001 のプライバシー拡張規格
• 「Privacy by Design」— Ann Cavoukian による 7 つの基本原則
• 「Privacy Engineering」— Bibi Lin、M. Selvi、A. Acar 著（学術・実務の概説）
• 「The Algorithmic Foundations of Differential Privacy」— Dwork と Roth 著（匿名化／差分プライバシーに関する部分）
• Data Privacy Framework（EU-US、US-UK、US-Swiss）— 現在の越境移転の仕組み
• 共通の参考資料（ビルド時に references/ にコピー）：findings-format.md、findings.schema.json、 validate-findings.mjs、to-sarif.mjs、severity-calibration.md、verification.md