写技术白皮书的目的是：
①培养大家从行业角度做宏观综述的能力；
②保证团队技术的可传承性，一份份白皮书仿若一本本九阳真经，至少有个复盘的本本留下来。
好，下面就开始这份（防）删库跑路技术白皮书。
删库跑路是一种历史悠久、后果严重的公司资产损坏事故，一旦发生，轻则业务短时间不可用，重则公司倒闭关门，甚至有人为此坐牢。
对于这种重大经营性风险，经历过挂牌上市的公司都有方法机制预防和应对。生产环境安全保障的流程制度是否健全，也是审计机构重点核查的对象。与其审计机构进场的时候临时抱佛脚，不如你仔细阅读本文，未雨绸缪，把该做的工具做好，把该建的流程规范建好。
1.1 微盟删库后被刑拘
最近一次也是最为人所知的是香港上市公司微盟集团删库。在这次运维工程师“含恨”出手连根擦除、应用服务中断整整九天的事件里，微盟被删除的数据体量达到了数百TB。最后这位贺姓员工被判处有期徒刑6年。有诗为证：一键惊神删主备，SaaS凭空起风雷。身负重责莫自弃，我心光明道不移。恢复小队通过审计日志可以看出，2020年2月23日19时许，微盟的贺姓运维工程师删除了微盟业务数据，甚至下了死手删除了备份数据文件。微盟被删的数据分为两部分，一部分是存放在自建数据库里的现网业务数据，部署在数据库服务器上；一部分是存放在备份服务器上的备份数据。因为是文件删除操作，两种服务器里的文件都是碎片化记忆，且不可见。二者区别在于，数据库服务器中的残存文件数量多，类型繁杂；而备份服务器文件类型单一，数据集中。
经过相对常规的操作，2月17日及以前的所有数据都找回来了。2月28日，微盟拿到2月17日的备份数据后，恢复所有业务线上生产环节，老用户可登录后台，微站产品所有数据重新上线。但这还不够，腾讯云技术团队和数据恢复公司还需要通过打捞小文件拼接大文件的方式继续恢复后续的数据。
图2 前线工程师在做拷贝数据
每一次拼接，都要数据从头到尾扫描一遍，匹配是否成功。为了加快扫描和验证，需要强大的计算力，腾讯云临时调用腾讯上海机房 100 台服务器做支持。如果能顺利推进，整个过程可无障碍执行，一旦出现问题，就要推翻重来，一次需要 12 小时。经历了无数次“打捞、扫描、拼接、验证”后，终于，最大的一个核心数据文件在2月28日晚上找回来了，它由 7 个碎片组成。
3月1日晚，微盟发布公告说，由于此次数据量规模非常大，为了保证数据一致性和线上体验，3月2日凌晨2点进行系统上线演练，3月3日上午9点数据恢复正式上线。同时发布了1.5 亿元的商家赔付计划。
这份公告对这次事件也进行了反思：“没有严格按照公司的内控管理制度，对运维人员的权限进行分级和分区管理。”这次事件中的最大问题在于，权限管理过于简化，没有严格划分业务场景并且梳理最低的操作权限需求，导致了超级管理员的出现，而恰巧超级管理员出现了不轨意图，给企业造成了重大损失。
“你让我评价这件事，我第一感受是不要再发生这种事情了，企业的IT治理一定要把安全放在第一位。”恢复数据作战总指挥徐勇州说，“微盟是幸运的，能100%找回数据是奇迹，但如果再发生一次，未必有这么幸运了。”
依据《刑法》第 286 条（对计算机信息系统功能进行删除、修改、增加、干扰，造成计算机信息系统不能正常运行，后果严重的，构成“破坏计算机信息系统罪”）以及相关司法解释，“删库跑路”如果造成 10 台以上计算机系统不能正常运行就可以判刑，如果影响 50 台以上则至少判 5 年。即“删库跑路”的量刑标准与影响到的计算机系统数量有关。
毫无疑问，以微盟的体量，贺姓员工量刑至少五年起。微盟如此惨痛的教训，唤起了我们更多的记忆。
1.2 顺丰删库后被辞退
2018年9月，顺丰科技运维高级工程师邓某在接到变更需求后，按照操作流程要求，登陆生产环境跳板机，在选定删除时，光标回跳到 RUSS 库的实例，在未看清所选内容的情况下，便通过 delete 执行删除，同时邓某忽略了弹窗提醒，直接回车，导致 RUSS 生产数据库被删掉。因为运维工程师一个不严谨的操作，导致 OMCS运营监控系统瞬间崩溃，他的结局是被辞退。
图3 顺丰内部通报邮件
1.3 删索引也会判刑
邱某2014年入职到杭州的一家科技公司，担任技术总监。因老板逼其离职，2018年6月23日就在自己家里面远程登上了公司在阿里云的数据库，当然为了不过早暴露，他选择删除了数据库上的一些关键索引和部分表格，但最终仍造成公司经济损失。因邱某自愿认罪并赔偿了公司8万元，杭州市余杭区人民法院酌情予以从轻处罚，并对被告人邱某判处有期徒刑二年六个月，缓刑三年。
1.4 广西移动用户数据被误格式化
2017年9月，某企业技术工程师帮助广西移动进行扩容割接（即增加系统容量）时，不小心将 HSS 设备里面的用户数据格式化删除，导致广西移动近 80 万用户数据丢失。
2017年6月10日，Verelox（一家提供VPS、服务器出租和托管的云主机服务商）贴出公告：不幸的是，一名前任管理员删光了所有的客户数据，并且擦除了大多数服务器上面的内容。正因为如此，我们已采取了必要的步骤或措施，暂时将我们的网络下线。我们一直在努力恢复数据，但是这个方法可能恢复不了已丢失的所有数据。
2017年4月5日，位于纽约的云服务商Digital Ocean 也遭遇了系统删库：由于配置错误，本应指向测试环境的任务被指向了生产环境，测试任务包含的环境初始化过程删除了主生产数据库，由此开启了一次长达4小时56分钟的停机事故。
2017 年 2 月，gitlab 的一位荷兰籍DBA 在深夜给线上数据库做负载均衡工作时，遭受了 DDoS 攻击。在阻止了攻击之后，又发现了数据库不同步的问题，于是开始修复。在修复的过程中，他发现 db2.staging都 hang 在那里，无法同步，于是他想把db2.staging
的数据库删除了，这样从新启动一个新的复制，结果，删除数据库的命令错误地敲在了生产环境上（db1.cluster）：sudo rm -rf这是一个包含了 300 GB 实时生产数据的文件夹，等到他彻底清醒过来急忙按下 CTRL+C，只剩下 4.5GB 数据……由于没有有效的备份，尝试了所有5个恢复工具都没有完成恢复，gitlab 被迫下线。
一桩桩一件件，触目惊心，我们不能等到事件发生之后，再来悔恨，再四处求助恢复数据。
除了删库跑路之外，我们其实还会遇到其他高风险以至于鸡飞蛋打。
常见的是云数据库 RDS 实例故障，比如我们曾经在就餐午高峰遭遇突发的主数据库 CPU 100%，谁也连不进去，整整 45 分钟。我们还曾遇到过阿里云单机房网络不可用，完全连不进去，整整三个小时。这时候如果企业有多活机房，则可通过其他机房的数据进行恢复。如果只有单机房，只能根据异地备份文件来恢复。
底层存储并不一定总能访问到，如果你要恢复数据，最好有一份异地备份文件。2018年6月27日下午，阿里云工程师团队在上线一个自动化运维新功能中，执行了一项变更验证操作，触发了一个未知代码bug，从而禁用了部分内部IP，导致全国大量客户投诉云存储 OSS 产品无法访问，也就是数据不可见了。
2.3 实例误释放灾难
云数据库实例一旦被误释放，数据和备份会都被删除，那将是塌天大祸。这时候如果有多活机房，则可通过其他机房的数据进行恢复。如果只有单机房，只能根据异地备份文件来恢复。
2.4 程序误删误覆盖灾难
BUG 上线产生了大量脏数据，或删错了很多数据，可通过“数据备份”和“日志备份”功能恢复到指定时间点。如果只是少量数据错误，可通过回滚 Binlog 日志文件进行修复。很多年前，我们就曾经在头一天晚上发布了一个版本，到了第二天上午八九点收到了洪水一样的投诉，这才发现大错已经酿成，追悔莫及。当时还只有单机房，只有凌晨的常规数据库备份，足足花了一天时间才将数据悉数纠正。
同上，我们对订正线上数据也非常谨慎，尤其是当一个新业务刚上线不久，管理后台功能尚未完善之际，运营人员经常会找研发刷库，而且通常会很急。急急忙忙编写刷库脚本的，与经过开发、联调、测试、上线完整流程的，就是不一样。不是不可以刷库。但请记住，经常刷库就一定要做成系统功能，常在河边走，难免会湿鞋，出了事儿就是大事儿。既然会遇到如此多灾难，那么我们应该如何防患于未然呢？
防范删库跑路，本质上还是一个数据库安全的问题。对于这个问题，业界早有定论。盖国强曾经撰写过一本书：《数据安全警示录》，提出了数据安全的五个纬度，可以基于这五个纬度来梳理企业的数据安全，并据此建立相应的安全防护措施。这五个纬度分别是：软件安全、备份安全、访问安全、防护安全、管理安全，它们可能会导致两种性质的安全问题：一）内部威胁：由于内部管理不善而导致的数据安全问题；二）外部威胁：由于外部恶意攻击入侵所带来的安全问题。通常我们把安全问题狭义化为后者，这实际上是片面的，在数据安全问题上，前者造成的数据损失、数据损毁，其发生概率和影响度都远远超过后者。
3.1 数据安全五大方面和十六条建议
下面对数据安全的五大方面做一个简要分析：
一）软件安全：指的是我们选择的数据库产品、版本是否稳定安全，厂商所能提供的补丁集和BUG修正是否及时，基础硬件与操作系统是否经过认证。很多用户在部署数据库软件时，仅仅选择了最容易获得的初始发布版本，遗漏了可能已经存在的补丁修正，并且在运行维护中并不能够及时跟踪软件更新，也无法获得BUG信息、补丁修正和安全告警，这就使得软件本身的很多风险隐患得不到修正。如果软件安全无法保证，数据库安全的基础也就丧失了。
二）备份安全：指用户数据能否得到及时有效的备份保全，能否在故障灾难之后获得及时的恢复和挽救。在数据库运行期，最为重要的就是备份安全，如果没有可靠的备份，将数据集中起来就只能是等待数据灾难，所以我们将备份安全提升到核心地位，备份以及随之衍生的容灾安全等，都是企业整体数据架构应该考虑的因素。很多企业在数据灾难之后因为缺乏有效备份而一蹶不振。根据 Gartner
早年间一份调查报告显示，在经历了数据完全丢失而导致系统停运的企业中，有五分之二再也没能恢复运营，余下的企业也有三分之一在两年内宣告破产。由此可见，由于备份安全问题导致的企业伤害可能远远大于黑客攻击。
三）访问安全：指用户数据库的访问来源和访问方式是否安全可控。通常数据库系统处于IT系统的核心，其安全架构涉及主机、系统、存储、网络等诸多方面，如果没有明确的访问控制，缺乏足够的访问分析与管理，那么数据库的安全将是混乱和无法控制的。在应用软件使用和访问数据库时，要正确设置权限，控制可靠的访问来源，保证数据库的访问安全，唯有保证访问安全才能够确保数据不被越权使用、不被误操作所损害，通常最基本的访问安全要实现程序控制、网络隔离、来源约束等。
四）安全防范：指通过主动的安全手段对数据库通讯、传输等进行增强、监控、防护、屏蔽或阻断，诸如数据加密、审计、数据防火墙等技术都在这一范畴之内。我们必须认识到，在IT技术高度发展的今天，风险是无处不在、层出不穷的，可能我们从未思考过的安全问题，每天都在不断涌现，所以在数据库环境中采取主动式防护，可以帮助我们监控分析和屏蔽很多未知风险。
五）管理安全：指在企业数据的日常管理维护范畴内，能否充分保证数据安全以及服务的高可用连续提供。诸如DBA的维护、文件的管理、参数或数据结构的变更等等都可能引入数据风险，管理安全要求我们通过规范、制度以及技术手段去确保维护管理安全。
另外，基于硬件、电力等基础平台的故障都可能影响数据库服务的高可用性，在管理中要通过监控手段及时预警，通过集群、备库等切换与服务分担保障服务的连续性。
基于以上分析，盖国强进一步提出了 16 条建议：
<1>备份重于一切：DBA四大守则的第一条就指出，『备份重于一切』。有了有效的备份，即使遭遇灾难，也可以从容应对。唯一会让DBA们从梦中惊醒的就是：没有备份！所以对于数据库运维来说，第一重要的是做好备份！有备方能无患！
<2>严格管控权限：过度授权为数据库埋下安全隐患，所以在向用户授权时一定要遵循最小权限授予原则，避免因为过度授权而带来的安全风险。微盟这次安全风险，如果用户只具备最低权限，那么也不会遭遇如此灾难。
<3>明确用户职责：应当明确不同的数据库用户的工作范围，应当使用普通用户身份的，就绝对不应该使用DBA的用户身份。只有职权相称，才能够避免错误，降低风险。即便是拥有管理员职责的用户，也应当遵循以不同身份执行不同任务的习惯，比如SYS和SYSTEM用户的使用就应当进行区分和界定。
<4>密码策略强化：毫无疑问，数据库用户应当使用强化的密码规则，确保弱口令带来的安全风险，很多数据泄露问题来自弱口令攻击和提权。
<5>限制登录工具：明确限制不同工具的使用场景，明确规定工具的准确来源，或者通过堡垒机等来限制数据库访问。对于工具也可以做出明确规则和限制，如限制仅能通过SQL Developer访问生产，PL/SQL Developer工具仅能访问测试环境，以减少安全风险甚至误操作风险。
<6>禁止远程DDL：可以限制DDL操作仅能在数据库服务器本地进行，禁止远程连接执行DDL操作，这一手段在很多（未上公有云的）公司被严格执行。
<7>使用绑定变量：在开发过程中，严格使用绑定变量，绑定变量可以防范SQL注入攻击，减少数据库安全风险。这次安全事故，很多用户开始猜测是SQL注入，走了很多分析上的弯路。
<8>监控监听日志：监听日志记录了数据库访问的来源、程序等信息，包括恶意扫描，密码尝试等，一定要重视监听日志的作用，并对其进行分析和监控，以清楚地绘制数据库访问图谱。
<9>数据网络隔离：数据库的网络环境应该一直隐藏在最后端，避免将数据库置于直接的访问连接之下，由此可以减少数据库的访问风险。
<10>测试和生产环境隔离：环境互通就意味着同时可以访问，也就可能带来很多意想不到的安全风险。企业应当将测试环境和生产环境部署于不可互通，或者不可同时访问的网络环境中，避免因为错误连接而发生的数据库灾难。分离部署一方面可以降低误操作的可能性，也可以屏蔽一些无关的访问可能，从而从网络链路上保证数据安全。
<11>密码差异设置：有些测试环境或者非产品环境是利用产品环境恢复得到的，DBA在建立了测试环境后，就没有修改数据库用户的登录密码；经常性的，DBA也习惯在所有环境中设置通用的密码；这些习惯为系统带来了很多风险和不确定性。特别建议用户在不同环境中采用不同的密码设置，这是因为一方面产品环境和测试环境面对的访问用户不同，密码设置相同则意味着产品环境的安全性完全得不到保障；另一方面，DBA登录到不同的数据库需要使用不同的密码，这进一步减低了DBA在错误的环境下执行命令的可能性。
<12>重要数据加密：很多重要的数据，需要加密存储，最典型的就是用户和密码信息，大量的泄密事件本质上是因为缺乏最基本的加密防范，对重要数据实施一定的安全防护加密，是应当予以适时考虑的安全方面之一。
<13>适时的软件升级：这里的软件指数据库软件。
<14>防范内部风险：不可否认，绝大部分安全问题都来自于企业内部，来自最紧密、最轻易的接触和访问。企业的人员变动，岗位变更，都可能导致数据安全问题的出现，单纯依靠对管理员的信任不足以保障数据安全，必须通过规章、制度与规范的约束才能够规避安全风险。很多企业为了便利而舍弃规范、规章或者安全限制是得不偿失的做法。安全防范应当从内部做起，从限制约束自我做起，当最紧密相关的访问都遵从守则，那么系统的安全性就能够获得大幅度的提升。
<15>树立安全意识：安全问题最大的敌人是侥幸，很多企业认为安全问题概率极低，不会落到自己的环境中，所以对于安全不做必要的投入，造成了安全疏忽。所以安全问题最大的敌人是我们自己，安全需要一点一滴的加强，逐步完善。
<16>开始安全审计：云数据库可能已经提供了一些安全防范的手段和方法。特别建议企业适当展开安全防范措施，开启部分任务审计，定期分析数据库风险，由此逐步完善数据库安全。
3.2 防患于未然的六大法宝
而经历了此次劫难完整过程的腾讯云团队，则给出了六条建议，相比较于事后抢救性恢复，如何避免这样的灾难再次发生，是更为重要的，只要把握住如下六大法宝，就可以防患于未然。
一）建设数据库灾备系统：
数据库灾备系统是基于数据库层的技术和架构来实现对数据的保护，确保在诸如机房故障、地震、火灾等不可抗因素下数据的安全。两地三中心、三地四中心这类叫法其实就是指数据库异地多中心的灾备系统。建立灾备系统的好处显而易见，在业务环境发生安全故障（自然灾备、机房故障、人为误删）的时候，我们可以第一时间切换到异地的灾备数据库恢复数据和业务访问。一套健全的灾备系统可以使最佳复原时间目标（RTO）降低到秒级。目前主流云厂商数据库产品都有配套的灾备产品解决方案，如下图所示。
图7 公有云提供的异地数据库灾备方案
二）有效的备份：微盟这个时候如果没有数据库备份，或者备份没有验证过导致备份文件不可用，就失去了最后一根救命稻草，只能选择走操作系统级别的磁盘文件恢复。即使侥幸能恢复，耗时也会非常之久，导致相当长的业务停机时间。需要注意的是，备份不是简单的工具应用，而是系统化的备份策略。全量备份、增量备份、日志备份的策略搭配、备份异地存储、备份有效性验证都必须考虑到位，把备份当做一个系统工程去建设，而不只是简单的备份工具运营。
对于绝大多数中小型公司来说，一个运维或DBA就能管整个系统，并且拥有整个系统所有主机的最大权限，比如 root。这种集权式的管理就存在“删库跑路”的风险。在运维体系的建议中，我们需要规避这种不受到权限制约的超级用户。建议方案是建立多权分立的权限体系。以三权分立的体系为例，将传统数据库系统 DBA的角色分解为三个相互独立的角色，分别是安全管理员，审计管理员，数据管理员。
基于此基础提出的安全策略，主要细分为三个部分，分别为数据加密、数据脱敏访问、强制访问控制，三者组合提供多个层级的数据安全保障能力。安全管理员、审计管理员、数据管理员这三个角色之间相互制约，消除出系统中的超级权限，从系统角色设计上解决了数据安全问题。
图8 三权分立权限分解图
数据加密是将数据库中的数据通过身份认证、密钥+密码、密钥管理等进行数据保护的技术，是防止数据库的数据信息篡改和泄露的有效手段，通过数据信息加密能够确保数据用户信息的安全，即使数据被非法导出、备份文件被窃取，也无法恢复和访问丢失的数据。对于一些重要的机密数据，如一些金融数据、账号密码、商业秘密等，都必须存储在数据库中，需要防止对它们的未授权访问，哪怕是整个系统都被破坏了，加密仍可以保护数据的安全。对数据库安全性的威胁有时来自于网络内部，一些内部用户可能非法获取用户名和密码，或利用其他方法越权使用数据库，甚至可以直接打开数据库文件来窃取或篡改信息。
1）业务敏感数据加密：调用加密函数，将加密后的结果写入数据库，正常读取的也是加密后的数据，在应用里面执行解密。当然，敏感数据加解密涉及到一定的应用程序改造成本，需要决策层权衡下。
2）数据库内置加密功能：比如MySQL5.7版本推出的数据库内置的TDE 透明数据加密，可对数据库的表空间文件进行加密。现在主流云厂商的数据库产品都有自己的加密功能，可以做到更加细粒度的加密。
数据库审计能够实时记录数据库活动，对数据库操作进行细粒度审计的合规性管理，对数据库遭受到的风险行为进行告警，如黑客对数据库 SQL 注入攻击、异常操作等。因此，提高数据库的安全级别，还需要数据库审计技术支撑。
2）（数据库）对象审计
3）（数据库）用户审计
另外，数据库审计技术还用于监视并记录对数据库服务器的各类操作行为，通过对网络数据的分析，实时、智能地解析对数据库服务器的各种操作，并记入审计数据库中以便日后进行查询、分析、过滤，实现对目标数据库系统用户操作的监控和审计。数据库审计技术可以监控和审计用户对数据库中的数据库表、视图、序列、包、存储过程、函数、库、索引、同义词、快照、触发器等的创建、修改和删除等，分析的内容可以精确到SQL操作语句一级。还可以根据设置的规则，智能判断出违规操作数据库的行为，并对违规行为进行记录和报警。
这一点其实并不是数据库功能系统层面的安全，而是管控制度层面的安全建设。
1）严格管控权限，明确用户职责。遵循最小权限授予原则，避免因为过度授权而带来的安全风险。明确不同的数据库用户能够用于的工作范围，防范和隔离风险。比如：数据库应用账号只赋予SELECT、UPDATE、INSERT权限，取消DELETE权限。把需要DELETE权限的逻辑改成用UPDATE实现，避免被物理删除。
2）密码策略强化。防范弱口令带来的安全风险，定期更换密码，同时生产和测试环境严格使用不同的密码策略。
4）制订规范并贯彻执行，良好的规范是减少故障的基础，全面的规范提升开发和运维人员的标准化。
5）防范内部风险，绝大部分安全问题都来自于企业内部，通过规章、制度与技术手段规避安全风险。比如建立三权分立权限体系。
6）树立安全意识，安全问题最大的敌人是侥幸，制定安全方案，定期分析数据库风险，逐步完善数据库安全。
7）及时打好安全补丁，务必保持数据库为最新版本。因为攻击者可以利用上一个版本的已知漏洞来访问企业的数据库。
腾讯云数据库团队语重心长地告诫我们，微盟删库事故的发生对其他企业的数据安全保护敲响了警钟，仅仅依靠单点防护难以达到真正的安全防护效果，而构建基于全生命周期的安全防护成为必然选择。
前文讲述了很多风险来源和安全规范，那么接下来分享一下我们保障数据库安全的常规操作。
4.1 访问安全类型的预防机制
首先，我们通过自研平台 IDCenter、SimpleWay 配搭 LDAP 服务完成了帐号管理。这样工程师在离职的时候，相关VPN帐号、堡垒机帐号、阿里云帐号均会被删除，再也无法登录生产环境。登录线上堡垒机也都有IP 白名单的限制，只允许公司 IP 访问。
其次，我们依托 JumpServer 来阻断危险操作。JumpServer 是一款由 Python + Django 开发的开源跳板机系统，能够为企业提供认证、授权、审计、自动化运维等基本功能。工程师登录 JumpServer 后，我们在内部屏蔽了一些高危命令，只要有人执行，系统就会强制阻断，而且系统对任何操作都会有审计和历史记录。
最后，开发工程师对线上的服务只有读的权限，没有操作权限。
4.2 安全防范类型的预防机制
首先，与支付交易相关的商业应用需要做到数据脱敏存取。即有可能被开放访问的用户和客户的敏感信息，如手机号，身份证号，银行卡号，密钥，在数据库存储和读取的时候会采用 AES-128 对称加解密，降低万一被拖库后的商业风险。
4.3 备份安全类型的预防机制
我们采用了混合云部署方式，横跨 8 个机房，既有公有云提供的云数据库，也有自行搭建的数据库集群，它们都有相应的备份机制。更进一步的是，我们通常采用异地双活机制，同时还会将数据同步到数据湖里，所以相当于数据做了三地实时备份。如下图所示，环境中有四个机房：主机房，从机房，数据机房，应急机房。
图9 交易系统网络拓扑图
如上图所示，餐饮门店的客户通过智能设备发起点餐或收单请求，第一次请求将默认访问基础域名，而基础域名指向主机房，所以请求将进入主机房。主机房会判定客户真正的业务归属机房以及对应的分片，将对应的动态域名下发给智能设备。智能设备以后的请求都将访问动态域名，请求会直接进入对应的机房以及分片。客户的业务归属机房和分片，可以通过控制台动态调整。调整后，可以快速通知到智能设备，从而做到秒级切换客户流量。主机房与从机房的多活数据（包括数据库数据和缓存数据）保持实时双向同步。主机房和从机房的业务数据变化都会分发到数据机房（即数据湖），所有大数据计算都在数据机房完成。就这样，我们天然地做到了数据多地实时备份。
4.4 管理安全类型的预防机制
我们有工具和流程双重保障。这其中的工具，指的是数据库自动化运维平台（内部代号iDB），这也是一些大型互联网公司所重点关注的IT基础设施之一。它可以做到两点：第一，确保生产环境的变更操作，有审核记录，有操作记录，能回滚，第二，用户岗位职责与系统用户权限相符合，责权利对称。
图10 iDB（数据库自动化运维平台）在IDCenter上的入口
数据存储安全保障，首先是工具的预防机制。
-
帐号密码控制：研发人员只是在 iDB 里为应用访问某个环境里的数据源申请工程帐号而已，部署和上线发布对他来说是透明的，工程的配置文件里密文密码是我们自研的另一个研发协作平台（内部代号CloudEngine）在构建镜像的时候自动完成填充的，他不需要接触到数据库密码。研发人员不知道数据库明文密码，也就没有机会犯错。
-
数据查询权限：研发人员只允许通过iDB查询线上数据，并保留登录和查询记录。
-
数据订正权限：研发人员只允许通过iDB提交DML语句，验证语法正确性、是否使用索引、分表操作是否包含路由字段和单条影响行数等规则，在DBA审核后生成备份并执行，误操作可回滚。
-
表结构修改权限：研发人员只允许通过iDB提交DDL语句，验证语法后经DBA审核后执行。这种DDL操作也支持回滚。
其次，是公有云数据库的安全预防机制。
-
云数据库的管理权限：数据库管理人员（即DBA）可以管理云数据库，但是数据库的实例释放操作则需要运维经理角色确认。
-
数据库访问白名单：只允许指定IP和业务工程所在网段访问相应的数据库。
最后，数据库的备份及可恢复性测试，非常关键。备份永远是数据库管理员的第一要务。我们设定通过脚本自动备份，将备份相关信息记录到iDB系统中，每周会做备份的可恢复性自动检查。
位于IDC机房的自建数据库集群的备份机制是，通过脚本自动备份，将备份相关信息记录到iDB系统中，每周会做备份的可恢复性自动检查。
阿里云的数据备份，则使用阿里云自带的“备份恢复”功能，介绍如下：
RDS提供如下两种备份功能：数据备份：设置的是周一至周日每天凌晨在备库实例进行全量物理备份（后台使用Percona XtraBackup备份），备份保留7天。日志备份：已开启日志备份（Binlog日志文件），日志备份保留7天。
恢复到阿里云RDS实例，可以这么做：
按备份集：根据“数据备份”，将备份文件数据克隆出一个独立的实例，验证后，再将数据手动或通过DTS迁回原实例。
按时间点：根据“数据备份”和“日志备份”，将最近的一次全备和全备后的日志备份恢复到一个新实例，经过验证后，再将数据迁回原实例。
恢复到自建机房数据库，可以这么做：
根据“数据备份”和“日志备份”，使用恢复工具PerconaXtraBackup将备份恢复到指定时间点。
虽然有这样那样的措施，但云数据库仍存在一定管理风险，下面依次阐述。
4.4.1 阿里云实例释放时的风险
手动释放阿里云RDS实例的时候，大家务必小心谨慎，请多人交叉核对实例ID是否正确。其原因如下所示。首先，阿里云上“按量付费”的读写实例，子帐号都可以直接释放实例，无需主帐号确认。其次，阿里云上“包年包月”的写实例，子帐号看不到“释放实例”的按钮，只能提工单释放。
但是在提工单的时候，需要手动填写阿里云的RDS“实例ID”，而无需提供额外信息，主帐号在工单中确认后，即可释放并退款。为了避免子帐号填写错误而误释放实例，需要在处理阿里云工单时引入线下审核机制，主帐号负责人务必与DBA二次确认后，再由主帐号确认退款。
4.4.2.阿里云RDS管理权限的风险
有RDS管理权限的话，即可在管理界面上删库和帐号，无需登录数据库。但阿里云管理平台上无法简单快捷地检查哪些子账户拥有RDS管理权限，所以除了DBA之外谁有权删库，无法一目了然。所以我们必须在赋权上小心谨慎，保证不同角色权限隔离。如拥有管理权限AliyunRDSFullAccess，就可以直接删除库，小心哦。
4.4.3.阿里云RDS的备份可恢复性测试
我们确实有在做自动化可恢复性测试，但仅限于我们自己的IDC机房的数据库备份可恢复性测试。阿里云的云数据库本身并没有备份可恢复性测试。
4.4.4.实例恢复时间过长
实例级故障恢复时间较长，对于高频交易类型业务来说也是一个重大风险，比如100G数据的实例恢复需要40分钟。
4.4.5.误操作没有快速恢复工具
目前阿里云没有提供快速恢复工具，需要开发工具，能快速从Binlog日志文件中恢复最近的误操作。
删库跑路再现江湖，疫情期间“删库跑路”的贺某运维工程师最终被判处有期徒刑6年，当初被他删除的数据体量达到了数百TB，甚至下了死手删除了备份数据文件，导致花了九天才恢复所有数据。微盟市值一度蒸发10亿元，截至2020年4月30日，造成微盟公司支付恢复数据服务费、商户赔付费及员工加班报酬等经济损失共计人民币2260余万元。预计这些经济损失，公司承担三分之二，管理层承担三分之一。
所以说小洞不补，大洞吃苦，一出了事儿就是大事儿。
备份，备份，备份，永远是 DBA 的第一重责。
但除了备份之外，还要未雨绸缪建设工具、流程和制度。
我司的研发哲学第五条是“永远要给自己留一个后备方案”。异地备份，多地备份，权限隔离，操作审计，交叉确认，……最后请善待员工，给公司留条后路。
点击联系发帖人
