隐私、安全与最小合规
少收数据、说清用途、服务端校验权限。按阶段决定需要哪些法律文档，以及自建产品的技术安全底线。
隐私政策不是从模板复制一篇长文，安全也不是上线前装个扫描器。
第一版最有效的原则只有一条：不需要的数据不要收；收了就要知道为什么收、存多久、谁能访问、怎么删。
规则核查日期：2026-08-31。本文不是法律意见。医疗、金融、未成年人、生物识别这类高风险场景应寻求专业帮助。
快速版
- 先列数据清单，答不出"为什么需要"的就别收。
- 权限在服务端检查，隐藏按钮不算权限控制。
- 密钥只在服务端环境，不进仓库、不进浏览器包。
- 日志里去掉密码、令牌、支付签名、敏感正文。
- 按阶段决定法律文档：Demo 一句话，上线要基础政策，收费要退款条款。
- 不要直接抄别人的隐私政策——你的数据处理方式和他不一样。
- 提前知道出事时怎么撤销密钥、禁用功能、联系用户。
先做数据清单
对每一项数据回答七个问题：来源、用途、存储位置、保留期限、访问角色、删除方式、第三方接收方。
| 数据 | 为什么需要 | 存哪里 | 多久删除 | 谁能访问 |
|---|---|---|---|---|
| 邮箱 | 登录与找回 | 账户数据库 | 账号删除后按规则处理 | 认证服务 |
| 上传文件 | 完成核心任务 | 对象存储 | 任务完成后定期清理 | 用户与处理服务 |
| 支付记录 | 对账与开票 | 交易台账 | 按法定保存期限 | 仅管理员 |
如果某一列答不出来，先暂停收集这项数据。 这个动作比写一篇长政策有用得多——收得少，要保护的就少，要解释的也少。
给用户真实选择
在收集之前说明处理目的和必要范围。不要把"同意所有营销与共享"绑定到基本功能上——用户为了用产品不得不同意营销推送，这不是同意。
提供查询、更正、删除、撤回授权的可执行入口。政策里写了但产品里做不到，比不写更糟。
境内处理个人信息应核对《个人信息保护法》以及自 2025 年起施行的《网络数据安全管理条例》。
法律文档按阶段准备
不需要第一天就有全套文档。按阶段来：
| 阶段 | 需要什么 |
|---|---|
| Demo / 等待名单 | 页面底部一行隐私声明 |
| 公开上线，不收费 | 基础隐私政策 + 用户协议 |
| 接入支付 / 订阅 | 上述 + 退款条款 + 明确联系方式 |
| 面向多国用户 | 按目标地区的数据法规增加声明 |
| 有团队 / 融资 | 找专业律师起草 |
多数个人产品停在第二、三阶段。
用户协议至少要说清
服务做什么和不做什么、禁止哪些行为、账户终止条件、知识产权归属（你拥有代码，用户拥有自己的内容）、免责范围、付费条款、争议适用规则。
隐私政策至少要说清
收集什么、怎么用、怎么存和保护、是否分享给第三方（支付、统计、邮件服务都算）、用户有哪些权利、用了哪些 Cookie 以及怎么控制。
不要直接复制别人的隐私政策。 每个产品的数据处理方式不同，照抄的结果是政策写的和实际做的不一致——这比没有政策风险更高，因为它构成了你对用户的书面承诺。
模板生成器或 AI 起草初稿都可以，但必须逐条改成你真实的做法。市面上有若干在线生成工具，具体选哪个、当前是否免费请自行核对，本页不列名单和价格。
接支付的额外要求
支付平台通常要求你的网站具备：明确的退款政策、可用的联系方式、清晰的服务说明。 缺这些可能直接导致审核不通过。
联系方式尤其重要。用户找不到你，本身就是不合规的信号。 见业务邮箱与发信送达。
技术底线
这一节是自建产品必须做到的。
- 密钥只放服务端环境，不进仓库、不进浏览器包
- 权限在服务端检查，不只是前端隐藏按钮
- 上传限制类型、大小、读取范围
- 日志去掉密码、令牌、支付签名、敏感正文
- 数据库和对象存储按最小权限配置
- 数据库端口不对公网开放
- 关键数据有备份，并真正演练过恢复
- 登录、支付、管理接口设了合理限流
第二条最常出问题。前端把入口藏起来，接口却没校验，任何人直接请求接口就能拿到数据。自测方法是用普通用户账号去请求管理员接口和别人的资源 ID。
付费内容也是同一类问题：
# 用未登录状态请求受保护页面，看能不能搜到正文
curl -s https://你的域名/members/某篇 | grep "正文里的某句话"
# 期望：什么都搜不到如果这条命令能搜到内容，你的付费墙是假的。
关于数据库端口，有一个容易踩的坑：Docker 的端口映射会绕过 ufw 之类的防火墙规则。所以要在映射里显式绑定本地地址：
ports:
- '127.0.0.1:5432:5432' # 前缀不能省省掉 127.0.0.1: 前缀，数据库就直接暴露在公网上，而防火墙看起来是开着的。详见自建服务器部署。
第三方服务在你的数据链路里
模型、统计、邮件、支付、客服服务都会接触数据。记录它们各自接收什么、用于什么、存在哪里，换服务商时同步更新政策。
不要默认"第三方很大所以一定合规"。你仍然要控制发送出去的数据范围。 尤其是把用户输入发给模型服务时，先想清楚里面可能包含什么。
安全事件准备
出事时临时找管理员账号和备份位置，会把小事故放大成大事故。提前写下这五件事：
1. 撤销密钥：在哪个平台、哪个页面、我有权限吗
2. 禁用受影响功能：改哪个开关、要不要重新构建
3. 保留必要日志：在哪、怎么导出、别在慌乱中清掉
4. 联系用户：从哪里拿到受影响用户列表、用什么渠道通知
5. 恢复数据：最近一次可用备份在哪、恢复要多久第 3 条容易被反向操作——出事时急着重启，日志就没了，根因也就查不出来了。
常见卡点
| 卡在哪 | 可能原因 | 试试这样 |
|---|---|---|
| 政策写了但做不到 | 抄了别人的模板 | 逐条改成你真实的做法 |
| 普通用户能拿到别人数据 | 只在前端隐藏 | 服务端校验权限，用普通账号自测 |
| 付费内容能被直接抓到 | 只在前端判断会员 | 服务端渲染前就校验权益 |
| 数据库被扫到 | Docker 映射绕过防火墙 | 映射加 127.0.0.1: 前缀 |
| 支付平台审核不通过 | 缺退款政策或联系方式 | 补齐退款条款和可用联系方式 |
| 日志里有令牌 | 打印了完整请求体 | 打印前脱敏 |
| 出事后查不出原因 | 重启把日志冲掉了 | 先导出日志再处理 |
| 备份存在但恢复失败 | 从没演练过 | 定期做一次真实恢复演练 |
验收标准
- 数据清单七列都填得出来，填不出的已停止收集
- 用普通用户账号测过：拿不到别人的资源、进不去管理接口
- 未登录状态下抓不到付费内容
- 密钥不在仓库里，也不在浏览器可见的变量里
- 数据库端口没有对公网开放
- 日志采样检查过，没有密码、令牌、签名
- 按当前阶段该有的法律文档都有，且内容和实际做法一致
- 接了支付的话，退款政策和联系方式在页面上找得到
- 安全事件五步已写下来，备份恢复演练过
本章动作
做两件事。
一是删掉一项当前不影响核心功能的数据收集。清单里最难回答"为什么需要"的那一项就是它。
二是用普通用户账号尝试访问别人的资源——把地址里的 ID 改成另一个用户的，看能不能拿到。能拿到就是最高优先级的问题，比任何法律文档都紧急。
下一步
- 环境变量与密钥管理——密钥怎么分层管理
- 自建服务器部署——服务器层的安全配置
- 数据库迁移、备份与恢复——备份和恢复演练
- 支付合规与风控——支付侧的合规要求
来源
- 《个人信息保护法》（核查日期 2026-08-31）
- 《网络数据安全管理条例》（2025 年起施行）
- 支付平台对退款政策和联系方式的具体要求以各平台当前审核标准为准