Education对于大量购买其书籍用作赠品或促销礼品或用于企业培训的客户给予特别折扣。
如需联系销售代表，请访问上的ContactUs（联系我们）页面。
保护OracleDatabase12c：技术入门 版权所有©2014，McGraw-HillEducation（出版商）。
保留所有权利。
在美国印刷。
除1976年美国版权法许可外，未经出版商事先书面许可，不得以任何形式或任何方式复制或分发本出版物，或者将其存储在数据库或检索系统中，但程序清单例外。
虽然程序清单可以在计算机系统中输入、存储和执行，但不得用于复制出版。
Oracle是OracleCorporation和/或其关联公司的注册商标。
所有其他商标是其各自所有者的商标，McGraw-HillEducation并不对所提及的包含这些标志的产品声明所有权。
本文档中转载的受版权保护的Oracle软件程序的屏幕截图均经过OracleCorporation和/或其关联公司的许可。
ISBN978-0-07-182617-4MHID0-07-182617-
3 策划编辑PaulCarlstroem 编辑部主任PattyMon 组稿协调员AmandaRussell 编审MargaretBerson 校对PaulTyler 发行主管JeanBodeaux 美术总监，封面JeffWeeks 出版商所获信息均来自可靠来源。
然而，由于我们的消息来源、出版商或其他环节可能存在人为或机械错误，因此出版商不对本文档中任何信息的准确性、妥善性或完整性作任何保证，并且不对任何错误或遗漏以及使用此信息带来的任何结果负责。
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是一家行业联盟和标准组织，致力于通过批量生产的标准化安全硬件来增强系统安全性。
序言 20世纪90年代初，接入互联网的数据库寥寥无几，当时的互联网肯定无法与现在同日而语。
当时，我们安全技术的用户主要是关注数据分类和多级安全性的政府和国防机构。
合规性法规更是少之又少。
当时还没有支付卡行业数据安全标准(PCI-DSS)，HIPAA也仅仅是初具雏形。
如果DBA希望窃取大量信息（当时，数百MB就是非常“大”的量了），他们需要携带一个有几块建筑用砖那么大、那么重的磁盘驱动器。
除了Oracle的多级安全解决方案外，我们客户群中采用比较广泛的数据库安全特性包括自主访问控制和数据库角色。
当时甚至不需要考虑内部人员、有组织犯罪、黑客和SQL注入带来的数据威胁。
主要的安全需求就是使用权限、角色和视图实施“按需知晓”原则。
我1993年加入Oracle时，所有数据库的用户群必然是有限的—当时还是采用客户端-服务器计算模式的时代，与运行数据库的机器相比，数据库显然比较小；有权访问数据库的用户数量也非常少。
大多数用户基本上都不需要考虑数据库安全性。
在一些应用中，SQL注入被认为是可以接受的。
事实上，我还记得在OracleForms中通过SQL注入修改查询是多么简单。
当然，由于大多数应用采用的都是客户端-服务器模式，因此这并不是什么大问题，因为应用用户需要使用自己的个人凭证来连接数据库，而不是当今应用所采用的单一大应用用户模型(OneBig-ApplicationUserModel)。
如今的世界已经大为不同。
DBA可以在外形尺寸和重量比手机还小的设备上轻松处理TB级的信息。
据统计，特权帐户和SQL注入是访问敏感信息的首选方式。
隐私与合规性要求几乎已渗透至全球的各行各业。
客户必须定期通过各项法规的审查，包括Sarbanes-Oxley法案、欧盟数据保护指令、中国的个人信息保护指南以及日本的APPI。
如今，三层软件架构已成为行业标准，能够访问一些级别应用数据的用户群非常巨大，通常至少数以千计。
如果您不想因用户个人信息被盗而上新闻头条，那么保护您的数据和基础设施已成为一项首要需求。
安全性与高可用性和可扩展性同等重要。
设计新应用时，从一开始就必须考虑安全性，而且要贯穿生命周期开发过程的每个阶段。
鉴于此，《保护OracleDatabase12c：技术入门》一书应运而生。
本书的三位作者在数据安全领域拥有数十年的工作经验，更重要的是，他们在Oracle数据库安全领域也拥有数十年的工作经验。
iv 本书由浅入深，首先介绍如何控制授权用户的访问。
这包括通过实施“最低权限”来防止受信任的DBA或其他未经授权的人员实际或者象征性地带走TB级的敏感信息。
数据库中的每个用户以及每种应用模式都应该具有完成工作所需的一组最小的授权和权限—我们将看到如何实现这一目标并了解其如此重要的原因。
全面介绍访问控制之后，本书将探讨发生失窃时如何保护数据；即使所有访问控制均被破坏的情况下如何保护数据。
本书将介绍数据加密的概念，并讨论如何在多个层面上实现数据加密。
接下来，本书将探讨一些更高级的访问控制方法，例如列级和行级访问控制。
这将不再局限于简单的表和系统权限。
随后，本书将介绍一个相关的安全特性：审计。
我们将探索数据库的审计功能以及如何主动使用这些功能，而不是将其用作事后诊断工具。
接下来，本书将讨论SQL注入。
SQL注入可能是最普遍的数据库攻击方式。
SQL注入利用已开发的应用代码中的漏洞，与数据库无关。
由于应用代码比数据库代码要多得多，而且大多数应用代码在编写过程中都没有考虑SQL注入的问题，因而许多应用易受攻击。
在互联网上搜索“SQL注入”将返回数百万条新闻，其中许多新闻的内容都是某公司最近遭受攻击，导致敏感客户数据泄漏。
本书将探讨数据库和安全专业人员如何在应用与数据库之间添加一个防护层，进而削弱外部人员成功发起SQL注入攻击的可能性。
最后，本书将介绍如何实现合规性。
1993年，一家公司运行10个甚至100个Oracle数据库就算“很多”了。
20年后，运行成千甚至上万个Oracle数据库的公司早已司空见惯。
企业必须确保所有这些数据库都安装了最新补丁并且完成了安全配置。
验证检查是一项繁琐甚至难以完成的工作，但如果采用适当的方法和工具则另当别论。
本节将介绍这方面的信息。
您将了解如何验证和确认系统配置的合规性，以确保数据库环境是采用安全的、经过验证的方式搭建的。
如果您对安全性—具体来说，为Oracle数据库提供安全防护—感兴趣的话，本书将非常适合您。
尽管本书使用OracleDatabase12c作为书名的一部分，但其中大多数内容适用于OracleDatabase9i及更高版本。
ThomasKyte/ v 致谢 作者诚挚感谢以下人员在本手稿的编制和审查过程中提供的宝贵帮助：TroyKitch、MelodyLiu、VikramPesati和JamesSpooner。
vi 引言 为重要信息提供安全防护很不幸成为全球任何组织都需要面对的一个问题。
我们不断在新闻中看到黑客通过攻击获取了某公司的敏感数据并给该公司造成了重大法律、经济和声誉损失。
即便绝大多数敏感数据都存储在关系数据库中，大多数组织的信息安全措施也很少侧重于这些数据库的安全性。
尽管许多技术和产品可以通过各种方式提高数据库的安全性，但我们需要的是采用简要而全面的方式概述所面临的主要威胁以及解决这些问题的相应技术。
攻击者可能会利用一切可利用的弱点，包括数据库未正确配置安全控制、操作系统未安装补丁以及用户帐户被盗用。
此外，还有一些更间接的方法，例如SQL注入或在网络上拦截数据。
真正安全的数据库系统防护需要考虑攻击者可能利用的一切漏洞。
本书中的每一章将介绍一类威胁，不过这些威胁都是息息相关的。
没有一种解决方案可以防范所有攻击方式，各种安全机制是相辅相成的。
纵深防御是有效应对已知和未知威胁的唯一途径。
我们首先介绍数据库中可用的安全特性。
•第一章：控制数据访问和限制特权用户介绍验证用户身份以及控制其可访问 的数据的基本概念。
本章涵盖如何确定每个用户所需访问权限以及如何限制高权限用户的最佳实践。
•第二章：防止直接访问数据阐述如何通过加密来防止试图绕过上一章中介绍的访问控制机制直接访问数据的攻击。
•第三章：高级访问控制阐述如何通过更高级的访问控制机制实现更精准的控制。
这些机制包括虚拟专用数据库、OracleLabelSecurity和RealApplicationSecurity。
•第四章：审计数据库活动阐述如何维持有效的审计跟踪，这是一项重要的纵深防御技术，可检测特权用户的权限滥用以及前述章节中实施的安全策略的意外违规情况。
随后，我们还将探讨如何引入外部组件来提高数据库及其存储的数据的安全性。
•第五章：控制SQL输入阐述如何使用专业的数据库防火墙监视访问数据库的SQL语句。
这有助于防范Web用户对数据库发起的SQL注入攻击。
vii •第六章：屏蔽敏感数据阐述如何采用数据屏蔽技术从用于测试或开发的数据中删除敏感信息。
本章还探讨如何采用数据编辑功能动态屏蔽针对生产数据库的查询结果。
•第七章：验证配置合规性阐述根据行业认可的标准评估数据库配置的必要性，以及如何通过相应的评估工具来确保持续合规性。
在本书中，我们将重点介绍OracleDatabase12c的新特性。
不过本书中介绍 的大多数解决方案也适用于更早版本的OracleDatabase。
viii 第一章 控制数据访问和限制特权用户 数据库系统安全防护领域最重要的任务就是确定用户对数据的访问权限。
本章介绍用户帐户管理以及如何确定每个用户的访问权限。
随后，本章将探讨用户的特权访问类型以及可通过哪些工具删除用户不需要的访问权限。
用户管理 针对数据库的所有访问都是由用户发起的，无论是管理用户、应用帐户还是普通用户。
由于用户可以直接连接到数据库，因此有必要对他们进行适当的身份验证，确保他们拥有适当的角色，并确保其帐户不会轻易受到攻击。
此外，还需要确保对其可使用的资源加以限制，否则将对数据库的其余部分造成间接影响。
CREATEUSER语句用于创建数据库用户及其相关模式。
在下面的例子中，通过密码来识别用户，该帐户将遵循_profile中的策略。
CREATEUSERjsmithIDENTIFIEDBYNoOne!
Knows_profileDEFAULTTABLESPACEdata_tsTEMPORARYTABLESPACEtemp_ts; 配置文件指定了一系列资源限制和密码参数，用于限制过度使用系统资源并对密码加以限制。
可通过密码相关参数进行密码管理，包括帐户锁定、密码老化、密码历史和密码复杂性验证。
密码验证功能或许是确保用户选择复杂密码的最重要的控制措施，旨在防止入侵者破解用户密码。
FAILED_LOGIN_ATTEMPTS参数可设定在登录失败达指定次数后锁定帐户，从而防范攻击者对密码进行暴力破解。
1 CREATE_profileLIMIT FAILED_LOGIN_ATTEMPTS6 --attemptsallowedbeforelocking PASSWORD_LIFE_TIME180 --maxlife-timeforthepassword PASSWORD_VERIFY_FUNCTIONora12c_verify_function;--Password complexity check DBA_USERS和DBA_PROFILES字典视图分别用于描述用户和配置文件。
用户创建权限只能分配给DBA或安全管理员。
应为每个用户分配一个表空间；否则，他们创建的任何对象都将进入SYSTEM表空间，从而导致数据字典对象与用户对象相冲突。
OracleMultitenant数据库用户 OracleDatabase12c的OracleMultitenant选件包括通用用户和本地用户。
通用用户是在容器数据库中创建的，在该容器数据库的所有可插拔数据库中均采用相同的用户名和密码。
通用用户除了具有容器层面授予的权限，还可以具有每个可插拔数据库中授予的其他权限。
每个可插拔数据库中的权限可能不尽相同，不过不需要在每个可插拔数据库中创建通用用户。
如需为容器数据库和所有可插拔数据库创建通用用户，请以SYSTEM身份登录容器数据库并使用CONTAINER=ALL参数创建用户。
请注意，所有通用用户都使用C##作为其名称的前缀。
SQLPLUS>CONNECTSYSTEM@rootEnterpassword:**********Connected.SQLPLUS>CREATEUSERC##DB_ADMINIDENTIFIEDBYIronMan4CONTAINER=ALL; 另一方面，本地用户是在可插拔数据库中创建的，不具备访问容器的权限。
这将帮助管理员更好地管理可插拔数据库，但是不能用于管理整个系统。
如需
2 创建本地用户，请使用SYSTEM身份连接至可插拔数据库，像往常一样授予必要的角色和权限，然后指定CONTAINER=CURRENT而不是CONTAINER=ALL。
SQLPLUS>CONNECTSYSTEM@pdb1Enterpassword:*********Connected.SQLPLUS>CREATEUSERpdb1_adminIDENTIFIEDBYSpiderMan3CONTAINER=CURRENT; 存储密码 用户连接数据库时需要提供密码，但应用、中间层系统和批处理作业不支持手动输入密码。
过去，提供密码的一种常用方法是在代码或脚本中嵌入用户名和密码。
这不仅会导致攻击面扩大，而且相关人员还需要确保其脚本未向其他人公开。
此外，如果密码经过修改，则脚本也需要进行相应的修改。
现在，您可以使用客户端Oracle钱夹存储密码凭证。
这样，密码就不会再出现在命令行历史记录中，密码管理策略也更容易实施，用户名或密码发生更改时也无需修改应用代码，最终有助于降低风险。
要使用Oracle钱夹配置密码存储，请设置.ora文件中的WALLET_LOCATION参数。
之后，应用在连接数据库时便无需提供登录凭证，如下所示： CONNECT/@hr_ 身份验证方式 用户需要先经过身份验证，然后才能连接数据库。
Oracle支持各种不同的身份验证方式，包括将密码存储在本地的数据库或目录中。
还可以由操作系统验证用户身份，这需要在创建用户时使用IDENTIFIEDEXTERNALLY子句，也可以由Kerberos、SSL/TLS和RADIUS等第三方服务来完成身份验证。
密码仅用于在用
3 户连接至数据库时的单向身份验证，而Kerberos和PKI支持双向身份验证，可确保用户连接至正确的数据库。
基于SSL/TLS进行通信的Oracle客户端和服务器必须拥有一个包含X.509证书、私钥和受信任证书列表的钱夹。
要完成此配置，管理员需要使用OracleWalletManager创建用于存储PKI凭证的钱夹，并使用OracleNetManager配置SSL身份验证所使用的.ora和listener.ora。
以下示例显示如何使用PKI证书创建用户： SQL>CREATEUSERjsmithIDENTIFIEDEXTERNALLYAS=jsmith,OU=HR,O=oracle,c=US'; 用户可以在支持Kerberos的环境中使用该服务验证数据库身份。
要配置此功能，请使用OracleNetManager在Oracle数据库服务器和客户端的.ora文件中设置必要的参数。
以下示例显示如何创建一个与Kerberos用户对应的、采用外部身份验证的用户： SQL>CREATEUSERjsmithIDENTIFIEDEXTERNALLYAS'jsmith@'; 现在，您无需提供用户名或密码便可连接至Oracle数据库服务器，如下所示： $sqlplus/@hr_; 集中用户管理 在一个企业中，如果有大量用户需要访问大量数据库，那么管理每个数据库中每个用户的唯一帐户就变得非常困难。
OracleEnterpriseUserSecurity(EUS)可在OracleDirectory中集中管理多个数据库的用户和角色，并且OracleDirectory将与MicrosoftActiveDirectory等目录相集成。
此类用户被称作企业用户，为他们分配的企业角色将确定对多个数据库的访问权限。
企业角色包括一个或多个全局角色，每个全局角色授予对特定数据库的访问权限。
4 EUS可通过OracleDirectory借助密码、Kerberos或SSL对用户和管理员进行身份验证。
连接时，数据库会从该目录中获取用户身份验证、授权（角色）信息和模式映射。
企业用户可以有自己的模式，也可以与所访问的数据库共享全局模式。
以下示例展示了一个采用独占模式的企业用户jsmith。
CREATEUSERjsmithIDENTIFIEDGLOBALLYAS'CN=jsmith,OU=HR,O=oracle,C=US'; 具备管理权限的用户 某些用户可以使用特殊的管理权限（如SYSDBA和SYSOPER）连接数据库，这样便可在不打开数据库的情况下执行维护操作。
这些用户可以使用基于网络的身份验证服务（如OracleDirectory）执行身份验证，也可以根据连接用户是否属于特定操作系统用户组来执行身份验证。
如果用户以管理权限连接时必须用密码来进行身份验证，那么该密码必须存储在数据库外部的密码文件中，该文件可通过orapwd命令进行管理。
该密码文件不支持用户管理功能，例如在多次登录失败后锁定帐户。
不过，当数据库运行时，每次登录失败都会产生延迟，从而在一定程度上限制密码破解。
代理身份验证和授权 有时，管理员需要连接应用模式来执行维护。
多个管理员共享应用模式密码将无法确保责任界定。
而代理身份验证可以让管理员先使用自己的凭证进行身份验证，然后再通过代理连接至应用模式。
在这种情况下，审计记录将显示执行维护活动的实际用户。
OracleCallInterface(OCI)、JDBC和SQL*PLUS命令行均支持这种代理身份验证。
以下示例允许app_dba用户连接至数据库后使用hrapp身份执行操作。
ALTERUSERhrappGRANTCONNECTTHROUGHapp_dba;
5 现在，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字典表显示所授予的对象权限。
其中包括对象的详细信息，包括模式所有者以及所授予的权限。
该表可用于报告权限和管理权限级别。
6 SQL>SELECTGRANTEE,OWNER,TABLE_NAME,PRIVILEGE FROMDBA_TAB_PRIVS WHEREGRANTEE='JSMITH'; GRANTEE OWNERTABLE_NAME PRIVILEGE ------------------------------------ JSMITH HR DEPARTMENTSSELECT JSMITH HR ADVENTURES SELECT JSMITH HR ADVENTURES INSERT JSMITH HR ADVENTURES DELETE JSMITH HR ADVENTURES UPDATE JSMITH HR ADD_DEPARTMENTEXECUTE 当不再需要某个对象上的权限时，应予以撤销。
SQL>REVOKEDELETEONhr.adventuresFROMjsmith; 系统权限和角色 对象权限可以非常精细地控制用户可以访问的数据，不过管理员有时可能需要访问多个对象。
系统权限允许访问特定类型的所有对象；例如，SELECTANYTABLE允许用户对任何模式中的任何表执行SLECT操作，EXECUTEANYPROCEDURE允许执行任何PL/SQL过程或函数。
其他系统权限适用于不涉及特定对象的操作，如创建对象、用户和角色；更改会话和系统参数；以及导出和导入数据库。
可以看出，这些权限令管理员执行的操作可以影响多个模式和对象。
另外一个方便的权限管理特性可将多个对象权限和系统权限归到一个角色中。
当需要为多个用户授予一组相同的权限时，角色将派上用场。
角色比单独的权限更易于管理，并且可与应用或工作职能相匹配。
可以将一些角色授予其他角色，这样便可通过一些小权限角色建立DBA这样的大权限角色。
与对象权限的GRANT选项类似，系统权限或角色也支持ADMINOPTION，该选项允许接收者将该角色或权限授予其他人。
7 下表中的字典表显示授予每个用户或角色的角色和权限。
例如，从这些表中可以看出，DBA是一个非常强大的角色，具备200多项系统权限，包括CREATE和ALTERSESSION；CREATE和ALTERANYTABLE；SELECT、INSERT、UPDATE和DELETEANYTABLE；EXPORT和IMPORTFULLDATABASE；DROP和CREATETABLESPACE；EXECUTEANYPROCEDURE以及十几个角色。
字典表DBA_TAB_PRIVSDBA_SYS_PRIVSDBA_ROLE_PRIVSDBA_ROLES 内容授予角色或用户的对象权限授予角色或用户的系统权限授予用户或其他角色的角色所有定义的角色 最小权限和职责分离 最小权限原则是指应为该系统的每个用户仅授予完成其预定任务或职能所需的最小一组权限。
授予用户或角色权限时，最好授予所需的特定对象权限，而不是授予允许访问数据库中所有对象的广泛系统权限。
同样，创建角色时应仅包含完成特定职能所需的少量权限，而不是创建像内置的DBA角色这样非常强大的角色。
授予用户一些小权限角色可确保用户与所需完成的任务相匹配，而不必授予过多不需要的权限。
职责分离的理念与最小权限原则密切相关。
具体来说，应让多个用户承担不同权限，而不是创建一个超级用户。
采用这种方式划分管理权限可加强责任界定，而且还可避免受信任的管理员滥用权限。
为了支持最小权限和职责分离原则，Oracle数据库很早就引入了SYSOPER管理权限，允许管理员执行启动和停止数据库等特定任务，而无需授予其SYSDBA的完全权限。
OracleDatabase12c新增的管理权限包括SYSBACKUP、SYSDG和SYSKM，分别用于支持数据库备份、DataGuard管理和密钥管理。
有了这些针对性的权限，管理员无需全能的SYSDBA权限也可执行管理数据库所需的一切常规操作。
8 控制特权用户 系统权限和强大的角色可对数据库进行高度控制，包括查看所有数据和更改数据。
一些管理用户需要使用这些强大的权限来执行维护、调优和备份，不过他们并不需要访问全部数据。
即使有管理权限的用户是可以信赖的，但也有必要限制这些特权帐户对公司数据资产和个人信息的访问，以防止内部用户或攻击者的非授权使用。
OracleDatabaseVault在数据库中提供了一些操作控制，包括通过领域来限制对表和视图等特定对象的访问。
创建DatabaseVault领域之后，向其中添加一些对象，并且可以将数据库用户指定为领域参与者。
这样只赋予领域参与者访问权限，其他用户被排除在外，即使他们拥有SELECTANYTABLE这样强大的系统权限也不能访问该领域中的对象。
下图显示了如何通过两个领域来保护包含人力资源(HR)和财务(FIN)数据的数据库模式。
领域一经启用，就会阻止特权管理用户或其他应用所有者使用其高级权限访问数据。
特权应用所有者HR无法访问FIN领域中的数据，甚至具有DBA角色的管理员也无法访问HR和FIN领域中的数据。
9 除了常规领域外，OracleDatabase12c还支持创建强制领域。
常规领域将阻止非领域参与者使用SELECTANYTABLE等系统权限访问数据，但是无法阻止模式所有者或其他用户使用对象权限访问领域中的数据。
强制领域将阻止所有非领域参与者访问领域中的数据。
强制领域的一种常见应用是在安装补丁和升级期间继续保护敏感数据，即当管理员需要修改应用模式但不应访问该模式中的数据表时。
配置OracleDatabaseVault的过程中会创建另外两个用户。
第一个用户是DatabaseVault所有者，他可以创建和管理领域以控制对敏感数据的访问。
第二个用户是DatabaseVault帐户管理员，负责在数据库中创建用户。
虽然一个用户就能完成这两项职能，但将这些职责划分给多个用户可以实现之前介绍的职责分离。
而且，通过将DVOWNER角色授予其他用户可将管理DatabaseVault领域的职责委派给他人。
应将该角色授予负责数据库安全配置的管理员，而不是普通的数据库管理员。
下图显示了如何使用DatabaseConfigurationAssistant启用OracleDatabaseVault。
管理DatabaseVault需要使用这些专门的用户和角色。
启用DatabaseVault后，SYSDBA管理权限将不适用于领域或用户管理。
10 管理授予的权限 最小权限原则是指每个用户以及授予用户的每个角色应只具备执行预定职能所需的一组最小权限。
虽然字典表显示1字符了已授予的权限和角色，但很难确定哪些权限是真正需要的。
系统使用了一段时间后，此问题尤为明显，因为权限和角色授予往往会累积，所以很难确定何时撤销才是安全的。
OracleDatabaseVault12c新增的“权限分析”特性捕获运行时使用的权限并生成一系列报告。
可以使用这些报告查找可能不再需要的权限，甚至生成自动撤销未用权限的脚本。
11 以下示例显示了如何为数据库的所有用户启用权限捕获。
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/SQLprocedurepleted. 捕获正常运行过程中使用的权限之后，经过适当的时间间隔，DBA_USED_PRIVS和DBA_UNUSED_PRIVS视图将显示哪些权限已被使用，更重要的是，还将显示哪些授予的权限未被使用。
SQLPLUS>BEGINDBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT(NAME=>'dba_capture_all_privs');end;/PL/SQLprocedurepleted.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; 以下视图可显示权限捕获所生成的信息。
12 视图DBA_PRIV_CAPTURESDBA_USED_PRIVSDBA_UNUSED_PRIVSDBA_USED_OBJPRIVSDBA_UNUSED_OBJPRIVSDBA_USED_OBJPRIVS_PATHDBA_UNUSED_OBJPRIVS_PATHDBA_USED_SYSPRIVSDBA_UNUSED_SYSPRIVSDBA_USED_SYSPRIVS_PATHDBA_UNUSED_SYSPRIVS_PATH DBA_USED_PUBPRIVS DBA_USED_USERPRIVSDBA_UNUSED_USERPRIVSDBA_USED_USERPRIVS_PATHDBA_UNUSED_USERPRIVS_PATH 描述列出现有权限分析策略的相关信息。
以所报告的权限分析策略为基准，列出已使用（未使用）的权限。
以所报告的权限分析策略为基准，列出已使用（未使用）的对象权限。
列出已用于（或未用于）所报告的权限分析策略的对象权限。
其中包括对象权限授予路径。
列出已用于（或未用于）所报告的权限分析策略的系统权限。
列出已用于（或未用于）所报告的权限分析策略的系统权限。
其中包括系统权限授予路径。
列出已用于所报告的权限分析策略的PUBLIC角色的所有权限。
列出已用于所报告的权限分析策略的用户权限。
列出已用于所报告的权限分析策略的用户权限。
其中包括用户权限授予路径。
13 第二章 防止直接访问数据 上一章介绍了如何配置Oracle数据库控制用户对数据的访问权限。
配置这个由数据库实施的访问控制是非常重要的，可确保只有相关人员能够访问所需的数据，其他人员则无权访问这些数据。
当然，攻击者并不会只盯着防御最强大的环节；如果附近有一扇开着的窗户，他们显然不会反复尝试打开上锁的前门。
如果为数据库正确配置了数据访问控制，那么攻击者自然会尝试绕过坚固的数据库，转而选择其他攻击目标。
一种途径是用特权操作系统用户（如root或oracle）的身份获取系统访问权限。
此类用户可以更改数据库程序的行为，令其忽略已配置好的访问控制设置。
针对此类攻击的最佳防范措施是阻止攻击者获取对主机系统的访问权限，例如遵从互联网安全中心发布的操作系统强化指导准则。
另一条攻击路线是绕过数据库直接读取或写入数据，包括磁盘文件存储中的数据以及通过网络在两个系统之间传输的数据。
这两种情况下均可通过加密技术为数据提供有效防护。
这样一来，用户只需注意加密密钥的安全性即可，而不必再为保护大量数据费神。
只要攻击者没有密钥，他们就无法从任何加密数据中截获有用信息。
而且，加密还是一些关于敏感或个人身份信息的法规和安全标准的强制要求。
本章将阐述如何配置和使用加密来保护静止数据和传输中的数据。
此外，本章还将介绍安全存储用于保护加密数据的加密密钥时的注意事项和选项。
14 静止数据 当信息写入数据库时，它最终将存储在磁盘文件中。
为了确保攻击者无法直接从磁盘文件中读取信息，每个应用在将数据存储到数据库中之前都应对数据进行加密。
然而，这需要额外的编程工作来确保应用在存储数据前进行加密并将其检索到的数据解密。
此外，应用还需要管理加密密钥并将其存放在安全的位置。
如果多个应用共享同一数据库中的信息，那么它们需要合作来加密和解密数据。
为了简化这一过程，Oracle在OracleAdvancedSecurity中引入了透明数据加密(TDE)。
数据库会在数据写入磁盘之前自动执行加密并在从磁盘中读取数据时自动执行解密，因此整个加密过程是透明的。
在数据库中存储和检索数据的应用只能看到解密后的数据或纯文本数据。
由于加密和解密是自动进行的，所以这并不是针对Oracle数据库用户的访问控制机制，而是一种防止用户绕过数据库直接访问数据的方法。
用户和应用使用SELECT语句检索数据时不用提供解密密钥。
而是由数据库实施上一章中介绍的访问控制规则，并拒绝未经授权的用户查看数据。
如果允许访问，则会在返回数据之前自动执行解密。
无论是否允许访问，永远都不会将加密数据返回给用户。
配置透明数据加密时，需要指定要加密的数据，然后再设置一些关于加密执行方式的选项。
指定加密数据时可以选择列加密（即对特定表中的特定列进行加密）和表空间加密（对特定表空间中所有表中的所有列进行加密）。
通过设置列的ENCRYPT属性可指定列加密，如下例所示。
如果只有几列包含需要保护的敏感信息，且这些列仅占数据库数据总量的一小部分，那么列加密是最理想的方案。
针对这种情况，一种比较高效的方法是仅产生敏感列的加密和解密开销，将其余数据存储为纯文本形式。
此外，还可以随时使用ALTERTABLE命令对现有数据应用此方法。
15 CREATETABLEemployee(first_nameVARCHAR2(128),last_nameVARCHAR2(128),empIDNUMBER,salaryNUMBER
(6)ENCRYPT ); 然而，在大多数用例中，表空间加密可提供一些引人注目的优势。
对整个表空间执行加密便无需确定哪些数据很重要需要保护，哪些不需要保护。
而且，这还将确保敏感数据不会因失察或要求变化而意外泄漏。
一些现代硬件在CPU中内置了专用于加速加密操作的特殊指令，在其上运行数据库时，对所有数据进行加密的性能开销几乎可以忽略不计，因此无需就哪些数据需要保护进行决断。
在创建表空间时配置表空间加密，如下所示： CREATETABLESPACEencrypt_tsDATAFILE'$ORACLE_HOME/dbs/encrypt_df.dbf'SIZE100MENCRYPTIONUSING'AES128'DEFAULTSTORAGE(ENCRYPT); 传输中的数据 攻击者绕过数据库直接访问数据的另一种途径是截取网络上传输的数据，例如在客户端与数据库服务器之间传输的数据。
在许多网络上，攻击者都可以相当轻松地捕获发往其他系统的网络流量，然后提取两个系统之间传输的信息。
鉴于此，不仅需要对磁盘上存储的数据加密，而且有必要对通过网络发送的数据加密。
16 使用SSL或Oracle原生加密对网络上的数据加以保护过去是AdvancedSecurity选件的一个特性，不过现在已成为Oracle数据库的一个标准特性。
可将此特性配置为同时提供加密（防止其他人读取通过网络发送的数据）和完整性保护（防止其他人修改或重放数据）。
每个Oracle客户端和服务器的网络数据保护设置均在.ora文件中配置。
每个系统的适用设置包括所支持的加密算法列表以及下面列出的四个加密和完整性保护选项中的一个。
根据这些设置，两个系统在建立连接时会协商确定是否启用加密和/或完整性保护，以及使用哪种加密算法。
•REJECTED系统不会启用此服务（无论是加密还是完整性保护）。
如果其他系统需要此服务，连接将失败。
•ACCEPTED系统不会请求启用该服务，但会在其他系统请求时表示同意。
•REQUESTED系统会请求启用该服务，不过当其他系统拒绝时，它会以未 启用服务的形式建立连接。
•REQUIRED系统会请求启用该服务。
如果其他系统拒绝，连接将失败。
密钥管理和存储 现代加密系统并不依赖秘密加密算法来保证数据的安全。
专业密码学家很久以前就发现，采用众所周知的且弱点经过专家仔细研究的算法会更安全。
这一事实的实际意义在于，受保护数据的安全性完全取决于加密密钥的保密性。
适当的密钥管理是必不可少的，可以防止攻击者破解或猜出密钥并获取受保护数据的访问权限。
17 管理员使用一系列SQL命令或者通过一个管理界面调用这些命令，执行Oracle数据库所需的所有密钥管理操作。
OracleDatabase12c新增的一个选项让用户能够以SYSKM身份（而非SYSDBA身份）连接数据库，然后执行密钥管理操作。
此处遵循了上一章中介绍的最小权限原则，SYSKM管理权限仅支持用户执行所有密钥管理任务，而不具备SYSDBA的超级权限。
OracleDatabase12c还在ADMINISTERKEYMANAGEMENT语句中引入了一组统一的密钥管理命令。
该语句支持所有密钥管理操作，这些操作以前需要结合使用orapki实用程序与ALTERSYSTEM语句才能完成。
以下示例显示了新命令的使用。
ConnectusingtheSYSKMadministrativeprivilege.sqlplususer/passwordASSYSKM CreateanewOraclewallet.SQL>ADMINISTERKEYMANAGEMENT CREATEKEYSTORE'keystore_location'IDENTIFIEDBYkeystore_password; OpenanOraclewallet.SQL>ADMINISTERKEYMANAGEMENT SETKEYSTOREOPENIDENTIFIEDBYkeystore_password; MakeabackupcopyofanOraclewallet.SQL>ADMINISTERKEYMANAGEMENT BACKUPKEYSTOREIDENTIFIEDBYkeystore_passwordTO'backup_location'; SetorrotatetheTDEmasterencryptionkey.SQL>ADMINISTERKEYMANAGEMENT SETENCRYPTIONKEYIDENTIFIEDBYkeystore_password; 18 密钥管理最重要的一个环节是将密钥存放在安全的位置。
Oracle数据库和其他Oracle产品均采用一个被称作“钱夹”的特殊文件存储加密密钥和其他机密数据。
当有人打开钱夹访问其中的密钥时，会使用由用户必须提供的密码派生的密钥对钱夹的内容进行加密。
用于加密钱夹的密码不会随意存放，从而确保攻击者一无所获。
当然，如果用户丢失或忘记密码，则无法打开钱夹或访问使用该钱夹加密的数据。
通常，使用TDE的Oracle数据库将主密钥存储在一个Oracle钱夹中，该钱夹会在数据库启动时打开。
然而，在某些安装中，让管理员在数据库启动时提供钱夹密码并不可行。
针对这种情况，可以为Oracle钱夹配置一个“自动登录”选项，这样数据库不使用密码也可打开钱夹。
尽管这时钱夹中的内容仍然处于加密状态，但却无法提供与常规的密码保护的钱夹同等级别的保护。
仅当可通过足够的外部安全措施防止攻击者访问钱夹文件时，才可采用此备选方案。
还有一种方法可以让数据库轻松地访问密钥，同时获得一些额外的安全优势，即将密钥远程存储在一台单独的企业密钥管理服务器上，如OracleKeyVault，数据库将通过网络访问该服务器。
使用SSL等网络协议保护数据库与密钥服务器之间的通信。
这样，密钥服务器还可以自动验证数据库的身份，无需管理员在数据库启动时提供密码。
密钥服务器可集中、安全地备份或复制密钥（可能是组织最宝贵的数据），以确保密钥始终可用。
专门的密钥服务器还可以自动管理每个密钥的生命周期，包括跟踪其创建和所有权、使用密钥的目的以及何时需要轮换或更换密钥。
19 许多法规，比如支付卡行业(PCI)制定的法规，都要求定期轮换加密密钥，从而避免单一密钥泄漏导致数据泄露。
Oracle数据库使用双层架构将密钥轮换的成本降至最低，从而支持更频繁地轮换密钥。
Oracle透明数据加密使用一个存储在钱夹或密钥服务器中的主密钥。
主密钥不会直接对数据进行加密，而是对内部生成的用于执行列和表空间加密的密钥进行加密。
更换主密钥时，无需重新加密所有数据，只需对小得多的一组数据加密密钥重新加密即可。
20 第三章 高级访问控制 第一章阐述了通过有选择地授予对象权限来控制用户数据访问权限的重要性。
用户应该只能访问包含了其执行任务所需数据的表。
然而，即便只授予用户特定表的SELECT或INSERT等对象权限，该权限也支持用户访问该表中的所有数据。
大多数应用的数据库表中所包含的数据远多于任何一个用户需要访问的数据。
举一个简单的例子，考虑SCOTT示例模式中的EMP员工表。
可以让所有用户查看关于员工姓名和部门的基本信息，不过薪酬属于保密信息，包括SAL和COMM列。
同样，组织可能希望限制对表中特定列的访问，可能只允许员工查看所在部门的数据。
在关系数据库中解决这一问题的长期方案是创建一个视图，其中包含一条WHERE子句来根据需要限制访问，仅允许用户访问视图，而不是基础表。
例如，以下视图就只允许访问一个部门中员工的非薪酬信息。
SQL>createorreplaceviewemp_dept20as2selectempno,ename,job,mgr,hiredate,deptno3fromempwheredeptno=20; Viewcreated. SQL>select*fromemp_dept20; EMPNOENAME JOB MGRHIREDATE DEPTNO ---------------------------------------------------------- 7369SMITH CLERK 790217-DEC-80 20 7566JONES MANAGER 783902-APR-81 20 7788SCOTT ANALYST 756619-APR-87 20 21 7876ADAMS CLERK 778823-MAY-87 20 7902FORD ANALYST 756603-DEC-81 20 将视图用于此目的困难在于，用于选择要包括的数据的所有标准都必须嵌入到视图定义中。
尽管可以在WHERE子句中包括子查询，比如通过子查询来确定请求用户的部门编号，但是编写能够准确表达所需策略的SQL查询很快会变得复杂。
常规策略通常还有一些例外情况，比如为HR管理员或部门经理提供更高的权限，这会增加难度。
Oracle数据库通过虚拟专用数据库(VPD)这个特性满足了这一需求。
使用VPD，可以执行管理员提供的PL/SQL函数确保每次访问表时都能生成适当的WHERE子句。
这样一来，用户便可相当轻松地执行确定所允许的访问权限所需的任何计算。
以下清单显示了一个简单的PL/SQL函数，其策略与上一个示例中的视图相同，通过相应的扩展可支持任何部门，并且可为HR管理员提供更高的权限。
functionemp_policy(p_schemainvarchar2,p_tableinvarchar2) returnvarchar2is user VARCHAR2(100); matchNUMBER; my_deptNUMBER; begin --Gettherequestinguser user:=sys_context('USERENV','SESSION_USER'); --CheckifrequestorisanHRemployeeselectcount(*)intomatchfromemp whereename=userandjoblike'HR%';ifmatch>0then return'1=1';--matchallrowsendif; --Findtherequestinguser'sdepartment 22 selectdeptnointomy_deptfromempwhereename=user; return'deptno='||my_dept;end; 最后，VPD还支持其他一些仅凭视图难以实现或无法实现的策略变体。
VPD策略可以包括那些含敏感信息的列，但只允许特定用户访问其内容，其他人则检索到null值。
VPD策略还可以根据用户执行的操作来提供针对不同行的访问权限。
例如，可以通过VPD策略来允许用户查看关于所有员工的信息，但只能更新他们自己的信息。
尽管VPD在确定筛选谓词方面提供了充分的灵活性，但开发人员仍需负责访问控制逻辑以及管理与应用相关的所有规则和约束。
例如，本例中的访问控制就基于JOB和DEPTNO列。
在其他一些情况下，访问控制决策可由特定应用角色控制。
通过数据标签控制访问 要使用上一节中介绍的细粒度访问控制，可以选择为每个数据项添加一个描述其敏感性或重要性的标签。
在许多政府和企业环境中，一些文档可能会标记为“绝密”或“仅限内部使用”，只有具备足够高“权限”的人员才能够访问这些文档。
通常，标签反映了序集级别，每个用户都将获得其权限范围内的最高级别。
该功能让数据库本身知道哪些数据是敏感的，相应地限制对其访问。
为了支持这一通用访问控制模型，OracleLabelSecurity(OLS)简化了为数据和用户分配标签以及根据这些标签实施访问控制的过程。
23 受OLS保护的表中的每行都会通过相应的标签来指示数据敏感性。
可以根据业务逻辑明确地设置每行的标签，不过大多情况下，系统会根据在表中插入行的用户会话的标签自动设置用户标签。
而用户会话的标签是根据各种因素计算得出，包括用户身份、数据库连接类型等。
用户标签可视为对标准数据库权限和角色的扩展。
数据库采用了OracleLabelSecurity后就增强了安全性，不再需要复杂的应用视图。
标签的格式表意丰富，足以支持几乎任意数据库分类方案。
每个标签包括一个级别（从最低到最高），用于表示数据的整体敏感性。
在级别内部，可以选择使用隔间partment)和组组件根据项目、部门或地理区域等属性隔离信息。
与级别组件不同，隔间之间没有排序。
组中可以包括其他组，这样就可以根据地理区域或组织层次结构轻松地表示部门。
图3-1显示了一个使用所有三个标签组件的分类方案。
图3-1：标签的组件当数据和用户会话都有标签时，可以用一组简单的规则来比较标签并确定是否允许访问。
如果用户标签的级别不低于数据标签的级别，并且包含数据标签中指定的所有隔间以及至少一个组（或其中一个组的父组），则用户可以读取表中带标签的行。
使用图3-1中的示例，标签中包括Global组的用户可以访问标签中包含NATO或Europe组的数据。
24 OracleLabelSecurity的主要优势包括灵活性和简化管理。
OLS提供与VPD相同类型的行级访问控制，但无需管理员创建PL/SQL策略函数来实施访问规则。
建立了可以为数据和用户会话分配标签的系统后，访问控制将统一实施，无需确定哪些人能访问各表中的数据。
对应用最终用户应用访问控制策略 目前为止所介绍的方法解决了按数据库用户控制数据访问的问题。
然而，在现代三层应用中，应用最终用户并不与数据库直接交互。
数据库查询和更新通常由代表整个应用的单一数据库用户执行，而不是由各个最终用户执行。
由于数据库对最终用户的身份一无所知，因此必须由应用来实施基于用户的访问控制策略。
除了需要在应用中进行额外的软件开发工作外，这种方法还会导致实施不一致，当一些系统要素可绕过应用直接连接数据库时，此问题尤为突出。
OracleDatabase12c中引入的OracleRealApplicationSecurity(RAS)为数据库提供了下一代应用访问控制框架，支持三层和双层应用在数据库层以声明方式定义、供应和实施访问控制要求。
OracleRAS引入了一个基于策略的授权模型，可识别数据库中的应用级用户、权限和角色，然后控制对表示业务对象的静止和动态记录集的访问。
RAS可将应用最终用户的身份传递至数据库，以便在数据库内部实施访问控制策略。
每个应用最终用户由一个轻量级“应用用户”表示。
与普通数据库用户不同，该应用用户不能用自己的模式存储数据对象，也没有专用的数据库连接。
应用可以创建任意数量的应用用户会话并在它们之间切换，同时仅与数据库建立单一连接。
该应用用户会话允许数据库知晓应用所执行的操作是由哪个最终用户发起的，这样数据库便可实施相应的访问控制策略。
25 与虚拟专用数据库特性一样，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角色的用户。
26 图3-2：有数据安全策略的表OracleRAS支持将应用用户的会话传递给数据库，允许通过应用定义的用户角色和数据操作直接指定数据安全策略。
RAS安全模型允许对业务对象统一指定和实施访问控制策略，无论访问路径为何。
OracleRAS通过对应用数据和操作使用声明式访问控制策略，贴近数据实施了安全防护，为三层和双层应用提供了端到端的安全性。
27 第四章 审计数据库活动 维护活动的审计跟踪是任何数据库纵深防御战略都不可或缺的一个要素。
即使正确配置了访问控制并采用了最小权限原则，仍然存在两个重要的风险。
第一个风险是需要重大权限履行工作职责的用户可能会滥用其权限。
第二个风险是访问控制或权限授予在无意中被配置得高于所需时，用户可能会获得意料之外的访问权限。
审计是检测这些突发事件的主要手段，为最终修复问题奠定基础。
有效的审计要求审计策略能够有选择地从大量事件中捕获重要细节，同时最大限度排除例行活动的干扰。
审计数据需要存储在安全的地方，这样才能确保事件记录的可靠性，特别是无法通过操纵审计数据来隐藏可疑的活动。
最后，还需要通过便捷的方式搜索所收集的审计数据，以查找特定信息或检测异常活动。
独立的Oracle用户组(IOUG)针对Oracle客户开展的调查显示，70%的企业正在对其数据库使用原生审计。
客户审计数据库是否符合SOX、HIPAA、PCIDSS、GLB、FISMA和其他国际标准。
审计提供关于人员、行为和时间的历史记录，让组织能够满足严格的控制和报告要求。
内部治理、本地安全策略和取证报告也带动了对审计的需求。
大多数企业希望能够追溯数据请求或更改、数据库更改、特定事件授权的命令发起方以及此类交互背后的业务理由。
合规性审计人员希望数据库管理员(DBA)及其上级（通常上至CFO和CSO）能够对数据和数据库本身的所有访问和更改作出解释。
28 Oracle数据库提供了业界最全面的审计功能，可捕获事件的详细信息来生成报告和警报。
审计捕获的信息包括数据库名称、主机名称、客户端程序名称、事件时间、事件状态、事件操作、数据库用户、对象所有者以及SQL语句本身等。
可以将审计配置为记录成功和失败的事件。
Oracle数据库还支持更细粒度的审计功能，可在应用表中的特定列被引用时执行审计。
例如，可以对包含信贷限额的表应用这样一条细粒度的审计策略：仅当更新信贷限额列时执行审计。
OracleDatabase12c中的审计功能变动 OracleDatabase12c对之前版本中丰富的数据库审计功能进行了完善，扩充了审计选项并且简化了管理。
OracleDatabase12c审计策略可配置为根据特定IP地址、程序、时间段或连接类型（如代理身份验证）进行审计。
此外，还可以轻松地将特定模式排除在审计之外。
这大大减少了生成的审计记录的数量，并确保在需要时能找到相关审计数据。
OracleDatabase12c审计功能利用策略和条件在Oracle数据库内部有选择地执行有效的审计。
此外，OracleDatabase12c还支持OracleDatabase11g审计语法。
这种“混合模式”支持采用之前审计语法的脚本和工具。
OracleDatabase12c统一审计为以下所有审计来源创建一个审计跟踪： •来自统一审计策略的审计记录（包括SYS审计记录）以及来自DBMS_FGAPL/SQL程序包的细粒度审计记录 •统一审计策略本身的管理•OracleDatabaseVault•OracleLabelSecurity•OracleRecoveryManager •OracleDataPump•OracleSQL*LoaderDirectLoad 29 统一审计跟踪位于AUDSYS模式的只读表中，确保信息以统一格式显示在UNIFIED_AUDIT_TRAIL视图中。
当数据库不可写入时，审计记录会写入到$ORACLE_BASE/audit/$ORACLE_SID目录下的操作系统文件中，然后在数据库变为可写入时再将其加载回统一审计跟踪。
为了与传统DBA职能保持职责分离，OracleDatabase12c引入了两个新角色：AUDIT_ADMIN用于管理策略和审计跟踪，AUDIT_VIEWER用于查看审计数据。
由于不会将这些角色授予DBA角色，所以DBA无法更改审计集合。
只能使用数据库内置的审计数据管理程序包来管理审计数据，不能使用SQLUPDATE或DELETE命令直接更新或删除审计数据。
此外，OracleDatabase12c还提供了一个不能关闭的强制审计活动列表。
这些审计活动包括 •CREATE/ALTER/DROPAUDITPOLICY•AUDIT/NOAUDIT•针对DBMS_FGAPL/SQL和DBMS_AUDIT_MGMTPL/SQL程序包的EXECUTE•针对AUDSYS审计跟踪表的ALTERTABLE（尽管不能更改此表）•在数据库打开前使用的SYSuserorwiththeSYSDBA,SYSOPER, SYSASM,SYSBACKUP,SYSDG,和SYSKMadministrativeprivileges,的顶级权限语句•审计特权用户的操作，直到系统中的审计配置可用为止•针对OracleDatabaseVault的所有配置更改 30 OracleDatabase12c中预定义的审计策略 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,ADMINISTERKEYMANAGEMENTALTERUSER,CREATEROLE,ALTERROLE,DROPROLE,SETROLE,CREATEPROFILE,ALTERPROFILE,DROPPROFILE,CREATEDATABASELINK,ALTERDATABASELINK,DROPDATABASELINK,LOGON,LOGOFF,CREATEDIRECTORY,DROPDIRECTORY; 31
2.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; 32 本例中的策略将监视来自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配置为在传输过程中对数据进行加密。
•管理审计策略 33 •提醒和管理不符合策略的事务•报告和分发即席或计划报告•AuditVaultAgent—基于主机的低影响程序，用于管理所在系统的数据收集并与AV服务器通信。
•审计跟踪—审计数据的来源。
有五种审计跟踪：•数据库审计跟踪，包括Oracle、MicrosoftSQLServer、SAPSybase、 IBMDB2forLUW和MySQL。
它们可以是审计表、审计文件或重做记录。
•操作系统审计跟踪（Linux、Windows、Solaris）•目录服务，如MicrosoftActiveDirectory•文件系统，如OracleACFS•数据库表或XML文件中的自定义审计数据OracleDatabaseFirewall—AVDF的网络组件。
OracleDatabaseFirewall监视网络上的SQL事务，并且可在SQL语句访问数据库服务器之前判定是应该许可、修改、阻止还是替换该SQL语句。
下一章将介绍OracleDatabaseFirewall是如何运作的。
目前我们只需要知道它向AuditVault提供关于其活动的审计数据即可。
图4-1显示了异构网络环境中部署的OracleAuditVaultandDatabaseFirewall和许多审计数据来源。
34 图4-1：OracleAuditVaultandDatabaseFirewall架构 报告和警报 AuditVaultServer具备全面的报告功能，可提供一系列标准的安全报告、即席报告和取证报告。
此外，还有一些现成的不符合策略的审计评估报告，旨在帮助满足PCI-DSS、GLBA、HIPAA、SOX和DPA等标准的要求。
像图4-2中这样的报告可用于监视大量活动，包括数据库服务器上的特权用户活动、对数据库结构的更改以及网络上关于入站SQL语句的数据。
报告可以整合来自数据库、操作系统和目录的审计信息，让您全面了解企业的所有活动。
35 图4-2：整合网络、数据库审计和操作系统事件日志审计人员可以通过控制台Web界面或者通过PDF或XLS文件交互式地访问报告，并且可自动将其分发给不同的组织团队。
系统会通过相应的规则自动高亮显示特定的行，这样您就可以快速发现可疑或未经授权的活动。
可以使用OracleBIPublisher创建新的或自定义的PDF和XLS报告模板来满足特定的安全需求。
报告基于的是一个高度优化的Oracle11gR2数据库，后者也可以通过配置允许外部报告工具访问审计数据。
也就是说，现有的管理信息(MI)工具甚至Excel电子表格均可访问重要的安全信息，但是为了确保审计记录的完整性，严格禁止更改或删除数据。
而且，AuditVault信息库模式经过归档，支持与第三方报告解决方案集成。
警报或事件管理让您可以创建复杂的警报定义，以便在审计人员控制台仪表盘上发出警报，并将通知发送给多个用户进行查证。
定义警报时可以使用SQL比较运算符（=、<、LIKE、IN和NULL等）和逻辑运算（NOT、AND和OR）指定布尔条件。
此外，还可使用组（使用括号）和通配符（%、_）为通用警报条件指定范围。
例如，您有一个JOBS表，只有授权帐户（比如HR_App）才能访问其 36 中的敏感数据。
图4-3中的示例显示，当任何非HR_App用户访问JOBS表时会发出警报。
图4-3：AVDF警报 37 第五章 控制SQL输入 政府和学术机构的研究表明，绝大多数数据泄漏是由SQL注入或滥用有权访问系统及其数据的内部人员的凭证引发的。
如今，大多数应用都采用单一用户帐户与数据库通信，且许多应用未充分验证其输入。
这种应用架构，再加上SQL注入或内部特权帐户滥用所引发的数据库攻击数量不断增加，导致数据库活动监视成为了整体安全架构的重要一环。
如今，市面上的大多数监视解决方案都依赖其策略中的正则表达式来确定应阻止哪些SQL语句访问数据库。
这些第一代解决方案所面临的的挑战是正则表达式的表达能力远不及SQL语句强大。
由于可以采用各种方式编写具有危害性的SQL语句，因此几乎不可能通过一条正则表达式规则检测到所有此类语句。
即使可以通过正则表达式检测到特定的SQL语句，但这些危害性语句也不是一成不变的。
除了阻止一组固定的“危害”语句外，另一种更有效的方式是根据连接至数据库的应用和用户的常规活动仅允许“良性”语句。
有效监视数据库SQL输入可阻止策略违规企图或发出相关警报，并提供全面的数据库活动报告来确保合规性。
OracleAuditVaultandDatabaseFirewall OracleAuditVaultandDatabaseFirewall为Oracle和非Oracle数据库提供第一道防线，并整合数据库、操作系统和目录中的审计数据。
该解决方案的DatabaseFirewall组件集成了一个基于SQL语法的高度精确的引擎来监视和阻止未经授权的SQL语句访问数据库。
与采用正则表达式的解决方案不同，OracleDatabaseFirewall对SQL本身进行解析，以达到企业数据库监视所需的精确度。
38 OracleDatabaseFirewall使用高度优化的流量捕获技术收集网络中的SQL请求。
然后，SQL查询将与尽可能多的会话信息相关联。
这包括查询的语法结构和上下文属性，例如： •数据库用户名 （例如dba_001） •操作系统用户名 （例如oracle_dom1\fred.bloggs） •客户端程序名称 （例如sqlplus.exe） •客户端IP地址 （例如192.0.2.12） •事务时间 （精确到毫秒） •安全目标名称 （例如） •数据库服务名称 （例如ounts.service1） 随后，这些信息将与SQL语句的进一步分析结果相结合，包括 •SQL类别 （例如，SELECT、DML-write、DDL、DCL和TCL等） •表名 （例如“tbl_customers”） 所有这些任务都将在网络包到达时实时完成，随后会将请求与OracleDatabaseFirewall策略进行对比。
OracleDatabaseFirewall按语法将SQL请求划分成不同的查询集群，这样可将SQL查询数量从数百万条缩减至数百条，然后可以按IP地址、客户端程序、SQL类型或用户名进一步分类。
这个将看似杂乱无章的SQL查询净化为数量级小几个的集群活动的过程就让OracleDatabaseFirewall有了区分“正常”事务与“异常”事务的能力。
39 通过DatabaseFirewall设置白名单 OracleDatabaseFirewall自动分析所有SQL语句，并且提供一个策略管理器为应用和通常执行同类SQL交互的用户快速创建“正常”行为白名单。
白名单策略是基于SQL请求创建的。
由于SQL请求中的某些属性与应用唯一明确相关，因此可以实现有效的选择性监视。
典型示例包括： •应用IP地址 （例如，192.0.2.100、192.0.2.101、192.0.2.102） •应用程序名称 （例如，service_123abff00、service_dd00） •应用数据库用户 （例如，db_appuser、db_appadmin） 通过OracleDatabaseFirewall设置黑名单 除了基于白名单的主动安全实施模型外，OracleDatabaseFirewall还支持黑名单。
与白名单策略一样，黑名单可以评估用户名、IP地址、时间和程序等各种因素，然后作出决策。
黑名单作为主动实施模型的例外情况，允许针对特定事件创建自定义规避策略。
例如，例外列表策略让来自预定IP地址的特定远程管理员可以诊断特定应用的性能问题，不受白名单或黑名单的限制。
可将黑名单视作用于评估各种因素的例外情况。
黑名单类似于传统防火墙中的“允许”和“拒绝”设置，其构成要素包括： •IP集•数据库用户集•操作系统用户集•客户端程序集 40 “集”是由同类属性构成的特定集合。
例如，下表显示了由用户构成的4个集： 集1报告用户marketing_01marketing_02marketing_03marketing_04mgt_BI_rep 集2DBA用户mikesmithwilliesoresdavejonesjohnasher 集3应用用户peoplesoft_201sap_usersiebel_4501app_001app_002 集4咨询用户jennaforteslouisegoodcons_001cons_002 我们可以针对每个集设置一条黑名单策略。
例如： 报告用户DBA用户应用用户咨询用户 通过、记录全部通过、报警通过阻止、记录全部 例外策略可在较高层次上对SQL请求进行有效筛选，简化应用、子网、用户组或用户的策略设置。
下图显示了一个例外策略的示例。
该策略将允许来自安全目标上的帐户应用的请求，但会阻止来自任何其他来源或身份的请求。
41 通过OracleDatabaseFirewall设置新颖(novelty)规则 新颖规则用于控制高级类别SQL和数据库表的SQL输入。
新颖规则配置适用于各种类别，具体取决于安全性对策略的要求。
这些类别包括： •数据操作 （INSERT、UPDATE、DELETE和SELECTINTO等） •只读数据操作•过程 (SELECT)（存储过程或RPC命令） •数据定义•数据控制语言•组合 （CREATE、DROP和ALTER等）（GRANT和REVOKE等）（事务中执行的命令） 42 •事务 （COMMIT和ROLLBACK等） •与事务的组合 （包含TCL命令的DML语句，等等） 新颖规则可将SQL命令与表相结合，轻松禁用所有表的日志记录，例如与应用本身无关的基础数据库字典表。
新颖规则可用于阻止或允许针对不同表的操作。
新颖规则通常用于控制DBA通过网络实施的操作，例如阻止他们访问特定的应用表。
通过OracleDatabaseFirewall处理未经授权的SQL 当OracleDatabaseFirewall发现一条未经授权的语句时，它会采用以下方式处理该语句： •对所有不符合策略的SQL语句发出警报。
•通过替换SQL语句来修改请求，即将不符合策略的语句替换为不会返回任 何数据的新的无害语句。
•终止连接：断开连接后，这将阻止来自特定数据库连接的所有语句访问服务器。
这是最激进的措施，如果应用使用连接池，那么这将影响所有使用该池的用户。
•阻止SQL语句：这将阻止特定语句访问数据库服务器。
实际的最终用户体验将取决于应用在服务器未响应时的处理方式。
可以将数据库的客户端连接配置为继续或终止。
OracleDatabaseFirewall网络部署 可以将OracleDatabaseFirewall部署为透明的网桥，只需将其插入到数据库客户端/应用服务器与受保护数据库之间相应区段的网络中，如下图所示。
这种“内 43 联”桥架构无需更改数据库客户端、应用或数据库本身的配置，并且提供灵活的主动和被动监视。
如需被动地监视数据库活动，还可以使用SPAN端口将流量转发给数据库防火墙。
如果难以添加网桥或者数据库服务器位于远程位置，那么可以将OracleDatabaseFirewall配置为代理，以便让所有对数据库服务器的访问都经由数据库防火墙进行。
这需要将数据库客户端或应用上的数据库服务器IP地址/端口更改为OracleDatabaseFirewall代理的IP地址/端口，同时将数据库监听器更改为拒绝直接连接。
也可以使用大多数企业网络交换机和传统防火墙将数据库流量重定向至OracleDatabaseFirewall代理端口，这样无需更改数据库客户端或应用即可保护SQL流量。
指定的数据库防火墙充当一些数据库的透明网桥的同时可充当其他数据库的代理。
DatabaseFirewall支持本地服务器端的仅监视代理，以确保能够灵活选择监视流量的网络点。
主机监视器（审计代理的一部分）捕获对数据库服务器的SQL访问并将其安全地转发给DatabaseFirewall。
主机监视器可用于远程监视Linux和Windows平台上运行的数据库服务器。
44 第六章 屏蔽敏感数据 许多组织都面临减少敏感数据泄露的挑战。
许多组织都需要在测试和开发系统中使用真实数据，但它们发现无法像保护生产系统那样保护这些系统。
因此，非生产环境中的敏感数据和受管制数据日益成为攻击者的目标。
而数据屏蔽则可通过在从生产环境移出数据前用虚构的数据不可逆地替代原始敏感数据，避免数据在非生产环境中泄漏，从而可以放心地与IT开发人员或业务合作伙伴共享数据。
与时同时，敏感数据在生产应用中过度公开也是许多组织所面临的一项挑战。
虽然向应用用户显示敏感信息自几年前就屡见不鲜，但如今组织必须对应用界面上显示的敏感数据进行编辑，以便更好地保护数据和遵守本地和国际法规。
然而，应用代码内部的这种编辑可能很复杂且容易出错，此问题在多个应用访问相同数据的整合环境中尤甚。
控制应用中敏感数据公开的最好、最经济高效的方法是在生产数据库内部实施相应策略，这样策略的实施便与访问数据的应用无关。
数据屏蔽会在物理上更改所存储的数据，以便将其移交给其他组织，而数据编辑不会在物理上更改所存储的数据，只会在数据离开数据库前进行转换，然后将转换结果显示在应用中。
在许多情况下，编辑仅适用于部分数据，例如信用卡的前12位数字、电子邮件域名前的用户名部分。
45 敏感数据发现 知道敏感数据所处的位置是决定如何对其进行保护的第一步。
大型应用的复杂性之高、规模之大令相当多的组织难以找到和识别所有敏感数据。
使用OracleEnterpriseManager中的数据发现和建模功能，企业可以检查数据库中与应用相关的元数据（如列名和数据类型）并对现有数据采样以帮助识别敏感数据。
例如，OracleEnterpriseManager可以根据列名、列注释或数据自身的特征来帮助找到信用卡和美国社会保险号。
以下示例显示了信用卡号的数据模式。
数据发现和建模功能还使用数据库中定义的外键约束来分析应用对象之间的关系。
这些关于应用的数据类型和对象关系的信息统称为应用数据模型(ADM)，并被存储在OracleEnterpriseManager信息库中。
对于没有使用数据库实施的引用完整性的应用，可在ADM中手动定义关系。
Oracle针对Oracle融合应用产品和OracleE-BusinessSuite开发了应用加速器。
应用加速器列出了每个应用的敏感数据。
OracleDataMasking使用应用加速器帮助屏蔽从生产数据库传入测试和开发环境的数据。
46 数据屏蔽 OracleDataMasking提供端到端的自动化，实现从生产环境自动供应测试数据库，并满足合规性要求，如下图所示。
可以替换信用卡和社会保险号等敏感信息，然后将其用于开发和测试，无需扩大安全边界。
在确保合规性和安全性的同时，这将减少需要监视的数据库系统的数量。
屏蔽格式库 OracleDataMasking提供了一个现成的屏蔽格式库，可用于最常见的敏感数据类型。
该库中的格式包括信用卡号、电话号码、社会保险号和国家标识号等敏感数据。
通过OracleDataMasking中的格式库，企业可对整个企业的数据库中的敏感数据应用数据隐私规则，以确保始终符合法规要求。
企业还可以用自己的屏蔽格式来扩展该库，以满足特定的数据隐私和应用要求。
将屏蔽定义与应用属性相关联之后，可将格式和数据关联保存在应用数据模型中，然后在测试、开发或合作伙伴需要刷新数据时重新执行。
OracleDataMaskingPack可通过OracleDatabaseGateways屏蔽异构数据库中的数据，如IBMDB2和MicrosoftSQLServer。
47 格式库（如上图所示）简化了屏蔽过程，可以采用经济高效的方式实现合规性。
格式库可扩展并且可通过自定义来满足各种复杂的业务需求，例如根据一组虚构的姓名生成电子邮件地址。
强大的屏蔽技术 OracleDataMasking支持各种高级屏蔽技术，允许复杂应用在测试和开发环境中使用屏蔽后的数据。
基于条件的屏蔽 混合屏蔽确定性屏蔽基于密钥的可逆屏蔽 根据条件对不同行应用不同的屏蔽格式。
例如，存储在同一表中关于多个国家/地区的公民的数据通常生成自己唯一的ID（SSN、国家标识号）。
将多个列中的存储相关数据作为一个组加以屏蔽。
例如，需要共同屏蔽的城市、州和邮编。
支持在多个数据库或应用中将数据屏蔽为同一个值。
这将确保在特定的值（如客户号）在所有数据库中屏蔽为同一个值。
支持使用基于密钥的可逆函数来屏蔽数据。
可以通过原始密钥来解除数据屏蔽。
48 克隆数据库和源数据库数据屏蔽 OracleDataMasking支持对从生产环境克隆来的数据库中的数据进行屏蔽或者对源数据库的数据进行屏蔽。
利用克隆数据库，OracleDataMasking构建了一个由需屏蔽的表和列构成的工作列表，并在物理上更改所存储的数据。
OracleDataMasking在屏蔽过程中使用了各种优化，因此不会访问无需屏蔽的对象，需要访问的表最多只会访问一次。
通常先屏蔽包含主键的表。
此外，OracleDataMasking创建屏蔽表时还使用NOLOGGING选项，以免生成过多的REDO日志。
OracleDataMasking现在支持数据源屏蔽，即在Oracle数据导出过程中对数据进行屏蔽。
随后，经过屏蔽的物理导出文件可直接与测试和开发组织共享，不存在敏感数据泄漏的风险。
这种新方法还支持在导出屏蔽过程中将文档或图像等数据设置为固定字符串。
这将减少需要传输给其他组织的数据集的大小。
数据编辑 除了在将敏感数据从数据库中导出前对其进行屏蔽外，越来越多的企业需要控制敏感数据在应用中的显示。
例如，呼叫中心应用会在其界面上向呼叫中心操作员公开客户信用卡信息和个人身份信息。
即使将这些信息向合法应用用户公开也可能违反隐私法规，给数据带来不必要的风险，而且这些用户根本没必要了解这些信息。
传统的敏感数据编辑方案通常采用自定义应用逻辑，导致整个企业内存在多种不一致的解决方案，且持续维护成本高昂。
此外，还必须严格控制新应用的开发，以确保能够正确访问自定义应用代码和新对象。
OracleAdvancedSecurity数据编辑可动态、选择性地编辑或清理查询结果中的敏感数据，然后查询结果才会显示在应用中，如下图所示。
它支持在访问相同 49 数据的应用模块中对数据库列进行一致的编辑。
数据编辑可最大限度减少对应用的更改，因为它不会更改内部数据库缓冲区、缓存或存储中的实际数据，并且在将转换后的数据返回给应用时会保留原始数据类型和格式。
与过去依赖于应用编码和新软件组件的方法不同，直接在Oracle数据库内核中实施数据编辑策略，以确保跨应用模块的一致性。
可根据数据库所跟踪的不同因素或应用传递给数据库的不同因素（如用户标识符、应用标识符和客户端IP地址）执行有条件的数据编辑。
编辑格式库提供了一些预先配置好的列模板，可用于编辑常用类型的敏感信息（如信用卡号和国家识别号）。
策略启用后立即生效，即便对于活动会话也不例外。
数据编辑策略和转换 数据编辑支持通过各种不同的转换来编辑指定列中的所有数据、保留数据的特定部分或者随机生成替换数据。
下图显示了一些受支持的数据转换示例。
50 可根据使用数据库和正在运行的应用中的运行时上下文的声明式策略条件有选择地应用数据编辑。
示例包括用户标识符、用户角色和客户端IP地址。
还可以利用OracleApplicationExpress(APEX)、OracleRealApplicationSecurity和OracleLabelSecurity中的上下文信息。
因为策略条件可以使用APEX自动跟踪的应用用户和应用标识符，所以APEX应用的编辑非常简单直观。
可以在一个数据编辑策略中合并多个运行时条件，以便对编辑时间点进行细粒度控制。
编辑策略在数据库中进行存储和管理，一经启用，立即生效。
从表面上看，数据编辑与数据屏蔽十分相似。
然而，一个重要区别在于Oracle数据编辑不会从物理上更改所存储的数据。
因此，Oracle数据编辑支持的转换功能仅仅是Oracle数据屏蔽的一个子集。
数据编辑的强大之处在于其卓越的性能、数据库内核级实施以及声明式策略条件。
部署数据编辑 可以快速为现有应用部署数据编辑，只需使用OracleEnterpriseManager或PL/SQL过程指定受保护的列、转换类型和条件即可。
OracleEnterpriseManager提供了一个简便易用的界面来创建和部署编辑策略，如下图所示。
51 OracleEnterpriseManager中提供了一些预定义的列模板，可用于编辑一些常见的敏感数据（如信用卡号和美国社会保险号），如下图所示。
EnterpriseManagerSensitiveDataDiscovery支持在复杂应用模式中查找需编辑的列。
OracleEnterpriseManager中的PolicyExpressionBuilder允许管理员定义编辑策略并将其应用于现有应用。
如下图所示，PolicyExpressionBuilder对话框将引导用户创建使用来自应用、数据库、APEX框架和其他数据库安全解决方案的上下文的策略条件。
52 除了OracleEnterpriseManager管理界面外，还可以使用数据库内部的API编写和应用编辑策略。
DBMS_REDACT.ADD_POLICY(object_schema=>'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。
53 第七章 验证配置合规性 如今的数据库需要大量配置设置，其复杂程度早已今非昔比。
攻击者通过配置中的漏洞获取对数据库的未授权访问。
例如，数据库中众所周知的用户名和密码组合就是一个常见的目标。
因此，需要扫描数据库来确保其经过安全配置，并且及时修复所发生的问题。
通过标记配置错误和提供有益于总体安全架构的控制建议，配置扫描可增强组织的整体安全性。
安全配置扫描已成为许多法规的重要组成部分，如支付卡行业数据安全标准(PCI-DSS)、Sarbanes-Oxley以及众多侵犯通知法规。
互联网安全中心(CIS)和美国国防部等众多机构也推荐了配置最佳实践。
随着新法规的发布和现有法规的不断发展，合规性的复杂程度不可小觑。
因此，部署一个能适应新法规的解决方案也就成为了企业的当务之急。
通过OracleEnterpriseManager执行安全配置扫描 OracleDatabaseLifecycleManagementPack提供了众多现成的基本配置报告和一个全面的合规性框架。
例如，帐户状态报告将显示所有数据库帐户及其状态。
另外还有一个报告可通过匹配各种Oracle产品自带默认帐户的已知密码，显示使用默认密码的数据库帐户。
其他报告还包括有关初始化参数、操作系统目录权限、用户帐户资料和敏感对象报告的信息。
如图7-1所示，可以通过Security菜单的Reports项访问这些现成的报告。
54 图7-1：OracleEnterpriseManager安全配置报告 通过OracleEnterpriseManager执行资产发现和分组 OracleDatabaseLifecycleManagementPack消除了手动跟踪IT资产（包括数据库）的必要。
它提供非侵入性网络扫描功能来发现服务器。
发现服务器之后，可轻松将其升级为托管状态，从而自动发现所有数据库和其他应用。
这种自动发现功能可以更加轻松地确保所有服务器和软件均处于托管状态，并且可为IT整合和优化计划提供支持。
由于管理员所负责的系统和服务数量不断增长，OracleEnterpriseManager提供了一个仅显示需要监视的目标的视图。
该视图被称为一个组。
组是一组用户定义的在逻辑上共同管理的目标。
您可以通过OracleEnterpriseManager中的组来共同监视和管理不同目标，轻松对这些目标执行管理操作，并且将这些分散的目标作为一个逻辑实体加以整合和监视。
例如，您可以定义一个TEST组，其中包含测试环境中的所有主机和数据库目标。
在测试组的主页中，您可以轻松查看该组中所有目标的总体状态和可用性，无需检查每个成员的状态。
即便组成员发生更改，提交给该组的所有作业也会自动与组成员保持同步。
55 在某个组的主页中，无论该组基于一组同构目标还是一组异构目标（如某企业的应用），管理员均可完成以下任务 •轻松确定组中所有成员以及待处理警报的总体安全配置合规性•下钻并分析特定目标的详细信息•通过汇总警报，快速下钻至警报详细信息，轻松确定组成员的状态 OracleEnterpriseManager配置扫描 OracleDatabaseLifecycleManagementPack提供了一个强大的合规性扫描解决方案，包括合规性框架、合规性标准和合规性标准规则，如下表所示。
合规性框架 合规性标准合规性标准规则 合规性框架是行业规定的针对底层IT基础架构、应用和流程的最佳实践准则。
合规性框架通过分层结构来直接表示这些行业框架。
合规性框架可用于表示PCI等框架。
合规性标准是指针对特定目标类型的检查或规则的集合。
合规性标准规则是用于确定特定配置参数或状态的测试。
Oracle支持以下规则类型。
•信息库规则评估针对目标定期收集的指标。
•实时监视规则监视对文件、流程等要素的更改。
56 Oracle提供的配置合规性标准 合规性标准作为度量目标的基准。
这些标准相当于最佳实践，支持安全管理员在不同企业系统和配置中保持一致性。
此外，趋势分析特性还可以对合规性评分进行持续的细粒度跟踪。
在上图所示的Oracle数据库基本安全配置检查中，可以看到系统执行了大量现成的检查。
所执行的检查包括分析目录和文件权限、Oracle参数设置、数据库密码配置文件设置、Oracle可执行文件所有权以及网络配置设置。
OracleEnterpriseManager附带了40多个现成的合规性标准，包括： •Oracle集群数据库基本安全配置•Oracle集群数据库实例基本安全配置•Oracle监听程序基本安全配置•Exadata计算节点配置监视•安全Linux程序包配置监视 57 管理框架、合规性标准和规则 OracleEnterpriseManager提供了一个可扩展的框架，可用于创建新的架构、标准和规则。
这种可扩展性让组织能够适应不断变化的合规性要求，并且创建自定义配置扫描来测试系统是否遵循内部最佳实践。
可通过OracleEnterpriseManager创建合规性标准规则，如下图所示。
还可以采用XML格式导入或导出规则。
事件严重性对于安全配置扫描至关重要。
OracleEnterpriseManager中的事件可分为下列严重性级别： •致命监视目标已停止运转。
•严重需要在某方面立即采取行动。
该方面不再起作用或意味着要出问题。
•警告某方面需格外注意，不过该方面仍还起作用。
•建议尽管某方面无需立即注意，但就该方面目前的状况来说建议多加留 神。
此严重性级别主要用于合规性标准。
•提示某方面发生了些小情况。
58 通过OracleEnterpriseManager进行实时监视 OracleDatabaseLifecycleManagementPack可实时监视针对文件、数据库对象或Windows注册表键的任何操作。
它还可以监视进程的启动和停止以及用户登录、注销和切换用户活动。
实时监视意味着可以捕获操作发生的准确时间以及执行操作的用户的名称。
实时监视的结果可与BMCRemedy等变更管理系统相协调。
这种协调可自动确定某个操作是否应发生（是否经过授权）。
如果没有变更管理服务器，那么可以通过管理控制台手动进行此审计状态批注。
实时监视通过将环境当前状态与客户的变更管理流程同步，帮助识别违反策略的操作。
这些操作会给环境带来高风险或使合规性控制无法通过审计。
实时监视的核心是Facet概念。
从本质上说，Facet包括配置文件、日志文件、进程和敏感数据库表等项目。
一个特定目标可以有多个与之关联的Facet。
可以根据Facet为核心Linux程序包、Exadata计算节点和用户访问Linux程序包创建多个实时监视标准。
OracleEnterpriseManager提供了数百个预先定义的Facet。
与框架和标准一样，可以定义和自定义Facet。
59 目标类型Facet日志文件二进制/库文件 配置文件安全密钥文件安全配置文件实用程序进程注册表键配置表 描述监视普通用户（非系统用户）对日志文件的修改。
监视二进制文件是否被篡改过或者二进制打补丁的时间。
除了列出各个二进制文件外，它还列出整个目录，但不包括频繁更改的文件。
捕获对任何配置文件的更改。
监视存储证书、密钥等内容的文件。
监视用于配置目标类型中的安全机制的文件，例如加密配置等。
监视通常在维护期间运行但不会在生产环境中运行的进程。
监视影响目标配置的MicrosoftWindows注册表键。
监视任何存储配置数据的数据库表。
每个Facet都通过一个实体类型来定义Facet描述的实体种类。
例如，在操作系统级监视中，实体类型包括操作系统文件、操作系统进程、操作系统用户、Windows注册表和一些ActiveDirectory。
在数据库监视中，实体类型包括表、视图、索引和过程等。
可以通过FacetLibrary界面创建Facet。
定义实时监视规则时，您首先需要确定主机上监视的实体类型。
下表列出了OracleEnterpriseManagerCloudControl12c中可通过实时监视规则进行监视的实体类型： 操作系统文件Oracle数据库表 Oracle数据库链接Oracle数据库触发器 操作系统进程Oracle数据库视图 操作系统用户Oracle数据库过程 Oracle数据库函数Oracle数据库表空间 Oracle数据库程序包Oracle数据库物化视图 Oracle数据库用户Oracle数据库配置文件 Oracle数据库序列Oracle数据库集群 60 使用OracleEnterpriseManager的通知功能 通知是OracleEnterpriseManager管理框架不可分割的一部分。
通知可在特定突发事件、常规事件或问题发生时执行操作系统命令（包括脚本）和PL/SQL过程等操作。
此功能可帮助您实现IT实践自动化。
例如，当发生数据库运行状态更改（正常/故障）等事件时，通知系统可以使用一个操作系统脚本自动打开内部故障单，以确保相应的IT人员可及时响应。
通过使用简单网络管理协议(SNMP)陷阱，针对OracleEnterpriseManager中发布的事件（例如特定量度超过阈值），OracleEnterpriseManager通知系统还可以让您将陷阱发送给支持SNMP的第三方应用（例如HPOpenView和BMCRemedy）。
通过OracleEnterpriseManager管理补丁 OracleDatabaseLifecycleManagementPack支持整个补丁管理生命周期，包括补丁建议、部署前分析、部署和报告。
它与MyOracleSupport相集成，提供可用补丁和推荐补丁的同步视图。
然后，可在部署前对这些补丁进行冲突分析。
接下来，用户可以在一个停机时间窗口内对多个数据库应用多个补丁。
补丁部署过程由于采用了高级技术（如RAC滚动打补丁和异地打补丁）而最大限度简化了操作和缩短了停机时间。
变更活动计划程序(CAP)让您可以计划、管理和监视涉及相关性、所有者协调以及多个进程的复杂操作。
这些操作包括每个季度定期部署安全补丁、根据业务需要搭建新服务器、迁移或整合数据库中心以及在整个环境中推广合规性标准。
CAP支持管理员完成以下任务•计划更改活动，包括设置开始和结束日期以及创建、分配和跟踪任务状态。
61 •使用自动化任务分配和完成支持来管理大量任务和目标。
•使用仪表盘监视计划潜在的延迟并快速评估总体计划状态。
•让任务所有者使用自己仪表盘上基于优先级或计划的视图管理自己的任务。
OracleEnterpriseManager中的配置合规性 虽然强大的SYSMAN帐户可用于遍历合规性框架，但Oracle可以通过细粒度权限来控制谁能查看结果和执行特定操作，因此支持职责分离。
下列权限和角色可用于管理对配置标准的访问： 权限CREATE_COMPLIANCE_ENTITYFULL_ANY_COMPLIANCE_ENTITYVIEW_ANY_COMPLIANCE_FWKMANAGE_TARGET_COMPLIANCEVIEW 描述创建合规性标准、规则和实时监视Facet管理合规性标准和合规性标准规则查看合规性框架定义和结果将合规性标准与目标相关联查看单一目标 角色EM_COMPLIANCE_DESIGNER EM_COMPLIANCE_OFFICER 描述 创建、修改和删除合规性标准、合规性标准规则及实时监视Facet。
查看合规性框架定义和结果。
62 更多信息 安全信息门户 •Oracle数据库安全•Oracle技术网上的数据库安全主题 Oracle产品文档 •Oracle数据库文档•Oracle数据库安全指南•OracleAuditVaultandDatabaseFirewall•OracleAdvancedSecurity•OracleDatabaseVault•OracleLabelSecurity•OracleDataMasking 63
如需联系销售代表，请访问上的ContactUs（联系我们）页面。
保护OracleDatabase12c：技术入门 版权所有©2014，McGraw-HillEducation（出版商）。
保留所有权利。
在美国印刷。
除1976年美国版权法许可外，未经出版商事先书面许可，不得以任何形式或任何方式复制或分发本出版物，或者将其存储在数据库或检索系统中，但程序清单例外。
虽然程序清单可以在计算机系统中输入、存储和执行，但不得用于复制出版。
Oracle是OracleCorporation和/或其关联公司的注册商标。
所有其他商标是其各自所有者的商标，McGraw-HillEducation并不对所提及的包含这些标志的产品声明所有权。
本文档中转载的受版权保护的Oracle软件程序的屏幕截图均经过OracleCorporation和/或其关联公司的许可。
ISBN978-0-07-182617-4MHID0-07-182617-
3 策划编辑PaulCarlstroem 编辑部主任PattyMon 组稿协调员AmandaRussell 编审MargaretBerson 校对PaulTyler 发行主管JeanBodeaux 美术总监，封面JeffWeeks 出版商所获信息均来自可靠来源。
然而，由于我们的消息来源、出版商或其他环节可能存在人为或机械错误，因此出版商不对本文档中任何信息的准确性、妥善性或完整性作任何保证，并且不对任何错误或遗漏以及使用此信息带来的任何结果负责。
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是一家行业联盟和标准组织，致力于通过批量生产的标准化安全硬件来增强系统安全性。
序言 20世纪90年代初，接入互联网的数据库寥寥无几，当时的互联网肯定无法与现在同日而语。
当时，我们安全技术的用户主要是关注数据分类和多级安全性的政府和国防机构。
合规性法规更是少之又少。
当时还没有支付卡行业数据安全标准(PCI-DSS)，HIPAA也仅仅是初具雏形。
如果DBA希望窃取大量信息（当时，数百MB就是非常“大”的量了），他们需要携带一个有几块建筑用砖那么大、那么重的磁盘驱动器。
除了Oracle的多级安全解决方案外，我们客户群中采用比较广泛的数据库安全特性包括自主访问控制和数据库角色。
当时甚至不需要考虑内部人员、有组织犯罪、黑客和SQL注入带来的数据威胁。
主要的安全需求就是使用权限、角色和视图实施“按需知晓”原则。
我1993年加入Oracle时，所有数据库的用户群必然是有限的—当时还是采用客户端-服务器计算模式的时代，与运行数据库的机器相比，数据库显然比较小；有权访问数据库的用户数量也非常少。
大多数用户基本上都不需要考虑数据库安全性。
在一些应用中，SQL注入被认为是可以接受的。
事实上，我还记得在OracleForms中通过SQL注入修改查询是多么简单。
当然，由于大多数应用采用的都是客户端-服务器模式，因此这并不是什么大问题，因为应用用户需要使用自己的个人凭证来连接数据库，而不是当今应用所采用的单一大应用用户模型(OneBig-ApplicationUserModel)。
如今的世界已经大为不同。
DBA可以在外形尺寸和重量比手机还小的设备上轻松处理TB级的信息。
据统计，特权帐户和SQL注入是访问敏感信息的首选方式。
隐私与合规性要求几乎已渗透至全球的各行各业。
客户必须定期通过各项法规的审查，包括Sarbanes-Oxley法案、欧盟数据保护指令、中国的个人信息保护指南以及日本的APPI。
如今，三层软件架构已成为行业标准，能够访问一些级别应用数据的用户群非常巨大，通常至少数以千计。
如果您不想因用户个人信息被盗而上新闻头条，那么保护您的数据和基础设施已成为一项首要需求。
安全性与高可用性和可扩展性同等重要。
设计新应用时，从一开始就必须考虑安全性，而且要贯穿生命周期开发过程的每个阶段。
鉴于此，《保护OracleDatabase12c：技术入门》一书应运而生。
本书的三位作者在数据安全领域拥有数十年的工作经验，更重要的是，他们在Oracle数据库安全领域也拥有数十年的工作经验。
iv 本书由浅入深，首先介绍如何控制授权用户的访问。
这包括通过实施“最低权限”来防止受信任的DBA或其他未经授权的人员实际或者象征性地带走TB级的敏感信息。
数据库中的每个用户以及每种应用模式都应该具有完成工作所需的一组最小的授权和权限—我们将看到如何实现这一目标并了解其如此重要的原因。
全面介绍访问控制之后，本书将探讨发生失窃时如何保护数据；即使所有访问控制均被破坏的情况下如何保护数据。
本书将介绍数据加密的概念，并讨论如何在多个层面上实现数据加密。
接下来，本书将探讨一些更高级的访问控制方法，例如列级和行级访问控制。
这将不再局限于简单的表和系统权限。
随后，本书将介绍一个相关的安全特性：审计。
我们将探索数据库的审计功能以及如何主动使用这些功能，而不是将其用作事后诊断工具。
接下来，本书将讨论SQL注入。
SQL注入可能是最普遍的数据库攻击方式。
SQL注入利用已开发的应用代码中的漏洞，与数据库无关。
由于应用代码比数据库代码要多得多，而且大多数应用代码在编写过程中都没有考虑SQL注入的问题，因而许多应用易受攻击。
在互联网上搜索“SQL注入”将返回数百万条新闻，其中许多新闻的内容都是某公司最近遭受攻击，导致敏感客户数据泄漏。
本书将探讨数据库和安全专业人员如何在应用与数据库之间添加一个防护层，进而削弱外部人员成功发起SQL注入攻击的可能性。
最后，本书将介绍如何实现合规性。
1993年，一家公司运行10个甚至100个Oracle数据库就算“很多”了。
20年后，运行成千甚至上万个Oracle数据库的公司早已司空见惯。
企业必须确保所有这些数据库都安装了最新补丁并且完成了安全配置。
验证检查是一项繁琐甚至难以完成的工作，但如果采用适当的方法和工具则另当别论。
本节将介绍这方面的信息。
您将了解如何验证和确认系统配置的合规性，以确保数据库环境是采用安全的、经过验证的方式搭建的。
如果您对安全性—具体来说，为Oracle数据库提供安全防护—感兴趣的话，本书将非常适合您。
尽管本书使用OracleDatabase12c作为书名的一部分，但其中大多数内容适用于OracleDatabase9i及更高版本。
ThomasKyte/ v 致谢 作者诚挚感谢以下人员在本手稿的编制和审查过程中提供的宝贵帮助：TroyKitch、MelodyLiu、VikramPesati和JamesSpooner。
vi 引言 为重要信息提供安全防护很不幸成为全球任何组织都需要面对的一个问题。
我们不断在新闻中看到黑客通过攻击获取了某公司的敏感数据并给该公司造成了重大法律、经济和声誉损失。
即便绝大多数敏感数据都存储在关系数据库中，大多数组织的信息安全措施也很少侧重于这些数据库的安全性。
尽管许多技术和产品可以通过各种方式提高数据库的安全性，但我们需要的是采用简要而全面的方式概述所面临的主要威胁以及解决这些问题的相应技术。
攻击者可能会利用一切可利用的弱点，包括数据库未正确配置安全控制、操作系统未安装补丁以及用户帐户被盗用。
此外，还有一些更间接的方法，例如SQL注入或在网络上拦截数据。
真正安全的数据库系统防护需要考虑攻击者可能利用的一切漏洞。
本书中的每一章将介绍一类威胁，不过这些威胁都是息息相关的。
没有一种解决方案可以防范所有攻击方式，各种安全机制是相辅相成的。
纵深防御是有效应对已知和未知威胁的唯一途径。
我们首先介绍数据库中可用的安全特性。
•第一章：控制数据访问和限制特权用户介绍验证用户身份以及控制其可访问 的数据的基本概念。
本章涵盖如何确定每个用户所需访问权限以及如何限制高权限用户的最佳实践。
•第二章：防止直接访问数据阐述如何通过加密来防止试图绕过上一章中介绍的访问控制机制直接访问数据的攻击。
•第三章：高级访问控制阐述如何通过更高级的访问控制机制实现更精准的控制。
这些机制包括虚拟专用数据库、OracleLabelSecurity和RealApplicationSecurity。
•第四章：审计数据库活动阐述如何维持有效的审计跟踪，这是一项重要的纵深防御技术，可检测特权用户的权限滥用以及前述章节中实施的安全策略的意外违规情况。
随后，我们还将探讨如何引入外部组件来提高数据库及其存储的数据的安全性。
•第五章：控制SQL输入阐述如何使用专业的数据库防火墙监视访问数据库的SQL语句。
这有助于防范Web用户对数据库发起的SQL注入攻击。
vii •第六章：屏蔽敏感数据阐述如何采用数据屏蔽技术从用于测试或开发的数据中删除敏感信息。
本章还探讨如何采用数据编辑功能动态屏蔽针对生产数据库的查询结果。
•第七章：验证配置合规性阐述根据行业认可的标准评估数据库配置的必要性，以及如何通过相应的评估工具来确保持续合规性。
在本书中，我们将重点介绍OracleDatabase12c的新特性。
不过本书中介绍 的大多数解决方案也适用于更早版本的OracleDatabase。
viii 第一章 控制数据访问和限制特权用户 数据库系统安全防护领域最重要的任务就是确定用户对数据的访问权限。
本章介绍用户帐户管理以及如何确定每个用户的访问权限。
随后，本章将探讨用户的特权访问类型以及可通过哪些工具删除用户不需要的访问权限。
用户管理 针对数据库的所有访问都是由用户发起的，无论是管理用户、应用帐户还是普通用户。
由于用户可以直接连接到数据库，因此有必要对他们进行适当的身份验证，确保他们拥有适当的角色，并确保其帐户不会轻易受到攻击。
此外，还需要确保对其可使用的资源加以限制，否则将对数据库的其余部分造成间接影响。
CREATEUSER语句用于创建数据库用户及其相关模式。
在下面的例子中，通过密码来识别用户，该帐户将遵循_profile中的策略。
CREATEUSERjsmithIDENTIFIEDBYNoOne!
Knows_profileDEFAULTTABLESPACEdata_tsTEMPORARYTABLESPACEtemp_ts; 配置文件指定了一系列资源限制和密码参数，用于限制过度使用系统资源并对密码加以限制。
可通过密码相关参数进行密码管理，包括帐户锁定、密码老化、密码历史和密码复杂性验证。
密码验证功能或许是确保用户选择复杂密码的最重要的控制措施，旨在防止入侵者破解用户密码。
FAILED_LOGIN_ATTEMPTS参数可设定在登录失败达指定次数后锁定帐户，从而防范攻击者对密码进行暴力破解。
1 CREATE_profileLIMIT FAILED_LOGIN_ATTEMPTS6 --attemptsallowedbeforelocking PASSWORD_LIFE_TIME180 --maxlife-timeforthepassword PASSWORD_VERIFY_FUNCTIONora12c_verify_function;--Password complexity check DBA_USERS和DBA_PROFILES字典视图分别用于描述用户和配置文件。
用户创建权限只能分配给DBA或安全管理员。
应为每个用户分配一个表空间；否则，他们创建的任何对象都将进入SYSTEM表空间，从而导致数据字典对象与用户对象相冲突。
OracleMultitenant数据库用户 OracleDatabase12c的OracleMultitenant选件包括通用用户和本地用户。
通用用户是在容器数据库中创建的，在该容器数据库的所有可插拔数据库中均采用相同的用户名和密码。
通用用户除了具有容器层面授予的权限，还可以具有每个可插拔数据库中授予的其他权限。
每个可插拔数据库中的权限可能不尽相同，不过不需要在每个可插拔数据库中创建通用用户。
如需为容器数据库和所有可插拔数据库创建通用用户，请以SYSTEM身份登录容器数据库并使用CONTAINER=ALL参数创建用户。
请注意，所有通用用户都使用C##作为其名称的前缀。
SQLPLUS>CONNECTSYSTEM@rootEnterpassword:**********Connected.SQLPLUS>CREATEUSERC##DB_ADMINIDENTIFIEDBYIronMan4CONTAINER=ALL; 另一方面，本地用户是在可插拔数据库中创建的，不具备访问容器的权限。
这将帮助管理员更好地管理可插拔数据库，但是不能用于管理整个系统。
如需
2 创建本地用户，请使用SYSTEM身份连接至可插拔数据库，像往常一样授予必要的角色和权限，然后指定CONTAINER=CURRENT而不是CONTAINER=ALL。
SQLPLUS>CONNECTSYSTEM@pdb1Enterpassword:*********Connected.SQLPLUS>CREATEUSERpdb1_adminIDENTIFIEDBYSpiderMan3CONTAINER=CURRENT; 存储密码 用户连接数据库时需要提供密码，但应用、中间层系统和批处理作业不支持手动输入密码。
过去，提供密码的一种常用方法是在代码或脚本中嵌入用户名和密码。
这不仅会导致攻击面扩大，而且相关人员还需要确保其脚本未向其他人公开。
此外，如果密码经过修改，则脚本也需要进行相应的修改。
现在，您可以使用客户端Oracle钱夹存储密码凭证。
这样，密码就不会再出现在命令行历史记录中，密码管理策略也更容易实施，用户名或密码发生更改时也无需修改应用代码，最终有助于降低风险。
要使用Oracle钱夹配置密码存储，请设置.ora文件中的WALLET_LOCATION参数。
之后，应用在连接数据库时便无需提供登录凭证，如下所示： CONNECT/@hr_ 身份验证方式 用户需要先经过身份验证，然后才能连接数据库。
Oracle支持各种不同的身份验证方式，包括将密码存储在本地的数据库或目录中。
还可以由操作系统验证用户身份，这需要在创建用户时使用IDENTIFIEDEXTERNALLY子句，也可以由Kerberos、SSL/TLS和RADIUS等第三方服务来完成身份验证。
密码仅用于在用
3 户连接至数据库时的单向身份验证，而Kerberos和PKI支持双向身份验证，可确保用户连接至正确的数据库。
基于SSL/TLS进行通信的Oracle客户端和服务器必须拥有一个包含X.509证书、私钥和受信任证书列表的钱夹。
要完成此配置，管理员需要使用OracleWalletManager创建用于存储PKI凭证的钱夹，并使用OracleNetManager配置SSL身份验证所使用的.ora和listener.ora。
以下示例显示如何使用PKI证书创建用户： SQL>CREATEUSERjsmithIDENTIFIEDEXTERNALLYAS=jsmith,OU=HR,O=oracle,c=US'; 用户可以在支持Kerberos的环境中使用该服务验证数据库身份。
要配置此功能，请使用OracleNetManager在Oracle数据库服务器和客户端的.ora文件中设置必要的参数。
以下示例显示如何创建一个与Kerberos用户对应的、采用外部身份验证的用户： SQL>CREATEUSERjsmithIDENTIFIEDEXTERNALLYAS'jsmith@'; 现在，您无需提供用户名或密码便可连接至Oracle数据库服务器，如下所示： $sqlplus/@hr_; 集中用户管理 在一个企业中，如果有大量用户需要访问大量数据库，那么管理每个数据库中每个用户的唯一帐户就变得非常困难。
OracleEnterpriseUserSecurity(EUS)可在OracleDirectory中集中管理多个数据库的用户和角色，并且OracleDirectory将与MicrosoftActiveDirectory等目录相集成。
此类用户被称作企业用户，为他们分配的企业角色将确定对多个数据库的访问权限。
企业角色包括一个或多个全局角色，每个全局角色授予对特定数据库的访问权限。
4 EUS可通过OracleDirectory借助密码、Kerberos或SSL对用户和管理员进行身份验证。
连接时，数据库会从该目录中获取用户身份验证、授权（角色）信息和模式映射。
企业用户可以有自己的模式，也可以与所访问的数据库共享全局模式。
以下示例展示了一个采用独占模式的企业用户jsmith。
CREATEUSERjsmithIDENTIFIEDGLOBALLYAS'CN=jsmith,OU=HR,O=oracle,C=US'; 具备管理权限的用户 某些用户可以使用特殊的管理权限（如SYSDBA和SYSOPER）连接数据库，这样便可在不打开数据库的情况下执行维护操作。
这些用户可以使用基于网络的身份验证服务（如OracleDirectory）执行身份验证，也可以根据连接用户是否属于特定操作系统用户组来执行身份验证。
如果用户以管理权限连接时必须用密码来进行身份验证，那么该密码必须存储在数据库外部的密码文件中，该文件可通过orapwd命令进行管理。
该密码文件不支持用户管理功能，例如在多次登录失败后锁定帐户。
不过，当数据库运行时，每次登录失败都会产生延迟，从而在一定程度上限制密码破解。
代理身份验证和授权 有时，管理员需要连接应用模式来执行维护。
多个管理员共享应用模式密码将无法确保责任界定。
而代理身份验证可以让管理员先使用自己的凭证进行身份验证，然后再通过代理连接至应用模式。
在这种情况下，审计记录将显示执行维护活动的实际用户。
OracleCallInterface(OCI)、JDBC和SQL*PLUS命令行均支持这种代理身份验证。
以下示例允许app_dba用户连接至数据库后使用hrapp身份执行操作。
ALTERUSERhrappGRANTCONNECTTHROUGHapp_dba;
5 现在，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字典表显示所授予的对象权限。
其中包括对象的详细信息，包括模式所有者以及所授予的权限。
该表可用于报告权限和管理权限级别。
6 SQL>SELECTGRANTEE,OWNER,TABLE_NAME,PRIVILEGE FROMDBA_TAB_PRIVS WHEREGRANTEE='JSMITH'; GRANTEE OWNERTABLE_NAME PRIVILEGE ------------------------------------ JSMITH HR DEPARTMENTSSELECT JSMITH HR ADVENTURES SELECT JSMITH HR ADVENTURES INSERT JSMITH HR ADVENTURES DELETE JSMITH HR ADVENTURES UPDATE JSMITH HR ADD_DEPARTMENTEXECUTE 当不再需要某个对象上的权限时，应予以撤销。
SQL>REVOKEDELETEONhr.adventuresFROMjsmith; 系统权限和角色 对象权限可以非常精细地控制用户可以访问的数据，不过管理员有时可能需要访问多个对象。
系统权限允许访问特定类型的所有对象；例如，SELECTANYTABLE允许用户对任何模式中的任何表执行SLECT操作，EXECUTEANYPROCEDURE允许执行任何PL/SQL过程或函数。
其他系统权限适用于不涉及特定对象的操作，如创建对象、用户和角色；更改会话和系统参数；以及导出和导入数据库。
可以看出，这些权限令管理员执行的操作可以影响多个模式和对象。
另外一个方便的权限管理特性可将多个对象权限和系统权限归到一个角色中。
当需要为多个用户授予一组相同的权限时，角色将派上用场。
角色比单独的权限更易于管理，并且可与应用或工作职能相匹配。
可以将一些角色授予其他角色，这样便可通过一些小权限角色建立DBA这样的大权限角色。
与对象权限的GRANT选项类似，系统权限或角色也支持ADMINOPTION，该选项允许接收者将该角色或权限授予其他人。
7 下表中的字典表显示授予每个用户或角色的角色和权限。
例如，从这些表中可以看出，DBA是一个非常强大的角色，具备200多项系统权限，包括CREATE和ALTERSESSION；CREATE和ALTERANYTABLE；SELECT、INSERT、UPDATE和DELETEANYTABLE；EXPORT和IMPORTFULLDATABASE；DROP和CREATETABLESPACE；EXECUTEANYPROCEDURE以及十几个角色。
字典表DBA_TAB_PRIVSDBA_SYS_PRIVSDBA_ROLE_PRIVSDBA_ROLES 内容授予角色或用户的对象权限授予角色或用户的系统权限授予用户或其他角色的角色所有定义的角色 最小权限和职责分离 最小权限原则是指应为该系统的每个用户仅授予完成其预定任务或职能所需的最小一组权限。
授予用户或角色权限时，最好授予所需的特定对象权限，而不是授予允许访问数据库中所有对象的广泛系统权限。
同样，创建角色时应仅包含完成特定职能所需的少量权限，而不是创建像内置的DBA角色这样非常强大的角色。
授予用户一些小权限角色可确保用户与所需完成的任务相匹配，而不必授予过多不需要的权限。
职责分离的理念与最小权限原则密切相关。
具体来说，应让多个用户承担不同权限，而不是创建一个超级用户。
采用这种方式划分管理权限可加强责任界定，而且还可避免受信任的管理员滥用权限。
为了支持最小权限和职责分离原则，Oracle数据库很早就引入了SYSOPER管理权限，允许管理员执行启动和停止数据库等特定任务，而无需授予其SYSDBA的完全权限。
OracleDatabase12c新增的管理权限包括SYSBACKUP、SYSDG和SYSKM，分别用于支持数据库备份、DataGuard管理和密钥管理。
有了这些针对性的权限，管理员无需全能的SYSDBA权限也可执行管理数据库所需的一切常规操作。
8 控制特权用户 系统权限和强大的角色可对数据库进行高度控制，包括查看所有数据和更改数据。
一些管理用户需要使用这些强大的权限来执行维护、调优和备份，不过他们并不需要访问全部数据。
即使有管理权限的用户是可以信赖的，但也有必要限制这些特权帐户对公司数据资产和个人信息的访问，以防止内部用户或攻击者的非授权使用。
OracleDatabaseVault在数据库中提供了一些操作控制，包括通过领域来限制对表和视图等特定对象的访问。
创建DatabaseVault领域之后，向其中添加一些对象，并且可以将数据库用户指定为领域参与者。
这样只赋予领域参与者访问权限，其他用户被排除在外，即使他们拥有SELECTANYTABLE这样强大的系统权限也不能访问该领域中的对象。
下图显示了如何通过两个领域来保护包含人力资源(HR)和财务(FIN)数据的数据库模式。
领域一经启用，就会阻止特权管理用户或其他应用所有者使用其高级权限访问数据。
特权应用所有者HR无法访问FIN领域中的数据，甚至具有DBA角色的管理员也无法访问HR和FIN领域中的数据。
9 除了常规领域外，OracleDatabase12c还支持创建强制领域。
常规领域将阻止非领域参与者使用SELECTANYTABLE等系统权限访问数据，但是无法阻止模式所有者或其他用户使用对象权限访问领域中的数据。
强制领域将阻止所有非领域参与者访问领域中的数据。
强制领域的一种常见应用是在安装补丁和升级期间继续保护敏感数据，即当管理员需要修改应用模式但不应访问该模式中的数据表时。
配置OracleDatabaseVault的过程中会创建另外两个用户。
第一个用户是DatabaseVault所有者，他可以创建和管理领域以控制对敏感数据的访问。
第二个用户是DatabaseVault帐户管理员，负责在数据库中创建用户。
虽然一个用户就能完成这两项职能，但将这些职责划分给多个用户可以实现之前介绍的职责分离。
而且，通过将DVOWNER角色授予其他用户可将管理DatabaseVault领域的职责委派给他人。
应将该角色授予负责数据库安全配置的管理员，而不是普通的数据库管理员。
下图显示了如何使用DatabaseConfigurationAssistant启用OracleDatabaseVault。
管理DatabaseVault需要使用这些专门的用户和角色。
启用DatabaseVault后，SYSDBA管理权限将不适用于领域或用户管理。
10 管理授予的权限 最小权限原则是指每个用户以及授予用户的每个角色应只具备执行预定职能所需的一组最小权限。
虽然字典表显示1字符了已授予的权限和角色，但很难确定哪些权限是真正需要的。
系统使用了一段时间后，此问题尤为明显，因为权限和角色授予往往会累积，所以很难确定何时撤销才是安全的。
OracleDatabaseVault12c新增的“权限分析”特性捕获运行时使用的权限并生成一系列报告。
可以使用这些报告查找可能不再需要的权限，甚至生成自动撤销未用权限的脚本。
11 以下示例显示了如何为数据库的所有用户启用权限捕获。
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/SQLprocedurepleted. 捕获正常运行过程中使用的权限之后，经过适当的时间间隔，DBA_USED_PRIVS和DBA_UNUSED_PRIVS视图将显示哪些权限已被使用，更重要的是，还将显示哪些授予的权限未被使用。
SQLPLUS>BEGINDBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT(NAME=>'dba_capture_all_privs');end;/PL/SQLprocedurepleted.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; 以下视图可显示权限捕获所生成的信息。
12 视图DBA_PRIV_CAPTURESDBA_USED_PRIVSDBA_UNUSED_PRIVSDBA_USED_OBJPRIVSDBA_UNUSED_OBJPRIVSDBA_USED_OBJPRIVS_PATHDBA_UNUSED_OBJPRIVS_PATHDBA_USED_SYSPRIVSDBA_UNUSED_SYSPRIVSDBA_USED_SYSPRIVS_PATHDBA_UNUSED_SYSPRIVS_PATH DBA_USED_PUBPRIVS DBA_USED_USERPRIVSDBA_UNUSED_USERPRIVSDBA_USED_USERPRIVS_PATHDBA_UNUSED_USERPRIVS_PATH 描述列出现有权限分析策略的相关信息。
以所报告的权限分析策略为基准，列出已使用（未使用）的权限。
以所报告的权限分析策略为基准，列出已使用（未使用）的对象权限。
列出已用于（或未用于）所报告的权限分析策略的对象权限。
其中包括对象权限授予路径。
列出已用于（或未用于）所报告的权限分析策略的系统权限。
列出已用于（或未用于）所报告的权限分析策略的系统权限。
其中包括系统权限授予路径。
列出已用于所报告的权限分析策略的PUBLIC角色的所有权限。
列出已用于所报告的权限分析策略的用户权限。
列出已用于所报告的权限分析策略的用户权限。
其中包括用户权限授予路径。
13 第二章 防止直接访问数据 上一章介绍了如何配置Oracle数据库控制用户对数据的访问权限。
配置这个由数据库实施的访问控制是非常重要的，可确保只有相关人员能够访问所需的数据，其他人员则无权访问这些数据。
当然，攻击者并不会只盯着防御最强大的环节；如果附近有一扇开着的窗户，他们显然不会反复尝试打开上锁的前门。
如果为数据库正确配置了数据访问控制，那么攻击者自然会尝试绕过坚固的数据库，转而选择其他攻击目标。
一种途径是用特权操作系统用户（如root或oracle）的身份获取系统访问权限。
此类用户可以更改数据库程序的行为，令其忽略已配置好的访问控制设置。
针对此类攻击的最佳防范措施是阻止攻击者获取对主机系统的访问权限，例如遵从互联网安全中心发布的操作系统强化指导准则。
另一条攻击路线是绕过数据库直接读取或写入数据，包括磁盘文件存储中的数据以及通过网络在两个系统之间传输的数据。
这两种情况下均可通过加密技术为数据提供有效防护。
这样一来，用户只需注意加密密钥的安全性即可，而不必再为保护大量数据费神。
只要攻击者没有密钥，他们就无法从任何加密数据中截获有用信息。
而且，加密还是一些关于敏感或个人身份信息的法规和安全标准的强制要求。
本章将阐述如何配置和使用加密来保护静止数据和传输中的数据。
此外，本章还将介绍安全存储用于保护加密数据的加密密钥时的注意事项和选项。
14 静止数据 当信息写入数据库时，它最终将存储在磁盘文件中。
为了确保攻击者无法直接从磁盘文件中读取信息，每个应用在将数据存储到数据库中之前都应对数据进行加密。
然而，这需要额外的编程工作来确保应用在存储数据前进行加密并将其检索到的数据解密。
此外，应用还需要管理加密密钥并将其存放在安全的位置。
如果多个应用共享同一数据库中的信息，那么它们需要合作来加密和解密数据。
为了简化这一过程，Oracle在OracleAdvancedSecurity中引入了透明数据加密(TDE)。
数据库会在数据写入磁盘之前自动执行加密并在从磁盘中读取数据时自动执行解密，因此整个加密过程是透明的。
在数据库中存储和检索数据的应用只能看到解密后的数据或纯文本数据。
由于加密和解密是自动进行的，所以这并不是针对Oracle数据库用户的访问控制机制，而是一种防止用户绕过数据库直接访问数据的方法。
用户和应用使用SELECT语句检索数据时不用提供解密密钥。
而是由数据库实施上一章中介绍的访问控制规则，并拒绝未经授权的用户查看数据。
如果允许访问，则会在返回数据之前自动执行解密。
无论是否允许访问，永远都不会将加密数据返回给用户。
配置透明数据加密时，需要指定要加密的数据，然后再设置一些关于加密执行方式的选项。
指定加密数据时可以选择列加密（即对特定表中的特定列进行加密）和表空间加密（对特定表空间中所有表中的所有列进行加密）。
通过设置列的ENCRYPT属性可指定列加密，如下例所示。
如果只有几列包含需要保护的敏感信息，且这些列仅占数据库数据总量的一小部分，那么列加密是最理想的方案。
针对这种情况，一种比较高效的方法是仅产生敏感列的加密和解密开销，将其余数据存储为纯文本形式。
此外，还可以随时使用ALTERTABLE命令对现有数据应用此方法。
15 CREATETABLEemployee(first_nameVARCHAR2(128),last_nameVARCHAR2(128),empIDNUMBER,salaryNUMBER
(6)ENCRYPT ); 然而，在大多数用例中，表空间加密可提供一些引人注目的优势。
对整个表空间执行加密便无需确定哪些数据很重要需要保护，哪些不需要保护。
而且，这还将确保敏感数据不会因失察或要求变化而意外泄漏。
一些现代硬件在CPU中内置了专用于加速加密操作的特殊指令，在其上运行数据库时，对所有数据进行加密的性能开销几乎可以忽略不计，因此无需就哪些数据需要保护进行决断。
在创建表空间时配置表空间加密，如下所示： CREATETABLESPACEencrypt_tsDATAFILE'$ORACLE_HOME/dbs/encrypt_df.dbf'SIZE100MENCRYPTIONUSING'AES128'DEFAULTSTORAGE(ENCRYPT); 传输中的数据 攻击者绕过数据库直接访问数据的另一种途径是截取网络上传输的数据，例如在客户端与数据库服务器之间传输的数据。
在许多网络上，攻击者都可以相当轻松地捕获发往其他系统的网络流量，然后提取两个系统之间传输的信息。
鉴于此，不仅需要对磁盘上存储的数据加密，而且有必要对通过网络发送的数据加密。
16 使用SSL或Oracle原生加密对网络上的数据加以保护过去是AdvancedSecurity选件的一个特性，不过现在已成为Oracle数据库的一个标准特性。
可将此特性配置为同时提供加密（防止其他人读取通过网络发送的数据）和完整性保护（防止其他人修改或重放数据）。
每个Oracle客户端和服务器的网络数据保护设置均在.ora文件中配置。
每个系统的适用设置包括所支持的加密算法列表以及下面列出的四个加密和完整性保护选项中的一个。
根据这些设置，两个系统在建立连接时会协商确定是否启用加密和/或完整性保护，以及使用哪种加密算法。
•REJECTED系统不会启用此服务（无论是加密还是完整性保护）。
如果其他系统需要此服务，连接将失败。
•ACCEPTED系统不会请求启用该服务，但会在其他系统请求时表示同意。
•REQUESTED系统会请求启用该服务，不过当其他系统拒绝时，它会以未 启用服务的形式建立连接。
•REQUIRED系统会请求启用该服务。
如果其他系统拒绝，连接将失败。
密钥管理和存储 现代加密系统并不依赖秘密加密算法来保证数据的安全。
专业密码学家很久以前就发现，采用众所周知的且弱点经过专家仔细研究的算法会更安全。
这一事实的实际意义在于，受保护数据的安全性完全取决于加密密钥的保密性。
适当的密钥管理是必不可少的，可以防止攻击者破解或猜出密钥并获取受保护数据的访问权限。
17 管理员使用一系列SQL命令或者通过一个管理界面调用这些命令，执行Oracle数据库所需的所有密钥管理操作。
OracleDatabase12c新增的一个选项让用户能够以SYSKM身份（而非SYSDBA身份）连接数据库，然后执行密钥管理操作。
此处遵循了上一章中介绍的最小权限原则，SYSKM管理权限仅支持用户执行所有密钥管理任务，而不具备SYSDBA的超级权限。
OracleDatabase12c还在ADMINISTERKEYMANAGEMENT语句中引入了一组统一的密钥管理命令。
该语句支持所有密钥管理操作，这些操作以前需要结合使用orapki实用程序与ALTERSYSTEM语句才能完成。
以下示例显示了新命令的使用。
ConnectusingtheSYSKMadministrativeprivilege.sqlplususer/passwordASSYSKM CreateanewOraclewallet.SQL>ADMINISTERKEYMANAGEMENT CREATEKEYSTORE'keystore_location'IDENTIFIEDBYkeystore_password; OpenanOraclewallet.SQL>ADMINISTERKEYMANAGEMENT SETKEYSTOREOPENIDENTIFIEDBYkeystore_password; MakeabackupcopyofanOraclewallet.SQL>ADMINISTERKEYMANAGEMENT BACKUPKEYSTOREIDENTIFIEDBYkeystore_passwordTO'backup_location'; SetorrotatetheTDEmasterencryptionkey.SQL>ADMINISTERKEYMANAGEMENT SETENCRYPTIONKEYIDENTIFIEDBYkeystore_password; 18 密钥管理最重要的一个环节是将密钥存放在安全的位置。
Oracle数据库和其他Oracle产品均采用一个被称作“钱夹”的特殊文件存储加密密钥和其他机密数据。
当有人打开钱夹访问其中的密钥时，会使用由用户必须提供的密码派生的密钥对钱夹的内容进行加密。
用于加密钱夹的密码不会随意存放，从而确保攻击者一无所获。
当然，如果用户丢失或忘记密码，则无法打开钱夹或访问使用该钱夹加密的数据。
通常，使用TDE的Oracle数据库将主密钥存储在一个Oracle钱夹中，该钱夹会在数据库启动时打开。
然而，在某些安装中，让管理员在数据库启动时提供钱夹密码并不可行。
针对这种情况，可以为Oracle钱夹配置一个“自动登录”选项，这样数据库不使用密码也可打开钱夹。
尽管这时钱夹中的内容仍然处于加密状态，但却无法提供与常规的密码保护的钱夹同等级别的保护。
仅当可通过足够的外部安全措施防止攻击者访问钱夹文件时，才可采用此备选方案。
还有一种方法可以让数据库轻松地访问密钥，同时获得一些额外的安全优势，即将密钥远程存储在一台单独的企业密钥管理服务器上，如OracleKeyVault，数据库将通过网络访问该服务器。
使用SSL等网络协议保护数据库与密钥服务器之间的通信。
这样，密钥服务器还可以自动验证数据库的身份，无需管理员在数据库启动时提供密码。
密钥服务器可集中、安全地备份或复制密钥（可能是组织最宝贵的数据），以确保密钥始终可用。
专门的密钥服务器还可以自动管理每个密钥的生命周期，包括跟踪其创建和所有权、使用密钥的目的以及何时需要轮换或更换密钥。
19 许多法规，比如支付卡行业(PCI)制定的法规，都要求定期轮换加密密钥，从而避免单一密钥泄漏导致数据泄露。
Oracle数据库使用双层架构将密钥轮换的成本降至最低，从而支持更频繁地轮换密钥。
Oracle透明数据加密使用一个存储在钱夹或密钥服务器中的主密钥。
主密钥不会直接对数据进行加密，而是对内部生成的用于执行列和表空间加密的密钥进行加密。
更换主密钥时，无需重新加密所有数据，只需对小得多的一组数据加密密钥重新加密即可。
20 第三章 高级访问控制 第一章阐述了通过有选择地授予对象权限来控制用户数据访问权限的重要性。
用户应该只能访问包含了其执行任务所需数据的表。
然而，即便只授予用户特定表的SELECT或INSERT等对象权限，该权限也支持用户访问该表中的所有数据。
大多数应用的数据库表中所包含的数据远多于任何一个用户需要访问的数据。
举一个简单的例子，考虑SCOTT示例模式中的EMP员工表。
可以让所有用户查看关于员工姓名和部门的基本信息，不过薪酬属于保密信息，包括SAL和COMM列。
同样，组织可能希望限制对表中特定列的访问，可能只允许员工查看所在部门的数据。
在关系数据库中解决这一问题的长期方案是创建一个视图，其中包含一条WHERE子句来根据需要限制访问，仅允许用户访问视图，而不是基础表。
例如，以下视图就只允许访问一个部门中员工的非薪酬信息。
SQL>createorreplaceviewemp_dept20as2selectempno,ename,job,mgr,hiredate,deptno3fromempwheredeptno=20; Viewcreated. SQL>select*fromemp_dept20; EMPNOENAME JOB MGRHIREDATE DEPTNO ---------------------------------------------------------- 7369SMITH CLERK 790217-DEC-80 20 7566JONES MANAGER 783902-APR-81 20 7788SCOTT ANALYST 756619-APR-87 20 21 7876ADAMS CLERK 778823-MAY-87 20 7902FORD ANALYST 756603-DEC-81 20 将视图用于此目的困难在于，用于选择要包括的数据的所有标准都必须嵌入到视图定义中。
尽管可以在WHERE子句中包括子查询，比如通过子查询来确定请求用户的部门编号，但是编写能够准确表达所需策略的SQL查询很快会变得复杂。
常规策略通常还有一些例外情况，比如为HR管理员或部门经理提供更高的权限，这会增加难度。
Oracle数据库通过虚拟专用数据库(VPD)这个特性满足了这一需求。
使用VPD，可以执行管理员提供的PL/SQL函数确保每次访问表时都能生成适当的WHERE子句。
这样一来，用户便可相当轻松地执行确定所允许的访问权限所需的任何计算。
以下清单显示了一个简单的PL/SQL函数，其策略与上一个示例中的视图相同，通过相应的扩展可支持任何部门，并且可为HR管理员提供更高的权限。
functionemp_policy(p_schemainvarchar2,p_tableinvarchar2) returnvarchar2is user VARCHAR2(100); matchNUMBER; my_deptNUMBER; begin --Gettherequestinguser user:=sys_context('USERENV','SESSION_USER'); --CheckifrequestorisanHRemployeeselectcount(*)intomatchfromemp whereename=userandjoblike'HR%';ifmatch>0then return'1=1';--matchallrowsendif; --Findtherequestinguser'sdepartment 22 selectdeptnointomy_deptfromempwhereename=user; return'deptno='||my_dept;end; 最后，VPD还支持其他一些仅凭视图难以实现或无法实现的策略变体。
VPD策略可以包括那些含敏感信息的列，但只允许特定用户访问其内容，其他人则检索到null值。
VPD策略还可以根据用户执行的操作来提供针对不同行的访问权限。
例如，可以通过VPD策略来允许用户查看关于所有员工的信息，但只能更新他们自己的信息。
尽管VPD在确定筛选谓词方面提供了充分的灵活性，但开发人员仍需负责访问控制逻辑以及管理与应用相关的所有规则和约束。
例如，本例中的访问控制就基于JOB和DEPTNO列。
在其他一些情况下，访问控制决策可由特定应用角色控制。
通过数据标签控制访问 要使用上一节中介绍的细粒度访问控制，可以选择为每个数据项添加一个描述其敏感性或重要性的标签。
在许多政府和企业环境中，一些文档可能会标记为“绝密”或“仅限内部使用”，只有具备足够高“权限”的人员才能够访问这些文档。
通常，标签反映了序集级别，每个用户都将获得其权限范围内的最高级别。
该功能让数据库本身知道哪些数据是敏感的，相应地限制对其访问。
为了支持这一通用访问控制模型，OracleLabelSecurity(OLS)简化了为数据和用户分配标签以及根据这些标签实施访问控制的过程。
23 受OLS保护的表中的每行都会通过相应的标签来指示数据敏感性。
可以根据业务逻辑明确地设置每行的标签，不过大多情况下，系统会根据在表中插入行的用户会话的标签自动设置用户标签。
而用户会话的标签是根据各种因素计算得出，包括用户身份、数据库连接类型等。
用户标签可视为对标准数据库权限和角色的扩展。
数据库采用了OracleLabelSecurity后就增强了安全性，不再需要复杂的应用视图。
标签的格式表意丰富，足以支持几乎任意数据库分类方案。
每个标签包括一个级别（从最低到最高），用于表示数据的整体敏感性。
在级别内部，可以选择使用隔间partment)和组组件根据项目、部门或地理区域等属性隔离信息。
与级别组件不同，隔间之间没有排序。
组中可以包括其他组，这样就可以根据地理区域或组织层次结构轻松地表示部门。
图3-1显示了一个使用所有三个标签组件的分类方案。
图3-1：标签的组件当数据和用户会话都有标签时，可以用一组简单的规则来比较标签并确定是否允许访问。
如果用户标签的级别不低于数据标签的级别，并且包含数据标签中指定的所有隔间以及至少一个组（或其中一个组的父组），则用户可以读取表中带标签的行。
使用图3-1中的示例，标签中包括Global组的用户可以访问标签中包含NATO或Europe组的数据。
24 OracleLabelSecurity的主要优势包括灵活性和简化管理。
OLS提供与VPD相同类型的行级访问控制，但无需管理员创建PL/SQL策略函数来实施访问规则。
建立了可以为数据和用户会话分配标签的系统后，访问控制将统一实施，无需确定哪些人能访问各表中的数据。
对应用最终用户应用访问控制策略 目前为止所介绍的方法解决了按数据库用户控制数据访问的问题。
然而，在现代三层应用中，应用最终用户并不与数据库直接交互。
数据库查询和更新通常由代表整个应用的单一数据库用户执行，而不是由各个最终用户执行。
由于数据库对最终用户的身份一无所知，因此必须由应用来实施基于用户的访问控制策略。
除了需要在应用中进行额外的软件开发工作外，这种方法还会导致实施不一致，当一些系统要素可绕过应用直接连接数据库时，此问题尤为突出。
OracleDatabase12c中引入的OracleRealApplicationSecurity(RAS)为数据库提供了下一代应用访问控制框架，支持三层和双层应用在数据库层以声明方式定义、供应和实施访问控制要求。
OracleRAS引入了一个基于策略的授权模型，可识别数据库中的应用级用户、权限和角色，然后控制对表示业务对象的静止和动态记录集的访问。
RAS可将应用最终用户的身份传递至数据库，以便在数据库内部实施访问控制策略。
每个应用最终用户由一个轻量级“应用用户”表示。
与普通数据库用户不同，该应用用户不能用自己的模式存储数据对象，也没有专用的数据库连接。
应用可以创建任意数量的应用用户会话并在它们之间切换，同时仅与数据库建立单一连接。
该应用用户会话允许数据库知晓应用所执行的操作是由哪个最终用户发起的，这样数据库便可实施相应的访问控制策略。
25 与虚拟专用数据库特性一样，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角色的用户。
26 图3-2：有数据安全策略的表OracleRAS支持将应用用户的会话传递给数据库，允许通过应用定义的用户角色和数据操作直接指定数据安全策略。
RAS安全模型允许对业务对象统一指定和实施访问控制策略，无论访问路径为何。
OracleRAS通过对应用数据和操作使用声明式访问控制策略，贴近数据实施了安全防护，为三层和双层应用提供了端到端的安全性。
27 第四章 审计数据库活动 维护活动的审计跟踪是任何数据库纵深防御战略都不可或缺的一个要素。
即使正确配置了访问控制并采用了最小权限原则，仍然存在两个重要的风险。
第一个风险是需要重大权限履行工作职责的用户可能会滥用其权限。
第二个风险是访问控制或权限授予在无意中被配置得高于所需时，用户可能会获得意料之外的访问权限。
审计是检测这些突发事件的主要手段，为最终修复问题奠定基础。
有效的审计要求审计策略能够有选择地从大量事件中捕获重要细节，同时最大限度排除例行活动的干扰。
审计数据需要存储在安全的地方，这样才能确保事件记录的可靠性，特别是无法通过操纵审计数据来隐藏可疑的活动。
最后，还需要通过便捷的方式搜索所收集的审计数据，以查找特定信息或检测异常活动。
独立的Oracle用户组(IOUG)针对Oracle客户开展的调查显示，70%的企业正在对其数据库使用原生审计。
客户审计数据库是否符合SOX、HIPAA、PCIDSS、GLB、FISMA和其他国际标准。
审计提供关于人员、行为和时间的历史记录，让组织能够满足严格的控制和报告要求。
内部治理、本地安全策略和取证报告也带动了对审计的需求。
大多数企业希望能够追溯数据请求或更改、数据库更改、特定事件授权的命令发起方以及此类交互背后的业务理由。
合规性审计人员希望数据库管理员(DBA)及其上级（通常上至CFO和CSO）能够对数据和数据库本身的所有访问和更改作出解释。
28 Oracle数据库提供了业界最全面的审计功能，可捕获事件的详细信息来生成报告和警报。
审计捕获的信息包括数据库名称、主机名称、客户端程序名称、事件时间、事件状态、事件操作、数据库用户、对象所有者以及SQL语句本身等。
可以将审计配置为记录成功和失败的事件。
Oracle数据库还支持更细粒度的审计功能，可在应用表中的特定列被引用时执行审计。
例如，可以对包含信贷限额的表应用这样一条细粒度的审计策略：仅当更新信贷限额列时执行审计。
OracleDatabase12c中的审计功能变动 OracleDatabase12c对之前版本中丰富的数据库审计功能进行了完善，扩充了审计选项并且简化了管理。
OracleDatabase12c审计策略可配置为根据特定IP地址、程序、时间段或连接类型（如代理身份验证）进行审计。
此外，还可以轻松地将特定模式排除在审计之外。
这大大减少了生成的审计记录的数量，并确保在需要时能找到相关审计数据。
OracleDatabase12c审计功能利用策略和条件在Oracle数据库内部有选择地执行有效的审计。
此外，OracleDatabase12c还支持OracleDatabase11g审计语法。
这种“混合模式”支持采用之前审计语法的脚本和工具。
OracleDatabase12c统一审计为以下所有审计来源创建一个审计跟踪： •来自统一审计策略的审计记录（包括SYS审计记录）以及来自DBMS_FGAPL/SQL程序包的细粒度审计记录 •统一审计策略本身的管理•OracleDatabaseVault•OracleLabelSecurity•OracleRecoveryManager •OracleDataPump•OracleSQL*LoaderDirectLoad 29 统一审计跟踪位于AUDSYS模式的只读表中，确保信息以统一格式显示在UNIFIED_AUDIT_TRAIL视图中。
当数据库不可写入时，审计记录会写入到$ORACLE_BASE/audit/$ORACLE_SID目录下的操作系统文件中，然后在数据库变为可写入时再将其加载回统一审计跟踪。
为了与传统DBA职能保持职责分离，OracleDatabase12c引入了两个新角色：AUDIT_ADMIN用于管理策略和审计跟踪，AUDIT_VIEWER用于查看审计数据。
由于不会将这些角色授予DBA角色，所以DBA无法更改审计集合。
只能使用数据库内置的审计数据管理程序包来管理审计数据，不能使用SQLUPDATE或DELETE命令直接更新或删除审计数据。
此外，OracleDatabase12c还提供了一个不能关闭的强制审计活动列表。
这些审计活动包括 •CREATE/ALTER/DROPAUDITPOLICY•AUDIT/NOAUDIT•针对DBMS_FGAPL/SQL和DBMS_AUDIT_MGMTPL/SQL程序包的EXECUTE•针对AUDSYS审计跟踪表的ALTERTABLE（尽管不能更改此表）•在数据库打开前使用的SYSuserorwiththeSYSDBA,SYSOPER, SYSASM,SYSBACKUP,SYSDG,和SYSKMadministrativeprivileges,的顶级权限语句•审计特权用户的操作，直到系统中的审计配置可用为止•针对OracleDatabaseVault的所有配置更改 30 OracleDatabase12c中预定义的审计策略 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,ADMINISTERKEYMANAGEMENTALTERUSER,CREATEROLE,ALTERROLE,DROPROLE,SETROLE,CREATEPROFILE,ALTERPROFILE,DROPPROFILE,CREATEDATABASELINK,ALTERDATABASELINK,DROPDATABASELINK,LOGON,LOGOFF,CREATEDIRECTORY,DROPDIRECTORY; 31
2.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; 32 本例中的策略将监视来自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配置为在传输过程中对数据进行加密。
•管理审计策略 33 •提醒和管理不符合策略的事务•报告和分发即席或计划报告•AuditVaultAgent—基于主机的低影响程序，用于管理所在系统的数据收集并与AV服务器通信。
•审计跟踪—审计数据的来源。
有五种审计跟踪：•数据库审计跟踪，包括Oracle、MicrosoftSQLServer、SAPSybase、 IBMDB2forLUW和MySQL。
它们可以是审计表、审计文件或重做记录。
•操作系统审计跟踪（Linux、Windows、Solaris）•目录服务，如MicrosoftActiveDirectory•文件系统，如OracleACFS•数据库表或XML文件中的自定义审计数据OracleDatabaseFirewall—AVDF的网络组件。
OracleDatabaseFirewall监视网络上的SQL事务，并且可在SQL语句访问数据库服务器之前判定是应该许可、修改、阻止还是替换该SQL语句。
下一章将介绍OracleDatabaseFirewall是如何运作的。
目前我们只需要知道它向AuditVault提供关于其活动的审计数据即可。
图4-1显示了异构网络环境中部署的OracleAuditVaultandDatabaseFirewall和许多审计数据来源。
34 图4-1：OracleAuditVaultandDatabaseFirewall架构 报告和警报 AuditVaultServer具备全面的报告功能，可提供一系列标准的安全报告、即席报告和取证报告。
此外，还有一些现成的不符合策略的审计评估报告，旨在帮助满足PCI-DSS、GLBA、HIPAA、SOX和DPA等标准的要求。
像图4-2中这样的报告可用于监视大量活动，包括数据库服务器上的特权用户活动、对数据库结构的更改以及网络上关于入站SQL语句的数据。
报告可以整合来自数据库、操作系统和目录的审计信息，让您全面了解企业的所有活动。
35 图4-2：整合网络、数据库审计和操作系统事件日志审计人员可以通过控制台Web界面或者通过PDF或XLS文件交互式地访问报告，并且可自动将其分发给不同的组织团队。
系统会通过相应的规则自动高亮显示特定的行，这样您就可以快速发现可疑或未经授权的活动。
可以使用OracleBIPublisher创建新的或自定义的PDF和XLS报告模板来满足特定的安全需求。
报告基于的是一个高度优化的Oracle11gR2数据库，后者也可以通过配置允许外部报告工具访问审计数据。
也就是说，现有的管理信息(MI)工具甚至Excel电子表格均可访问重要的安全信息，但是为了确保审计记录的完整性，严格禁止更改或删除数据。
而且，AuditVault信息库模式经过归档，支持与第三方报告解决方案集成。
警报或事件管理让您可以创建复杂的警报定义，以便在审计人员控制台仪表盘上发出警报，并将通知发送给多个用户进行查证。
定义警报时可以使用SQL比较运算符（=、<、LIKE、IN和NULL等）和逻辑运算（NOT、AND和OR）指定布尔条件。
此外，还可使用组（使用括号）和通配符（%、_）为通用警报条件指定范围。
例如，您有一个JOBS表，只有授权帐户（比如HR_App）才能访问其 36 中的敏感数据。
图4-3中的示例显示，当任何非HR_App用户访问JOBS表时会发出警报。
图4-3：AVDF警报 37 第五章 控制SQL输入 政府和学术机构的研究表明，绝大多数数据泄漏是由SQL注入或滥用有权访问系统及其数据的内部人员的凭证引发的。
如今，大多数应用都采用单一用户帐户与数据库通信，且许多应用未充分验证其输入。
这种应用架构，再加上SQL注入或内部特权帐户滥用所引发的数据库攻击数量不断增加，导致数据库活动监视成为了整体安全架构的重要一环。
如今，市面上的大多数监视解决方案都依赖其策略中的正则表达式来确定应阻止哪些SQL语句访问数据库。
这些第一代解决方案所面临的的挑战是正则表达式的表达能力远不及SQL语句强大。
由于可以采用各种方式编写具有危害性的SQL语句，因此几乎不可能通过一条正则表达式规则检测到所有此类语句。
即使可以通过正则表达式检测到特定的SQL语句，但这些危害性语句也不是一成不变的。
除了阻止一组固定的“危害”语句外，另一种更有效的方式是根据连接至数据库的应用和用户的常规活动仅允许“良性”语句。
有效监视数据库SQL输入可阻止策略违规企图或发出相关警报，并提供全面的数据库活动报告来确保合规性。
OracleAuditVaultandDatabaseFirewall OracleAuditVaultandDatabaseFirewall为Oracle和非Oracle数据库提供第一道防线，并整合数据库、操作系统和目录中的审计数据。
该解决方案的DatabaseFirewall组件集成了一个基于SQL语法的高度精确的引擎来监视和阻止未经授权的SQL语句访问数据库。
与采用正则表达式的解决方案不同，OracleDatabaseFirewall对SQL本身进行解析，以达到企业数据库监视所需的精确度。
38 OracleDatabaseFirewall使用高度优化的流量捕获技术收集网络中的SQL请求。
然后，SQL查询将与尽可能多的会话信息相关联。
这包括查询的语法结构和上下文属性，例如： •数据库用户名 （例如dba_001） •操作系统用户名 （例如oracle_dom1\fred.bloggs） •客户端程序名称 （例如sqlplus.exe） •客户端IP地址 （例如192.0.2.12） •事务时间 （精确到毫秒） •安全目标名称 （例如） •数据库服务名称 （例如ounts.service1） 随后，这些信息将与SQL语句的进一步分析结果相结合，包括 •SQL类别 （例如，SELECT、DML-write、DDL、DCL和TCL等） •表名 （例如“tbl_customers”） 所有这些任务都将在网络包到达时实时完成，随后会将请求与OracleDatabaseFirewall策略进行对比。
OracleDatabaseFirewall按语法将SQL请求划分成不同的查询集群，这样可将SQL查询数量从数百万条缩减至数百条，然后可以按IP地址、客户端程序、SQL类型或用户名进一步分类。
这个将看似杂乱无章的SQL查询净化为数量级小几个的集群活动的过程就让OracleDatabaseFirewall有了区分“正常”事务与“异常”事务的能力。
39 通过DatabaseFirewall设置白名单 OracleDatabaseFirewall自动分析所有SQL语句，并且提供一个策略管理器为应用和通常执行同类SQL交互的用户快速创建“正常”行为白名单。
白名单策略是基于SQL请求创建的。
由于SQL请求中的某些属性与应用唯一明确相关，因此可以实现有效的选择性监视。
典型示例包括： •应用IP地址 （例如，192.0.2.100、192.0.2.101、192.0.2.102） •应用程序名称 （例如，service_123abff00、service_dd00） •应用数据库用户 （例如，db_appuser、db_appadmin） 通过OracleDatabaseFirewall设置黑名单 除了基于白名单的主动安全实施模型外，OracleDatabaseFirewall还支持黑名单。
与白名单策略一样，黑名单可以评估用户名、IP地址、时间和程序等各种因素，然后作出决策。
黑名单作为主动实施模型的例外情况，允许针对特定事件创建自定义规避策略。
例如，例外列表策略让来自预定IP地址的特定远程管理员可以诊断特定应用的性能问题，不受白名单或黑名单的限制。
可将黑名单视作用于评估各种因素的例外情况。
黑名单类似于传统防火墙中的“允许”和“拒绝”设置，其构成要素包括： •IP集•数据库用户集•操作系统用户集•客户端程序集 40 “集”是由同类属性构成的特定集合。
例如，下表显示了由用户构成的4个集： 集1报告用户marketing_01marketing_02marketing_03marketing_04mgt_BI_rep 集2DBA用户mikesmithwilliesoresdavejonesjohnasher 集3应用用户peoplesoft_201sap_usersiebel_4501app_001app_002 集4咨询用户jennaforteslouisegoodcons_001cons_002 我们可以针对每个集设置一条黑名单策略。
例如： 报告用户DBA用户应用用户咨询用户 通过、记录全部通过、报警通过阻止、记录全部 例外策略可在较高层次上对SQL请求进行有效筛选，简化应用、子网、用户组或用户的策略设置。
下图显示了一个例外策略的示例。
该策略将允许来自安全目标上的帐户应用的请求，但会阻止来自任何其他来源或身份的请求。
41 通过OracleDatabaseFirewall设置新颖(novelty)规则 新颖规则用于控制高级类别SQL和数据库表的SQL输入。
新颖规则配置适用于各种类别，具体取决于安全性对策略的要求。
这些类别包括： •数据操作 （INSERT、UPDATE、DELETE和SELECTINTO等） •只读数据操作•过程 (SELECT)（存储过程或RPC命令） •数据定义•数据控制语言•组合 （CREATE、DROP和ALTER等）（GRANT和REVOKE等）（事务中执行的命令） 42 •事务 （COMMIT和ROLLBACK等） •与事务的组合 （包含TCL命令的DML语句，等等） 新颖规则可将SQL命令与表相结合，轻松禁用所有表的日志记录，例如与应用本身无关的基础数据库字典表。
新颖规则可用于阻止或允许针对不同表的操作。
新颖规则通常用于控制DBA通过网络实施的操作，例如阻止他们访问特定的应用表。
通过OracleDatabaseFirewall处理未经授权的SQL 当OracleDatabaseFirewall发现一条未经授权的语句时，它会采用以下方式处理该语句： •对所有不符合策略的SQL语句发出警报。
•通过替换SQL语句来修改请求，即将不符合策略的语句替换为不会返回任 何数据的新的无害语句。
•终止连接：断开连接后，这将阻止来自特定数据库连接的所有语句访问服务器。
这是最激进的措施，如果应用使用连接池，那么这将影响所有使用该池的用户。
•阻止SQL语句：这将阻止特定语句访问数据库服务器。
实际的最终用户体验将取决于应用在服务器未响应时的处理方式。
可以将数据库的客户端连接配置为继续或终止。
OracleDatabaseFirewall网络部署 可以将OracleDatabaseFirewall部署为透明的网桥，只需将其插入到数据库客户端/应用服务器与受保护数据库之间相应区段的网络中，如下图所示。
这种“内 43 联”桥架构无需更改数据库客户端、应用或数据库本身的配置，并且提供灵活的主动和被动监视。
如需被动地监视数据库活动，还可以使用SPAN端口将流量转发给数据库防火墙。
如果难以添加网桥或者数据库服务器位于远程位置，那么可以将OracleDatabaseFirewall配置为代理，以便让所有对数据库服务器的访问都经由数据库防火墙进行。
这需要将数据库客户端或应用上的数据库服务器IP地址/端口更改为OracleDatabaseFirewall代理的IP地址/端口，同时将数据库监听器更改为拒绝直接连接。
也可以使用大多数企业网络交换机和传统防火墙将数据库流量重定向至OracleDatabaseFirewall代理端口，这样无需更改数据库客户端或应用即可保护SQL流量。
指定的数据库防火墙充当一些数据库的透明网桥的同时可充当其他数据库的代理。
DatabaseFirewall支持本地服务器端的仅监视代理，以确保能够灵活选择监视流量的网络点。
主机监视器（审计代理的一部分）捕获对数据库服务器的SQL访问并将其安全地转发给DatabaseFirewall。
主机监视器可用于远程监视Linux和Windows平台上运行的数据库服务器。
44 第六章 屏蔽敏感数据 许多组织都面临减少敏感数据泄露的挑战。
许多组织都需要在测试和开发系统中使用真实数据，但它们发现无法像保护生产系统那样保护这些系统。
因此，非生产环境中的敏感数据和受管制数据日益成为攻击者的目标。
而数据屏蔽则可通过在从生产环境移出数据前用虚构的数据不可逆地替代原始敏感数据，避免数据在非生产环境中泄漏，从而可以放心地与IT开发人员或业务合作伙伴共享数据。
与时同时，敏感数据在生产应用中过度公开也是许多组织所面临的一项挑战。
虽然向应用用户显示敏感信息自几年前就屡见不鲜，但如今组织必须对应用界面上显示的敏感数据进行编辑，以便更好地保护数据和遵守本地和国际法规。
然而，应用代码内部的这种编辑可能很复杂且容易出错，此问题在多个应用访问相同数据的整合环境中尤甚。
控制应用中敏感数据公开的最好、最经济高效的方法是在生产数据库内部实施相应策略，这样策略的实施便与访问数据的应用无关。
数据屏蔽会在物理上更改所存储的数据，以便将其移交给其他组织，而数据编辑不会在物理上更改所存储的数据，只会在数据离开数据库前进行转换，然后将转换结果显示在应用中。
在许多情况下，编辑仅适用于部分数据，例如信用卡的前12位数字、电子邮件域名前的用户名部分。
45 敏感数据发现 知道敏感数据所处的位置是决定如何对其进行保护的第一步。
大型应用的复杂性之高、规模之大令相当多的组织难以找到和识别所有敏感数据。
使用OracleEnterpriseManager中的数据发现和建模功能，企业可以检查数据库中与应用相关的元数据（如列名和数据类型）并对现有数据采样以帮助识别敏感数据。
例如，OracleEnterpriseManager可以根据列名、列注释或数据自身的特征来帮助找到信用卡和美国社会保险号。
以下示例显示了信用卡号的数据模式。
数据发现和建模功能还使用数据库中定义的外键约束来分析应用对象之间的关系。
这些关于应用的数据类型和对象关系的信息统称为应用数据模型(ADM)，并被存储在OracleEnterpriseManager信息库中。
对于没有使用数据库实施的引用完整性的应用，可在ADM中手动定义关系。
Oracle针对Oracle融合应用产品和OracleE-BusinessSuite开发了应用加速器。
应用加速器列出了每个应用的敏感数据。
OracleDataMasking使用应用加速器帮助屏蔽从生产数据库传入测试和开发环境的数据。
46 数据屏蔽 OracleDataMasking提供端到端的自动化，实现从生产环境自动供应测试数据库，并满足合规性要求，如下图所示。
可以替换信用卡和社会保险号等敏感信息，然后将其用于开发和测试，无需扩大安全边界。
在确保合规性和安全性的同时，这将减少需要监视的数据库系统的数量。
屏蔽格式库 OracleDataMasking提供了一个现成的屏蔽格式库，可用于最常见的敏感数据类型。
该库中的格式包括信用卡号、电话号码、社会保险号和国家标识号等敏感数据。
通过OracleDataMasking中的格式库，企业可对整个企业的数据库中的敏感数据应用数据隐私规则，以确保始终符合法规要求。
企业还可以用自己的屏蔽格式来扩展该库，以满足特定的数据隐私和应用要求。
将屏蔽定义与应用属性相关联之后，可将格式和数据关联保存在应用数据模型中，然后在测试、开发或合作伙伴需要刷新数据时重新执行。
OracleDataMaskingPack可通过OracleDatabaseGateways屏蔽异构数据库中的数据，如IBMDB2和MicrosoftSQLServer。
47 格式库（如上图所示）简化了屏蔽过程，可以采用经济高效的方式实现合规性。
格式库可扩展并且可通过自定义来满足各种复杂的业务需求，例如根据一组虚构的姓名生成电子邮件地址。
强大的屏蔽技术 OracleDataMasking支持各种高级屏蔽技术，允许复杂应用在测试和开发环境中使用屏蔽后的数据。
基于条件的屏蔽 混合屏蔽确定性屏蔽基于密钥的可逆屏蔽 根据条件对不同行应用不同的屏蔽格式。
例如，存储在同一表中关于多个国家/地区的公民的数据通常生成自己唯一的ID（SSN、国家标识号）。
将多个列中的存储相关数据作为一个组加以屏蔽。
例如，需要共同屏蔽的城市、州和邮编。
支持在多个数据库或应用中将数据屏蔽为同一个值。
这将确保在特定的值（如客户号）在所有数据库中屏蔽为同一个值。
支持使用基于密钥的可逆函数来屏蔽数据。
可以通过原始密钥来解除数据屏蔽。
48 克隆数据库和源数据库数据屏蔽 OracleDataMasking支持对从生产环境克隆来的数据库中的数据进行屏蔽或者对源数据库的数据进行屏蔽。
利用克隆数据库，OracleDataMasking构建了一个由需屏蔽的表和列构成的工作列表，并在物理上更改所存储的数据。
OracleDataMasking在屏蔽过程中使用了各种优化，因此不会访问无需屏蔽的对象，需要访问的表最多只会访问一次。
通常先屏蔽包含主键的表。
此外，OracleDataMasking创建屏蔽表时还使用NOLOGGING选项，以免生成过多的REDO日志。
OracleDataMasking现在支持数据源屏蔽，即在Oracle数据导出过程中对数据进行屏蔽。
随后，经过屏蔽的物理导出文件可直接与测试和开发组织共享，不存在敏感数据泄漏的风险。
这种新方法还支持在导出屏蔽过程中将文档或图像等数据设置为固定字符串。
这将减少需要传输给其他组织的数据集的大小。
数据编辑 除了在将敏感数据从数据库中导出前对其进行屏蔽外，越来越多的企业需要控制敏感数据在应用中的显示。
例如，呼叫中心应用会在其界面上向呼叫中心操作员公开客户信用卡信息和个人身份信息。
即使将这些信息向合法应用用户公开也可能违反隐私法规，给数据带来不必要的风险，而且这些用户根本没必要了解这些信息。
传统的敏感数据编辑方案通常采用自定义应用逻辑，导致整个企业内存在多种不一致的解决方案，且持续维护成本高昂。
此外，还必须严格控制新应用的开发，以确保能够正确访问自定义应用代码和新对象。
OracleAdvancedSecurity数据编辑可动态、选择性地编辑或清理查询结果中的敏感数据，然后查询结果才会显示在应用中，如下图所示。
它支持在访问相同 49 数据的应用模块中对数据库列进行一致的编辑。
数据编辑可最大限度减少对应用的更改，因为它不会更改内部数据库缓冲区、缓存或存储中的实际数据，并且在将转换后的数据返回给应用时会保留原始数据类型和格式。
与过去依赖于应用编码和新软件组件的方法不同，直接在Oracle数据库内核中实施数据编辑策略，以确保跨应用模块的一致性。
可根据数据库所跟踪的不同因素或应用传递给数据库的不同因素（如用户标识符、应用标识符和客户端IP地址）执行有条件的数据编辑。
编辑格式库提供了一些预先配置好的列模板，可用于编辑常用类型的敏感信息（如信用卡号和国家识别号）。
策略启用后立即生效，即便对于活动会话也不例外。
数据编辑策略和转换 数据编辑支持通过各种不同的转换来编辑指定列中的所有数据、保留数据的特定部分或者随机生成替换数据。
下图显示了一些受支持的数据转换示例。
50 可根据使用数据库和正在运行的应用中的运行时上下文的声明式策略条件有选择地应用数据编辑。
示例包括用户标识符、用户角色和客户端IP地址。
还可以利用OracleApplicationExpress(APEX)、OracleRealApplicationSecurity和OracleLabelSecurity中的上下文信息。
因为策略条件可以使用APEX自动跟踪的应用用户和应用标识符，所以APEX应用的编辑非常简单直观。
可以在一个数据编辑策略中合并多个运行时条件，以便对编辑时间点进行细粒度控制。
编辑策略在数据库中进行存储和管理，一经启用，立即生效。
从表面上看，数据编辑与数据屏蔽十分相似。
然而，一个重要区别在于Oracle数据编辑不会从物理上更改所存储的数据。
因此，Oracle数据编辑支持的转换功能仅仅是Oracle数据屏蔽的一个子集。
数据编辑的强大之处在于其卓越的性能、数据库内核级实施以及声明式策略条件。
部署数据编辑 可以快速为现有应用部署数据编辑，只需使用OracleEnterpriseManager或PL/SQL过程指定受保护的列、转换类型和条件即可。
OracleEnterpriseManager提供了一个简便易用的界面来创建和部署编辑策略，如下图所示。
51 OracleEnterpriseManager中提供了一些预定义的列模板，可用于编辑一些常见的敏感数据（如信用卡号和美国社会保险号），如下图所示。
EnterpriseManagerSensitiveDataDiscovery支持在复杂应用模式中查找需编辑的列。
OracleEnterpriseManager中的PolicyExpressionBuilder允许管理员定义编辑策略并将其应用于现有应用。
如下图所示，PolicyExpressionBuilder对话框将引导用户创建使用来自应用、数据库、APEX框架和其他数据库安全解决方案的上下文的策略条件。
52 除了OracleEnterpriseManager管理界面外，还可以使用数据库内部的API编写和应用编辑策略。
DBMS_REDACT.ADD_POLICY(object_schema=>'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。
53 第七章 验证配置合规性 如今的数据库需要大量配置设置，其复杂程度早已今非昔比。
攻击者通过配置中的漏洞获取对数据库的未授权访问。
例如，数据库中众所周知的用户名和密码组合就是一个常见的目标。
因此，需要扫描数据库来确保其经过安全配置，并且及时修复所发生的问题。
通过标记配置错误和提供有益于总体安全架构的控制建议，配置扫描可增强组织的整体安全性。
安全配置扫描已成为许多法规的重要组成部分，如支付卡行业数据安全标准(PCI-DSS)、Sarbanes-Oxley以及众多侵犯通知法规。
互联网安全中心(CIS)和美国国防部等众多机构也推荐了配置最佳实践。
随着新法规的发布和现有法规的不断发展，合规性的复杂程度不可小觑。
因此，部署一个能适应新法规的解决方案也就成为了企业的当务之急。
通过OracleEnterpriseManager执行安全配置扫描 OracleDatabaseLifecycleManagementPack提供了众多现成的基本配置报告和一个全面的合规性框架。
例如，帐户状态报告将显示所有数据库帐户及其状态。
另外还有一个报告可通过匹配各种Oracle产品自带默认帐户的已知密码，显示使用默认密码的数据库帐户。
其他报告还包括有关初始化参数、操作系统目录权限、用户帐户资料和敏感对象报告的信息。
如图7-1所示，可以通过Security菜单的Reports项访问这些现成的报告。
54 图7-1：OracleEnterpriseManager安全配置报告 通过OracleEnterpriseManager执行资产发现和分组 OracleDatabaseLifecycleManagementPack消除了手动跟踪IT资产（包括数据库）的必要。
它提供非侵入性网络扫描功能来发现服务器。
发现服务器之后，可轻松将其升级为托管状态，从而自动发现所有数据库和其他应用。
这种自动发现功能可以更加轻松地确保所有服务器和软件均处于托管状态，并且可为IT整合和优化计划提供支持。
由于管理员所负责的系统和服务数量不断增长，OracleEnterpriseManager提供了一个仅显示需要监视的目标的视图。
该视图被称为一个组。
组是一组用户定义的在逻辑上共同管理的目标。
您可以通过OracleEnterpriseManager中的组来共同监视和管理不同目标，轻松对这些目标执行管理操作，并且将这些分散的目标作为一个逻辑实体加以整合和监视。
例如，您可以定义一个TEST组，其中包含测试环境中的所有主机和数据库目标。
在测试组的主页中，您可以轻松查看该组中所有目标的总体状态和可用性，无需检查每个成员的状态。
即便组成员发生更改，提交给该组的所有作业也会自动与组成员保持同步。
55 在某个组的主页中，无论该组基于一组同构目标还是一组异构目标（如某企业的应用），管理员均可完成以下任务 •轻松确定组中所有成员以及待处理警报的总体安全配置合规性•下钻并分析特定目标的详细信息•通过汇总警报，快速下钻至警报详细信息，轻松确定组成员的状态 OracleEnterpriseManager配置扫描 OracleDatabaseLifecycleManagementPack提供了一个强大的合规性扫描解决方案，包括合规性框架、合规性标准和合规性标准规则，如下表所示。
合规性框架 合规性标准合规性标准规则 合规性框架是行业规定的针对底层IT基础架构、应用和流程的最佳实践准则。
合规性框架通过分层结构来直接表示这些行业框架。
合规性框架可用于表示PCI等框架。
合规性标准是指针对特定目标类型的检查或规则的集合。
合规性标准规则是用于确定特定配置参数或状态的测试。
Oracle支持以下规则类型。
•信息库规则评估针对目标定期收集的指标。
•实时监视规则监视对文件、流程等要素的更改。
56 Oracle提供的配置合规性标准 合规性标准作为度量目标的基准。
这些标准相当于最佳实践，支持安全管理员在不同企业系统和配置中保持一致性。
此外，趋势分析特性还可以对合规性评分进行持续的细粒度跟踪。
在上图所示的Oracle数据库基本安全配置检查中，可以看到系统执行了大量现成的检查。
所执行的检查包括分析目录和文件权限、Oracle参数设置、数据库密码配置文件设置、Oracle可执行文件所有权以及网络配置设置。
OracleEnterpriseManager附带了40多个现成的合规性标准，包括： •Oracle集群数据库基本安全配置•Oracle集群数据库实例基本安全配置•Oracle监听程序基本安全配置•Exadata计算节点配置监视•安全Linux程序包配置监视 57 管理框架、合规性标准和规则 OracleEnterpriseManager提供了一个可扩展的框架，可用于创建新的架构、标准和规则。
这种可扩展性让组织能够适应不断变化的合规性要求，并且创建自定义配置扫描来测试系统是否遵循内部最佳实践。
可通过OracleEnterpriseManager创建合规性标准规则，如下图所示。
还可以采用XML格式导入或导出规则。
事件严重性对于安全配置扫描至关重要。
OracleEnterpriseManager中的事件可分为下列严重性级别： •致命监视目标已停止运转。
•严重需要在某方面立即采取行动。
该方面不再起作用或意味着要出问题。
•警告某方面需格外注意，不过该方面仍还起作用。
•建议尽管某方面无需立即注意，但就该方面目前的状况来说建议多加留 神。
此严重性级别主要用于合规性标准。
•提示某方面发生了些小情况。
58 通过OracleEnterpriseManager进行实时监视 OracleDatabaseLifecycleManagementPack可实时监视针对文件、数据库对象或Windows注册表键的任何操作。
它还可以监视进程的启动和停止以及用户登录、注销和切换用户活动。
实时监视意味着可以捕获操作发生的准确时间以及执行操作的用户的名称。
实时监视的结果可与BMCRemedy等变更管理系统相协调。
这种协调可自动确定某个操作是否应发生（是否经过授权）。
如果没有变更管理服务器，那么可以通过管理控制台手动进行此审计状态批注。
实时监视通过将环境当前状态与客户的变更管理流程同步，帮助识别违反策略的操作。
这些操作会给环境带来高风险或使合规性控制无法通过审计。
实时监视的核心是Facet概念。
从本质上说，Facet包括配置文件、日志文件、进程和敏感数据库表等项目。
一个特定目标可以有多个与之关联的Facet。
可以根据Facet为核心Linux程序包、Exadata计算节点和用户访问Linux程序包创建多个实时监视标准。
OracleEnterpriseManager提供了数百个预先定义的Facet。
与框架和标准一样，可以定义和自定义Facet。
59 目标类型Facet日志文件二进制/库文件 配置文件安全密钥文件安全配置文件实用程序进程注册表键配置表 描述监视普通用户（非系统用户）对日志文件的修改。
监视二进制文件是否被篡改过或者二进制打补丁的时间。
除了列出各个二进制文件外，它还列出整个目录，但不包括频繁更改的文件。
捕获对任何配置文件的更改。
监视存储证书、密钥等内容的文件。
监视用于配置目标类型中的安全机制的文件，例如加密配置等。
监视通常在维护期间运行但不会在生产环境中运行的进程。
监视影响目标配置的MicrosoftWindows注册表键。
监视任何存储配置数据的数据库表。
每个Facet都通过一个实体类型来定义Facet描述的实体种类。
例如，在操作系统级监视中，实体类型包括操作系统文件、操作系统进程、操作系统用户、Windows注册表和一些ActiveDirectory。
在数据库监视中，实体类型包括表、视图、索引和过程等。
可以通过FacetLibrary界面创建Facet。
定义实时监视规则时，您首先需要确定主机上监视的实体类型。
下表列出了OracleEnterpriseManagerCloudControl12c中可通过实时监视规则进行监视的实体类型： 操作系统文件Oracle数据库表 Oracle数据库链接Oracle数据库触发器 操作系统进程Oracle数据库视图 操作系统用户Oracle数据库过程 Oracle数据库函数Oracle数据库表空间 Oracle数据库程序包Oracle数据库物化视图 Oracle数据库用户Oracle数据库配置文件 Oracle数据库序列Oracle数据库集群 60 使用OracleEnterpriseManager的通知功能 通知是OracleEnterpriseManager管理框架不可分割的一部分。
通知可在特定突发事件、常规事件或问题发生时执行操作系统命令（包括脚本）和PL/SQL过程等操作。
此功能可帮助您实现IT实践自动化。
例如，当发生数据库运行状态更改（正常/故障）等事件时，通知系统可以使用一个操作系统脚本自动打开内部故障单，以确保相应的IT人员可及时响应。
通过使用简单网络管理协议(SNMP)陷阱，针对OracleEnterpriseManager中发布的事件（例如特定量度超过阈值），OracleEnterpriseManager通知系统还可以让您将陷阱发送给支持SNMP的第三方应用（例如HPOpenView和BMCRemedy）。
通过OracleEnterpriseManager管理补丁 OracleDatabaseLifecycleManagementPack支持整个补丁管理生命周期，包括补丁建议、部署前分析、部署和报告。
它与MyOracleSupport相集成，提供可用补丁和推荐补丁的同步视图。
然后，可在部署前对这些补丁进行冲突分析。
接下来，用户可以在一个停机时间窗口内对多个数据库应用多个补丁。
补丁部署过程由于采用了高级技术（如RAC滚动打补丁和异地打补丁）而最大限度简化了操作和缩短了停机时间。
变更活动计划程序(CAP)让您可以计划、管理和监视涉及相关性、所有者协调以及多个进程的复杂操作。
这些操作包括每个季度定期部署安全补丁、根据业务需要搭建新服务器、迁移或整合数据库中心以及在整个环境中推广合规性标准。
CAP支持管理员完成以下任务•计划更改活动，包括设置开始和结束日期以及创建、分配和跟踪任务状态。
61 •使用自动化任务分配和完成支持来管理大量任务和目标。
•使用仪表盘监视计划潜在的延迟并快速评估总体计划状态。
•让任务所有者使用自己仪表盘上基于优先级或计划的视图管理自己的任务。
OracleEnterpriseManager中的配置合规性 虽然强大的SYSMAN帐户可用于遍历合规性框架，但Oracle可以通过细粒度权限来控制谁能查看结果和执行特定操作，因此支持职责分离。
下列权限和角色可用于管理对配置标准的访问： 权限CREATE_COMPLIANCE_ENTITYFULL_ANY_COMPLIANCE_ENTITYVIEW_ANY_COMPLIANCE_FWKMANAGE_TARGET_COMPLIANCEVIEW 描述创建合规性标准、规则和实时监视Facet管理合规性标准和合规性标准规则查看合规性框架定义和结果将合规性标准与目标相关联查看单一目标 角色EM_COMPLIANCE_DESIGNER EM_COMPLIANCE_OFFICER 描述 创建、修改和删除合规性标准、合规性标准规则及实时监视Facet。
查看合规性框架定义和结果。
62 更多信息 安全信息门户 •Oracle数据库安全•Oracle技术网上的数据库安全主题 Oracle产品文档 •Oracle数据库文档•Oracle数据库安全指南•OracleAuditVaultandDatabaseFirewall•OracleAdvancedSecurity•OracleDatabaseVault•OracleLabelSecurity•OracleDataMasking 63
声明：
该资讯来自于互联网网友发布，如有侵犯您的权益请联系我们。
相关文章
