1. 首页>
  2. 腾讯云代理

删库跑路只用1秒,数据恢复7天7夜,如何避免历史重演?

腾讯云 2020年03月10日 浏览384

    腾讯云代理 腾讯云新闻 腾讯云代理 腾讯云直播申请 游戏上云

摘要:

 “删库跑路”作为调侃程序猿的梗一直以来广为流传,但是当真的发生的时候,犹如黑天鹅降临,瞬间业务全线停摆,造成难以估量的损失。在SaaS领域举足轻重的服务提供商微盟,就刚刚经历了这样一场没有硝烟又争分夺秒的战争。


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

 

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

 

要想快速恢复业务正常运转,摆在微盟面前的难题是如何在数据库连同备份文件被全部删除,且数据体量达到数百T的情况下,进行100%的数据恢复。而专业的数据恢复公司,也只敢谨慎评估20%左右的修复预期。


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


1


PartⅠ 7天7夜,数据100%恢复



幸运的是,虽然文件相关的索引节点信息被删除了,但只要没有数据写入,数据块还是在的,这为修复提供了一种潜在可能。备份服务器上文件类型单一,数据集中,且微盟数据被删后,硬盘没有被二次写入,理论上里面可能存在相对完整的备份数据,于是技术团队决定从备份服务器入手恢复数据。

 

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


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

 

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



根据微盟公告,微盟将在权限管理方面,使用腾讯云CAM权限系统进行云资源管理,严格执行分级授权和最小集权制度,对高危险动作执行二次授权制度;使用腾讯云堡垒机替换自建堡垒机,进行细粒度许可权分级和授权管理。

 

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

 

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


1


Part Ⅱ 六大法宝,将灾难扼杀在摇篮



相比较于事后抢救性恢复,如何避免这样的灾难再次发生,是更为重要的。只要把握住六大法宝,就可以防患于未然。

 

一、建设数据库灾备系统


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


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


建立灾备系统的好处显而易见:在业务环境发生安全故障(自然灾备、机房故障、人为误删)的时候,可以第一时间切换到异地的灾备数据库恢复数据和业务访问。一套健全的灾备系统可以使最佳复原时间目标(RTO)降低到秒级,


目前主流云厂商数据库产品都有配套的灾备产品解决方案,以腾讯云MySQL产品的两地三中心方案为例:


image

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


二、有效的备份


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


这个时候如果没有数据库备份,或者备份没有验证过导致备份文件不可用,就失去了最后一根救命稻草,只能选择走操作系统级别的磁盘文件恢复。即使侥幸能恢复,耗时也会非常之久,导致相当长的业务停机时间。

 

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

 

三、访问控制策略


对于绝大多数中小型公司来说,一个运维或DBA管整个系统,并且拥有整个系统所有主机的最大权限,比如root。这种集权式的管理就存在“删库跑路”的风险。


在运维体系的建议中,我们需要规避这种不受到权限制约的超级用户。建议方案是建立多权分立的权限体系。


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

 

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


image

四、数据存储加密


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

 

数据库服务器端的加密需要对数据库管理系统本身进行操作,属于核心层加密,能够对数据库的敏感列、表空间、备份、Data Pump 的Export文件等进行加密,也能够对客户端到数据库之间的通信链路传输进行加密,防止物理链路数据被窃取。客户端加密的好处是不会加重数据库服务器的负载,这种加密方式通常利用数据库外层工具实现。

 

对于一些重要的机密数据,如一些金融数据、账号密码、商业秘密等,都必须存储在数据库中,需要防止对它们的未授权访问,哪怕是整个系统都被破坏了,加密仍可以保护数据的安全。对数据库安全性的威胁有时来自于网络内部,一些内部用户可能非法获取用户名和密码,或利用其他方法越权使用数据库,甚至可以直接打开数据库文件来窃取或篡改信息。


因此,采用加密技术对重要数据进行加密处理,能够保证数据存储的安全。数据加密方式有两种:


  1. 业务则加密

    调用数据库内置的加密函数,将加密后的结果写入数据库,正常读取的也是加密后的数据,在应用里面执行解密。当然,业务则加密这里涉及到一定的应用程序改造成本,需要决策层权衡下。

  2. 数据库内置加密功能

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


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


image

五、数据库审计能力


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

 

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



image

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


数据库审计技术可以监控和审计用户对数据库中的数据库表、视图、序列、包、存储过程、函数、库、索引、同义词、快照、触发器等的创建、修改和删除等,分析的内容可以精确到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、及时打好安全补丁,务必保持数据库为最新版本。因为攻击者可以利用上一个版本的已知漏洞来访问企业的数据库。


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


相关文章