敏感信息泄露整改报告

数据库里躺着明文身份证号，敏感这事是信息泄露我上周三发现的。运维同事在群里发了张截图，整改某张用户表里手机号、报告身份证、敏感家庭住址三列全裸奔，信息泄露连base64都没做。整改更离谱的报告是，这张表有读取权限的敏感账号多达17个，包括两个已经离职半年的信息泄露前员工。当天下午我们拉了紧急会议，整改会议室里没人说话，报告只听见空调嗡嗡响。敏感

问题出在三年前的信息泄露一次“临时方案”。当时业务部门要紧急上线一个活动，整改开发图省事，直接把用户信息塞进了一张新表，没走脱敏流程。活动结束后没人清理，这张表就成了定时炸弹。我查了操作日志，过去一年里有23次批量导出记录，其中7次导出量超过10万条。谁导的？导去哪了？日志只记了账号，没记IP。这等于门锁着但钥匙插在门上。

整改从当天晚上开始。先把那张表的访问权限砍到只剩两个系统账号，其他全禁。然后写脚本把存量数据加密——手机号用AES-256，身份证号额外加盐哈希。跑脚本那晚我盯着屏幕，进度条每走一格，心里就松一点。凌晨三点跑完，确认没有漏网字段。第二天把导出功能加了二次审批，超过1000条自动触发风控告警。

但光堵技术漏洞不够。我翻了翻内部wiki，发现数据安全规范上次更新是2021年，里面还在用“建议加密”这种词。建议？这又不是劝人早睡。直接改成“必须加密，违者按事故处理”。另外把离职账号清理流程从“IT手动查”改成“HR系统自动触发”，离职当天权限全灭。测试那天我故意用前同事账号登录，提示“账号不存在”，这才算踏实。

有个细节让我后怕。那张表里还有200多条未成年人信息，是之前做教育类活动留下的。如果泄露，就不是罚款能了事的。我们给这批数据单独做了标记，访问需要法务和合规双签。法务同事说“早该这样”，我苦笑，早该的事多了。

整改报告写到第三版才过。第一版被批“太技术”，第二版被说“没重点”。第三版我直接列了张表：风险点、整改动作、责任人、完成时间。每行后面附上验证截图。比如“明文存储”对应“已加密”，截图是数据库里显示的一串星号。领导看完说“这还差不多”。

现在每周五下午我会跑一次敏感数据扫描。脚本会检查所有表里有没有疑似身份证号格式的字段，有就发邮件告警。上周扫出两个测试库里的假数据，虽然虚惊一场，但总比真出事强。同事说我太紧张，我说你试试半夜被电话叫醒说数据泄露的滋味。

最后说个观察。很多公司把数据安全当消防——着火才救。但敏感信息泄露这事，救不回来。用户身份证号一旦流出去，就像泼出去的水，道歉信写一万字也没用。所以别等出事再整改，平时就得把权限管死、把日志记全、把加密做成默认动作。这行没有捷径，只有笨功夫。