数据库oracle数据库学习

McGraw-HillEducation对于大量购买其书籍用作赠品或促销礼品或用于企业培训的客户给予特别折扣.
如需联系销售代表,请访问www.
mhprofessional.
com上的ContactUs(联系我们)页面.
保护OracleDatabase12c:技术入门版权所有2014,McGraw-HillEducation(出版商).
保留所有权利.
在美国印刷.
除1976年美国版权法许可外,未经出版商事先书面许可,不得以任何形式或任何方式复制或分发本出版物,或者将其存储在数据库或检索系统中,但程序清单例外.
虽然程序清单可以在计算机系统中输入、存储和执行,但不得用于复制出版.
Oracle是OracleCorporation和/或其关联公司的注册商标.
所有其他商标是其各自所有者的商标,McGraw-HillEducation并不对所提及的包含这些标志的产品声明所有权.
本文档中转载的受版权保护的Oracle软件程序的屏幕截图均经过OracleCorporation和/或其关联公司的许可.
ISBN978-0-07-182617-4MHID0-07-182617-3策划编辑校对PaulCarlstroemPaulTyler编辑部主任发行主管PattyMonJeanBodeaux组稿协调员美术总监,封面AmandaRussellJeffWeeks编审MargaretBerson出版商所获信息均来自可靠来源.
然而,由于我们的消息来源、出版商或其他环节可能存在人为或机械错误,因此出版商不对本文档中任何信息的准确性、妥善性或完整性作任何保证,并且不对任何错误或遗漏以及使用此信息带来的任何结果负责.
OracleCorporation不对本文档中任何信息的准确性、妥善性或完整性作任何陈述或保证,同时也不对任何错误或遗漏承担责任.
作者简介MichelleMalcherIOUG董事会主席和DRWHoldingsDBA团队负责人Michelle在芝加哥的DRWHoldings担任OracleACE总监及DBA团队负责人,在数据库开发、设计和管理方面拥有多年经验.
她精通超大型数据库环境的安全性、性能调优、数据建模和数据库架构.
她曾负责其公司数据库的安全性,后来开始致力于写作和演讲,涉及安全性和合规性话题以及RAC、ASM和数据恢复等数据库管理领域.
她还是《IOUGBestPracticesTipBooklet》等多部图书的特约作者.
她始终积极推进IOUG的发展,目前担任IOUG董事会主席.
PaulNeedhamOracle数据库安全产品管理高级总监Paul负责Oracle数据库安全特性及相关产品的开发工作,包括OracleAdvancedSecurity、OracleDatabaseVault、OracleAuditVaultandDatabaseFirewall和OracleLabelSecurity.
自1991年加入Oracle咨询部门以来,Paul始终致力于协助客户确定其安全需求和安全挑战,并构建创新解决方案.
他于1998年加入Oracle数据库安全产品管理团队,随后推出了众多新数据库安全特性和新产品.
加入Oracle之前,Paul曾在BDMInternational(一家跨国信息技术公司)负责各种政府项目,并且曾作为实习生在美国国家安全局学习数据库安全技术.
Paul毕业于美国普渡大学,获计算机科学理学学士学位.
ScottRotondoOracle数据库安全技术专家组顾问成员Scott是Oracle数据库安全开发团队的一位软件架构师.
Scott拥有25年计算机从业经验,曾先后在操作系统和数据库开发部门担任高级技术和管理职务,主要致力于安全特性研发工作.
从2008年到2010年,Scott担任可信计算组(TrustedComputingGroup)总裁;TCG是一家行业联盟和标准组织,致力于通过批量生产的标准化安全硬件来增强系统安全性.
iv序言20世纪90年代初,接入互联网的数据库寥寥无几,当时的互联网肯定无法与现在同日而语.
当时,我们安全技术的用户主要是关注数据分类和多级安全性的政府和国防机构.
合规性法规更是少之又少.
当时还没有支付卡行业数据安全标准(PCI-DSS),HIPAA也仅仅是初具雏形.
如果DBA希望窃取大量信息(当时,数百MB就是非常"大"的量了),他们需要携带一个有几块建筑用砖那么大、那么重的磁盘驱动器.
除了Oracle的多级安全解决方案外,我们客户群中采用比较广泛的数据库安全特性包括自主访问控制和数据库角色.
当时甚至不需要考虑内部人员、有组织犯罪、黑客和SQL注入带来的数据威胁.
主要的安全需求就是使用权限、角色和视图实施"按需知晓"原则.
我1993年加入Oracle时,所有数据库的用户群必然是有限的—当时还是采用客户端-服务器计算模式的时代,与运行数据库的机器相比,数据库显然比较小;有权访问数据库的用户数量也非常少.
大多数用户基本上都不需要考虑数据库安全性.
在一些应用中,SQL注入被认为是可以接受的.
事实上,我还记得在OracleForms中通过SQL注入修改查询是多么简单.
当然,由于大多数应用采用的都是客户端-服务器模式,因此这并不是什么大问题,因为应用用户需要使用自己的个人凭证来连接数据库,而不是当今应用所采用的单一大应用用户模型(One-Big-ApplicationUserModel).
如今的世界已经大为不同.
DBA可以在外形尺寸和重量比手机还小的设备上轻松处理TB级的信息.
据统计,特权帐户和SQL注入是访问敏感信息的首选方式.
隐私与合规性要求几乎已渗透至全球的各行各业.
客户必须定期通过各项法规的审查,包括Sarbanes-Oxley法案、欧盟数据保护指令、中国的个人信息保护指南以及日本的APPI.
如今,三层软件架构已成为行业标准,能够访问一些级别应用数据的用户群非常巨大,通常至少数以千计.
如果您不想因用户个人信息被盗而上新闻头条,那么保护您的数据和基础设施已成为一项首要需求.
安全性与高可用性和可扩展性同等重要.
设计新应用时,从一开始就必须考虑安全性,而且要贯穿生命周期开发过程的每个阶段.
鉴于此,《保护OracleDatabase12c:技术入门》一书应运而生.
本书的三位作者在数据安全领域拥有数十年的工作经验,更重要的是,他们在Oracle数据库安全领域也拥有数十年的工作经验.
v本书由浅入深,首先介绍如何控制授权用户的访问.
这包括通过实施"最低权限"来防止受信任的DBA或其他未经授权的人员实际或者象征性地带走TB级的敏感信息.
数据库中的每个用户以及每种应用模式都应该具有完成工作所需的一组最小的授权和权限—我们将看到如何实现这一目标并了解其如此重要的原因.
全面介绍访问控制之后,本书将探讨发生失窃时如何保护数据;即使所有访问控制均被破坏的情况下如何保护数据.
本书将介绍数据加密的概念,并讨论如何在多个层面上实现数据加密.
接下来,本书将探讨一些更高级的访问控制方法,例如列级和行级访问控制.
这将不再局限于简单的表和系统权限.
随后,本书将介绍一个相关的安全特性:审计.
我们将探索数据库的审计功能以及如何主动使用这些功能,而不是将其用作事后诊断工具.
接下来,本书将讨论SQL注入.
SQL注入可能是最普遍的数据库攻击方式.
SQL注入利用已开发的应用代码中的漏洞,与数据库无关.
由于应用代码比数据库代码要多得多,而且大多数应用代码在编写过程中都没有考虑SQL注入的问题,因而许多应用易受攻击.
在互联网上搜索"SQL注入"将返回数百万条新闻,其中许多新闻的内容都是某公司最近遭受攻击,导致敏感客户数据泄漏.
本书将探讨数据库和安全专业人员如何在应用与数据库之间添加一个防护层,进而削弱外部人员成功发起SQL注入攻击的可能性.
最后,本书将介绍如何实现合规性.
1993年,一家公司运行10个甚至100个Oracle数据库就算"很多"了.
20年后,运行成千甚至上万个Oracle数据库的公司早已司空见惯.
企业必须确保所有这些数据库都安装了最新补丁并且完成了安全配置.
验证检查是一项繁琐甚至难以完成的工作,但如果采用适当的方法和工具则另当别论.
本节将介绍这方面的信息.
您将了解如何验证和确认系统配置的合规性,以确保数据库环境是采用安全的、经过验证的方式搭建的.
如果您对安全性—具体来说,为Oracle数据库提供安全防护—感兴趣的话,本书将非常适合您.
尽管本书使用OracleDatabase12c作为书名的一部分,但其中大多数内容适用于OracleDatabase9i及更高版本.
ThomasKytehttp://asktom.
oracle.
com/vi致谢作者诚挚感谢以下人员在本手稿的编制和审查过程中提供的宝贵帮助:TroyKitch、MelodyLiu、VikramPesati和JamesSpooner.
vii引言为重要信息提供安全防护很不幸成为全球任何组织都需要面对的一个问题.
我们不断在新闻中看到黑客通过攻击获取了某公司的敏感数据并给该公司造成了重大法律、经济和声誉损失.
即便绝大多数敏感数据都存储在关系数据库中,大多数组织的信息安全措施也很少侧重于这些数据库的安全性.
尽管许多技术和产品可以通过各种方式提高数据库的安全性,但我们需要的是采用简要而全面的方式概述所面临的主要威胁以及解决这些问题的相应技术.
攻击者可能会利用一切可利用的弱点,包括数据库未正确配置安全控制、操作系统未安装补丁以及用户帐户被盗用.
此外,还有一些更间接的方法,例如SQL注入或在网络上拦截数据.
真正安全的数据库系统防护需要考虑攻击者可能利用的一切漏洞.
本书中的每一章将介绍一类威胁,不过这些威胁都是息息相关的.
没有一种解决方案可以防范所有攻击方式,各种安全机制是相辅相成的.
纵深防御是有效应对已知和未知威胁的唯一途径.
我们首先介绍数据库中可用的安全特性.
第一章:控制数据访问和限制特权用户介绍验证用户身份以及控制其可访问的数据的基本概念.
本章涵盖如何确定每个用户所需访问权限以及如何限制高权限用户的最佳实践.
第二章:防止直接访问数据阐述如何通过加密来防止试图绕过上一章中介绍的访问控制机制直接访问数据的攻击.
第三章:高级访问控制阐述如何通过更高级的访问控制机制实现更精准的控制.
这些机制包括虚拟专用数据库、OracleLabelSecurity和RealApplicationSecurity.
第四章:审计数据库活动阐述如何维持有效的审计跟踪,这是一项重要的纵深防御技术,可检测特权用户的权限滥用以及前述章节中实施的安全策略的意外违规情况.
随后,我们还将探讨如何引入外部组件来提高数据库及其存储的数据的安全性.
第五章:控制SQL输入阐述如何使用专业的数据库防火墙监视访问数据库的SQL语句.
这有助于防范Web用户对数据库发起的SQL注入攻击.
viii第六章:屏蔽敏感数据阐述如何采用数据屏蔽技术从用于测试或开发的数据中删除敏感信息.
本章还探讨如何采用数据编辑功能动态屏蔽针对生产数据库的查询结果.
第七章:验证配置合规性阐述根据行业认可的标准评估数据库配置的必要性,以及如何通过相应的评估工具来确保持续合规性.
在本书中,我们将重点介绍OracleDatabase12c的新特性.
不过本书中介绍的大多数解决方案也适用于更早版本的OracleDatabase.
1第一章控制数据访问和限制特权用户数据库系统安全防护领域最重要的任务就是确定用户对数据的访问权限.
本章介绍用户帐户管理以及如何确定每个用户的访问权限.
随后,本章将探讨用户的特权访问类型以及可通过哪些工具删除用户不需要的访问权限.
用户管理针对数据库的所有访问都是由用户发起的,无论是管理用户、应用帐户还是普通用户.
由于用户可以直接连接到数据库,因此有必要对他们进行适当的身份验证,确保他们拥有适当的角色,并确保其帐户不会轻易受到攻击.
此外,还需要确保对其可使用的资源加以限制,否则将对数据库的其余部分造成间接影响.
CREATEUSER语句用于创建数据库用户及其相关模式.
在下面的例子中,通过密码来识别用户,该帐户将遵循org_profile中的策略.
CREATEUSERjsmithIDENTIFIEDBYNoOne!
KnowsPROFILEorg_profileDEFAULTTABLESPACEdata_tsTEMPORARYTABLESPACEtemp_ts;配置文件指定了一系列资源限制和密码参数,用于限制过度使用系统资源并对密码加以限制.
可通过密码相关参数进行密码管理,包括帐户锁定、密码老化、密码历史和密码复杂性验证.
密码验证功能或许是确保用户选择复杂密码的最重要的控制措施,旨在防止入侵者破解用户密码.
FAILED_LOGIN_ATTEMPTS参数可设定在登录失败达指定次数后锁定帐户,从而防范攻击者对密码进行暴力破解.
2CREATEPROFILEorg_profileLIMITFAILED_LOGIN_ATTEMPTS6--attemptsallowedbeforelockingPASSWORD_LIFE_TIME180--maxlife-timeforthepasswordPASSWORD_VERIFY_FUNCTIONora12c_verify_function;--PasswordcomplexitycheckDBA_USERS和DBA_PROFILES字典视图分别用于描述用户和配置文件.
用户创建权限只能分配给DBA或安全管理员.
应为每个用户分配一个表空间;否则,他们创建的任何对象都将进入SYSTEM表空间,从而导致数据字典对象与用户对象相冲突.
OracleMultitenant数据库用户OracleDatabase12c的OracleMultitenant选件包括通用用户和本地用户.
通用用户是在容器数据库中创建的,在该容器数据库的所有可插拔数据库中均采用相同的用户名和密码.
通用用户除了具有容器层面授予的权限,还可以具有每个可插拔数据库中授予的其他权限.
每个可插拔数据库中的权限可能不尽相同,不过不需要在每个可插拔数据库中创建通用用户.
如需为容器数据库和所有可插拔数据库创建通用用户,请以SYSTEM身份登录容器数据库并使用CONTAINER=ALL参数创建用户.
请注意,所有通用用户都使用C##作为其名称的前缀.
SQLPLUS>CONNECTSYSTEM@rootEnterpassword:Connected.
SQLPLUS>CREATEUSERC##DB_ADMINIDENTIFIEDBYIronMan4CONTAINER=ALL;另一方面,本地用户是在可插拔数据库中创建的,不具备访问容器的权限.
这将帮助管理员更好地管理可插拔数据库,但是不能用于管理整个系统.
如需3创建本地用户,请使用SYSTEM身份连接至可插拔数据库,像往常一样授予必要的角色和权限,然后指定CONTAINER=CURRENT而不是CONTAINER=ALL.
SQLPLUS>CONNECTSYSTEM@pdb1Enterpassword:Connected.
SQLPLUS>CREATEUSERpdb1_adminIDENTIFIEDBYSpiderMan3CONTAINER=CURRENT;存储密码用户连接数据库时需要提供密码,但应用、中间层系统和批处理作业不支持手动输入密码.
过去,提供密码的一种常用方法是在代码或脚本中嵌入用户名和密码.
这不仅会导致攻击面扩大,而且相关人员还需要确保其脚本未向其他人公开.
此外,如果密码经过修改,则脚本也需要进行相应的修改.
现在,您可以使用客户端Oracle钱夹存储密码凭证.
这样,密码就不会再出现在命令行历史记录中,密码管理策略也更容易实施,用户名或密码发生更改时也无需修改应用代码,最终有助于降低风险.
要使用Oracle钱夹配置密码存储,请设置sqlnet.
ora文件中的WALLET_LOCATION参数.
之后,应用在连接数据库时便无需提供登录凭证,如下所示:CONNECT/@hr_db.
example.
com身份验证方式用户需要先经过身份验证,然后才能连接数据库.
Oracle支持各种不同的身份验证方式,包括将密码存储在本地的数据库或目录中.
还可以由操作系统验证用户身份,这需要在创建用户时使用IDENTIFIEDEXTERNALLY子句,也可以由Kerberos、SSL/TLS和RADIUS等第三方服务来完成身份验证.
密码仅用于在用4户连接至数据库时的单向身份验证,而Kerberos和PKI支持双向身份验证,可确保用户连接至正确的数据库.
基于SSL/TLS进行通信的Oracle客户端和服务器必须拥有一个包含X.
509证书、私钥和受信任证书列表的钱夹.
要完成此配置,管理员需要使用OracleWalletManager创建用于存储PKI凭证的钱夹,并使用OracleNetManager配置SSL身份验证所使用的sqlnet.
ora和listener.
ora.
以下示例显示如何使用PKI证书创建用户:SQL>CREATEUSERjsmithIDENTIFIEDEXTERNALLYAS'cn=jsmith,OU=HR,O=oracle,c=US';用户可以在支持Kerberos的环境中使用该服务验证数据库身份.
要配置此功能,请使用OracleNetManager在Oracle数据库服务器和客户端的sqlnet.
ora文件中设置必要的参数.
以下示例显示如何创建一个与Kerberos用户对应的、采用外部身份验证的用户:SQL>CREATEUSERjsmithIDENTIFIEDEXTERNALLYAS'jsmith@example.
com';现在,您无需提供用户名或密码便可连接至Oracle数据库服务器,如下所示:$sqlplus/@hr_db.
example.
com;集中用户管理在一个企业中,如果有大量用户需要访问大量数据库,那么管理每个数据库中每个用户的唯一帐户就变得非常困难.
OracleEnterpriseUserSecurity(EUS)可在OracleInternetDirectory中集中管理多个数据库的用户和角色,并且OracleInternetDirectory将与MicrosoftActiveDirectory等目录相集成.
此类用户被称作企业用户,为他们分配的企业角色将确定对多个数据库的访问权限.
企业角色包括一个或多个全局角色,每个全局角色授予对特定数据库的访问权限.
5EUS可通过OracleInternetDirectory借助密码、Kerberos或SSL对用户和管理员进行身份验证.
连接时,数据库会从该目录中获取用户身份验证、授权(角色)信息和模式映射.
企业用户可以有自己的模式,也可以与所访问的数据库共享全局模式.
以下示例展示了一个采用独占模式的企业用户jsmith.
CREATEUSERjsmithIDENTIFIEDGLOBALLYAS'CN=jsmith,OU=HR,O=oracle,C=US';具备管理权限的用户某些用户可以使用特殊的管理权限(如SYSDBA和SYSOPER)连接数据库,这样便可在不打开数据库的情况下执行维护操作.
这些用户可以使用基于网络的身份验证服务(如OracleInternetDirectory)执行身份验证,也可以根据连接用户是否属于特定操作系统用户组来执行身份验证.
如果用户以管理权限连接时必须用密码来进行身份验证,那么该密码必须存储在数据库外部的密码文件中,该文件可通过orapwd命令进行管理.
该密码文件不支持用户管理功能,例如在多次登录失败后锁定帐户.
不过,当数据库运行时,每次登录失败都会产生延迟,从而在一定程度上限制密码破解.
代理身份验证和授权有时,管理员需要连接应用模式来执行维护.
多个管理员共享应用模式密码将无法确保责任界定.
而代理身份验证可以让管理员先使用自己的凭证进行身份验证,然后再通过代理连接至应用模式.
在这种情况下,审计记录将显示执行维护活动的实际用户.
OracleCallInterface(OCI)、JDBC和SQL*PLUS命令行均支持这种代理身份验证.
以下示例允许app_dba用户连接至数据库后使用hrapp身份执行操作.
ALTERUSERhrappGRANTCONNECTTHROUGHapp_dba;6现在,app_dba用户可以使用自己的密码连接数据库,然后通过代理使用hrapp用户的身份,如下所示:CONNECTapp_dba[hrapp]Enterpassword:基本访问控制数据库中的每个对象(如表、视图和过程)都包含在模式中.
模式是Oracle数据库中拥有对象的用户.
模式用户通常具备操作模式中所含对象的完全权限.
其他用户的访问权限则由对象权限确定,对象权限将允许用户对特定对象执行特定操作.
针对对象的一些典型操作包括SELECT、INSERT、UPDATE、DELETE、ALTER和EXECUTE.
拥有对象的模式用户可向其他用户授予对象权限.
而且,如果授予对象权限时使用了GRANTOPTION,那么该权限的接收者也能够向其他人授予相同的权限.
以这种方式传递授权的能力非常强大,应慎用.
以下示例显示如何创建一个只具备数项权限的用户:创建一个会话并连接至数据库,允许对DEPARTMENTS表执行SELECT操作,允许执行ADD_DEPARTMENT过程,并授予读取和更改ADVENTURES表中数据的完全权限:SQL>CREATEUSERjsmithIDENTIFIEDBY"Raider5!
";SQL>GRANTCREATESESSIONTOjsmith;SQL>GRANTSELECTONhr.
departmentsTOjsmith;SQL>GRANTEXECUTEONhr.
add_departmentTOjsmith;SQL>GRANTSELECT,INSERT,UPDATE,DELETEONhr.
adventuresTOjsmith;DBA_TAB_PRIVS字典表显示所授予的对象权限.
其中包括对象的详细信息,包括模式所有者以及所授予的权限.
该表可用于报告权限和管理权限级别.
7SQL>SELECTGRANTEE,OWNER,TABLE_NAME,PRIVILEGEFROMDBA_TAB_PRIVSWHEREGRANTEE='JSMITH';GRANTEEOWNERTABLE_NAMEPRIVILEGEJSMITHHRDEPARTMENTSSELECTJSMITHHRADVENTURESSELECTJSMITHHRADVENTURESINSERTJSMITHHRADVENTURESDELETEJSMITHHRADVENTURESUPDATEJSMITHHRADD_DEPARTMENTEXECUTE当不再需要某个对象上的权限时,应予以撤销.
SQL>REVOKEDELETEONhr.
adventuresFROMjsmith;系统权限和角色对象权限可以非常精细地控制用户可以访问的数据,不过管理员有时可能需要访问多个对象.
系统权限允许访问特定类型的所有对象;例如,SELECTANYTABLE允许用户对任何模式中的任何表执行SLECT操作,EXECUTEANYPROCEDURE允许执行任何PL/SQL过程或函数.
其他系统权限适用于不涉及特定对象的操作,如创建对象、用户和角色;更改会话和系统参数;以及导出和导入数据库.
可以看出,这些权限令管理员执行的操作可以影响多个模式和对象.
另外一个方便的权限管理特性可将多个对象权限和系统权限归到一个角色中.
当需要为多个用户授予一组相同的权限时,角色将派上用场.
角色比单独的权限更易于管理,并且可与应用或工作职能相匹配.
可以将一些角色授予其他角色,这样便可通过一些小权限角色建立DBA这样的大权限角色.
与对象权限的GRANT选项类似,系统权限或角色也支持ADMINOPTION,该选项允许接收者将该角色或权限授予其他人.
8下表中的字典表显示授予每个用户或角色的角色和权限.
例如,从这些表中可以看出,DBA是一个非常强大的角色,具备200多项系统权限,包括CREATE和ALTERSESSION;CREATE和ALTERANYTABLE;SELECT、INSERT、UPDATE和DELETEANYTABLE;EXPORT和IMPORTFULLDATABASE;DROP和CREATETABLESPACE;EXECUTEANYPROCEDURE以及十几个角色.
字典表内容DBA_TAB_PRIVS授予角色或用户的对象权限DBA_SYS_PRIVS授予角色或用户的系统权限DBA_ROLE_PRIVS授予用户或其他角色的角色DBA_ROLES所有定义的角色最小权限和职责分离最小权限原则是指应为该系统的每个用户仅授予完成其预定任务或职能所需的最小一组权限.
授予用户或角色权限时,最好授予所需的特定对象权限,而不是授予允许访问数据库中所有对象的广泛系统权限.
同样,创建角色时应仅包含完成特定职能所需的少量权限,而不是创建像内置的DBA角色这样非常强大的角色.
授予用户一些小权限角色可确保用户与所需完成的任务相匹配,而不必授予过多不需要的权限.
职责分离的理念与最小权限原则密切相关.
具体来说,应让多个用户承担不同权限,而不是创建一个超级用户.
采用这种方式划分管理权限可加强责任界定,而且还可避免受信任的管理员滥用权限.
为了支持最小权限和职责分离原则,Oracle数据库很早就引入了SYSOPER管理权限,允许管理员执行启动和停止数据库等特定任务,而无需授予其SYSDBA的完全权限.
OracleDatabase12c新增的管理权限包括SYSBACKUP、SYSDG和SYSKM,分别用于支持数据库备份、DataGuard管理和密钥管理.
有了这些针对性的权限,管理员无需全能的SYSDBA权限也可执行管理数据库所需的一切常规操作.
9控制特权用户系统权限和强大的角色可对数据库进行高度控制,包括查看所有数据和更改数据.
一些管理用户需要使用这些强大的权限来执行维护、调优和备份,不过他们并不需要访问全部数据.
即使有管理权限的用户是可以信赖的,但也有必要限制这些特权帐户对公司数据资产和个人信息的访问,以防止内部用户或攻击者的非授权使用.
OracleDatabaseVault在数据库中提供了一些操作控制,包括通过领域来限制对表和视图等特定对象的访问.
创建DatabaseVault领域之后,向其中添加一些对象,并且可以将数据库用户指定为领域参与者.
这样只赋予领域参与者访问权限,其他用户被排除在外,即使他们拥有SELECTANYTABLE这样强大的系统权限也不能访问该领域中的对象.
下图显示了如何通过两个领域来保护包含人力资源(HR)和财务(FIN)数据的数据库模式.
领域一经启用,就会阻止特权管理用户或其他应用所有者使用其高级权限访问数据.
特权应用所有者HR无法访问FIN领域中的数据,甚至具有DBA角色的管理员也无法访问HR和FIN领域中的数据.
10除了常规领域外,OracleDatabase12c还支持创建强制领域.
常规领域将阻止非领域参与者使用SELECTANYTABLE等系统权限访问数据,但是无法阻止模式所有者或其他用户使用对象权限访问领域中的数据.
强制领域将阻止所有非领域参与者访问领域中的数据.
强制领域的一种常见应用是在安装补丁和升级期间继续保护敏感数据,即当管理员需要修改应用模式但不应访问该模式中的数据表时.
配置OracleDatabaseVault的过程中会创建另外两个用户.
第一个用户是DatabaseVault所有者,他可以创建和管理领域以控制对敏感数据的访问.
第二个用户是DatabaseVault帐户管理员,负责在数据库中创建用户.
虽然一个用户就能完成这两项职能,但将这些职责划分给多个用户可以实现之前介绍的职责分离.
而且,通过将DVOWNER角色授予其他用户可将管理DatabaseVault领域的职责委派给他人.
应将该角色授予负责数据库安全配置的管理员,而不是普通的数据库管理员.
下图显示了如何使用DatabaseConfigurationAssistant启用OracleDatabaseVault.
管理DatabaseVault需要使用这些专门的用户和角色.
启用DatabaseVault后,SYSDBA管理权限将不适用于领域或用户管理.
11管理授予的权限最小权限原则是指每个用户以及授予用户的每个角色应只具备执行预定职能所需的一组最小权限.
虽然字典表显示1字符了已授予的权限和角色,但很难确定哪些权限是真正需要的.
系统使用了一段时间后,此问题尤为明显,因为权限和角色授予往往会累积,所以很难确定何时撤销才是安全的.
OracleDatabaseVault12c新增的"权限分析"特性捕获运行时使用的权限并生成一系列报告.
可以使用这些报告查找可能不再需要的权限,甚至生成自动撤销未用权限的脚本.
12以下示例显示了如何为数据库的所有用户启用权限捕获.
SQLPLUS>BEGINDBMS_PRIVILEGE_CAPTURE.
CREATE_CAPTURE(NAME=>'dba_capture_all_privs',DESCRIPTION=>'privilege_analysis_for_all_users',TYPE=>DBMS_PRIVILEGE_CAPTURE.
G_DATABASE);END;/PL/SQLproceduresuccessfullycompleted.
捕获正常运行过程中使用的权限之后,经过适当的时间间隔,DBA_USED_PRIVS和DBA_UNUSED_PRIVS视图将显示哪些权限已被使用,更重要的是,还将显示哪些授予的权限未被使用.
SQLPLUS>BEGINDBMS_PRIVILEGE_CAPTURE.
GENERATE_RESULT(NAME=>'dba_capture_all_privs');end;/PL/SQLproceduresuccessfullycompleted.
SQLPLUS>SELECTUSERNAME,USED_ROLE,SYS_PRIV,OBJ_PRIV,USER_PRIV,OBJECT_OWNER,OBJECT_NAMEFROMDBA_USED_PRIVS;SQLPLUS>SELECTUSERNAME,USED_ROLE,SYS_PRIV,OBJ_PRIV,USER_PRIV,OBJECT_OWNER,OBJECT_NAMEFROMDBA_UNUSED_PRIVS;可以使用类似下面的SQL语句生成用于撤销未用权限的脚本.
管理员应先检查该脚本,验证要撤销的权限列表,然后再执行.
--GenerateascripttorevokeSQLPLUS>SELECT'revoke'||OBJ_PRIV||'on'||OBJECT_OWNER||'.
'||OBJECT_NAME||'from'||USERNAME||';'FROMDBA_UNUSED_PRIVS;以下视图可显示权限捕获所生成的信息.
13视图描述DBA_PRIV_CAPTURES列出现有权限分析策略的相关信息.
DBA_USED_PRIVSDBA_UNUSED_PRIVS以所报告的权限分析策略为基准,列出已使用(未使用)的权限.
DBA_USED_OBJPRIVSDBA_UNUSED_OBJPRIVS以所报告的权限分析策略为基准,列出已使用(未使用)的对象权限.
DBA_USED_OBJPRIVS_PATHDBA_UNUSED_OBJPRIVS_PATH列出已用于(或未用于)所报告的权限分析策略的对象权限.
其中包括对象权限授予路径.
DBA_USED_SYSPRIVSDBA_UNUSED_SYSPRIVS列出已用于(或未用于)所报告的权限分析策略的系统权限.
DBA_USED_SYSPRIVS_PATHDBA_UNUSED_SYSPRIVS_PATH列出已用于(或未用于)所报告的权限分析策略的系统权限.
其中包括系统权限授予路径.
DBA_USED_PUBPRIVS列出已用于所报告的权限分析策略的PUBLIC角色的所有权限.
DBA_USED_USERPRIVSDBA_UNUSED_USERPRIVS列出已用于所报告的权限分析策略的用户权限.
DBA_USED_USERPRIVS_PATHDBA_UNUSED_USERPRIVS_PATH列出已用于所报告的权限分析策略的用户权限.
其中包括用户权限授予路径.
14第二章防止直接访问数据上一章介绍了如何配置Oracle数据库控制用户对数据的访问权限.
配置这个由数据库实施的访问控制是非常重要的,可确保只有相关人员能够访问所需的数据,其他人员则无权访问这些数据.
当然,攻击者并不会只盯着防御最强大的环节;如果附近有一扇开着的窗户,他们显然不会反复尝试打开上锁的前门.
如果为数据库正确配置了数据访问控制,那么攻击者自然会尝试绕过坚固的数据库,转而选择其他攻击目标.
一种途径是用特权操作系统用户(如root或oracle)的身份获取系统访问权限.
此类用户可以更改数据库程序的行为,令其忽略已配置好的访问控制设置.
针对此类攻击的最佳防范措施是阻止攻击者获取对主机系统的访问权限,例如遵从互联网安全中心发布的操作系统强化指导准则.
另一条攻击路线是绕过数据库直接读取或写入数据,包括磁盘文件存储中的数据以及通过网络在两个系统之间传输的数据.
这两种情况下均可通过加密技术为数据提供有效防护.
这样一来,用户只需注意加密密钥的安全性即可,而不必再为保护大量数据费神.
只要攻击者没有密钥,他们就无法从任何加密数据中截获有用信息.
而且,加密还是一些关于敏感或个人身份信息的法规和安全标准的强制要求.
本章将阐述如何配置和使用加密来保护静止数据和传输中的数据.
此外,本章还将介绍安全存储用于保护加密数据的加密密钥时的注意事项和选项.
15静止数据当信息写入数据库时,它最终将存储在磁盘文件中.
为了确保攻击者无法直接从磁盘文件中读取信息,每个应用在将数据存储到数据库中之前都应对数据进行加密.
然而,这需要额外的编程工作来确保应用在存储数据前进行加密并将其检索到的数据解密.
此外,应用还需要管理加密密钥并将其存放在安全的位置.
如果多个应用共享同一数据库中的信息,那么它们需要合作来加密和解密数据.
为了简化这一过程,Oracle在OracleAdvancedSecurity中引入了透明数据加密(TDE).
数据库会在数据写入磁盘之前自动执行加密并在从磁盘中读取数据时自动执行解密,因此整个加密过程是透明的.
在数据库中存储和检索数据的应用只能看到解密后的数据或纯文本数据.
由于加密和解密是自动进行的,所以这并不是针对Oracle数据库用户的访问控制机制,而是一种防止用户绕过数据库直接访问数据的方法.
用户和应用使用SELECT语句检索数据时不用提供解密密钥.
而是由数据库实施上一章中介绍的访问控制规则,并拒绝未经授权的用户查看数据.
如果允许访问,则会在返回数据之前自动执行解密.
无论是否允许访问,永远都不会将加密数据返回给用户.
配置透明数据加密时,需要指定要加密的数据,然后再设置一些关于加密执行方式的选项.
指定加密数据时可以选择列加密(即对特定表中的特定列进行加密)和表空间加密(对特定表空间中所有表中的所有列进行加密).
通过设置列的ENCRYPT属性可指定列加密,如下例所示.
如果只有几列包含需要保护的敏感信息,且这些列仅占数据库数据总量的一小部分,那么列加密是最理想的方案.
针对这种情况,一种比较高效的方法是仅产生敏感列的加密和解密开销,将其余数据存储为纯文本形式.
此外,还可以随时使用ALTERTABLE命令对现有数据应用此方法.
16CREATETABLEemployee(first_nameVARCHAR2(128),last_nameVARCHAR2(128),empIDNUMBER,salaryNUMBER(6)ENCRYPT);然而,在大多数用例中,表空间加密可提供一些引人注目的优势.
对整个表空间执行加密便无需确定哪些数据很重要需要保护,哪些不需要保护.
而且,这还将确保敏感数据不会因失察或要求变化而意外泄漏.
一些现代硬件在CPU中内置了专用于加速加密操作的特殊指令,在其上运行数据库时,对所有数据进行加密的性能开销几乎可以忽略不计,因此无需就哪些数据需要保护进行决断.
在创建表空间时配置表空间加密,如下所示:CREATETABLESPACEencrypt_tsDATAFILE'$ORACLE_HOME/dbs/encrypt_df.
dbf'SIZE100MENCRYPTIONUSING'AES128'DEFAULTSTORAGE(ENCRYPT);传输中的数据攻击者绕过数据库直接访问数据的另一种途径是截取网络上传输的数据,例如在客户端与数据库服务器之间传输的数据.
在许多网络上,攻击者都可以相当轻松地捕获发往其他系统的网络流量,然后提取两个系统之间传输的信息.
鉴于此,不仅需要对磁盘上存储的数据加密,而且有必要对通过网络发送的数据加密.
17使用SSL或Oracle原生加密对网络上的数据加以保护过去是AdvancedSecurity选件的一个特性,不过现在已成为Oracle数据库的一个标准特性.
可将此特性配置为同时提供加密(防止其他人读取通过网络发送的数据)和完整性保护(防止其他人修改或重放数据).
每个Oracle客户端和服务器的网络数据保护设置均在sqlnet.
ora文件中配置.
每个系统的适用设置包括所支持的加密算法列表以及下面列出的四个加密和完整性保护选项中的一个.
根据这些设置,两个系统在建立连接时会协商确定是否启用加密和/或完整性保护,以及使用哪种加密算法.
REJECTED系统不会启用此服务(无论是加密还是完整性保护).
如果其他系统需要此服务,连接将失败.
ACCEPTED系统不会请求启用该服务,但会在其他系统请求时表示同意.
REQUESTED系统会请求启用该服务,不过当其他系统拒绝时,它会以未启用服务的形式建立连接.
REQUIRED系统会请求启用该服务.
如果其他系统拒绝,连接将失败.
密钥管理和存储现代加密系统并不依赖秘密加密算法来保证数据的安全.
专业密码学家很久以前就发现,采用众所周知的且弱点经过专家仔细研究的算法会更安全.
这一事实的实际意义在于,受保护数据的安全性完全取决于加密密钥的保密性.
适当的密钥管理是必不可少的,可以防止攻击者破解或猜出密钥并获取受保护数据的访问权限.
18管理员使用一系列SQL命令或者通过一个管理界面调用这些命令,执行Oracle数据库所需的所有密钥管理操作.
OracleDatabase12c新增的一个选项让用户能够以SYSKM身份(而非SYSDBA身份)连接数据库,然后执行密钥管理操作.
此处遵循了上一章中介绍的最小权限原则,SYSKM管理权限仅支持用户执行所有密钥管理任务,而不具备SYSDBA的超级权限.
OracleDatabase12c还在ADMINISTERKEYMANAGEMENT语句中引入了一组统一的密钥管理命令.
该语句支持所有密钥管理操作,这些操作以前需要结合使用orapki实用程序与ALTERSYSTEM语句才能完成.
以下示例显示了新命令的使用.
ConnectusingtheSYSKMadministrativeprivilege.
sqlplususer/passwordASSYSKMCreateanewOraclewallet.
SQL>ADMINISTERKEYMANAGEMENTCREATEKEYSTORE'keystore_location'IDENTIFIEDBYkeystore_password;OpenanOraclewallet.
SQL>ADMINISTERKEYMANAGEMENTSETKEYSTOREOPENIDENTIFIEDBYkeystore_password;MakeabackupcopyofanOraclewallet.
SQL>ADMINISTERKEYMANAGEMENTBACKUPKEYSTOREIDENTIFIEDBYkeystore_passwordTO'backup_location';SetorrotatetheTDEmasterencryptionkey.
SQL>ADMINISTERKEYMANAGEMENTSETENCRYPTIONKEYIDENTIFIEDBYkeystore_password;19密钥管理最重要的一个环节是将密钥存放在安全的位置.
Oracle数据库和其他Oracle产品均采用一个被称作"钱夹"的特殊文件存储加密密钥和其他机密数据.
当有人打开钱夹访问其中的密钥时,会使用由用户必须提供的密码派生的密钥对钱夹的内容进行加密.
用于加密钱夹的密码不会随意存放,从而确保攻击者一无所获.
当然,如果用户丢失或忘记密码,则无法打开钱夹或访问使用该钱夹加密的数据.
通常,使用TDE的Oracle数据库将主密钥存储在一个Oracle钱夹中,该钱夹会在数据库启动时打开.
然而,在某些安装中,让管理员在数据库启动时提供钱夹密码并不可行.
针对这种情况,可以为Oracle钱夹配置一个"自动登录"选项,这样数据库不使用密码也可打开钱夹.
尽管这时钱夹中的内容仍然处于加密状态,但却无法提供与常规的密码保护的钱夹同等级别的保护.
仅当可通过足够的外部安全措施防止攻击者访问钱夹文件时,才可采用此备选方案.
还有一种方法可以让数据库轻松地访问密钥,同时获得一些额外的安全优势,即将密钥远程存储在一台单独的企业密钥管理服务器上,如OracleKeyVault,数据库将通过网络访问该服务器.
使用SSL等网络协议保护数据库与密钥服务器之间的通信.
这样,密钥服务器还可以自动验证数据库的身份,无需管理员在数据库启动时提供密码.
密钥服务器可集中、安全地备份或复制密钥(可能是组织最宝贵的数据),以确保密钥始终可用.
专门的密钥服务器还可以自动管理每个密钥的生命周期,包括跟踪其创建和所有权、使用密钥的目的以及何时需要轮换或更换密钥.
20许多法规,比如支付卡行业(PCI)制定的法规,都要求定期轮换加密密钥,从而避免单一密钥泄漏导致数据泄露.
Oracle数据库使用双层架构将密钥轮换的成本降至最低,从而支持更频繁地轮换密钥.
Oracle透明数据加密使用一个存储在钱夹或密钥服务器中的主密钥.
主密钥不会直接对数据进行加密,而是对内部生成的用于执行列和表空间加密的密钥进行加密.
更换主密钥时,无需重新加密所有数据,只需对小得多的一组数据加密密钥重新加密即可.
21第三章高级访问控制第一章阐述了通过有选择地授予对象权限来控制用户数据访问权限的重要性.
用户应该只能访问包含了其执行任务所需数据的表.
然而,即便只授予用户特定表的SELECT或INSERT等对象权限,该权限也支持用户访问该表中的所有数据.
大多数应用的数据库表中所包含的数据远多于任何一个用户需要访问的数据.
举一个简单的例子,考虑SCOTT示例模式中的EMP员工表.
可以让所有用户查看关于员工姓名和部门的基本信息,不过薪酬属于保密信息,包括SAL和COMM列.
同样,组织可能希望限制对表中特定列的访问,可能只允许员工查看所在部门的数据.
在关系数据库中解决这一问题的长期方案是创建一个视图,其中包含一条WHERE子句来根据需要限制访问,仅允许用户访问视图,而不是基础表.
例如,以下视图就只允许访问一个部门中员工的非薪酬信息.
SQL>createorreplaceviewemp_dept20as2selectempno,ename,job,mgr,hiredate,deptno3fromempwheredeptno=20;Viewcreated.
SQL>select*fromemp_dept20;EMPNOENAMEJOBMGRHIREDATEDEPTNO7369SMITHCLERK790217-DEC-80207566JONESMANAGER783902-APR-81207788SCOTTANALYST756619-APR-8720227876ADAMSCLERK778823-MAY-87207902FORDANALYST756603-DEC-8120将视图用于此目的困难在于,用于选择要包括的数据的所有标准都必须嵌入到视图定义中.
尽管可以在WHERE子句中包括子查询,比如通过子查询来确定请求用户的部门编号,但是编写能够准确表达所需策略的SQL查询很快会变得复杂.
常规策略通常还有一些例外情况,比如为HR管理员或部门经理提供更高的权限,这会增加难度.
Oracle数据库通过虚拟专用数据库(VPD)这个特性满足了这一需求.
使用VPD,可以执行管理员提供的PL/SQL函数确保每次访问表时都能生成适当的WHERE子句.
这样一来,用户便可相当轻松地执行确定所允许的访问权限所需的任何计算.
以下清单显示了一个简单的PL/SQL函数,其策略与上一个示例中的视图相同,通过相应的扩展可支持任何部门,并且可为HR管理员提供更高的权限.
functionemp_policy(p_schemainvarchar2,p_tableinvarchar2)returnvarchar2isuserVARCHAR2(100);matchNUMBER;my_deptNUMBER;begin--Gettherequestinguseruser:=sys_context('USERENV','SESSION_USER');--CheckifrequestorisanHRemployeeselectcount(*)intomatchfromempwhereename=userandjoblike'HR%';ifmatch>0thenreturn'1=1';--matchallrowsendif;--Findtherequestinguser'sdepartment23selectdeptnointomy_deptfromempwhereename=user;return'deptno='||my_dept;end;最后,VPD还支持其他一些仅凭视图难以实现或无法实现的策略变体.
VPD策略可以包括那些含敏感信息的列,但只允许特定用户访问其内容,其他人则检索到null值.
VPD策略还可以根据用户执行的操作来提供针对不同行的访问权限.
例如,可以通过VPD策略来允许用户查看关于所有员工的信息,但只能更新他们自己的信息.
尽管VPD在确定筛选谓词方面提供了充分的灵活性,但开发人员仍需负责访问控制逻辑以及管理与应用相关的所有规则和约束.
例如,本例中的访问控制就基于JOB和DEPTNO列.
在其他一些情况下,访问控制决策可由特定应用角色控制.
通过数据标签控制访问要使用上一节中介绍的细粒度访问控制,可以选择为每个数据项添加一个描述其敏感性或重要性的标签.
在许多政府和企业环境中,一些文档可能会标记为"绝密"或"仅限内部使用",只有具备足够高"权限"的人员才能够访问这些文档.
通常,标签反映了序集级别,每个用户都将获得其权限范围内的最高级别.
该功能让数据库本身知道哪些数据是敏感的,相应地限制对其访问.
为了支持这一通用访问控制模型,OracleLabelSecurity(OLS)简化了为数据和用户分配标签以及根据这些标签实施访问控制的过程.
24受OLS保护的表中的每行都会通过相应的标签来指示数据敏感性.
可以根据业务逻辑明确地设置每行的标签,不过大多情况下,系统会根据在表中插入行的用户会话的标签自动设置用户标签.
而用户会话的标签是根据各种因素计算得出,包括用户身份、数据库连接类型等.
用户标签可视为对标准数据库权限和角色的扩展.
数据库采用了OracleLabelSecurity后就增强了安全性,不再需要复杂的应用视图.
标签的格式表意丰富,足以支持几乎任意数据库分类方案.
每个标签包括一个级别(从最低到最高),用于表示数据的整体敏感性.
在级别内部,可以选择使用隔间(compartment)和组组件根据项目、部门或地理区域等属性隔离信息.
与级别组件不同,隔间之间没有排序.
组中可以包括其他组,这样就可以根据地理区域或组织层次结构轻松地表示部门.
图3-1显示了一个使用所有三个标签组件的分类方案.
图3-1:标签的组件当数据和用户会话都有标签时,可以用一组简单的规则来比较标签并确定是否允许访问.
如果用户标签的级别不低于数据标签的级别,并且包含数据标签中指定的所有隔间以及至少一个组(或其中一个组的父组),则用户可以读取表中带标签的行.
使用图3-1中的示例,标签中包括Global组的用户可以访问标签中包含NATO或Europe组的数据.
25OracleLabelSecurity的主要优势包括灵活性和简化管理.
OLS提供与VPD相同类型的行级访问控制,但无需管理员创建PL/SQL策略函数来实施访问规则.
建立了可以为数据和用户会话分配标签的系统后,访问控制将统一实施,无需确定哪些人能访问各表中的数据.
对应用最终用户应用访问控制策略目前为止所介绍的方法解决了按数据库用户控制数据访问的问题.
然而,在现代三层应用中,应用最终用户并不与数据库直接交互.
数据库查询和更新通常由代表整个应用的单一数据库用户执行,而不是由各个最终用户执行.
由于数据库对最终用户的身份一无所知,因此必须由应用来实施基于用户的访问控制策略.
除了需要在应用中进行额外的软件开发工作外,这种方法还会导致实施不一致,当一些系统要素可绕过应用直接连接数据库时,此问题尤为突出.
OracleDatabase12c中引入的OracleRealApplicationSecurity(RAS)为数据库提供了下一代应用访问控制框架,支持三层和双层应用在数据库层以声明方式定义、供应和实施访问控制要求.
OracleRAS引入了一个基于策略的授权模型,可识别数据库中的应用级用户、权限和角色,然后控制对表示业务对象的静止和动态记录集的访问.
RAS可将应用最终用户的身份传递至数据库,以便在数据库内部实施访问控制策略.
每个应用最终用户由一个轻量级"应用用户"表示.
与普通数据库用户不同,该应用用户不能用自己的模式存储数据对象,也没有专用的数据库连接.
应用可以创建任意数量的应用用户会话并在它们之间切换,同时仅与数据库建立单一连接.
该应用用户会话允许数据库知晓应用所执行的操作是由哪个最终用户发起的,这样数据库便可实施相应的访问控制策略.
26与虚拟专用数据库特性一样,RealApplicationSecurity可对数据库表中的列和行实施细粒度的访问限制.
但是,RAS支持管理员用一种更通用的声明式语法指定这些限制.
首先,管理员为要保护的每个表创建一个或多个数据领域.
每个领域都使用与SQL查询中的WHERE子句相同的语法标识表中行的一个相应子集.
然后,为各领域添加一个访问控制列表(ACL),用于确定哪些用户或角色有权对该领域中的数据执行哪些操作.
此外,RAS还允许数据库实施每个应用独有的安全策略.
除了常见的SELECT、INSERT、UPDATE和DELETE之外,应用还可以定义自己的权限来表示与该应用相关的更复杂的操作.
管理员可以指定用户必须具备应用定义的特定权限才能访问某列.
此外,应用还可以在SQL语句中检查应用定义的某项权限,这样该语句将仅在授予了用户所需权限的情况下才会生效.
图3-2显示了一个EMPLOYEES表及其相关的数据安全策略.
该策略包含一个领域,其指定了DEPARTMENT_ID列中包含60或100的所有行.
与该领域相关联的ACL仅允许具有应用定义的Employee_Role或Manager_Role角色的用户从表中选择这些行.
SALARY列受到进一步的保护,用户必须具备VIEW_SENSITIVE_INFO权限(也是由应用定义的)才能访问该敏感列中的值.
ACL将该权限授予拥有Manager_Role角色的用户.
27图3-2:有数据安全策略的表OracleRAS支持将应用用户的会话传递给数据库,允许通过应用定义的用户角色和数据操作直接指定数据安全策略.
RAS安全模型允许对业务对象统一指定和实施访问控制策略,无论访问路径为何.
OracleRAS通过对应用数据和操作使用声明式访问控制策略,贴近数据实施了安全防护,为三层和双层应用提供了端到端的安全性.
28第四章审计数据库活动维护活动的审计跟踪是任何数据库纵深防御战略都不可或缺的一个要素.
即使正确配置了访问控制并采用了最小权限原则,仍然存在两个重要的风险.
第一个风险是需要重大权限履行工作职责的用户可能会滥用其权限.
第二个风险是访问控制或权限授予在无意中被配置得高于所需时,用户可能会获得意料之外的访问权限.
审计是检测这些突发事件的主要手段,为最终修复问题奠定基础.
有效的审计要求审计策略能够有选择地从大量事件中捕获重要细节,同时最大限度排除例行活动的干扰.
审计数据需要存储在安全的地方,这样才能确保事件记录的可靠性,特别是无法通过操纵审计数据来隐藏可疑的活动.
最后,还需要通过便捷的方式搜索所收集的审计数据,以查找特定信息或检测异常活动.
独立的Oracle用户组(IOUG)针对Oracle客户开展的调查显示,70%的企业正在对其数据库使用原生审计.
客户审计数据库是否符合SOX、HIPAA、PCIDSS、GLB、FISMA和其他国际标准.
审计提供关于人员、行为和时间的历史记录,让组织能够满足严格的控制和报告要求.
内部治理、本地安全策略和取证报告也带动了对审计的需求.
大多数企业希望能够追溯数据请求或更改、数据库更改、特定事件授权的命令发起方以及此类交互背后的业务理由.
合规性审计人员希望数据库管理员(DBA)及其上级(通常上至CFO和CSO)能够对数据和数据库本身的所有访问和更改作出解释.
29Oracle数据库提供了业界最全面的审计功能,可捕获事件的详细信息来生成报告和警报.
审计捕获的信息包括数据库名称、主机名称、客户端程序名称、事件时间、事件状态、事件操作、数据库用户、对象所有者以及SQL语句本身等.
可以将审计配置为记录成功和失败的事件.
Oracle数据库还支持更细粒度的审计功能,可在应用表中的特定列被引用时执行审计.
例如,可以对包含信贷限额的表应用这样一条细粒度的审计策略:仅当更新信贷限额列时执行审计.
OracleDatabase12c中的审计功能变动OracleDatabase12c对之前版本中丰富的数据库审计功能进行了完善,扩充了审计选项并且简化了管理.
OracleDatabase12c审计策略可配置为根据特定IP地址、程序、时间段或连接类型(如代理身份验证)进行审计.
此外,还可以轻松地将特定模式排除在审计之外.
这大大减少了生成的审计记录的数量,并确保在需要时能找到相关审计数据.
OracleDatabase12c审计功能利用策略和条件在Oracle数据库内部有选择地执行有效的审计.
此外,OracleDatabase12c还支持OracleDatabase11g审计语法.
这种"混合模式"支持采用之前审计语法的脚本和工具.
OracleDatabase12c统一审计为以下所有审计来源创建一个审计跟踪:来自统一审计策略的审计记录(包括SYS审计记录)以及来自DBMS_FGAPL/SQL程序包的细粒度审计记录统一审计策略本身的管理OracleDatabaseVaultOracleLabelSecurityOracleRecoveryManagerOracleDataPumpOracleSQL*LoaderDirectLoad30统一审计跟踪位于AUDSYS模式的只读表中,确保信息以统一格式显示在UNIFIED_AUDIT_TRAIL视图中.
当数据库不可写入时,审计记录会写入到$ORACLE_BASE/audit/$ORACLE_SID目录下的操作系统文件中,然后在数据库变为可写入时再将其加载回统一审计跟踪.
为了与传统DBA职能保持职责分离,OracleDatabase12c引入了两个新角色:AUDIT_ADMIN用于管理策略和审计跟踪,AUDIT_VIEWER用于查看审计数据.
由于不会将这些角色授予DBA角色,所以DBA无法更改审计集合.
只能使用数据库内置的审计数据管理程序包来管理审计数据,不能使用SQLUPDATE或DELETE命令直接更新或删除审计数据.
此外,OracleDatabase12c还提供了一个不能关闭的强制审计活动列表.
这些审计活动包括CREATE/ALTER/DROPAUDITPOLICYAUDIT/NOAUDIT针对DBMS_FGAPL/SQL和DBMS_AUDIT_MGMTPL/SQL程序包的EXECUTE针对AUDSYS审计跟踪表的ALTERTABLE(尽管不能更改此表)在数据库打开前使用的SYSuserorwiththeSYSDBA,SYSOPER,SYSASM,SYSBACKUP,SYSDG,和SYSKMadministrativeprivileges,的顶级权限语句审计特权用户的操作,直到系统中的审计配置可用为止针对OracleDatabaseVault的所有配置更改31OracleDatabase12c中预定义的审计策略OracleDatabase12附带了3个配置好的默认审计策略.
每个审计策略都配置为针对常用审计用例提供审计设置.
1.
安全配置(ORA_SECURECONFIG)统一审计策略提供了所有安全配置审计选项.
该策略默认处于启用状态.
SQL命令CREATEAUDITPOLICYORA_SECURECONFIG权限ALTERANYTABLE,CREATEANYTABLE,DROPANYTABLE,CREATEANYPROCEDURE,DROPANYPROCEDURE,ALTERANYPROCEDURE,GRANTANYPRIVILEGE,GRANTANYOBJECTPRIVILEGE,GRANTANYROLE,AUDITSYSTEM,CREATEEXTERNALJOB,CREATEANYJOB,CREATEANYLIBRARY,EXEMPTACCESSPOLICY,CREATEUSER,DROPUSER,ALTERDATABASE,ALTERSYSTEM,CREATEPUBLICSYNONYM,DROPPUBLICSYNONYM,CREATESQLTRANSLATIONPROFILE,CREATEANYSQLTRANSLATIONPROFILE,DROPANYSQLTRANSLATIONPROFILE,ALTERANYSQLTRANSLATIONPROFILE,CREATEANYSQLTRANSLATIONPROFILE,DROPANYSQLTRANSLATIONPROFILE,ALTERANYSQLTRANSLATIONPROFILE,TRANSLATEANYSQL,EXEMPTREDACTIONPOLICY,PURGEDBA_RECYCLEBIN,LOGMINING,ADMINISTERKEYMANAGEMENT操作ALTERUSER,CREATEROLE,ALTERROLE,DROPROLE,SETROLE,CREATEPROFILE,ALTERPROFILE,DROPPROFILE,CREATEDATABASELINK,ALTERDATABASELINK,DROPDATABASELINK,LOGON,LOGOFF,CREATEDIRECTORY,DROPDIRECTORY;322.
Oracle数据库参数变更(ORA_DATABASE_PARAMETER)审计常用的Oracle数据库参数设置.
该策略默认处于禁用状态.
SQL命令CREATEAUDITPOLICYORA_DATABASE_PARAMETER操作ACTIONSALTERDATABASE,ALTERSYSTEM,CREATESPFILE;3.
用户帐户和权限管理(ORA_ACCOUNT_MGMT)预定义的统一审计策略审计常用的用户帐户和角色设置.
该策略默认处于禁用状态.
SQL命令CREATEAUDITPOLICYORA_ACCOUNT_MGMT操作CREATEUSER,CREATEROLE,ALTERUSER,ALTERROLE,DROPUSER,DROPROLE,SETROLE,GRANT,REVOKE;自定义审计策略当默认策略未捕获所需审计数据时,或者只需审计更少的事件时,自定义策略可引用用户会话的任何上下文属性.
下面的清单显示了一个自定义策略的示例:CREATEAUDITPOLICYcustomer_audpolACTIONSINSERTONsales.
CUSTOMERS,UPDATEONsales.
CUSTOMERS,DELETEonsales.
CUSTOMERSWHEN'SYS_CONTEXT(''USERNEV'',''IP_ADDRESS'')=''192.
0.
2.
1'''EVALUATEPERSTATEMENT;AUDITPOLICYcustomer_audpol;33本例中的策略将监视来自IP地址为192.
0.
2.
1的客户端的任何INSERT、UPDATE和DELETE语句.
通过OracleAuditVaultandDatabaseFirewall进行监视虽然审计的生成很简单、自动化程度很高,但是制定全面的审计计划还需要考虑其他方面.
首先,大规模部署Oracle和非Oracle数据库会产生大量需要整合的审计数据.
其次,良好的实践证明应将审计数据传输至一个远程集中位置,以防止活动受审计的个人篡改数据.
最后,有必要采用一种高效的方式持续监视审计数据流,以找到存在安全隐患的具体事件并发现需要立即引起注意的问题.
OracleAuditVaultandDatabaseFirewall(AVDF)简化了在安全信息库中收集审计记录的过程,实现与所审计的数据库职责分离,并且生成关于审计事件数据的综合报告和警报.
AVDF不仅将从Oracle数据库收集审计数据,而且还从OracleMySQL、MicrosoftSQLServer、SAPSybase和IBMDB2forLUW中收集审计数据.
该产品旨在帮助企业整理数百个数据库实例中的信息,并且通过单一平台实现统一策略管理和事件传播.
AVDF主要包含以下四个要素:AuditVault(AV)Server—审计记录的中央信息库(毫无悬念,它们保存在Oracle数据库中!
).
它包括压缩、分区、加密和特权用户控制等Oracle技术.
AVServer主要执行以下四项任务:整合来自防火墙、Oracle和非Oracle数据库、操作系统、目录和其他自定义来源的审计数据和事件日志.
还可以将AuditVault配置为在传输过程中对数据进行加密.
管理审计策略34提醒和管理不符合策略的事务报告和分发即席或计划报告AuditVaultAgent—基于主机的低影响程序,用于管理所在系统的数据收集并与AV服务器通信.
审计跟踪—审计数据的来源.
有五种审计跟踪:数据库审计跟踪,包括Oracle、MicrosoftSQLServer、SAPSybase、IBMDB2forLUW和MySQL.
它们可以是审计表、审计文件或重做记录.
操作系统审计跟踪(Linux、Windows、Solaris)目录服务,如MicrosoftActiveDirectory文件系统,如OracleACFS数据库表或XML文件中的自定义审计数据OracleDatabaseFirewall—AVDF的网络组件.
OracleDatabaseFirewall监视网络上的SQL事务,并且可在SQL语句访问数据库服务器之前判定是应该许可、修改、阻止还是替换该SQL语句.
下一章将介绍OracleDatabaseFirewall是如何运作的.
目前我们只需要知道它向AuditVault提供关于其活动的审计数据即可.
图4-1显示了异构网络环境中部署的OracleAuditVaultandDatabaseFirewall和许多审计数据来源.
35图4-1:OracleAuditVaultandDatabaseFirewall架构报告和警报AuditVaultServer具备全面的报告功能,可提供一系列标准的安全报告、即席报告和取证报告.
此外,还有一些现成的不符合策略的审计评估报告,旨在帮助满足PCI-DSS、GLBA、HIPAA、SOX和DPA等标准的要求.
像图4-2中这样的报告可用于监视大量活动,包括数据库服务器上的特权用户活动、对数据库结构的更改以及网络上关于入站SQL语句的数据.
报告可以整合来自数据库、操作系统和目录的审计信息,让您全面了解企业的所有活动.
36图4-2:整合网络、数据库审计和操作系统事件日志审计人员可以通过控制台Web界面或者通过PDF或XLS文件交互式地访问报告,并且可自动将其分发给不同的组织团队.
系统会通过相应的规则自动高亮显示特定的行,这样您就可以快速发现可疑或未经授权的活动.
可以使用OracleBIPublisher创建新的或自定义的PDF和XLS报告模板来满足特定的安全需求.
报告基于的是一个高度优化的Oracle11gR2数据库,后者也可以通过配置允许外部报告工具访问审计数据.
也就是说,现有的管理信息(MI)工具甚至Excel电子表格均可访问重要的安全信息,但是为了确保审计记录的完整性,严格禁止更改或删除数据.
而且,AuditVault信息库模式经过归档,支持与第三方报告解决方案集成.
警报或事件管理让您可以创建复杂的警报定义,以便在审计人员控制台仪表盘上发出警报,并将通知发送给多个用户进行查证.
定义警报时可以使用SQL比较运算符(=、'CALLCENTER',object_name=>'CUSTOMERS',policy_name=>'RedactCustomerPII',expression=>'SYS_CONTEXT(''USERENV'',''CLIENT_IDENTIFIER'')!
=''SUPERVISOR04''ORSYS_CONTEXT(''USERENV'',''CLIENT_IDENTIFIER'')ISNULL',column_name=>'SSN',function_type=>DBMS_REDACT.
PARTIAL,function_parameters=>'VVVFVVFVVVV,VVV-VV-VVVV,X,1,5');数据编辑易于部署的另一个原因在于其对应用和数据库的透明性.
就应用透明性而言,数据编辑支持应用以及各种数据库对象(包括表、视图和物化视图)常用的列数据类型.
编辑后的值将保留原始数据的关键特征,如数据类型和可选的格式化字符.
就数据库透明性而言,数据编辑不会对管理任务产生影响,例如,使用OracleDataPump移动数据或者使用OracleRecoveryManager备份和恢复数据.
它不会影响数据库集群配置,如OracleRealApplicationClusters、OracleActiveDataGuard和OracleGoldenGate.
54第七章验证配置合规性如今的数据库需要大量配置设置,其复杂程度早已今非昔比.
攻击者通过配置中的漏洞获取对数据库的未授权访问.
例如,数据库中众所周知的用户名和密码组合就是一个常见的目标.
因此,需要扫描数据库来确保其经过安全配置,并且及时修复所发生的问题.
通过标记配置错误和提供有益于总体安全架构的控制建议,配置扫描可增强组织的整体安全性.
安全配置扫描已成为许多法规的重要组成部分,如支付卡行业数据安全标准(PCI-DSS)、Sarbanes-Oxley以及众多侵犯通知法规.
互联网安全中心(CIS)和美国国防部等众多机构也推荐了配置最佳实践.
随着新法规的发布和现有法规的不断发展,合规性的复杂程度不可小觑.
因此,部署一个能适应新法规的解决方案也就成为了企业的当务之急.
通过OracleEnterpriseManager执行安全配置扫描OracleDatabaseLifecycleManagementPack提供了众多现成的基本配置报告和一个全面的合规性框架.
例如,帐户状态报告将显示所有数据库帐户及其状态.
另外还有一个报告可通过匹配各种Oracle产品自带默认帐户的已知密码,显示使用默认密码的数据库帐户.
其他报告还包括有关初始化参数、操作系统目录权限、用户帐户资料和敏感对象报告的信息.
如图7-1所示,可以通过Security菜单的Reports项访问这些现成的报告.
55图7-1:OracleEnterpriseManager安全配置报告通过OracleEnterpriseManager执行资产发现和分组OracleDatabaseLifecycleManagementPack消除了手动跟踪IT资产(包括数据库)的必要.
它提供非侵入性网络扫描功能来发现服务器.
发现服务器之后,可轻松将其升级为托管状态,从而自动发现所有数据库和其他应用.
这种自动发现功能可以更加轻松地确保所有服务器和软件均处于托管状态,并且可为IT整合和优化计划提供支持.
由于管理员所负责的系统和服务数量不断增长,OracleEnterpriseManager提供了一个仅显示需要监视的目标的视图.
该视图被称为一个组.
组是一组用户定义的在逻辑上共同管理的目标.
您可以通过OracleEnterpriseManager中的组来共同监视和管理不同目标,轻松对这些目标执行管理操作,并且将这些分散的目标作为一个逻辑实体加以整合和监视.
例如,您可以定义一个TEST组,其中包含测试环境中的所有主机和数据库目标.
在测试组的主页中,您可以轻松查看该组中所有目标的总体状态和可用性,无需检查每个成员的状态.
即便组成员发生更改,提交给该组的所有作业也会自动与组成员保持同步.
56在某个组的主页中,无论该组基于一组同构目标还是一组异构目标(如某企业的应用),管理员均可完成以下任务轻松确定组中所有成员以及待处理警报的总体安全配置合规性下钻并分析特定目标的详细信息通过汇总警报,快速下钻至警报详细信息,轻松确定组成员的状态OracleEnterpriseManager配置扫描OracleDatabaseLifecycleManagementPack提供了一个强大的合规性扫描解决方案,包括合规性框架、合规性标准和合规性标准规则,如下表所示.
合规性框架合规性框架是行业规定的针对底层IT基础架构、应用和流程的最佳实践准则.
合规性框架通过分层结构来直接表示这些行业框架.
合规性框架可用于表示PCI等框架.
合规性标准合规性标准是指针对特定目标类型的检查或规则的集合.
合规性标准规则合规性标准规则是用于确定特定配置参数或状态的测试.
Oracle支持以下规则类型.
信息库规则评估针对目标定期收集的指标.
实时监视规则监视对文件、流程等要素的更改.
57Oracle提供的配置合规性标准合规性标准作为度量目标的基准.
这些标准相当于最佳实践,支持安全管理员在不同企业系统和配置中保持一致性.
此外,趋势分析特性还可以对合规性评分进行持续的细粒度跟踪.
在上图所示的Oracle数据库基本安全配置检查中,可以看到系统执行了大量现成的检查.
所执行的检查包括分析目录和文件权限、Oracle参数设置、数据库密码配置文件设置、Oracle可执行文件所有权以及网络配置设置.
OracleEnterpriseManager附带了40多个现成的合规性标准,包括:Oracle集群数据库基本安全配置Oracle集群数据库实例基本安全配置Oracle监听程序基本安全配置Exadata计算节点配置监视安全Linux程序包配置监视58管理框架、合规性标准和规则OracleEnterpriseManager提供了一个可扩展的框架,可用于创建新的架构、标准和规则.
这种可扩展性让组织能够适应不断变化的合规性要求,并且创建自定义配置扫描来测试系统是否遵循内部最佳实践.
可通过OracleEnterpriseManager创建合规性标准规则,如下图所示.
还可以采用XML格式导入或导出规则.
事件严重性对于安全配置扫描至关重要.
OracleEnterpriseManager中的事件可分为下列严重性级别:致命监视目标已停止运转.
严重需要在某方面立即采取行动.
该方面不再起作用或意味着要出问题.
警告某方面需格外注意,不过该方面仍还起作用.
建议尽管某方面无需立即注意,但就该方面目前的状况来说建议多加留神.
此严重性级别主要用于合规性标准.
提示某方面发生了些小情况.
59通过OracleEnterpriseManager进行实时监视OracleDatabaseLifecycleManagementPack可实时监视针对文件、数据库对象或Windows注册表键的任何操作.
它还可以监视进程的启动和停止以及用户登录、注销和切换用户活动.
实时监视意味着可以捕获操作发生的准确时间以及执行操作的用户的名称.
实时监视的结果可与BMCRemedy等变更管理系统相协调.
这种协调可自动确定某个操作是否应发生(是否经过授权).
如果没有变更管理服务器,那么可以通过管理控制台手动进行此审计状态批注.
实时监视通过将环境当前状态与客户的变更管理流程同步,帮助识别违反策略的操作.
这些操作会给环境带来高风险或使合规性控制无法通过审计.
实时监视的核心是Facet概念.
从本质上说,Facet包括配置文件、日志文件、进程和敏感数据库表等项目.
一个特定目标可以有多个与之关联的Facet.
可以根据Facet为核心Linux程序包、Exadata计算节点和用户访问Linux程序包创建多个实时监视标准.
OracleEnterpriseManager提供了数百个预先定义的Facet.
与框架和标准一样,可以定义和自定义Facet.
60目标类型Facet描述日志文件监视普通用户(非系统用户)对日志文件的修改.
二进制/库文件监视二进制文件是否被篡改过或者二进制打补丁的时间.
除了列出各个二进制文件外,它还列出整个目录,但不包括频繁更改的文件.
配置文件捕获对任何配置文件的更改.
安全密钥文件监视存储证书、密钥等内容的文件.
安全配置文件监视用于配置目标类型中的安全机制的文件,例如加密配置等.
实用程序进程监视通常在维护期间运行但不会在生产环境中运行的进程.
注册表键监视影响目标配置的MicrosoftWindows注册表键.
配置表监视任何存储配置数据的数据库表.
每个Facet都通过一个实体类型来定义Facet描述的实体种类.
例如,在操作系统级监视中,实体类型包括操作系统文件、操作系统进程、操作系统用户、Windows注册表和一些ActiveDirectory.
在数据库监视中,实体类型包括表、视图、索引和过程等.
可以通过FacetLibrary界面创建Facet.
定义实时监视规则时,您首先需要确定主机上监视的实体类型.
下表列出了OracleEnterpriseManagerCloudControl12c中可通过实时监视规则进行监视的实体类型:操作系统文件操作系统进程操作系统用户Oracle数据库用户Oracle数据库表Oracle数据库视图Oracle数据库过程Oracle数据库配置文件Oracle数据库链接Oracle数据库函数Oracle数据库程序包Oracle数据库序列Oracle数据库触发器Oracle数据库表空间Oracle数据库物化视图Oracle数据库集群61使用OracleEnterpriseManager的通知功能通知是OracleEnterpriseManager管理框架不可分割的一部分.
通知可在特定突发事件、常规事件或问题发生时执行操作系统命令(包括脚本)和PL/SQL过程等操作.
此功能可帮助您实现IT实践自动化.
例如,当发生数据库运行状态更改(正常/故障)等事件时,通知系统可以使用一个操作系统脚本自动打开内部故障单,以确保相应的IT人员可及时响应.
通过使用简单网络管理协议(SNMP)陷阱,针对OracleEnterpriseManager中发布的事件(例如特定量度超过阈值),OracleEnterpriseManager通知系统还可以让您将陷阱发送给支持SNMP的第三方应用(例如HPOpenView和BMCRemedy).
通过OracleEnterpriseManager管理补丁OracleDatabaseLifecycleManagementPack支持整个补丁管理生命周期,包括补丁建议、部署前分析、部署和报告.
它与MyOracleSupport相集成,提供可用补丁和推荐补丁的同步视图.
然后,可在部署前对这些补丁进行冲突分析.
接下来,用户可以在一个停机时间窗口内对多个数据库应用多个补丁.
补丁部署过程由于采用了高级技术(如RAC滚动打补丁和异地打补丁)而最大限度简化了操作和缩短了停机时间.
变更活动计划程序(CAP)让您可以计划、管理和监视涉及相关性、所有者协调以及多个进程的复杂操作.
这些操作包括每个季度定期部署安全补丁、根据业务需要搭建新服务器、迁移或整合数据库中心以及在整个环境中推广合规性标准.
CAP支持管理员完成以下任务计划更改活动,包括设置开始和结束日期以及创建、分配和跟踪任务状态.
62使用自动化任务分配和完成支持来管理大量任务和目标.
使用仪表盘监视计划潜在的延迟并快速评估总体计划状态.
让任务所有者使用自己仪表盘上基于优先级或计划的视图管理自己的任务.
OracleEnterpriseManager中的配置合规性虽然强大的SYSMAN帐户可用于遍历合规性框架,但Oracle可以通过细粒度权限来控制谁能查看结果和执行特定操作,因此支持职责分离.
下列权限和角色可用于管理对配置标准的访问:权限描述CREATE_COMPLIANCE_ENTITY创建合规性标准、规则和实时监视FacetFULL_ANY_COMPLIANCE_ENTITY管理合规性标准和合规性标准规则VIEW_ANY_COMPLIANCE_FWK查看合规性框架定义和结果MANAGE_TARGET_COMPLIANCE将合规性标准与目标相关联VIEW查看单一目标角色描述EM_COMPLIANCE_DESIGNER创建、修改和删除合规性标准、合规性标准规则及实时监视Facet.
EM_COMPLIANCE_OFFICER查看合规性框架定义和结果.
63更多信息安全信息门户Oracle数据库安全Oracle技术网上的数据库安全主题Oracle产品文档Oracle数据库文档Oracle数据库安全指南OracleAuditVaultandDatabaseFirewallOracleAdvancedSecurityOracleDatabaseVaultOracleLabelSecurityOracleDataMasking