
关于
构建收集用户数据的应用时使用。确保从一开始就内置隐私保护——数据最小化、同意管理、加密。
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 泄露到日志中
- [ ] 隐私政策——清晰、最新、可访问
限制
- 仅在任务明确匹配上述范围时使用此技能。
- 不要将输出视为环境特定验证、测试或专家审查的替代品。
- 如果缺少所需的输入、权限、安全边界或成功标准,请停下来寻求澄清。
