活动实录|拒绝"删库到跑路"，探究饿了么数据安全保障体系

数人云“告别人肉运维”上海Meetup的实录第二弹来啦！本次分享的嘉宾是饿了么DBA团队负责人虢国飞。实录将从用户访问、数据库架构体系、数据备份、数据流转和数据操作等几个方面介绍饿了么目前在数据安全方面的一些措施。

虢国飞 / 饿了么DBA团队负责人

从事数据库领域10+年，主要关注于数据库管理自动化建设和MySQL、Pg、MSSQL、NoSQL等领域的研究。

本次主题关于数据安全的保障。前面的引子是Gitlab数据库出现问题，它有五重的数据保障，但都失效了。开始之前有几个问题：

1. 在座很多是做运维或数据库工作的，现在公司数据库有备份吗？

2. 如果数据库有备份，多长时间做一次还原测试来验证数据库的备份是不是有效？

3. 有没有一个月之内做一次整个备份检验的？在一个月之内做一次，比如一年做十次或者十二次还原检验？

带着上面的疑问，我分享一下饿了么在数据安全上所采取的一些措施，包括备份和还原的方式，与大家一起探讨。

本次活动主题是如何减少人肉运维，让数据库运维和业务运维实现自动化。为什么做到保持有备份，并且验证备份有效的公司不是那么多呢？关键在于资源，资源不光包括硬件资源，也包括人力资源。如果通过人肉方式时刻保证整套系统持续有效运作，成本相当高。

数据访问

数据在入到数据库之前，可能会面临一些注入的攻击甚至拖库等风险。用户访问数据库的时候，饿了么有一个中间层叫做DAL层，如果做一些分库分表的应用很多时候都会运用这一中间层软件，开源软件有此类功能的也很多，像mycat、atlas等。

在这一层，饿了么做了一些数据方面相关的保护。首先，因为有中间这一层，所以在底层数据架构方面对研发或者对外都是一个不透明的状态，拿不到具体数据库IP地址，我们只把这些敏感的信息开放到有限的一些人的手里；第二层面，在DAL层把一些敏感的信息全部加密掉，比如用户名、密码这种访问数据库的信息；第三，会对风险的SQL做一些限制，比如一次要拉一百万数据的SQL，是不支持的，或者想drop一个表，这样的风险动作都会屏蔽掉。

饿了么对外开放的一些权限在账号部分也做了限制：

首先，每个业务都是专用的账号，不会多业务共用一个账号；

第二，账号权限是最小的，一般就是增、删、改、查，有的甚至是只有增、改、查三个权限，删除权限都没有，所以账号风险是最小化。还有一个是对内网的网段去做限制，在账号赋权的时候限定它能访问的网段；

第三，SQL限制讲过，DAL层会做一些相应的限制，在数据库一层也可以去做，比如一些更新的SQL是不带条件的，这时可以限制掉，包括删除的动作。如果没有带条件，这个风险是很高的，一般认为都是有问题的，所以这部分风险会在数据层去屏蔽。

在数据访问上，主要把信息进行一个屏蔽以及加密，以及对权限和操作的动作做了一层保障。DAL的架构在中间层，也是相当于对数据库提前做了一个访问控制和负载均衡层，当然它的功能不止这一点，还包括刚刚说的路由，一些紧急SQL的屏蔽等。

数据流转

数据进来之后会面临各方需要使用数据的问题：
首先，在DAL这层进到生产数据库的时候，在入口这一端做限制；
第二，数据落到相应BU生产数据库的时候，如果这些数据要给其它BU去访问，数据应该如何提供？目前比较通用的方式是通过接口，某个BU去调用其他BU一些相应的业务接口提去数据。如果接口提供不了的话，跨业务的访问也走DAL层，DAL会把所有访问的痕迹记录下来。对于生产的数据，现在有很多研发会要求在他们的alpha和beta环境去做压力测试，要同步生产的数据，还有需要查生产的数据，但这些数据可能包含敏感数据，怎么办？

饿了么开发了一个DBQuery的软件。对研发来说DBQuery能提供能查生产的数据，然后导出生产的数据，同时还能够把数据同步到其它的环境，但是这些操作都是受限的。首先它能操作的数据量是有限的，一些敏感的记录会做脱敏的处理，所有研发人员在上面所做的操作都会被记录下来，例如在上面做的导出动作、拉取数据、查询等。如果是这个平台本身不能支持的需求，那么会联合DBA和安全团队去做把关，比如要对第三方提供一些大数据量的数据，这样会有安全的保障。所以数据流的控制从入口，跨业务团队的访问，以及到不同的环境数据同步，包括研发想查看的这些记录，都会记录下来它的操作，以及对这些操作做相应的限制。

备份还原

DBA最重要的一个责任——数据库的备份和还原。饿了么的方案和大家所知道的或所了解的都差不多，但是如何把它做到或者更好的做到，各个公司都会不一样。饿了么有全量、增量、以及Binlog的备份，然后会拷贝到Ceph做保存，包括本地的备份和远程的备份。关键的第三点，它能够完成自动的部署、运行和监控。一个业务上线的时候，因为有标准化，上去之后，备份就自动跑，如果没有备份，就会收到告警。运行得正不正常，或者备份中失败了，或者没有运行备份，都可以通过监控的一个界面看到情况，备份的时长以及什么时间点去做的、在哪些机器上去做的，都是自动在后台运行的。

数据还原也是如此，有一个循环的周期。饿了么重要数据验证周期是15天。因为有好几百套DB，15天到一个月，重要的是15天会验证一次，一个月周期的是不太重要的一些业务，都会在循环的周期去做验证。验证除了检验备份的可靠性以外，还有一个目的，即拿到数据还原的时长。研发或者领导会问如果现在某个数据库出现了问题，多久能够找回来或者还原回来数据？这些都是需要数据支持的。它还可以去抽样，除了它自己循环去检测的，可以随时拉一个库出来，还原到哪个时间甚至哪个点位都是可以的。饿了么通过平台去实现，不需要找机器、再找被分在哪里，只要告之要还原的是哪个库，想还原到什么样子，维护成本很小。

上图右侧截图里有一些应用的时间以及它的状态是成功还是失败。

DBA操作

除了在防范数据入口的时候对业务的数据进行一些控制，还要在底层做一些备份还原保障，另外DBA的一些操作对数据安全也相当重要，这部分出问题的情况也不少。在如何保证DBA操作的安全方面，很多公司都会有各种各样的军规。

类似的军规饿了么也有，但现在慢慢淡化，因为军规是与人相关的因素，特别不可控，饿了么之前做军规的时候把那些操作的风险都分了不同的类，一个要求是能保证操作的时候能够快速的回滚，举个例子，比如清空一个表的数据应该如何做，因为有时风险很大。我们的处理方式是先把这个表去rename一个待删除的表，放一周之后会有自动的任务再去清理这个表。如果操作的时候出现问题，那可以马上让它rename恢复过来。还有一个限制是风险操作在操作的时间上做限制，不能在业务高峰时间去做这些动作，是有一个维护的窗口期，在业务的低峰期才去做。这样能够保证一旦出问题损失最小化，虽然我们能够快速恢复，但是如果在高峰时间操作其影响仍然很大，如果选择有维护窗口期的话，损失是最小的。

之所以讲淡化军规是因为现在饿了么想做工具化，这个工具里最重要的是把高风险操作的流程步骤固化到工具里面，让工具去操作，人就不用太在意操作的流程是不是OK的。有些做不到的流程，它也会提示出来有什么风险，操作的时候会给DBA一个相应的警告。工具化之后，很多操作就可以在后台自动运行了

以上实际在生产上面跑的一些需求，红色的部分大部分是自动执行的，因为平台上线的时间才几个月，之前这部分全是DBA在操作的，现在有很多任务DBA不需要自己操作，由后台的系统任务去调度起来，基本上没有风险，所以需要关注的点就变得越来越少了，人力也可以解放出来把这个平台做得更好。饿了么今年正在做一个开发的自助平台，设计的目标是研发能够在上面完成数据库的一些操作，包括数据归档，加表等动作，符合平台验证规则的话DBA不需要干预。

架构保障

上图是饿了么现在架构的情况。首先有两个机房，A机房和大家主流的部署架构差不多，即主从的一个架构。有一台特殊的机器DS（DelaySlave），它会保持与生产数据的数据同步有一个时差，比如它会延后一天或者是半天的时间、12小时，如果生产操作出现了问题，就可以快速的通过它回放到操作前的一个点把这些数据找出来。这样的恢复速度是最快的，追回的时间仅要几分钟。它不光提供半天之内数据快速恢复，而且饿了么的备份也都在上面做，这样备份的时候不会影响到生产运行。哪怕这台机器上跑很多的备份任务都不会影响，因为它主要是做数据的备份，而且监控就是在标准化部署这一台之后，所有的备份任务和监控程序都会自动与它做匹配，所以只要完成这一架构的搭建，接下来的事情系统自动去做，也不需要人肉干预。如果它没有备份成功或者备份失败或者跳过了备份，在监控备份和还原监控里面都会得到体现。

下面这是做还原的一部分机器，我们是循环周期去做还原的，所以它在一个周期内必定会完成这些库的校验，验证它的备份是否有效。在另一个机房，中间有一个组件叫DRC，这个软件最初淘宝做得比较多，即跨机房的一些数据的同步。它提供了数据同步和订阅的功能，监听数据库状态的变更，而且在多机房之间同步的时候可以做很多动作，比方如数据的压缩、过滤，还有刚刚提到的数据订阅，出了问题它可以上报。此外，有一个特殊的机器叫QS，DBQuery服务的功能就部署在它上面，在上面会完成研发对数据的查询以及数据从它到各个环境的导入、过滤和脱敏。

从整个架构体系对数据的保障来看，一是有多机房，二是主从的HA，以及DelaySlave和一些备份机制。从数据入进来到DAL层、到数据库里面针对一些账号权限的限制以及架构的保障和备份、还原体系的完善以及DelaySlave的延迟备份来保障饿了么整个数据的安全，这样的架构体系为数据安全提供了多层保障。

总结