---

name: privacy-by-design description: "在构建收集用户数据的应用时使用。确保从一开始就内置隐私保护——数据最小化、同意、加密。" risk: safe source: community date_added: "2026-02-23"

隐私设计

概述

从一开始就将隐私保护集成到软件架构中，而不是事后补救。此技能在设计数据库、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
})

实施清单

• [ ] 审计所有收集的数据字段——每个字段是否有明确目的？
• [ ] 实现同意管理——用户能否控制可选数据收集？
• [ ] 设置数据保留策略——是否有自动清理？
• [ ] 加密敏感数据——静态和传输中
• [ ] 实现用户权利端点——访问、删除、导出
• [ ] 审计第三方 SDK——它们发送了什么数据？
• [ ] 安全日志——确保没有 PII 泄露到日志中
• [ ] 隐私政策——清晰、最新、可访问

限制

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