开发者社区> 行者武松> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

不以规矩不成方圆:Digital Ocean也删除了他们的数据库

简介:
+关注继续查看

640?wx_fmt=png&wxfrom=5&wx_lazy=1

上周(2017-04-05),位于纽约的云服务商 Digital Ocean 遭遇了一次长达4小时56分钟的停机事故,事故的原因竟然是:主数据库被删除了(primary database had been deleted)。


我曾经开过一个玩笑说:没有删除过数据库的DBA,职业生涯是不完整的。现在看起来,又有人因此而完整了。


对于我们来说,需要本着科学的态度,学习并且引以为警示,做到防患于未然。


Digital Ocean 公布了整个故障的根本原因(Root Cause):

The root cause of this incident was a engineer-driven configuration error. A process performing automated testing was misconfigured using production credentials.

故障的根本原因在于工程师的配置错误,一个自动执行的测试流程使用了错误提供的生产环境认证配置。


这个根本原因翻译过来就是:由于配置错误,本应指向测试环境的任务被指向了生产环境,测试任务包含的环境初始化过程删除了主生产数据库。


幸运的是,Digital Ocean 公司实现了 DBA 守则的第一条:有效的备份重于一切。


他们在发现故障后三分钟发现了数据库被删除,随后在7分钟内启动恢复任务,时间线非常清晰


  • T0.00 - 10:24 EDT - First observation of issues

  • T0.03 - 10:27 EDT - Verified that production database had been deleted on master

  • T0.10 - 10:34 EDT - Began recovery from time-delayed replica

  • T1.29 - 11:53 EDT - Backup of time-delayed replica completed

  • T2.10 - 12:34 EDT - Copy of backup to master completed; recovery commencing

  • T3.07 - 13:31 EDT - Recovery of master completed; copy of backups to replicas ongoing

  • T4.56 - 15:20 EDT - All systems restored

这个故障告诉我们什么呢?我认为规则的重要不断凸现出来


我在前一段总结了 数据库安全的16条军规,其中的几条正是基于类似的惨痛教训总结而来的,我筛选几条和大家分享:

备份重于一切

我曾经在总结的DBA四大守则的第一条就指出,『备份重于一切』,有了有效的备份,即使遭遇灾难,也可以从容应对,对于重要的生产环境,适当建立备库进行数据保护,查询分担,也会减少生产库的风险;

唯一会让DBA们从梦中惊醒的就是:没有备份! 所以对于数据库运维来说,第一重要的是做好备份!有备方能无患!

限制登录工具

明确限制不同工具的使用场景,明确规定工具的准确来源,或者通过堡垒机等来限制数据库访问。对于工具也可以做出明确规则和限制,如限制仅能通过SQL Developer访问生产,PL/SQL Developer工具仅能访问测试环境,以减少安全风险甚至误操作风险;

测试和生产隔离

互通就意味着同时可以访问,也就可能带来很多意想不到的安全风险,企业应当将测试环境和生产环境部署于不可互通,或者不可同时访问的网络环境中,避免因为错误连接而发生的数据库灾难。 分离部署一方面可以降低误操作的可能性,也可以屏蔽一些无关的访问可能,从而从网络链路上保证数据安全;

密码差异设置

有些测试环境或者非产品环境是利用产品环境恢复得到的,DBA在建立了测试环境后,就没有修改数据库用户的登录密码;经常性的,DBA也习惯在所有环境中设置通用的密码;这些习惯为系统带来了很多风险和不确定性。 我们建议用户在不同环境中采用不同的密码设置,这是因为一方面产品环境和测试环境面对的访问用户不同,密码设置相同则意味着产品环境的安全性完全得不到保障;另一方面,DBA登录到不同的数据库需要使用不同的密码,这进一步减低了DBA在错误的环境下执行命令的可能性。


这样的例子已经屡见不鲜了,近期的就有:

五重备份无一有效,还有哪些 rm -rf 和GitLab类似的忧伤?


如何检查和发现数据库的隐含风险呢?你可以通过云和恩墨的免费智能巡检平台 - Bethune 来进行全面诊断和检查。

Bethune ( https://bethune.enmotech.com )为你的数据库发现潜在问题,早日消除安全隐患!

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

祝愿大家的 DBA 生涯都能够平安圆满!



本文出自数据和云公众号,原文链接


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
【鸿蒙】Data Ability本地数据库写入读取数据
1)配置权限和UI的实现 放在config.json的abilities同级下
0 0
达梦(DM)3、数据库迁移(Windows篇)(下)
为了适配国产化,需要从 MySQL 迁移到达梦数据库,总体的迁移过程也不算复杂,在此记录如下
0 0
LeetCode(数据库)- Leetcodify Friends Recommendations
LeetCode(数据库)- Leetcodify Friends Recommendations
0 0
openGauss/GaussDB200 《FusionInsight LibrA: Huawei’s Enterprise Cloud Data Analytics Platform》
Huawei FusionInsight LibrA (FI-MPPDB)是OLAP系统,从《openGauss数据库核心技术》这本书上的描述看LibrA就是GaussDB200,从openGauss的代码上看,openGauss的OLAP特性也是来自这个产品。
0 0
AVEVA Plant(PDMS)数据库的保护
AVEVA Plant(PDMS)数据库的保护 eryar@163.com   以下内容摘自一网友邮件: ----- Original Message ----- Sent: Tuesday, September 25, 2012 9:46 PM Subject: PDMS项目管理 你好,看了你写的很多文章,大部分都是关于程序出图的设置,我想咨询你一个关于PDMS项目管理的问题,希望能够赐教。
1321 0
+关注
行者武松
杀人者,打虎武松也。
文章
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载