腾讯云MySQL备份与恢复全方位保障数据安全

删库跑路只用1秒，数据恢复7天7夜，如何避免历史重演？
“删库跑路”作为调侃程序猿的梗一直以来广为流传，但是当真的发生的时候，犹如黑天鹅降临，瞬间业务全线停摆，造成难以估量的损失。

在SaaS领域举足轻重的服务提供商微盟，就刚刚经历了这样一场没有硝烟又争分夺秒的战争。

一周前，微盟部署在自建MySQL数据库上的核心业务数据，被微盟某运维人员用一种让程序员闻风丧胆的Linux系统下文件删除命令，整体进行了不可逆的删除。

更残酷的是，备份数据也一起删除了。

所有微盟平台上的用户和商家业务因此被迫停滞了一周，而服务没有恢复的每一分每一秒都是收入和用户的损失，这次删库造成的后果也超出了外界想象。

要想快速恢复业务正常运转，摆在微盟面前的难题是如何在数据库连同备份文件被全部删除，且数据体量达到数百T的情况下，进行100%的数据恢复。

现实情况是，哪怕是专业的数据恢复公司，也只敢谨慎评估20%左右的修复预期。

微盟立刻启动紧急响应机制，并向腾讯云紧急求援。

虽然文件相关的索引节点信息被删除了，但只要没有数据写入，数据块还是在的，这为修复提供了一种潜在可能。

备份服务器上文件类型单一，数据集中，且微盟数据被删后，硬盘没有被二次写入，理论上里面可能存在相对完整的备份数据，于是技术团队决定从备份服务器入手恢复数据。

至此，一场可以载入史册的操作系统级的数据恢复战役打响了。

为减少恢复时间，在征得微盟同意后，技术团队越过镜像拷贝的步骤，在不拆除原有服务器上的数据盘的前提下，将另外一块系统盘安装到原有服务器上，通过新系统盘加载OS和数据恢复软件，直接扫描提取数据盘中的“隐藏”数据，其间涉及到数据读取、不同数据块的拼接、遗漏数据的二次扫描、数据验证等环环相扣的操作步骤不予言表。

终于，经过7天7夜的奋战，3月1日晚，微盟发布公告称，数据已经全面找回，同时宣布基础设施全力上云。

根据微盟公告，微盟将采取以下措施提升对数据安全的保障：首先在权限管理方面，使用腾讯云CAM权限系统进行云资源管理，严格执行分级授
权和最小集权制度，对高危险动作执行二次授权制度；使用腾讯云堡垒机替换自建堡垒机，进行细粒度许可权分级和授权管理。

借助腾讯云数据库MySQL的数据高可用和安全体系，逐步放弃自建数据库服务，迁移到腾讯云数据库，提升数据库跨可用区和易地灾备的能力。

云数据库在数据安全、运维成本、稳定性、可用性和备份恢复上比自建数据库更有优势，这也是微盟此次决定全面迁移到腾讯云数据库的主要原因。

相比较于事后抢救性恢复，如何避免这样的灾难再次发生，是更为重要的。

只要把握住六大法宝，就可以防患于未然。

一、建设数据库灾备系统
数据库灾备系统是：基于数据库层的技术和架构来实现对数据的保护，确保在诸如机房故障、地震、火灾等不可抗因素下数据的安全。

两地三中心，三地四中心这类叫法其实就是指数据库异地多中心的灾备系统。

建立灾备系统的好处显而易见：在业务环境发生安全故障(自然灾备、机房故障、人为误删)的时候，可以第一时间切换到异地的灾备数据库恢复数据和业务访问。

一套健全的灾备系统可以使最佳复原时间目标（RTO）降低到秒级。

目前主流云厂商数据库产品都有配套的灾备产品解决方案，以腾讯云MySQL产品的两地三中心方案为例：
自建数据库可以仿照云厂商的数据库灾备架构，来建设自己的数据库灾备系统。

当然，搭建数据库灾备系统对企业的技术门槛要求较高：
除了搭建部署数据库灾备架构，还需要架构链路的监控、网络质量保障、故障自动转移机制、数据一致性校验等配套的系统策略跟上。

二、有效的备份
数据库备份绝对是在安全故障下的救命稻草。

这个时候如果没有数据库备份，或者备份没有验证过导致备份文件不可用，就失去了最后一根救命稻草。

这时，只能选择走操作系统级别的磁盘文件恢复，难度和过程就非常大了。

即使侥幸能恢复，耗时也会非常之久，导致相当长的业务停机时间。

这里要注意：备份不是简单的工具应用，而是系统化的备份策略。

全量备份、增量备份、日志备份的策略搭配、备份异地存储、备份有效性验证都必须考虑到位，把备份当做一个系统工程去建设，而不只是简单的备份工具运营。

三、访问控制策略
对于绝大多数中小型公司来说，普遍的现象就是，一个运维或DBA管整个系统，并且拥有整个系统所有主机的最大权限，比如root。

这种集权式的管理完全就可能带来“删库跑路”的的风险。

在运维体系的建议中，我们需要规避这种不受到权限制约的超级用户。

比较好的一个方案就是：建议多权分立的权限体系。

这里以三权分立的体系为例，将传统数据库系统DBA 的角色分解为三个相互独立的角色，安全管理员，审计管理员，数据管理员;
基于此基础提出的安全策略，主要细分为三个部分，分别为数据加密，数据脱敏访问，强制访问控制，三者组合提供多个层级的数据安全保障能力。

安全管理员，审计管理员，数据管理员，这个三个角色之间相互制约，消除出系统中的超级权限，从系统角色设计上了解决了数据安全问题。

三权分立权限分解图如下:
四、数据存储加密
数据加密是将数据库中的数据通过身份认证、密钥+密码、密钥管理等进行数据保护的技术，是防止数据库的数据信息篡改和泄露的有效手段，通过数据信息加密能够确保数据用户信息的安全，即使数据被非法导出、备份文件被窃取，也无法恢复和访问丢失的数据。

数据库服务器端的加密需要对数据库管理系统本身进行操作，属于核心层加密，能够对数据库的敏感列加密、对数据库的表空间加密、对数据库备份加密、对Data Pump 的Export文件加密等。

也能够对客户端到数据库之间的通信链路传输进行加密，防止物理链路数据被窃取。

客户端加密的好处是不会加重数据库服务器的负载，这种加密方式通常利用数据库外层工具实现。

对于一些重要的机密数据，如一些金融数据、账号密码、商业秘密等，都必须存储在数据库中，需要防止对它们的未授权访问，哪怕是整个系统都被破坏了，加密仍可以保护数据的安全。

对数据库安全性的威胁有时来自于网络内部，一些内部用户可能非法获取用户名和密码，或利用其他方法越权使用数据库，甚至可以直接打开数据库文件来窃取或篡改信息。

因此，采用加密技术对重要数据进行加密处理，能够保证数据存储的安全。

重要数据加密，尤其是用户和密码等信息，在数据库中应当进行加密存储；
加密方式：一是业务则加密；二是使用数据库内置的功能加密
1.业务则加密
调用数据库内置的加密函数，将加密后的结果写入数据库，正常读取的也是加密后的数据，在应用里面执行解密。

当然，业务则加密这里涉及到一定的应用程序改造成本，需要决策层权衡下。

2.数据库内置加密功能
比如:MySQL5.7版本推出的数据库内置的TDE 透明数据加密，可对数据库的表空间文件进行加密。

现在主流云厂商的数据库产品都陆续推出了自己的加密功能，可以做到更加细粒度的加密，以腾讯云某自研数据库的加密功能为例：
支持两种加密粒度，列级加密和文件加密。

五、数据库审计能力
数据库审计能够实时记录数据库活动，对数据库操作进行细粒度审计的合规性管理，对数据库遭受到的风险行为进行告警，针对黑客对数据库SQL 注入攻击、异常操作等数据库风险行为进行记录与告警。

因此，提高数据库的安全级别，还需要数据库审计技术支撑。

审计主要有如下几种
另外，数据库审计技术还用于监视并记录对数据库服务器的各类操作行为，通过对网络数据的分析，实时、智能地解析对数据库服务器的各种操作，并记入审计数据库中以便日后进行查询、分析、过滤，实现对目标数据库系统用户操作的监控和审计。

数据库审计技术可以监控和审计用户对数据库中的数据库表、视图、序列、包、存储过程、函数、库、索引、同义词、快照、触发器等的创建、修改和删除等，分析的内容可以精确到SQL操作语句一级；还可以根据设置的规则，智能地判断出违规操作数据库的行为，并对违规行为进行记录、报警。

六、强调安全规范
这一点其实并不是数据库功能系统层面的安全，而是管控制度层面的安全建设。

1、严格管控权限，明确用户职责。

遵循最小权限授予原则，避免因为过度授权而带来的安全风险；明确不同的数据库用户能够用于的工作范围，防范和隔离风险；比如：数据库应用账号只赋予SELECT、UPDATE、INSERT权限，取消DELETE权限。

把需要DELETE权限的逻辑改成用UPDATE实现，避免被物理删除；
2、密码策略强化，防范弱口令带来的安全风险，定期更换密码，同时生产和测试环境严格使用不同的密码策略。

3、移除匿名账户和废弃的账户，比如经典的：
mysql> use mysql;
mysql> DELETE FROM user WHERE user="";
mysql> flush privileges;
4、制订规范并贯彻执行，良好的规范是减少故障的基础，全面的规范提升开发和运维人员的标准化；
5、防范内部风险，绝大部分安全问题都来自于企业内部，通过规章、制度与技术手段规避安全风险。

比如：建立之前提到的三权分立权限体系。

6、树立安全意识和开始安全审计，安全问题最大的敌人是侥幸，制定安全方案，定期分析数据库风险，逐步完善数据库安全
7、及时打好安全补丁。

务必保持数据库为最新版本。

因为攻击者可以利用上一个版本的已知漏洞来访问企业的数据库。

微盟事故的发生对其他企业的数据安全保护也敲响了警钟，仅仅依靠单点防护难以达到真正的安全防护效果，而构建基于全生命周期的安全防护成为必然选择。