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日 定稿　于北京