开发者学堂课程【数据库安全：数据库安全面临的挑战】学习笔记，与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/69/detail/1172
数据库安全面临的挑战
内容介绍：
一、主要内容概述
二、企业级数据库安全面临的挑战
三、其他事件
四、企业级数据库安全挑战
一、主要内容概述
·企业级数据库安全挑战
·阿里云全链路的数据库安全架构(概述)
·云端数据库安全管理:SSL+ TDE
·云端数据库安全管理︰授权、白名单与VPC
·云端数据库安全管理︰备份与恢复
·云端数据库安全管理︰企业级数据管理
·云端数据库安全管理:SQL审计
第一个是企业级数据库安全的挑战，今天在云数据库时代，数据库跟原来的区别，在这种情况下数据库安全跟原来有哪些区别，先介绍一下数据库安全的挑战。第二个就是会完整的概述一下整个云数据库的数据库安全的架构是什么样子，可以从哪些方面去保证的数据库安全。
接着会从以下的五个细节去介绍一下怎么去做好云端的数据库安全，可能包括SSL+TDE授权白名单和vpc备份恢复、企业级数据库管理、收购审计等等这几个方面。
二、企业级数据库安全面临的挑战
整体来说，数据库安全这门课其实是一个比较枯燥的一门课程，所以这里从三个比较影响比较大的数据安全的事件讲起。第一个事情也可以引以为戒，从这三个数据安全事件的角度去看一下，如何去用要介绍的这些云数据库的安全的架构去避免或者防止这些数据安全事件的发生。或者说这些安全事件发生了之后，可以用当前的数据安全的机制去保证的业务快速的恢复，保障的业务连续不要有大的影响。
1.某盟“删库跑路”
l 7天才完成数据恢复
l 向客户赔付约1.5亿
l 股价最高下跌36%
l 竞争对手乘机挖客户
第一个是今年年初的时候，大概是在2月23号左右发生的某盟“删库跑路”事件，此事件基本上在在2月份3月份的整个一个月里面都是整个数据库领域影响非常大的一件事情，某盟是一家非常在上市领域非常有名的一家公司，这家公司是2013年创建的2019年正式在香港上市，这件事情是在2020年的2月也就是它上市的大概一周年之际发生的，某盟主要是向中小企业提供在线的电子商务在线的营销解决方案，它的客户有很多新零售领域的大的客户包括沃尔玛、联想的在线商城、劲霸、会员、巴拉巴拉等等比较大的在线零售企业客户。具体的先来简单的回顾一下，首先是在2月23号晚上的6点左右，公司运维部的核心成员贺某通过VPN在家里连上公司的办公环境，登录到公司的核心的业务运行的服务器上，在服务器上执行了一些恶意操作，虽然没有透漏是什么恶意操作，基本上可以从后期的处理猜测来看，很简单的操作造成这么大的破坏性的影响，基本上是IM-F/的操作或者IM-F*的操作。操作很简单但是后面的恢复整整花了7天的时间，而且恢复的过程非常的坎坷。
在2月25号的时候，公司其实已经全力都在做数据恢复了，也有很多的客户在向公司进行投诉了，2月25号的时候它们发了一个公告说它们已经恢复了一部分数据，并且新的用户或者一部分新的业务已经可以开始提供服务了可以看到，并且它们在那个时候说，大概两天之后也就2月28号就可以把所有的数据都恢复了，但是实际上直到3月3号它们整个数据才完成恢复，可见整个的恢复过程比它们想象的其实是要复杂得多的。到3月3号的时候，它们最终发布了一个公告，说它们2月23号之前所有的数据都已经恢复了，后来也给出了一个解释，说当事人是由于个人精神和生活的原因导致的删库。
不管是什么原因，这里也不是今天要追究的重点，就这一次事件是一个很简单的三步操作，但是却给公司带来了非常大的影响，直接的经济损失是它们在过程中宣布向它们受影响的客户要赔付1.5个亿的现金赔付，1.5个亿会由公司的管理层出其中的1/3，公司会出2/3，这是直接的损失经济损失。
第二部分对公司的股价其实有非常大的影响，因为整个事件其实持续了大概半个月左右，半个月到一个月的时间，它们的竞争对手也在时间大力挖客户的墙角，公司的股价在这段时间，最高下跌也达到了36%，这家公司的整体的市值接近150亿到200亿，下跌36%基本上是50亿的市值蒸发掉了。而且它的竞争对手在这段时间其实非常活跃，基本上在各种尝试挖他们的客户，所以不仅这种对于直接的经济损失非常大，间接的损失以及客户的信心的影响都非常大。某盟事件可以看到，要么就是它没有备份要么就是它的数据有备份，但是也是备份在本地的，所以这里就有非常大的安全隐患。后面会去看要怎么去通过的安全机制保障，避免这种情况的发生。
2.Gitlab意外删库
l 6小时最新数据彻底丢失
l 约4900提交、700客户信息
l 多种备份手段失效
l “多窗口”命令执行错误
第2个比较有名的事件是Gitlab的删库事件，Gitlab删库事件发生在2017年的1月份，事件可以简单讲因为事件它们整个的处理过程其实非常透明，从事件发生就立刻在它们的官方的博客上公布了删库的原因以及每一步是怎么处理的，并且它们把每一步的处理过程全部都公开出来，简单的来说是这样的。
首先Gitlab是当前的基于get一个完全的集成的软件开发平台，是当前第二大的开源托管的数据库管理平台。使用的客户非常多，包括索尼、NASA、阿里巴巴等等很多大的公司都在用Gitlab做数据托管。
简单的理一下事件的时间线，这件这事情发生的时间是在2017年1月31号，在下午6点的时候，它们的公司的业务人员就发现数据库的压力比较大，但压力比较大的原因，其实也比较明确是由于外部的黑客攻击导致的，黑客攻击导致的数据库里面有大量的ddl、dma、dml的操作，大量的dml操作导致它们数据库的备库的延迟非常大，它们发现有大概4个G的数据日志在备库上没有回放，本来其实也没有什么关系，因为备库延迟就延迟了，正常一般情况下备库也是没有被启用的。但是它们的数据库管理员，发现了备库有比较大的延迟以后就打算做一个比较常规的操作，他打算做一个被迫重建的操作，在被迫重建的时候他们首先需要删除所有备库上的数据，但是当事人在做删除数据的操作的时候没有在备库做，它在多个窗口切换的时候选择了在主库上做，在主库上做数据库的删除操作，当它发现操作错了的时候，他立刻按CTRL C来停止操作但是已经没有用了，300G的数据库已经被删到了只剩4.5个G的数据，数据基本上已经全部丢失了。此案例有一个非常有意思的事情就是客户其实是有很多备份的，然后它们号称有好几种备份的手段，包括S3的备份、逻辑备份、快照备份，总之是有好几种备份手段的。但是当他们把发现数据库被删掉之后想去恢复的时候，发现多种备份手段都没有用，最后找到了一个6个小时之前的备份，用6个小时之前的备份把整个的数据库恢复起来了。
故障持续两个小时，但是却丢掉了6个小时的数据，数据库回档到6个小时之前。幸运的是它们是做代码仓库开源代码托管的，代码都没有丢，因为代码是以文件的形式存储的。
数据库里面6个小时丢掉的数据这大概有4900个提交相关的信息全部丢掉了，就是comment、folk等等相关的信息全部丢掉了。在这6个小时期间大概有700个用户信息也丢掉了，估计是它们新注册的用户。以上是Gitlab的删库事件，Gitlab删库事件和前面的删库性质其实是不一样的。第一个是意外导致的不是有意的，第二个是不一样的，就是它有备份但是它还是丢了6个小时的数据，所以可见不仅要有备份，备份的有效性其实也是一个要去重点保障的，后面去看一下在云环境里面如何去进行保障。
3.天津港危化品爆炸
l 无法预料、突发性
l 影响多个数据中心，包括
l 超算中心、一般数据中心
l 需要区域级的容灾方案
最后一个是2015年的天津港危险品爆炸事件，事件其实时间已经比较长了，当时的人员、财务的伤亡都非常严重。关注一下这次爆炸事件对数据中心的影响，据不完全统计大概有接近10个左右的数据中心，在这一次爆炸过程中受到不同程度的损毁，有的可能直接不可用了，有的可能是一部分的服务器不能提供服务了。
本事件的特点有如下几个方面，第一个是它完全无法预料、突发性非常强，另外它是数据中心级别的。就是今天在整个数据中心里面的数据可能都不可以用，所以说要避免这一类数据安全事件，不仅仅是说要考虑单个的实力，要考虑整个跨区域跨数据中心的整个人才方案要怎么去做。
三、其他事件
以上是三次比较典型的数据安全事件。其实互联网上数据安全事件基本上还是比较频繁的，这里列举几个，第一个时间大概是在去年，是微软出现了一个非常奇怪或者诡异的数据库数据丢失事件，它们的DNS服务不可用了导致它们的数据库有一部分的数据库被删了，当然它们删除的数据的时间不是特别长，可能是几分钟几遍，但是DNS服务不可用如何导致数据丢失，有兴趣的人可以在网上去搜索一下看一下。这里简单说一下，DNS服务不可用导致有一部分数据使用了kms密钥管理服务的数据库，无法连接密钥管理系统，连不上密钥管理系统的，它会认为这部分加密的数据就没有办法被访问，数据库里面会有一个删除操作，因为它会认为这部分数据没有密钥了，没有密钥就把这部分数据删掉。
第二个是前一段时间关于顺丰的删库跑路，也比较简单是员工的误操作，他要删除A库，但是不小心删除了B库，恢复的时间也特别的长，就是基本互联网上每隔一段时间都还是会有数据安全事件出来，当公司成立到一定阶段，数据越来越重要、业务的连续性也越来越重要，这时就要去关注如何通过系统的方式去保障的数据库安全。
四、企业级数据库安全挑战
l 外部的窃取或攻击
l 网络安全攻击
l 网络数据窃取
l 内部安全隐患
l 数据库权限管理困难
l 敏感数据发现、管理困难
l 人为误操作难以避免
l 系统、软件Bug
l 不可抗力
l 地震、洪水等自然灾害
l 其他导致数据中心失效的原因，包括爆炸、城市施工等
第一个是内部的安全隐患，其实是比较常见的，互联网上有一份数据统计，基本上数据泄露事件可能有20%~30%都是来自于内部的安全隐患。
内部的安全隐患包括第一是数据库的权限难以管理，当企业在快速发展的过程中，公司里面可能只有20个人进行研发的时候，数据库的权限管理还比较简单，试想一下如果一个公司有100或者200个研发人员，数据库权限如何进行管理。当公司的人员越来越多的时候，数据库的管理权限管理会越来越困难。
第二是敏感数据的发现和管理也非常困难。随着国外和国内对于个人信息的保护越来越严格，敏感数据的管理变得越来越重要。如果公司造成的敏感数据的泄露不仅仅说是数据安全事件这么简单，公司的法人可能要受到相应的法律的惩罚，所以敏感数据的管理变得要求越来越高。但是敏感数据的发现和管理通常比较困难，如今的应用系统非常多，10个20个甚至当公司的研发人员分到一定程度的时候，业务系统可能有100个200个之多。每一个业务系统可能都会使用或者收集一部分的敏感数据，这时候去做统一的敏感数据的管理就非常困难。敏感数据可能包括电话号码、姓名、信用卡信息、银行卡信息、收货地址、护照、身份证号等都属于敏感信息。
第三个是人为操作，人为误操作难以避免，前面的几个例子里面人为的操有两个，一个是某盟事件，还有一个gitlab事件，都是由于人为操作造成的。但是人为操作有两类，第一类是故意的，第二类是故意的。因为人总是会犯错，即便是人非常的专注，只要的操作多，总是会有误操作的，所以人为的误操作也是一个非常难避免。可能就像前面提到的一样他可能本来想在备库进行一个操作，但是窗口太多了人也又比较疲惫，可能在主库进行了操作。包括可能做ddl的时候表现在update微量条件里面可能少了某一个条件，本来要更新10条数据的，结果一下可能更新了几千几万甚至几亿条数据。人为操作也是一个数据安全巨大的挑战。
另外是系统和软件的bug也会有这种问题，软件、系统都是人写的，系统可能用的人多bug稍微少一点，软件也是人写的多少都是会有bug的，有的bug可能不影响数据，但是有的bug会影响数据，软件系统一旦影响数据，根据经验来看通常会很难恢复。因为它可能会以某种很奇怪的逻辑对数据进行了变更，想要恢复通常非常困难，根据以前的这些几次软件出bug，数据的恢复都会非常困难。
还有一类是外部的窃取或者攻击，这一类也非常多现在互联网上也有比较多的网络安全攻击，通过一定的漏洞潜到的系统里，把数据进行加密必须要必须要支付给多少钱可能才给恢复这种包括网络安全工具。
还有一类就是更直接的就是数据窃取，它到系统直接把数据全部拖走，这是外部的窃取。另外还有一类就是不可抗力，不可抗力简单的来归纳有以下几种，第一个是地震洪水等自然灾害，另外还有就是由于其他原因导致的数据中心事项，这其他原因，可能包括爆炸、城市施工等等都可能导致数据安全问题。一般来说数据中心的选址还有搭建都会去尽量考虑避免洪水、地震，避免这种地震多发地带，避免有洪水的地方，但是有时候天灾人祸有时候还是会有一些这种意想不到的情况发生，是属于不可抗力的情况。
