Privacy by Design

Privacy by Design (GDPR)

1）这是什么以及为什么

Privacy by Design （PbD）是从一开始就将隐私嵌入产品中的原则：业务需求、体系结构、代码、流程和操作。用GDPR来说，这表现为"通过设计和默认方式隐私"（最小化费用，默认设置-最大限度地私有化，透明度和问责制）。

• 最大限度地减少个人数据的收集和处理（PD）。
• 确保合法性、透明度、正确性、目标和时限的限制。
• 降低风险（技术和法律），简化审核和合规性。

2）GDPR的角色，法律框架和原则

2.1个角色

控制器（Controller）：定义处理目标/工具。
处理器（Processor）：根据DPA合同代表控制器处理PDn。
数据主体（Data Subject）：与PDn相关的物理。
DPO（数据保护官）：按需独立监控和咨询。

2.2法律依据（选择和记录）

同意，条约，合法利益，法律义务，重要利益，公共任务。对于每个人，都是目的，数据，保留，召回的可能性（供同意）。

2.3处理原则（第5条）

合法性、公正性、透明度

目的限制

最小化数据

精确度

存储限制

完整性和隐私

问责制（问责制）-证明合规性的能力。

3） SDLC中的PbD过程（参考框架）

1.启动：制定处理目标和法律依据，指定所有者数据和DPO点。
2.数据映射（Data Mapping）- 字段源 信任模型 在哪里流向谁读取 存储 期限。
3.风险评估/DPIA：LINDDUN隐私威胁模型，影响评估，减少措施。
4.体系结构解决方案：选择最小化，别名，加密，分区方案。
5.UX/同意/通知要求：可理解的文本,granular consent,默认设置。
6.实施：私有默认、安全遥测、无机密编写/PII。
7.验证：隐私测试，静态分析，私有单元测试，DPIA协议。
8.运营：DSAR过程，撤消和删除，事件监控，供应商咆哮。
9.定期修订：当目标/技术发生变化时，re-DPIA。

4） PbD工程模式

4.1最小化和分解

仅收集必要的字段；应用渐进式专业。
将标识符和内容分开：分别存储通信密钥（token/reference）。

4.2别名和匿名

别名：分别存储真实标识符；工作层看到令牌。
匿名：使用k-匿名，l-diversity，t-closeness；对于分析-差异隐私（ε-预算）。

4.3访问控制和角色划分

PoLP，ABAC/RBAC，职责范围，管理人员和分析师的单独轮廓。
那些。措施：mTLS，SSO/OIDC，scoped令牌，访问PDn的临时凭据。

4.4加密和隔离

In Transit: TLS 1.3/mTLS;At Rest: AEAD/Envelope + KMS/HSM.

租户/dataset的单独钥匙；"遗忘权"的加密删除。

4.5回避和删除

TTL按领域/目标明确的政策；piplines中的自动陷阱；"双相"删除（逻辑→物理）。
对于后援-分开钥匙和短窗口存储个人狙击手。

4.6私人遥测和成像

默认情况下为PII；与盐一起使用令牌/哈希。
Prodewser上的敏感场掩盖/令牌化。

4.7 UX隐私和同意

按类别（分析，营销，个性化）分列的Granular consent。
"私人违约"：一切都不关键-关闭，直到他们同意。
清晰的"撤消同意"选项,并在新使用时发出即时通知。

5）DPIA和LINDDUN（简称）

DPIA（数据保护影响评估）：高风险（大规模监测，评估，新技术）是必需的。它包括处理描述，需求/比例性，风险评估，减少措施。
LINDDUN угрозы: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance.针对每个威胁-对策（最小化，别名，DP，透明度，同意管理，审计）。

6）跨境转移

找出供应商的存储/访问位置。
使用SCC（标准合同条款）并进行传输影响评估。
技术人员：端到端加密,客户端加密,特别敏感的数据,远程访问限制。

7）供应商和处理器（供应商管理）

DPA/嵌套处理器，技术和组织措施，子处理器-控制。
定期的评论和审计；检查权；退出/迁移计划（data export）。

8）数据主体权利（DSAR）

访问、修补、删除、限制、可移植性、异议,不是AADM（分析/自动化）对象。
SLA和自动化：查询跟踪，身份证明，响应日志。
产品中的技术嗡嗡声：按标识快速搜索和导出；级联删除。

9）自动化解决方桉和分析（第22条）

如果"重大影响"的决定是由自动机做出的-确保人干预的权利，可解释，特征透明。
日志路径和模型转换；上诉机制。

10）处理安全（第32条）和事件（第33/34条）

面向风险的措施：加密，完整性，可持续性，恢复计划（RTO/RPO）。
PDn事件：检测过程 三重评估 风险评估 通知监管机构72小时（需要）和受试者（如果风险很高）。
单独的花花公子，DPO/律师联系人列表，通知模板。

11）隐私和ML/分析

数据管理集：数据线、许可证/基础、同意。
技术：差分私有性，联合学习，安全进化，最小化拳头。
攻击防御：membership/model inversion-定期泄漏评估、ε 设置、噪音/clip。
合成数据-仅对缺乏角色恢复进行验证。

12）建筑方案（模式）

12.1"双环"ID体系结构

路径A （PDS-个人数据商店）：真实标识数据（RID）,访问-严格限制,密钥/加密/审计。
电路B（运营）：带有令牌的业务数据；通过令牌经纪人与限额和审计进行通信。

12.2个同意总线（同意服务）

集中服务,存储同意版本和历史记录。
SDK："can_use（类别，purpose）"-即时决定；一切都是合乎逻辑的。

12.3转义策略作为代码

YAML配置：实体→字段→ TTL →到期时操作（匿名/删除/抢占）。
调度程序执行工作,报告由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（处理活动记录）是操作注册表：目的，法律依据，数据/主体类别，传输，保留时间，措施。
政策：隐私,cookies,产品中的信息通知（以易懂的语言）。
员工培训和年度评论。

15）经常出错

收集"以防万一"并存储"永远"。
同意是唯一的依据，尽管契约/合法利益是适当的。
"空白"cookie横幅没有真正的开关。
缺乏数据映射和DSAR准备不足。
带有PII的徽标，无保护的备份，RID和操作数据的混合。
没有供应商控制和跨境传输。

16）支票单

• 确定处理目的和法律依据；ROPA更新。
• 已完成数据映射和DPIA（如有必要）。
• 实现最小化、别名化、加密（路径/静止）。
• 同意是颗粒状的，具有可理解的UX；违约是私有的。
• 将转义策略设置为代码；已验证删除/匿名。
• Logi/遥测-无PII；已启用掩码。
• 准备了DSAR hooks和出口。
• 进行了团队培训并批准了DPO。

• 每季度审查请愿书和法律依据。
• 处理器/子处理器的定期审核。
• 事件监测和通知准备≤ 72时。
• 在过程/技术变化时修订DPIA。
• 合规工件存储（DPIA、ROPA、测试报告）。

17) FAQ

问：是否有可能完全摆脱同意？
答：有时-是的（合同/法律义务/合法利益），但前提是严格要求并评估利益平衡。市场营销和非批判性分析-通常需要同意。

问： 别名是否足够?

答：不，这些仍然是个人数据。要退出GDPR领域，需要可靠的匿名（可验证无法重新识别）。

问： 如何使用ML和个性化?

答：尽量减少fici，使用DP/federated方法，制定解决方案，确保个人干预和拒绝特征分析的权利。

问：商业和隐私冲突怎么办？
答：重新设计收集（渐进式配置）,切换到单元/合成,重新评估法律依据,提供无跟踪选项。

• "秘密管理"
• "At Rest加密"
• "In Transit加密"
• "审核和不变日志"
• "；请求的签字和核实"；
• "密钥管理和旋转"