数据泄露的案例；多半坏在权限太宽

权限给宽这件事，在出事之前基本没人当回事。上线赶时间，数据库账号直接拿最高权限，测试环境和生产环境共用一个连接串，外包进来先给管理员，当时都管这叫方便。等真出了事再回头翻，公开报道里的数据泄露的案例，很多压根不是被人硬攻进去的，是门本来就没关严，钥匙还配了一大把。

数据泄露的案例里，多数门是钥匙配多了

看多了这类复盘，会发现一个共同点：入侵路径短得离谱。不是零日漏洞，不是供应链投毒，就是某个后台账号能查全库、某个接口没做鉴权、某个备份文件躺在公开可读的目录里。攻击者不需要什么技术含量，翻一翻、试一试，门就开了。真正难的那部分，反而是防守方自己：谁有这个权限，什么时候给的，给到哪张表，没人说得清。

这里面有个很尴尬的现实。安全设备买了一堆，WAF、堡垒机、告警平台都上线了，可权限清单还停留在某个人脑子里的印象。问一句“这个库账号谁能连”，回答一般是“开发都能连吧”。这种回答背后的意思就是，没人管。

一个账号走天下，省的是谁的事

项目早期图快，后端连接数据库就用一个高权限账号，读写删一把梭。业务跑起来了，谁也不敢动它，怕改出问题。报表要导数据，拿的还是这个账号；运维上去查个字段，也是这个账号；连临时跑个脚本，连接串复制粘贴，还是它。结果就是，日志里所有操作都长一个样，事后想追是谁干的，追不动。

更麻烦的是这个账号往往还写在代码仓库里，或者散落在几个配置文件里。代码库权限一松，等于把数据库钥匙也一起送出去了。这种事不新鲜，每年都能见到类似的公开复盘，只是当事方通常不会把细节讲太细。

权限是一步步被撑宽的

很少有人在第一天就主动给全库权限，都是被逼出来的。开发说这张表读不到，运维顺手授一下；业务说这个字段要更新，再授一下；后来加了新库新表，懒得细分，直接给整个库。授权这个动作有，回收这个动作基本没有。半年下来，一个本该只读三张表的账号，权限列表能拉出一长串。

所以别老盯着“有没有被黑”这个问题。先问一句：现在生产库上有多少个账号，各自能碰什么，最近一次复核是什么时候。答不上来，那就不是有没有风险的问题，是风险有多大、什么时候露头的问题。

备份和导出，往往泄得最狠

数据库本身防护做得还行，结果栽在备份上。这种案例网上一搜一大把：备份文件放在站点根目录下，名字还特别好猜；导出的表格丢在服务器桌面，一放几个月；对象存储的桶设成公开读，链接被人顺着爬。备份里的数据量和完整度，通常比线上能查到的还高，一旦流出去，损失反而更大。

这块的处理其实不复杂。备份目录放到 web 根目录之外，桶设私有，导出文件加个到期清理的规矩，敏感库的导出走单独的只读账号，别再共用那个全能账号。做起来都是小事，难的是有人真的去检查一遍。

离职、外包、临时账号，最容易漏

人员流动这块是重灾区。员工走了，账号还在，邮箱还能登，VPN 还能连，只是没人用。外包团队进场，图省事给个管理员，项目结束合同一结，权限留在那。还有那种“就用两周”的临时账号，两周过去半年还在。

合理的做法是给账号带上寿命。外包用临时账号，设到期时间，用完就停；关键系统走跳板机，操作留痕；离职流程里加一道权限回收，跟交还电脑一样是固定动作。这些不是技术问题，是流程问题，流程不写死，全靠人记，早晚会漏。

日志没记全，事后只能靠猜

权限收窄是一半，另一半是留痕。数据库的审计日志没开，或者只保留很短时间，出了事就只能看应用日志猜。账号又是共用的，日志里全是同一个用户名，猜都没法猜。

建议把敏感表的访问单独记一份，谁在什么时间导了多少行，至少能查。日志本身也要管权限，别让它变成新的泄露源。保留周期按业务需要定，太短没用，太长又占地方，这个得自己权衡。

权限复核别搞成一年一次的仪式

很多团队也做复核，一年一次，打印一张表大家签个字，签完照旧。这种复核基本等于没有。比较实际的做法是把它拆小：新授权必须写清楚用途和期限，到期自动提醒；每季度拉一次账号权限清单，和业务对一遍；发现长期没登录、权限又大的账号，优先处理。用脚本定期对比权限表，比人眼看靠谱。

把口子收窄，有几件事今天就能做

不用等安全预算批下来。业务账号按库拆开，只授需要的表，主机那里别用百分号通配，写具体 IP；读写账号分开，报表和导出走只读；生产库不让测试环境连；连接串别进代码库；超管账号不共用，操作留记录；备份和导出文件离开站点目录；离职和外包账号当天处理。这几件做完，能挡掉一大半常见情况。剩下的靠持续检查，别指望一次配完就永远安全。

最后留个自查的引子：打开数据库，把所有账号和对应权限列出来，逐个问一句“它为什么需要这些”。答不上来的，先收掉再说。出事之后再补这一课，代价通常不是技术能解决的。