privacy-by-design

概述

Privacy by Design 是一个在软件架构设计之初就集成隐私保护的技能，而非事后追加。它在设计数据库、API 和用户流程时应用隐私设计原则（GDPR 第 25 条、Cavoukian 框架），保护真实用户数据并建立信任。

何时使用

构建收集个人数据（姓名、邮箱、位置、偏好）的应用时
设计数据库模式、API 或认证流程时
用户提及表单、用户账户、分析或第三方集成时
生产部署时，在发布前验证隐私控制

法律框架

GDPR（欧盟）：主要参考。第 25 条规定“通过设计和默认的数据保护”。适用于欧盟用户，常被全球采用。
CCPA（加州）：知情权、删除权、退出销售权。原则相似：最小化、披露、允许控制。
LGPD（巴西）：与 GDPR 一致。目的限制、必要性、透明性。适用于巴西用户。

针对你所面向的最严格框架进行设计，通常也能满足其他框架。

核心原则

数据最小化：只收集严格必要的数据。每个字段都需要有文档化的理由。避免“以后可能用得上”。
目的限制：记录每个数据点的目的。不将数据复用于用户未同意的目的。
存储限制：定义保留期限。到期后实现自动删除或匿名化。默认绝不“永久”保留数据。
默认隐私：可选收集采用选择加入而非选择退出。敏感设置（分析、营销）默认关闭。不使用预勾选的同意框。
端到端安全：静态和传输中加密。使用 RBAC。记录敏感数据访问以供审计。
透明性：记录收集了什么以及为什么。清晰的隐私政策。用户可以轻松访问和删除。

用户权利（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、令牌	脱敏 PII；使用哈希 ID 或结构化日志
错误消息暴露数据	向客户端返回通用错误；在服务端记录详情
第三方 SDK 在同意前加载	仅在同意后加载分析/广告；使用同意管理
无删除流程	从第一天起设计账户删除 + 数据清除
备份永久保留数据	将备份纳入保留策略；加密备份
无同意的 Cookie	使用同意横幅；在适用时尊重 Do Not Track

第三方审计

在添加触及用户数据的依赖之前：

它收集或接收什么数据？
它将数据发送到哪里（服务器、国家）？
它是在用户同意之前还是之后加载？
如果用户选择退出，我们能否禁用它？
他们的隐私政策是否与我们一致？

实施检查清单

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

这些数据是否必要？能否用更少数据实现目标？
我们是否对此用途有明确同意？
是否加密（静态和传输中）？
我们是否有保留/删除策略？
用户能否导出或删除其数据？
第三方服务是否已披露并征得同意？
日志是否不含 PII？
备份是否纳入保留策略？

最佳实践

✅ 对每个新数据字段问“我们需要这个吗？” ✅ 从第一天起设计删除和导出流程 ✅ 尽可能对敏感标识符使用哈希或令牌化 ✅ 在模式或元数据中记录目的和保留期 ❌ 不要以明文记录密码、令牌或 PII ❌ 不要在未经明确同意的情况下与第三方共享数据 ❌ 不要假设“我们以后再加隐私”——这很少发生 ❌ 不要向客户端暴露堆栈跟踪或内部错误

何时使用

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

限制

仅当任务明确匹配上述范围时使用此技能。
不要将输出视为特定环境验证、测试或专家评审的替代品。
如果缺少必需的输入、权限、安全边界或成功标准，请停止并请求澄清。

技能介绍

概述

何时使用

法律框架

核心原则

用户权利（GDPR）

深入：为什么重要

代码示例

常见陷阱

第三方审计

实施检查清单

最佳实践

何时使用

限制