ORACLE DBA手记 4.数据安全警示录(修订版)

节选

[

在数据库领域工作了十几年,我发现国内技术人员往往一直在充当救火员的角色,企业常常也认为只有能够力挽狂澜、起死回生的技术人员,才是好的技术人员。而实际上,能够不犯错误、少犯错误、提前预防、规避灾难的技术人员才是企业技术环境的*有力保障,能够未雨绸缪、防患于未然才是更好的技术实践。
我们每年都帮助很多企业挽救数据、拯救危机,本书写作的契机正是因为2011年12月30日和31日,连续两个整天,我们连续挽救了几个用户的数据库灾难,这些灾难发生的原因之简单,让人不可思议,在迈入2012年这个神秘年份的一刻,深深触动了我,我想,如果将这些案例描述出来,就可能帮助一些用户警醒借鉴,避免再陷入这样的困境。而从别人的挫折中学习、借鉴,进而在自我的环境中未雨绸缪,防患于未然,是每个数据库管理人员和企业数据环境管理者应该具备的素质。
写作这本书还和2011年底众多席卷而来的密码泄露事件有关,当我注视着*常用的几个密码都在互联网上被公开时,除了手忙脚乱地在各大网站修改密码,剩下的就是深深的遗憾。几乎所有从事IT行业的人,都深知安全的重要性,可是在实际执行中,大家又往往习惯性失明,忽视了自己本应能够达到的力所能及之安全,很多专业人士就以这样或者那样的侥幸心理忽略了风险的存在,并一步一步走向安全危机。
对于数据库安全来说,通常我们认为缺乏的并非是技术手段,更多的是缺乏规范和安全认知,如果用户都能够严格遵循安全守则并应用现有的安全技术手段,数据库的安全性就能够大幅增强,我们的安全事故率也会大大降低。
所以我决定动笔,写下自己多年来所遭遇到的安全案例以及对于数据安全的思考,如果本书中的内容能够帮助一些企业规避错误,保全数据,挽救一些技术人员的时间,那么我将感到无比欣喜,于我们的生命中,*为宝贵的就是时间,寸金难买寸光阴。

[信息安全]
在传统的信息安全领域,存在三个基本的安全要素,分别是保密性(Confidentiality)、完整性(Integrity)和可用性(Availability),缩写为CIA。
这三个要素的基本定义如下:
保密性:指信息在存储、使用和传输过程中的保密性,要确保信息在这些环节中不会泄露给非授权方。
完整性:指信息在存储、使用和传输过程中不会被非授权用户篡改、变更,同时需要防止授权用户对系统及信息进行非授权篡改,保持信息在整个过程中的内外一致性。
可用性:信息系统因其服务使命,必须在用户需要时,可以被正常访问,授权用户或实体对信息系统的正常使用不应被异常拒绝或中断,应当允许其可靠、及时地访问和获取信息及资源。高可用系统要求所有时间可用,要确保系统不因电源故障、硬件故障和系统升级等因素影响服务的可用性。
信息安全的三要素是对安全的概括和提炼,不同机构和组织,因为需求不同,对CIA的侧重也会有所不同,随着信息安全的发展,CIA经过细化和补充,增加了许多新的内容,包括可追溯性(Accountability)、抗抵赖性(Non-repudiation)、真实性(Authenticity)、可控性(Controllable)等。与CIA三元组相反的一个概念是DAD三元组,即泄露(Disclosure)、篡改(Alteration)和破坏(Destruction),实际上DAD就是信息安全面临的*普遍的三类风险,是信息安全实践活动*终应该解决的问题。
从CIA理念出发,我们通过对信息安全范畴所有相关主题精炼整理得到了一个标准化的知识体系,被称为公共知识体系——CBK(Common Body of Knowledge),CBK包括10个知识范畴(Domain),对安全进行了全面的概括,具有极强的指导意义,这10个范畴分别为:访问控制,电信、网络和互联网安全,风险管理和业务连续性计划,策略、标准和组织,计算机架构和系统安全,法制、合规、调查和遵从,应用程序安全,密码学,操作安全,物理环境安全。

[数据安全]
信息安全的核心是数据安全。
在数据安全的范畴内,也包含信息安全的诸多方面,根据多年的服务经验与思考,我们将安全划分为五大方面,分别是:软件安全、备份安全、访问安全、防护安全和管理安全。
这五大方面是信息安全在数据领域的引申和映射,在企业数据安全中,这五大方面相辅相成、互有交叉、共同存在,下图是一张关于安全的思维导图,本书中的案例涉及了这五大方面。

在这五大安全方向中,可能出现两种性质的安全问题,**,由于内部管理不善而导致的数据安全问题;第二,由于外部恶意攻击入侵所带来的安全安问题。通常我们把安全问题狭义化为后者,这实际上是片面的,在数据安全问题上,前者造成数据损失、数据损毁的概率和影响度都远远超过后者。
下面我们对数据安全的五大方面做一下简要的分析和探讨:
1.软件安全是指数据库和应用软件产品、版本是否稳定安全;厂商所能提供的补丁集和BUG修正是否及时、基础硬件与操作系统是否经过认证。很多用户在部署数据库软件时,仅仅选择了*容易获得的初始发布版本(如Oracle Database 11.2.0.1或者Oracle Database 12.0.1.0等),遗漏了可能已经存在的补丁修正,并且在运行维护中并不能够及时跟踪软件更新,也无法获得BUG信息、补丁修正和安全告警,这就使得软件本身的很多风险隐患得不到修正。除了数据库基础软件,如果应用软件中存在漏洞或者后门,被恶意或未授权利用,用户的数据也无法获得安全保障。如果软件安全无法保证,数据库安全的基础也就丧失了。
2.备份安全是指用户数据能否得到及时有效的备份保全,能否在故障灾难之后获得及时的恢复和挽救。在数据库运行期,*为重要的就是备份安全,如果没有可靠的备份,将数据集中起来就只能等待数据灾难,所以我们将备份安全提升到核心地位,备份以及随之衍生的备份加密、容灾安全、高可用、数据脱敏等,都是企业整体数据架构应该考虑的因素。很多企业在数据灾难发生之后因为缺乏有效备份而一蹶不振,根据Gartner 2007年发布的一份调查报告显示,在经历了数据完全丢失而导致系统停运的企业中,有2/5再也没能恢复运营,余下的企业也有1/3在两年内宣告破产,由此可见,由于备份安全问题导致的企业伤害可能远远大于黑客攻击。
3.访问安全是指用户数据库的访问来源和访问方式是否安全可控。通常数据库系统处于IT系统的核心位置,其安全架构涉及主机、系统、存储、网络等诸多方面,如果没有明确的访问控制,缺乏足够的访问分析与管理,那么数据库的安全将是混乱和无法控制的。在应用软件使用和访问数据库时,要正确设置权限,控制可靠的访问来源,保证数据库的访问安全,唯有保证访问安全才能够确保数据不被越权使用、不被误操作所损害,通常*基本的访问安全要实现程序控制、网络隔离、来源约束等。
4.安全防护是指通过主动的安全手段对数据库通信、传输等进行增强、监控、防护、屏蔽或阻断,诸如数据加密、审计、数据防火墙等技术都在这一范畴之内。我们必须认识到,在IT技术高度发展的今天,风险是无处不在、层出不穷的,我们从未思考过的安全问题可能每天都在不断发生,所以在数据库环境中采取主动式防护,可以帮助我们监控分析和屏蔽很多未知风险,已经有很多成熟的产品和技术可以用于安全防范。
5.管理安全是指在企业数据的日常管理维护范畴内,能否充分保证数据安全以及服务的高可用连续提供。诸如DBA的维护、文件的管理、参数或数据结构的变更等都可能引入数据风险,管理安全要求我们通过规范、制度以及技术手段去确保维护管理安全;另外,基于硬件、电力等基础平台的故障都可能影响数据库服务的高可用性,在管理中要通过监控手段及时预警,通过集群、备库等切换与服务保障服务的连续性。
这就是数据安全的五大方面。
[Oracle数据库安全]
Oracle数据库自1977年开始,就一直将安全置于首位,从强大的数据恢复机制,到不断增强的加密以及安全防范措施。“Oracle”这个名字就是来自美国中央情报局投资的项目代码,而美国中央情报局也正是Oracle*早期的用户之一。
接触过Oracle数据库的人都应当熟悉一个类似如下图所示的错误“ORA-00942:表或视图不存在”,这个简单的错误提示,*初就是在美国中央情报局的要求下作为一项安全防范设定的,这个提示的安全意义在于:避免提供任何具体的实质性提示性信息,以预防黑客的攻击性尝试。由此可见,安全防范可以从每一个细节入手,安全是一项全面整体的技术实现,并非孤立的存在。

受密码事件影响,我们首先从Oracle数据库的密码机制上来深入了解一下Oracle的加密机制。虽然我们知道早在Oracle 数据库版本8的年代,就已经提供了强大丰富的数据库加密功能,但是直至今日,恐怕半数以上的数据库中,仍然存放着用户的明文密码,并且未采用任何数据库安全增强机制。这也是我认为*重要的安全问题:我们并不缺乏安全防范手段,但是缺乏对安全风险的认知。
诚然,我们对安全的认识是随着不断出现的安全事故逐步增强的,但是希望大家都能够有计划地逐步增强对数据库的安全防范,主动规划推进数据安全与从挫折中学习提高实有天壤之别。对于2011年底的密码泄露事件,如果各大网站能够采取基本的技术手段对用户密码进行一定的加密,那么这次密码泄露的安全事件就不会显得那么初级和让人恐慌,想一想明文密码和MD5(Message-Digest Algorithm 5,信息摘要算法5)散列值的区别?前者基本上意味着数据库从未从安全角度进行过任何思考和增强。
Oracle数据库的用户信息及加密密码存储于一个名为USER$的数据表中(所有者为SYS用户),我们可以通过基于USER$表建立的DBA_USERS视图来查询和获得这些信息,包括密码散列后的值。
在Oracle Database 11g之前,用户口令遵循DES标准(Data Encryption Standard),通过对称算法进行加密,用户名为“Salt”,密码*长为30个字符,所有字母被强制转换为大写。从Oracle 7 至 Oracle 10g,加密一直使用username和password串联之后进行HASH运算,例如sys/temp1和system/p1将会获得相同的HASH加密输出。
从Oracle Database 11g开始,Oracle允许*多使用30个字符、大小写混合方式作为密码,同时支持DES和SHA-1算法进行加密(SHA-1算法支持大小写混合,通过初始化参数SEC_CASE_SENSITIVE_LOGON开关),使用password||salt的方式进行HASH加密。
下图展示了Oracle 9i数据库中用户密码的加密形式,DBA_USERS视图的PASSWORD字段显示了加密后的密码(Encrypted Password):

在Oracle 11g中,密码从DBA_USERS视图中隐藏起来,这进一步增强了安全性,即便具有访问视图权限的用户,也无法获得口令的散列值如下图所示,由此我们也可以看出Oracle数据库软件的安全增强历程:

密码的加密内容存储在底层的核心表(USER$是Oracle数据库的元数据表之一)中,以下PASSWORD字段存储的是DES标准加密值,SPARE4存储的是SHA-1加密输出:

关于口令的维护,Oracle支持各种约束性限制(通过utlpwdmg.sql 脚本启用),诸如复杂程度、长度、有效期、失败登录次数等,通过这些增强,Oracle的口令限制可以定制出非常稳固的安全解决方案,如果你从未接触和研究过这些手段,那么可能说明你的数据库还缺乏足够的**层安全防守。
如果我们能够从Oracle的安全策略入手,学习一下Oracle的密码安全解决方案,就能构建一套较为完善的基本安全解决方案。从Oracle的**个Internet版本 Oracle 8i(1998年发布)开始,Oracle就提供了一个加密包DBMS_OBFUSCATION_TOOLKIT 用于数据安全防护,这个加密包支持DES、3DES 和 MD5散列算法。
通过非常简单的封装调用,DBMS_OBFUSCATION_TOOLKIT 包就能够实现数据加密,下图展示了一个简单的示例输出,对于给定字符串进行MD5散列,会以RAW方式返回结果(通过创建稳固的函数,可以实现用户登录时的即时散列、比较和认证):

从Oracle Database 10g开始,DBMS_CRYPTO包被引入到数据库中,该程序包支持更广泛的加密算法,并用于替代DBMS_OBFUSCATION_TOOLKIT包,在新的版本中,诸如DES、3DES、AES、RC4、MD5、SHA-1、MD4、HMAC_MD5、HMAC_SH1等算法和加密方式都被支持。
通过选定的加密算法和加密方式,可以对重要数据进行加密和解密,我们不仅可以实现对密码或数值、字符数据的加密,还可以对类似LOB等非结构化数据进行加密。下图展示了使用DES算法的CBC模式和PKCS5补码规则进行加密解密的实现,示例模拟了对信用卡卡号的处理过程,金融类企业数据的安全性更为突出,需要进行安全加密的类型更为丰富。

我想重申的是,对于不同的数据库产品,都存在足够成熟的安全实现手段,应用这些安全手段就能够实现对于数据的基本保护,对于我们技术人而言,*重要的是认识和重视数据安全问题,并逐步推动企业或组织应用安全手段进行数据安全增强。重视数据、保护数据,这是每一位技术人的共同使命!

[本书使命]
本书所描述的所有恢复以及安全案例全部确有其事,但是基于用户隐私的考虑,我们隐去了所有和客户相关的信息,对于摘录的内容涉及用户判断的,全部进行了处理,但是时间、故障内容一切属实。多年来的灾难挽救让我积累了很多素材,所以写作这本书是一次回顾的旅程,以一条主线,将众多的灾难挽救过程串联起来。这本书中的很多案例,尚属首次曝光,而你也许还会注意到,书中的某些技术细节和恢复方法你从未在其他地方看到。
本书中的很多案例的恢复过程非常艰难,拯救过程也花费了大量的人力、物力和时间,我们也因此赢得了价值不菲的商业合同,但是从内心上来说,我们永远不希望用户陷入这样的境地,所以我写了本书,使得这些曾经惨痛的教训可以具备更广泛的借鉴意义。
基于这些想法,我对每个案例的发生过程进行了描述,并且提出了供大家警示的规避法则。所以,我希望这是一本写给大家看的数据安全之书,不仅仅是给技术人员,更重要的是给企业数据管理者,如果不了解这些案例,你也许永远不会理解数据库为何会遭遇灭顶之灾,你也许永远无法理解为何千里之堤一朝溃于蚁穴。
当然,这仍然是一本相当深入的技术书,我将很多案例的详细拯救过程记录下来,包括一些相当深入的技术探讨,这些技术探讨一方面可以帮助读者加深对Oracle数据库技术的认知,另一方面又可以在你遇到类似案例时,做出同样的营救工作。
对于我自身来说,年纪越长,就越是认识到这个世界上*为宝贵的就是时间,如果我的分享,从警示到技术,能够帮助大家规避错误,少犯错误,在恢复时不走弯路,快速拯救数据,节省工程师们和用户的时间,那么这就是我*强烈的愿望,拯救时间,即为功德,这世界上,寸金买不到寸光阴。
这本书是用他人的灾难,为大家警示,但愿我们都能够从中吸取教训,永远不要遇到本书所描述的种种灾难。

[致谢]
感谢我的朋友们,他们对我的帮助和支持使得本书的很多内容得以成型,刘磊在ACOUG上的演讲《猜测的力量》帮助我丰富了关于REDO分析的案例;本书还引用了杨廷琨分析解决的一个ASM故障案例,此外,附录中老杨提供的函数非常有用;感谢用户,是他们的信赖使得我们能够接触种种艰难的案例,并帮助他们挽回数据;感谢支持帮助过我的朋友们以及一贯支持我的读者们,书中真挚的内容就是我*好的回报。
感谢我的好友丁晓强,他在支付宝公司进行了多年的安全与运维体系的建设与管理工作,他基于实践而来的对于安全和运维的真知灼见给予了本书很多肯綮的建议,这些建议让我对安全有了更加系统全面的理解,从而也对本书的架构做出了调整,虽然有很多想法没能在本书中体现,但是我相信,我仍然有机会在未来和大家继续分享我从他那里学来的宝贵经验。
再次感谢杨廷琨,他在本书出版之前,通读了全书书稿,细致到帮我修改敲错的字母和写错的汉字,认真的态度让我钦佩得无以复加;他还帮助我增加了两个警示条目,内容来自他感触*为深刻的技术经历。老杨的工位和我相邻,在工作中我无论何时请教都可以即刻得到他绝妙的提示,让我节省了大量的工作时间,这是达成本书的另外一个重要助力。
我还要感谢我的太太、儿子及其他家人,因为写这本书,我牺牲了很多陪伴他们的时间,也正因为有他们的支持,我才能够不断地写下去。
*后,但愿书中这些看起来似乎遥远的故事,能够警醒你似曾相识的某些操作,并且永远不要面对这样的灾难。
盖国强(Eygle)
2012年1月20日 初稿
2012年3月1日 定稿 于北京

]

本书特色

[

本书源于众多实践案例的总结,我们将大量的数据安全事件、数据库安全漏洞、Oracle数据库灾难恢复案例融合于一体,进行了详细的阐述和分析,并总结形成了指导企业规范运维、强化管理、规避灾难的指导原则。本书通过概括总结形成的数据库运维原则,希望能够给企业运维管理者以警示,通过提前预防措施和规范化管理避免遭遇到书中描述的种种情形;此外,本书还通过复杂的Oracle数据库灾难恢复案例,深入阐述了数据库运行和工作的内部原理,希望能为读者的深入技术探索提供帮助。本书既适合企业自动化和智能化运维的管理者参考,也适合深入学习数据库技术的读者学习探索。

]

内容简介

[

本书源于众多实践案例的总结,我们将大量的数据安全事件、数据库安全漏洞、Oracle数据库灾难恢复案例融合于一体,进行了详细的阐述和分析,并总结形成了指导企业规范运维、强化管理、规避灾难的指导原则。本书通过概括总结形成的数据库运维原则,希望能够给企业运维管理者以警示,通过提前预防措施和规范化管理避免遭遇到书中描述的种种情形;此外,本书还通过复杂的Oracle数据库灾难恢复案例,深入阐述了数据库运行和工作的内部原理,希望能为读者的深入技术探索提供帮助。本书既适合企业自动化和智能化运维的管理者参考,也适合深入学习数据库技术的读者学习探索。

]

作者简介

[

盖国强 云和恩墨创始人,Oracle ACE总监 盖国强先生是中国地区首位Oracle ACE和ACE总监,曾获评”中国首届杰出数据库工程师”奖,拥有近20年的数据行业咨询和实践经验,著有《深入解析Oracle》、《循序渐进Oracle》等技术书籍。盖国强先生于2011年发起创立云和恩墨公司,致力于以『数据驱动,成就未来』为使命,为企业和用户提供卓越的数据产品和服务。

]

目录

第1章 知己知彼 忘战必危 1
1.1 危机四伏,数据注定泄露 1
1.2 从罗维邓白氏案例看数据道德 4
1.3 数据库管理员出售新生儿信息 6
1.4 美国上千万信用卡信息疑遭盗取 7
1.5 数据外泄主要来自内部 8
1.6 GDPR带来的数据安全思考 9
1.7 数据库的漏洞都会重来 12
1.8 那些运维中的疏忽导致的数据风险 16
1.9 参考资料 18
第2章 运筹帷幄 三十六计 20
2.1 有效的备份重于一切 21
2.2 测试环境和生产环境隔离 24
2.3 禁止远程的和业务时间的DDL操作 26
2.4 ORACLE数据库DEVOPS的三十六计 37
2.5 参考资料 40
第3章 合抱之木 生于毫末 41
3.1 ORACLE数据库软件发布序列 42
3.2 DB LINK必须升级的预警 48
3.3 SQL语句注入和CVE-2017-10282警告 71
3.4 JAVA VM的反序列化 86
3.5 从一次UPDATE的优化讲起 94
3.6 一个逻辑坏块引发的灾难 104
3.7 参考资料 106
第4章 靡不有初 鲜克有终 107
4.1 以空间之由——恢复误删数据文件案例 109
4.2 以拯救之因——强制恢复导致ORA-600 4000错误的案例 133
4.3 以优化之名——存储优化导致表空间误删案例 152
4.4 以安全之期 159
4.5 以便利之机 175
第5章 未雨绸缪 防患未然 180
5.1 DBA四大守则 182
5.2 DBA守则外四则 183
5.3 各种惨痛的案例 187
5.4 参考资料 210
第6章 亡羊补牢 未为迟也 212
6.1 数据篡改案例解析 213
6.2 密码安全与加密 244
6.3 分析与恢复被篡改的敏感数据 266
6.4 参考资料 271
第7章 明察秋毫 见微知著 272
7.1 一次小碰撞引发的灾难——ASM保护式文件离线引发故障 273
7.2 又一次小碰撞引发的灾难——文件离线与归档日志缺失 的案例 281
7.3 空间与文件离线——离线表空间修复 303
7.4 对写文件错误的处置改进 331
第8章 心存目想 三思后行 339
8.1 TRUNCATE导致的灾难——核心字典表误操作TRUNCATE 340
8.2 脚本错误导致的灾难——数据库整体被删除故障 353
第9章 千丈之堤 溃于蚁穴 363
9.1 一个字符引发的灾难——大小写字符疏忽导致的维护故障 364
9.2 一个盘符引发的灾难——判断失误导致的误格式化故障 385
9.3 一个BEGIN引发的灾难 389
9.4 一个空格引发的事故 404
9.5 一个坏块引发的灾难 406
9.6 一个标志位的影响 422
9.7 一个磁盘添加引发的故障——通过AMDU恢复数据的 案例一则 431
第10章 物尽其用 尺有所短 439
10.1 关库与关机——强制关机导致的写丢失故障 441
10.2 从小恙到灾难——重建控制文件失误导致的故障 470
10.3 尺有所短,物有不足——硬件故障导致的灾难一则 480
10.4 由性能问题而追溯的磁盘故障 483
10.5 静默错误引起的数据灾难 488
10.6 ORACLE的写丢失检测特性 496
10.7 ORACLE 12.2的写丢失检测增强 503
10.8 参考资料 507
附录A:BBED的说明 509
附录B:函数F_GET_FROM_DUMP: 512
数据驱动,成就未来 517

封面

ORACLE DBA手记 4.数据安全警示录(修订版)

书名:ORACLE DBA手记 4.数据安全警示录(修订版)

作者:盖国强

页数:532

定价:¥99.0

出版社:电子工业出版社

出版日期:2018-05-01

ISBN:9787121362750

PDF电子书大小:37MB 高清扫描完整版

百度云下载:http://www.chendianrong.com/pdf

发表评论

邮箱地址不会被公开。 必填项已用*标注