privacy-engineering

隐私工程——GDPR / CCPA 技术实现

在代码、数据和基础设施层实现隐私控制。这项技能不是流于表面的法律合规工作，而是将法律要求转化为系统的工程实践，让系统真正做到其承诺的事情。

隐私与安全相互关联，但并不相同。安全防范未经授权的访问；隐私防范已获授权但不恰当的使用。一个安全性无懈可击、却记录每次按键并与供应商共享记录的系统，就是一场隐私灾难。这项技能涵盖了两者区分中的隐私部分。

交叉参考：owasp-audit 涵盖安全方面，iam-audit 涵盖个人数据的访问控制，secrets-audit 涵盖凭据处理，incident-triage 涵盖隐私泄露的响应方面（GDPR 的 72 小时通知时限从发现泄露时开始，而不是调查结束时），security-comms 涵盖面向客户的披露草稿。

授权

审查用户组织拥有的系统，或用户受托审查的系统。通过架构、代码、配置和合成记录追踪数据流，不要提取真实个人数据。如果发现了不该出现的个人数据，记录其位置和类别，但不要复制数据值。法律结论（合法依据、泄露是否需要通报）应由 DPO 和法律顾问作出。

监管环境（与工程相关的部分）

这项技能用于生成符合要求的技术实现。最终的合规判定仍由法律顾问负责；这项技能是技术执行层。

法规	适用范围	关键工程要点
GDPR（欧盟）	对欧盟 / 欧洲经济区居民的个人数据进行任何处理	第 5 条（原则）、第 6 条（合法依据）、第 7 条（同意）、第 15-22 条（数据主体权利）、第 25 条（隐私保护设计）、第 30 条（处理活动记录）、第 32 条（安全）、第 33 条（泄露通知——72 小时）、第 35 条（DPIA）
CCPA / CPRA（加利福尼亚州）	达到规定门槛、处理加州居民数据的企业	知情权、删除权、更正权、选择退出出售 / 共享的权利。敏感个人信息类别。年度隐私声明。服务提供商合同
LGPD（巴西）	巴西居民	与 GDPR 类似，但有本地差异
PIPEDA（加拿大）	联邦商业活动	基于同意并考虑合理预期；泄露通知
州法律（美国）	各州规定不一——弗吉尼亚州、科罗拉多州、康涅狄格州、犹他州等	大体上类似 CCPA；符合 GDPR + CCPA 的工程实践通常也能满足州法律要求

工程实践：针对适用法规中最严格的要求构建系统，其他要求不必过虑。在多数方面，GDPR 是最严格的；CCPA 增加了“选择退出出售 / 共享”的权利和敏感个人信息类别。

隐私保护设计——工程实践

实践 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）
• 存储完整的 user-agent，但实际上只需设备类别（截断）
• 为验证年龄而收集出生日期，但实际上只需确认“超过 13 岁／18 岁／21 岁”（存储布尔值，而非日期）
• 为“可选”通知而收集电话号码，并在用户选择退出后继续保留
• 备份数据保留时间超过实际运营需求数年
• 分析平台接收包含订单 ID／用户 ID 的完整 URL 路径

审计 grep 模式：

• 数据库架构中的个人数据列名：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 横幅上的“全部接受”只需点击一次，“全部拒绝”也必须只需点击一次。拒绝时需要逐一浏览五个面板的横幅不合规。

常见审计发现：

• 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 或删除流程
• 确认数据驻留位置（数据存储在哪里——欧盟、美国或其他地区），并确认已建立跨境传输机制（向欧盟以外传输时使用标准合同条款）

常见发现：

• Sentry／Datadog／LogRocket／FullStory 在错误报告和会话录制中采集个人身份信息（PII）
• 使用 Slack 讨论客户数据（如果在私信／频道中共享 PII，Slack 就会成为子处理者）
• 2024 年前使用的分析工具涉及跨境传输（欧盟—美国数据隐私框架通过后，美国获得充分性认定——请确认你的供应商已列入名单）
• 向未签署 DPA 的供应商发送 Webhook

实践 7：泄露通知

GDPR 第 33 条：在知悉个人数据泄露后 72 小时内通知监管机构。第 34 条：如果泄露造成高风险，须毫不迟延地通知受影响的个人。

工程方面的切入点（此技能负责技术检测／范围界定，实际通知由法务处理）：

• 检测：针对个人数据外泄／未授权访问模式配置 SIEM 规则（参见 siem-detection）
• 范围界定：能够快速确定涉及哪些记录／字段／个人（审计日志、访问日志、查询历史）
• 遏制：撤销访问权限、轮换凭证（参见 secrets-audit、incident-triage）
• 文档记录：知悉时间线从团队中任何人知悉时开始计时，而不是从领导层收到简报时开始——从检测到通知领导层的延迟会直接影响 72 小时期限

实践 8：DPIA（数据保护影响评估）

高风险处理必须进行 DPIA（第 35 条）——例如大规模处理敏感数据、系统性监控、影响个人的自动化决策。

DPIA 所需的工程输入：

• 数据流图（重复使用 threat-modeling 产物）
• 个人数据类别
• 数据主体类别
• 接收方（内部及供应商）
• 各类别数据的保留期限
• 安全措施（链接到 owasp-audit、iam-audit、crypto-audit 的输出）
• 风险评估及缓解措施

此技能负责生成工程输入；DPIA 本身由法务／隐私顾问编制。

验证后记录

违反强制义务的缺口（第 17 条规定的擦除路径遗漏某个存储位置、在获得同意前就启动跟踪、向供应商发送超出所述目的的个人数据）属于发现项：该义务本身就是预期控制措施。应根据缺口对个人数据造成的暴露风险评级，而不是根据可能的罚款金额评级。不会造成暴露的缺口（未列出处理依据的处理活动记录、虽未书面记录但已强制执行的保留期限）属于文档缺口；纵深防御方面的缺口则属于强化建议。两者都不应写入 findings.json。按照 references/findings-format.md 中的定义，为每个候选项给出一个结论：

• 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。依赖项内部的控制措施也算：如果某 SDK 的默认值为 sendDefaultPii: false，且从未被覆盖，则 ruled_out_by.location 应指向锁文件中固定该 SDK 的行，而 control 应说明该默认值和版本。“不可达”（已安装但从未初始化的供应商 SDK）应指向依赖项声明。

1. 在确认任何事项之前，先按照 references/verification.md 执行反驳检查。隐私声明、DPA 或“法务已批准”都不能排除代码实际执行的数据流；文档中记录的保留期限，也不能排除从未清除数据的存储。

2. 使用 references/severity-calibration.md 校准严重程度。受影响主体是数据主体。敏感个人数据（Practice 1）流向广告供应商的严重程度，高于 DPA 涵盖的错误追踪器中包含电子邮件地址的情况。静态追踪的置信度最高为 medium；要达到 high，需要重现检查（"reproduced": true），例如检查测试账户的 DSAR 导出结果或删除结果。

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 并验证。报告根据该文件生成，绝不会更改其中未明确写出的判定或严重性。

# 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 提出的七项基础原则
• 《Privacy Engineering》— Bibi Lin、M. Selvi、A. Acar（学术 / 从业者概述）
• 《The Algorithmic Foundations of Differential Privacy》— Dwork 与 Roth（适用于匿名化 / 差分隐私部分）
• Data Privacy Framework（欧盟-美国、美国-英国、美国-瑞士）— 当前的跨境传输机制
• 共享参考资料（构建时复制到 references/）：findings-format.md、findings.schema.json、 validate-findings.mjs、to-sarif.mjs、severity-calibration.md、verification.md