用户数据存储的合规底线

用户数据的合规底线，从第一行采集代码之前就该定下来。先问自己三个问题：这个字段能不能不收、打算怎么存、真丢了怎么办。三问都有答案，底线就守住了大半。 最小化收集 只收业务必需的字段：注册环节要个手机号能完成验证，就不要顺带收身份证号；用不到的数据不采集，这是个人信息保护最朴素的原则。隐私政策里如实列明收集哪些字段、用来做什么、保存多久，并在页面放一个稳定可访问的链接。展示环节同样适用最小化：客服后台看用户手机号只显示后四位，导出权限单独审批。字段收得少、看得少、导得少，三条线一起收，泄露面自然就小。应用日志也要留神：别把手机号、身份证号整串打进日志，排查是方便了，泄露面也跟着变大。 加密存储 密码必须单向哈希，选 bcrypt 或 argon2，MD5 和明文属于不及格，Linux 下 htpasswd -bnBC 10 "" '示例密码' 就能生成 bcrypt 格式的参考。身份证号、银行卡号这类敏感字段做应用层加密，密钥与数据分开存放，别把密钥和数据表放在同一个数据库里。传输环节全站 HTTPS，内网服务之间的敏感调用也建议上 TLS（传输层加密协议）。磁盘加密可以作为补充，但要清楚它的边界：加密解决的是盘丢了数据不丢，解决不了账号被拖库，应用层加密仍是主力。 泄露时的动作 应急流程要提前写下来：确认泄露范围、封堵入口、评估影响、按法规要求向主管部门报告并告知受影响用户。流程平时演练一次，真出事按脚本走，慌乱中的处置失误往往比泄露本身伤得更深。 存储层面再补一句：用户数据所在的服务器，访问权限收到人、操作日志开着、到期数据按机制清理。合规底线只是及格线，日常的安全功夫都在平时。