上周(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 )为你的数据库发现潜在问题,早日消除安全隐患!
祝愿大家的 DBA 生涯都能够平安圆满!
本文出自数据和云公众号,原文链接