privacy-by-design

隐私设计

概述

从一开始就将隐私保护融入软件架构，而不是事后补救。此技能在设计数据库、API 和用户流程时，运用隐私设计原则（GDPR 第 25 条、Cavoukian 框架），保护真实用户的数据并建立信任。

何时使用此技能

• 构建收集个人数据（姓名、电子邮件、位置、偏好）的应用时使用
• 设计数据库架构、API 或身份验证流程时使用
• 用户提到表单、用户账号、分析或第三方集成时使用
• 部署到生产环境时使用——上线前核验隐私控制措施

法律框架

GDPR（欧盟） — 主要参考依据。第 25 条规定了“通过设计和默认设置保护数据”的要求。适用于欧盟用户，且通常也在全球范围内采用。

CCPA（加利福尼亚州） — 知情权、删除权、拒绝出售个人信息的权利。原则类似：尽量减少、披露信息、允许用户掌控。

LGPD（巴西） — 与 GDPR 保持一致。目的限制、必要性、透明度。适用于巴西用户。

分别梳理每个适用司法管辖区和处理目的；符合一个框架并不代表符合其他框架。

---

核心原则

1. 数据最小化

只收集严格必要的数据。每个字段都需要有记录在案的理由。避免“以后可能用得上”这样的想法。

2. 目的限制

记录每项数据的用途。识别并记录每个处理目的的合法依据和兼容性；同意只是其中一种依据，并非唯一依据。

3. 存储限制

定义保留期限。保留期限到期后，自动删除或匿名化数据。默认情况下，绝不“永久”保留数据。

4. 默认保护隐私

对可选数据收集采用主动加入，而非主动退出。敏感设置（分析、营销）默认关闭。不得预先勾选同意框。

5. 端到端安全

对静态数据和传输中的数据进行加密。使用 RBAC。记录对敏感数据的访问情况，以供审计。

6. 透明度

记录收集了哪些数据及其原因。提供清晰的隐私政策。方便用户访问和删除数据。

---

用户权利（GDPR）

从第一天起就确保能够实现以下权利：

权利	要构建的功能
访问权	提供返回所有用户数据的端点或流程
更正权	允许更新或更正数据
删除权	提供经过验证的删除工作流，处理适用的法律例外情况，并明确备份的到期时限及恢复抑制措施
数据可携权	以机器可读格式（JSON、CSV）导出数据

---

深入了解：为何重要

数据最小化 — 数据越少，泄露造成的影响越小、存储成本越低，合规也越简单。每个字段都是一种责任。

目的限制 — 根据 GDPR 评估重复使用数据的合法依据和兼容性；并非每项处理活动都普遍要求获得同意。在架构或元数据中记录用途。

保留期限 — 无限期存储会增加风险并违反 GDPR。为每种数据类型定义 retention_days；自动执行清理。

日志记录 — 日志经常泄露个人身份信息（PII）。对电子邮件、ID、令牌进行脱敏。采用带允许列表的结构化日志记录。

第三方 — 每个 SDK（分析、崩溃报告、广告）都可能向其他地方发送数据。审查依赖项，并在加载可选跟踪功能前，明确适用的同意要求和合法依据要求。

---

代码示例

JavaScript/Node — 最简用户模型

// BAD: Collecting everything "just in case"
const user = { email, name, phone, address, birthdate, ipAddress, userAgent, ... };

// GOOD: Minimal, documented purpose
const user = {
  email,        // purpose: authentication
  displayName,  // purpose: UI display
  createdAt,    // purpose: account age
};

JavaScript — 跟踪前先获取同意

// BAD: Track first, ask later
analytics.track(userId, event);

// GOOD: Check consent first
if (userConsent.analytics) {
  analytics.track(userId, event);
}

Python — 安全日志记录

# BAD: Logging PII in plain text
logger.info(f"User {user.email} logged in from {request.remote_addr}")

# GOOD: Redact or hash identifiers
logger.info(f"User {hash_user_id(user.id)} logged in")
# Or: logger.info("User login", extra={"user_id_hash": hash_id(user.id)})

SQL — 包含用途和保留期限的架构

-- GOOD: Document purpose and retention in schema
CREATE TABLE users (
  id UUID PRIMARY KEY,
  email VARCHAR(255) NOT NULL,  -- purpose: auth, retention: account lifetime
  display_name VARCHAR(100),   -- purpose: UI, retention: account lifetime
  created_at TIMESTAMPTZ,      -- purpose: audit, retention: 7 years
  last_login_at TIMESTAMPTZ    -- purpose: security, retention: 90 days
);

-- Add retention policy (PostgreSQL example)
-- Schedule job to anonymize/delete last_login_at after 90 days

API — 仅返回所需字段

# BAD: Returning full user object
return jsonify(user)  # May include internal fields, hashed passwords

# GOOD: Explicit allowlist
return jsonify({
    "id": user.id,
    "email": user.email,
    "displayName": user.display_name,
})

---

常见陷阱

陷阱	解决方案
日志中包含电子邮件地址、IP 地址、令牌	对个人身份信息进行脱敏；使用哈希 ID 或结构化日志
错误消息暴露数据	向客户端返回通用错误；在服务端记录详细信息
第三方 SDK 在获得同意前加载	仅在获得同意后加载分析/广告功能；使用同意管理机制
没有删除流程	从一开始就设计账户删除和数据清除流程
备份永久保留数据	将备份纳入保留策略；对备份进行加密
未经同意使用 Cookie	使用同意横幅；在适用情况下尊重 Do Not Track

---

第三方审计

在添加会接触用户数据的依赖项之前：

• 它会收集或接收哪些数据？
• 它会将数据发送到哪里（服务器、国家/地区）？
• 它是在用户同意前还是同意后加载？
• 用户选择退出后，我们能否将其停用？
• 其隐私政策是否与我们的政策一致？

---

实施检查清单

构建涉及用户数据的功能时：

• 这些数据是否必要？能否用更少的数据实现目标？
• 我们是否已获得对这项用途的明确同意？
• 数据是否已加密（静态存储和传输过程中）？
• 我们是否制定了数据保留/删除政策？
• 用户能否导出或删除自己的数据？
• 是否已披露第三方服务并获得同意？
• 日志中是否不含个人身份信息？
• 备份是否纳入保留政策？

---

最佳实践

• ✅ 每新增一个数据字段，都要问“我们需要这个吗？”
• ✅ 从一开始就设计删除和导出流程
• ✅ 尽可能对敏感标识符进行哈希处理或令牌化
• ✅ 在架构或元数据中记录数据用途和保留期限
• ❌ 不要以明文记录密码、令牌或个人身份信息
• ❌ 未记录合法依据、采取适当保障措施且未获得适用的同意时，不要共享个人数据
• ❌ 不要认为“以后再加隐私保护”——这种事很少会发生
• ❌ 不要向客户端暴露堆栈跟踪或内部错误

---

适用场景

在构建收集、存储或处理个人数据的软件时适用此技能。请在设计和实施期间主动应用。

限制

• 仅当任务明确符合上述范围时，才使用此技能。
• 不要将输出视为可替代针对具体环境的验证、测试或专家审查。
• 如果缺少必要输入、权限、安全边界或成功标准，请暂停并请求澄清。

哈希处理/令牌化通常只是对标识符进行假名化；它不会自动实现数据匿名化，也不会消除隐私义务。请评估重新识别风险，并限制对密钥/映射关系的访问。数据保留和擦除需要针对具体用途制定规则、考虑合法例外，并对恢复/删除处理进行测试。这是设计指导，不是合规认证。请参阅 EDPB 合法依据和 ICO 假名化。