上篇认识了合规框架。这一篇落到开发者每天打交道的数据上：你写的代码怎么处理用户数据，才不踩法律红线？这部分和 GDPR、个人信息保护法（中国 PIPL）、等保都强相关，是合规里最”代码化”的一块。

读完这篇，你能拿到一份”数据合规开发清单”，写代码时逐项对照。

红线一：收集要”最小化、有告知、获同意”

• 数据最小化：只收集业务真正需要的字段。做登录要手机号就够了，别顺手收集身份证、人脸——多收一个字段，就多一份泄露风险和合规负担。
• 告知与同意：在隐私政策里说清”收什么、干嘛用、给谁看”，用户勾选同意后才能收。默认勾选、藏起条款都是违规。
• 区分必要与非必要：必要信息（如交易需实名）可强制，非必要（如个性化推荐）要允许用户拒绝且不影响主功能。

红线二：存储要加密、要分级

• 敏感信息加密存：密码用 bcrypt/Argon2（上篇讲过）；身份证号、手机号、银行卡等个人敏感信息存储要加密（如 AES），不能明文落库。
• 密钥分离管理：加密密钥不能和密文放同一数据库，要用 KMS（密钥管理服务）独立保管，否则加密形同虚设。
• 数据分级分类：把数据分成公开/内部/敏感/核心，敏感和核心数据重点保护、访问严控、操作留痕。这是等保和 PIPL 的共同要求。

红线三：展示与传输要脱敏

• 脱敏展示：页面/接口返回手机号、身份证时，绝不返回完整明文。正确做法：138****8000、身份证 110***********1234。后台日志、导出文件同样要脱敏。
• 传输加密：所有含个人信息的接口必须 HTTPS（PKI 篇讲过），内网传输敏感数据也建议加密，防内网嗅探。
• 日志合规：别把用户明文密码、完整 Token、完整卡号写进日志——这是高频违规点，攻击者拿到日志直接拿到凭证。

红线四：响应用户权利

GDPR/PIPL 都赋予用户权利，系统要能支撑：

• 查询权：用户能查”你存了我哪些数据”。
• 更正权：用户能改错的信息。
• 删除权（被遗忘权）：用户注销后，要在系统中真正删除（或匿名化）其数据，而不是”逻辑删除”留着继续用。
• 可携带权：用户能导出自己的数据。

开发者要提前在数据库设计上留好”按用户 ID 彻底清除数据”的能力，否则用户要求删除时你删不干净，就是违规。

红线五：跨境与第三方

• 跨境传输：中国个人信息出境、欧盟数据传到第三国，都有专门机制（如标准合同、安全评估）。别默认把数据同步到境外服务器。
• 第三方共享：把数据给合作方/SDK（如统计、推送）前，要评估对方资质、签数据处理协议（DPA）、告知用户。很多 App 因违规 SDK 收集信息被通报。

开发者合规清单（贴墙）

1. 收集前：是否必要？是否告知并获同意？
2. 存储：敏感字段是否加密？密钥是否独立管理（KMS）？
3. 展示：接口/页面/日志是否脱敏？
4. 传输：是否全 HTTPS？内网敏感流是否加密？
5. 账号：密码是否慢哈希加盐？
6. 权限：谁能看敏感数据？是否有访问审计日志？
7. 删除：能否按用户 ID 彻底清除/匿名化？
8. 第三方：SDK/合作方是否评估、签协议、告知用户？
9. 留存：数据保留期是否合理？过期是否清理？
10. 应急：数据泄露是否有上报和通知流程？

常见坑位提醒

• 日志打明文手机号/密码：攻击者和内鬼最爱翻日志。务必脱敏后再记。
• “逻辑删除”当合规删除：用户注销只打 deleted=1，数据仍在库可被分析利用，违反删除权。要真删或匿名化。
• 密钥和密文同库：数据库一拖库，密钥密文一起没，加密白搭。密钥走 KMS。
• 隐私政策是摆设：不实际执行、偷偷多收数据，一旦出事就是”未告知+超范围收集”双违规。
• 忽略第三方 SDK：引入一个违规收集信息的 SDK，板子打在你身上。上线前审计 SDK 权限。
• 默认全量同步到境外：触发跨境合规机制缺失，轻则整改重则罚款。

实战：脱敏与加密的代码样例

光说原则不够，给两段可直接参考的代码。

脱敏展示（手机号/身份证打码）：

def mask_phone(p: str) -> str:
    return p[:3] + "****" + p[-4:] if len(p) == 11 else "****"

def mask_id_card(idc: str) -> str:
    return idc[:6] + "*" * (len(idc) - 10) + idc[-4:]

字段加密存储（用 KMS 托管密钥，应用只持数据密钥）：

from cryptography.fernet import Fernet
# 实际生产中密钥从 KMS 获取，绝不硬编码/不随库存储
key = kms.get_data_key()            # 从密钥管理服务取
cipher = Fernet(key)
token = cipher.encrypt(phone.encode())   # 密文入库
plain = cipher.decrypt(token).decode()    # 取出时解密

关键：密钥走 KMS，密文在业务库，二者分离；明文只在内存短暂存在，不进日志、不进响应体（除非已脱敏）。

同意管理：别让”默认勾选”成雷

“告知同意”是 PIPL/GDPR 的共同红线，开发上要注意：

• 隐私政策要真实可读，不能藏在超链接里、用极小字糊弄。
• 非必要信息（如个性化推荐、营销短信）必须单独、主动授权，不能”一键全同意”默认捆绑。
• 用户撤回同意要像”同意”一样容易——提供关闭开关，撤回后停止处理相关数据。
• 把”同意了什么、何时同意”记录下来，证明你合规采集，审计时能拿出来。

很多 App 被通报，问题就出在”偷偷多收、默认全勾”。技术实现上，把”同意项”当成结构化数据存（哪个功能、哪个版本、哪个时间、用户 ID），而不是一句空话。

数据保留与销毁：过期就清

合规要求”不为目的之外留存”。开发上：

• 给每类数据定保留期（如日志 90 天、订单 5 年、验证码 5 分钟）。
• 到期自动清理/匿名化，用定时任务或生命周期策略（如对象存储的过期删除）。
• 用户注销后，按”删除权”真删或匿名化，不能只打 deleted=1 继续分析利用。
• 备份里也要考虑：归档备份可能含已删除用户数据，重新导入时要注意脱敏或剔除。

跨境与第三方：两个高频雷区

• 跨境传输：中国个人信息出境、欧盟数据传第三国，都有专门机制（标准合同 SCC、安全评估、认证）。默认别把数据同步到境外服务器，要出境先走合规流程。
• 第三方 SDK：引入一个统计/推送/广告 SDK，它可能偷偷收集设备号、位置。上线前必须审计 SDK 权限与数据流向，签数据处理协议（DPA），并在隐私政策告知用户。无数 App 因”违规 SDK 收集信息”被通报下架——板子打在你身上，不是 SDK 厂商。

把清单变成工程习惯

“开发者合规十项清单”不是写完贴墙就完，要变成工程卡点：代码评审看”有没有脱敏/加密/留痕”，上线检查看”有没有默认勾选/违规 SDK/境外同步”，监控看”日志有没有明文凭证”。把合规检查嵌进 CI/CD 和评审流程，它才真落地，而不是出事才翻清单。

小测验：看看你掌握了没

• 问题一：数据最小化指什么？答案：只收集业务必需的字段，不多收，降低泄露与合规风险。
• 问题二：为什么密钥不能和密文同库？答案：拖库即同失，加密失效；密钥应独立用 KMS 管理。
• 问题三：用户注销后逻辑删除够吗？答案：不够，违反删除权，应彻底删除或匿名化其数据。

这一篇你该记住的

• 收集：最小化、告知同意、必要/非必要区分。
• 存储：敏感字段加密（AES）、密钥独立 KMS、数据分级分类。
• 展示/传输：脱敏（手机/身份证打码）、全 HTTPS、日志不写明文凭证。
• 用户权利：查询/更正/删除(真删或匿名化)/携带，设计上预留按 ID 清除能力。
• 跨境/第三方：出境机制、SDK 评估与协议；附”开发者合规十项清单”逐项对照。

合规要求清楚了，最后一篇我们讲企业怎么把合规真正落地——从制度、流程到认证，让合规从文档变成日常运转的体系。