“从入门到删库到跑路”！

原本一个口头禅笑话 ，居然神奇般的发生了，而且还是一个有着3700员工、在香港上市的公司。

这童话般事件的发生了，暴露了从技术到管理、安全合规，风险管理甚至公关都有很大的问题。不知道这3700名员工中有多少人是在这些部门，不过我认为这些部门的人90%都可以开除了。

管理上方面员工管理，员工岗位培训、安全保障培训有没有到位，安全和保密协议都有没有签，人力资源对员工状态了解够不够，有没有专门指导和帮助机制？员工权限控制做到了么？运维、开发、安全和DBA有没有分工，有没有专职人员？员工有没有操作互备和相互确认机制？

从技术上方面架构系统架构上首先不合理：数据库为啥没有做多层架构（数据库，缓存、内存数据），没有分布式架构（分区，分库，文件系统分布式存储）。

备份

数据备份机制有没有，数据备份检查有没有？数据回复机制有没有，灾难演练有么有做过？冗余热备库有没有？

审计和告警

监控告警有没有、操作和数据审计有没有。

从公告中内容，操作审计是没有，以至于要大量时间反向追踪查找IP和用户。正常情况下应该是在事故发生时间，异常登陆和操作发出告警。然后是服务器、和数据应用告警，然后是业务上告警。在业务发生告警时候，应该马上就能查到什么时间、来源IP，谁操作了什么。

一般来一个合格的跳板机或者堡垒机都可以实现操作审计，对异常和破坏性操作予以告警和预先阻止，一个大型的公司应该是必须满足的，有专门商业产品可供选择。

小公司和团队也可以选择开源软件方案，也能满足绝大多数的审计和告警需求。比如Gravitational的Teleport工具就可以满足对SSH会话的安全审计，有关这个工具可以参考虫虫最新一篇文章介绍，Teleport用BPF增强SSH会话的安全审计技术方案。

安全合规，风险管理方面

在数据备份上和告警上，审计上都没有做到，说明安全和合规团队是不存在或者完全失职的。按照国家对一个在线商务运营的资质要求来说合规方面应该都要有相关资质要求和措施年检要求，至于怎么拿到资质备案和满足年检这也是值得要问的问题。

公关方面从涉事后公告中直接暴露了和各种细节方面的问题来说公关团队的也是失职的。还有晚上爆了的该员工、其媳妇以及公司高管方面种种小道爆料来说说明公关方面也做的不到位。