内部竞争导致员工恶意删除公司核心项目数据库

我一个做数据库运维的老同学跟我讲过一件让他至今说起来都叹气的事。他之前在一家中型互联网公司负责数据库管理，公司内部有两个业务部门长期不和，为了争预算、争资源、争老板的认可，已经明里暗里较劲了好几年。有一次公司战略调整，把明年的重点项目资源倾斜给了A部门，B部门的负责人当场没有说什么，但会后整个部门的士气明显低落。没过几天，公司突然发现A部门正在研发的新项目数据库全部无法访问了。技术人员排查后发现，数据库被人用管理员账号远程登录后执行了删除指令，核心业务表被全部清空，连备份库里的数据也被人为删除了。更糟糕的是，这个数据库里存放的不只是A部门的代码和数据，还有即将发布的版本的全部配置文件和测试脚本，整条产线因为这个操作陷入了全面停滞。后来通过安全日志追溯，发现执行删除操作的账号是数据库管理员的一个高权限账号，而这个账号在系统里有好几个人都持有。锁定嫌疑人花了一段时间，最后发现是B部门的一个技术总监，利用他当年做DBA时遗留的管理权限，在深夜远程登录后执行了删除操作。他之所以能做这件事，是因为公司在人员转岗和离职时，没有同步回收IT系统的权限，他已经从技术部门转到业务部门一年多了，但数据库的高权限还保留着。

这个案例里的风险点其实非常经典。权限回收滞后是企业内部安全最常见的漏洞之一，尤其是在人员流动比较大的公司。员工从技术岗转到业务岗、从开发转到产品、从一个部门调到另一个部门，对应的系统权限却没有同步更新。旧账号的权限留得越久，被恶意利用的可能性就越大。不光是离职的人需要关权限，转岗的人也必须要清理和重建权限。另外，这个案例还暴露了一个很重要的问题：高权限账号没有做操作复核。在企业的核心数据库上，执行删除操作这种危险动作，至少要有一个"双人复核"的机制。一个人发出指令，另一个人确认，系统才能执行。如果当时有这个机制，即使技术总监还能用那个老账号登录，他一个人也无法完成删除操作。还有就是内部监控的缺失。半夜三更有人用管理员账号登录核心数据库，系统没有发出任何告警，这本身就是一个很大的安全缺口。日常运维中如果给关键操作加上实时告警，很多损失是可以被控制在萌芽状态的。

这件事给我最大的触动是，企业的安全管理不能只盯着外部黑客，内部员工的恶意行为往往破坏力更大。我常常建议企业把安全管理分成两条线：一条防外部，一条防内部。防内部的措施其实在技术上并不复杂，关键是在管理上要敢于执行。操作审计、权限定期回收、敏感操作复核、异常行为告警，这几样东西只要认真配置好，绝大多数内部恶意操作都能被拦截或者发现。