eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« 如何隐藏或加密 Oracle 备份 RMAN脚本中的口令 | Blog首页 | 【安全警告】Oracle 12c 多租户的SQL注入高危风险防范 »

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

DigitalOcean.png

上周(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 )为你的数据库发现潜在问题,早日消除安全隐患!

Bethune.jpeg

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


加入"云和恩墨大讲堂"微信群,参与讨论学习

搜索 盖国强(Eygle)微信号:eyygle,或者扫描下面二维码,备注:云和恩墨大讲堂,即可入群。每周与千人共享免费技术分享,与讲师在线讨论。

YhemTalk.jpeg

关注公众号,获得后续精彩分享

Erweima.jpeg


历史上的今天...
    >> 2014-04-18文章:
    >> 2011-04-18文章:
    >> 2007-04-18文章:
    >> 2006-04-18文章:
    >> 2005-04-18文章:
           回到北京

无觅

By eygle on 2017-04-18 12:48 | Comments (0) | Backup&Recovery | 3246 |


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com