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

数人云“告别人肉运维”上海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的延迟备份来保障饿了么整个数据的安全，这样的架构体系为数据安全提供了多层保障。

总结