去年十月，信息泄露一个做电商的处理朋友凌晨两点给我打电话，声音都在抖。信息泄露他的处理后台数据库被拖了，三万多个客户的信息泄露姓名、电话、处理收货地址全挂在某个境外论坛上，信息泄露标价0.3个比特币。处理他问我第一句话是信息泄露：“我现在关服务器还来得及吗？”来不及。数据一旦流出去，处理就像泼出去的信息泄露水，你只能想办法把水擦干，处理而不是信息泄露假装它没泼过。

信息泄露之后，处理最先要做的信息泄露不是追责，也不是发声明，而是切断泄露源。很多人第一反应是删库、关站，这反而破坏证据。正确做法是立刻修改所有相关系统的管理员密码，检查API接口有没有未授权调用，数据库有没有异常导出记录。如果泄露来自内部人员，先锁掉他的账号权限，但别打草惊蛇。我见过一个案例，某公司发现数据泄露后马上在群里质问，结果那个员工当场把本地留存的导出文件全删了，最后连泄露范围都查不清。

接下来是确认泄露了什么。别猜，去查日志。数据库的慢查询日志、Web服务器的访问日志、云平台的操作审计，这些能告诉你攻击者是从哪个入口进来的，拖走了哪张表，大概多少条。如果日志已经被清了，那就从泄露出来的数据样本反推。比如论坛上放出来的那几百条记录，字段结构是什么，有没有内部才有的标记。这一步决定了后面要通知谁、通知到什么程度。

然后才是通知受影响的人。这里有个坑：很多公司喜欢发一封措辞模糊的邮件，说“可能存在潜在风险”，让用户“注意防范”。这种话等于没说。用户需要知道的是：泄露了哪些字段，有没有密码，有没有身份证号，有没有银行卡。如果只是手机号和地址，风险主要是骚扰电话和精准诈骗；如果包含密码，必须强制用户重置，并且检查有没有撞库登录。我那个电商朋友后来给每个用户发了短信，直接写“您的姓名、电话、地址可能被泄露，请警惕冒充客服的退款诈骗”，投诉率反而比含糊其辞低得多。

法律层面的事跑不掉。《个人信息保护法》第五十七条写得很清楚，发生泄露要立即采取补救措施，并通知履行个人信息保护职责的部门和个人。注意“立即”两个字。有公司拖了三天才报，被罚了五十万。通知监管部门不是走过场，要写清楚泄露原因、可能造成的危害、已经采取的补救措施。如果涉及超过一百万人，或者敏感个人信息，还得在省级以上媒体公告。别想着瞒，瞒不住的，现在数据交易圈子消息传得比微博还快。

技术上的补救要同步做。改架构，别只打补丁。如果泄露是因为SQL注入，那就上参数化查询；如果是弱口令，那就强制复杂密码加双因素认证；如果是云存储桶权限配错了，那就把ACL改成私有，再加个访问日志告警。我见过一个团队，泄露之后只把被攻击的那个接口下线了，结果两周后另一个老接口又被同一伙人打穿。安全这事，要么全查一遍，要么等着第二次。

最后说点实在的。信息泄露处理完之后，别急着写复盘报告给老板看。先做一次外部攻击面扫描，看看还有没有暴露在公网的数据库、没鉴权的后台、硬编码在代码里的密钥。再找个第三方做一次渗透测试，别找那种只跑扫描器的，要找真正会手工测试的。钱花在这上面，比事后公关便宜得多。我那个朋友后来花了八万做整改，比他被勒索的金额还高，但至少到现在一年多了，没再出过事。

数据泄露不是“如果”，是“什么时候”。处理的核心就三件事：止损、告知、加固。顺序别乱，动作要快，态度要诚实。用户不指望你永远不出事，但指望你出事之后别装死。