文章
企业管理
作者:Porus Homi Havewala
Oracle Data Masking Pack 快速入门
2010 年 8 月发布
在当今的企业界,数据机密性绝对是必不可少的。随着数据库延伸到生活的方方面面,这些数据库中收集的过剩信息数量惊人。
这些数据库包括个人信息和机密信息,由于与客户的保密合同以及保护个人可识别信息 (PII) 的隐私法规的要求,公司有义务保护这些信息。公司还必须确保符合全球适用的标准和法规,如全球支付卡行业 (PCI) 数据安全标准、美国 Sarbanes Oxley 法案 (SOX)、日本 J-SOX 以及欧盟数据保护指令 95/46/EC。
在实际情况中,数据库经常从生产环境克隆或复制到测试环境,或从测试环境克隆或复制到开发环境。可能存在多个测试或开发副本。例如,一个生产 Oracle E-Business Suite 实例可能有 10 个或更多个对应的测试或开发实例副本,用于多个不同的开发团队或部门,这种情况很正常。
于是就存在外部供应商为了自己的应用程序开发或测试目的而请求数据的可能。市场研究人员可能需要数据进行分析。目前,由于全球经济模式,应用程序供应商和市场研究人员可能处于海外国家/地区,因此您的整个数据集可能最终被传到不同国家/地区,在那里有可能不像数据的原产地国家/地区那样恪守数据的机密性。
在所有这些情况中,数据库管理员 (DBA) 在提供数据库的异地副本或开发副本之前,都必须负责为数据提供最终保护。通常,这需要手动查看 DBA 负责的众多数据库中的所有表和列,以便找到任何保存了潜在机密数据的列。
然后必须创建自定义 SQL 或 PL/SQL 脚本对数据进行处理和屏蔽,将其变成看起来仍然像真数据的假数据,对于如今复杂的企业应用程序,这是一个严苛的要求。
必须编写单独的自定义脚本来屏蔽每个单独的数据库,即使这些数据库有类似的需要屏蔽的列。没有一种集中的方法可以在多个数据库之间共享屏蔽技术。
编写并部署自定义屏蔽脚本之后,还必须针对包含敏感数据的列的未来改动手动对这些脚本进行维护。随着数据库数量的增加,需要创建和维护的脚本越来越多,显然这不是一个可伸缩的解决方案。
而且,自定义屏蔽脚本的可审核性也不是很好,因为审核人员不可能逐个检查为每个数据库自定义的每个脚本。因此,手动屏蔽过程的效率不可能使审核者满意。
这就是所谓的 DBA 1.0 时代,当时许多 DBA 挣扎于使用命令行操作管理数量和大小均日益增加的数据库。所有日常管理任务都是手动完成,有时使用脚本,有时不用,这些任务包括:数据库备份、性能诊断和调优、补丁应用以及备用数据库的创建和管理。
随后 Oracle Enterprise Manager 进入了舞台,在这一过程中诞生了新一代的 DBA — DBA 2.0。
这一代 DBA 看到了使用 Oracle Enterprise Manager 图形用户界面的价值,认识到该产品将提升生产率,使许多任务可以更快地完成,并且可实现“集中化管理”。
正是 Oracle 的这一旗舰企业管理产品简化了 DBA 的日常任务,使这些任务可以自动化进行,从而使 DBA 能够省下更多的时间全神贯注于真正重要的事情:Oracle 数据库及其相关产品的安全性、架构和持续发展的新技术。
当然,对于任何具有数百个目标的中到大型站点,必须正确构建 Oracle Enterprise Manager Grid Control 站点的架构。有关所需架构的概述,请参阅本作者最近在 Oracle 技术网 (OTN) 上发布的文章面向大型站点的 Oracle Enterprise Manager Grid Control 架构。本文阐明了大型中央 Oracle Enterprise Manager Grid Control 站点如何管理和监视包含多个目标(如数据库、监听器、应用服务器等)在内的一千多台主机。
注意到现实世界中对数据屏蔽的不断增长的需求,Oracle 在 Oracle Enterprise Manager 10g 第 4 版中首次发布了 Oracle Data Masking Pack 来帮助 DBA 解决这一问题。
Oracle Data Masking Pack 见于 Oracle Enterprise Manager Grid Control 中以及 Oracle Enterprise Manager Database Control(自 11g 第 1 版起)中。后者仅用于监视和管理一个数据库。而 Oracle Enterprise Manager Grid Control 可以监视和管理许多数据库,全部从一个访问中央信息库的 Web 控制台进行。
Oracle Enterprise Manager Grid Control 的集中化功能非常适合新的 Oracle Data Masking Pack。其思路是将所有数据屏蔽格式集中存储在一个库中,然后将其应用于 Oracle Enterprise Manager Grid Control 管理的所有数据库。
这些集中的数据屏蔽格式可以由企业信息安全团队创建,然后可将其移交给负责各个项目的 DBA。DBA 将创建数据屏蔽定义,将其数据库中的特定列和表映射到提供给他们的合适的数据屏蔽格式。
屏蔽定义然后可应用于任何被管理的数据库中的机密数据,还可以在管理不同数据库目标组的 DBA 团队之间共享。
因此,通过对企业数据库空间内的所有敏感数据统一定义和应用数据隐私规则,Oracle Data Masking Pack 允许采用集中的企业级战略来满足隐私法规要求。
我们将在下文中对此一探究竟。
本文演示所用的版本是 Oracle Enterprise Manager 10g Grid Control 第 5 版。在这个版本以及最新版本中(截至本文撰写时,最新版本是 Oracle Enterprise Manager 11g Grid Control 第 1 版),可在 Database>Schema 选项卡中的 Data Masking 部分下访问 Oracle Data Masking Pack。(参见图 1)。而在 Oracle Enterprise Manager 10g 第 4 版中的 Data Masking 首个版本中,可在 Database>Administration 选项卡中找到这一部分。

图 1:Schema 选项卡中的 Data Masking 部分
选择 Format Library 链接,访问预定义的现成屏蔽格式的集合。这些格式用于常见机密数据,例如 MasterCard 号、Visa 号、社会保险号等等,如图 2 所示。
您可以对数据使用预定义格式,甚至可以创建自己的格式,稍后可见。

图 2:Format Library 屏幕
从屏蔽格式列表中选择 National Insurance Number Formatted,然后单击 View 按钮。这将显示组成该特定格式的格式项(参见图 3),该格式用于英国。
您一眼就可以看出,其中有一个数组列表类型的格式项,这允许定义一系列的值,另外还有一个随机数字类型的格式项。
您还可以指定后处理函数,在此情况下,该函数是现成的。后处理函数可以检查生成的字段的有效性,并执行一些额外的格式设置;在本例中,在生成的值之间插入空格。

图 3:Format Entries 屏幕
现在我们来看看眼前的任务。
IT 经理已经授权作为 DBA 的您创建人力资源表“Employees”的一个副本并将其提供给外部供应商用于开发目的。但是,必须保护所有机密数据,您将负责确保实现这一点。
为了进行这一测试,创建了 Employees 表的一个副本 Employees_test。然后检查该表中的数据,看看哪些列是数据屏蔽过程的可能候选列。
从图 4 中可以看到该表的各个字段以及该表包含的数据。

图 4:Employees_test 表
该表中的机密字段之一显然是 NRIC 列,即员工所在地新加坡的国民登记身份证号。
NRIC 号与美国的社会保险号码类似。它是应屏蔽的个人可识别信息 (PII)。
为了演示屏蔽,本文假定 NRIC 列是该表中唯一需要屏蔽的列。在现实情况中,还可以屏蔽某些其他列,例如 First_Name、Last_Name、Phone_Number 和 Salary。
您决定表中的 NRIC 列需要采用新的屏蔽格式。
在图 2 中所示的 Data Masking Definitions > Format Library 页中,单击 Create 按钮,这允许您创建自己特定的数据屏蔽格式。
将显示 Create Format 屏幕,如图 5 所示。

图 5:Create Format 屏幕
新格式名为 Singapore NRIC Number。开始时没有格式项,您可以逐项添加。
图 5 中所示的下拉框显示各种可用的格式类型。这些格式经过筛选,只显示适用于列数据类型的格式类型。格式类型称为屏蔽基元。例如 Random Digits、Random Dates、Random Strings、Fixed Strings 等。
此处提供的一个内置屏蔽例程是 Shuffle,可用于在一列的不同行之间随机移动值。它可用于列格式未知且不可能生成值的情况。
有些数据,如名称,还可以使用 Table Column 格式项用来自外部数据源的假名替换。还可以使用 User Defined Function 生成屏蔽值,比如在金融机构中使用算法得出某些值(如账号)。
Substitute 屏蔽格式类型可用于确定性屏蔽,即对一个甚至多个数据库中所有表中的某个数据列使用相同类型的屏蔽。例如,可能需要在多个表和多个数据库中以类似方式屏蔽员工编号。使用 Substitute 屏蔽格式,可通过基于哈希的替换将每个员工编号屏蔽成独一无二的屏蔽值,并且为任何特定的输入值生成相同的屏蔽值。
NRIC 号则是另外一种情况。通过官方提供的信息,您可以知道 NRIC 号的格式,因此选择 Array List 作为第一个格式项。
在图 6 所示的屏幕中,键入可作为 NRIC 号开头的有效字母值:S,F,T,G。

图 6:Array List 屏幕
以这种方式,您组合使用不同类型的格式项,从而组成整个 NRIC 号。下一项指定为 Random Digits 格式,其值的范围为 7 至 7,意味着将生成 7 个随机数字。
接下来的格式项类型是 Random Strings,其字符串长度为 1 至 1,表示单个字母。参见图 7。
基于您指定的格式项,立即生成了示例 NRIC 号并显示于页面底部,这样您可以查看操作是否正确。
未指定后处理函数。在这种情况下,您可以指定一个函数将最后一个字母变成大写。

图 7:Create Format 屏幕
单击 OK 按钮时,这个新的屏蔽格式将显示在屏蔽格式库中,如图 2 所示。
返回 Database > Schema 选项卡,单击 Data Masking 部分下的 Definitions(参见图 1)。
在此,您可以选择要屏蔽的实际数据列,并将其与库中的屏蔽格式关联。数据定义本身是列与屏蔽格式之间的映射。
将显示 Data Masking Definitions 屏幕(参见图 8)。该屏幕显示此数据库中已定义的所有定义的列表。该列表为空,因为目前还没有定义。

图 8:Data Masking Definitions 屏幕
在此屏幕中,可以导入数据屏蔽定义或创建新的数据屏蔽定义。
单击 Create 按钮。将显示 Create Masking Definition 屏幕,您可以在这里创建 HR Employees_Test Masking Definition。
在该定义中选择实际表和列 — HR.EMPLOYEES_TEST 表中的 NRIC 列(参见图 9)。
在此屏幕中,可以向定义添加数据库中不同表中的多个列,但对于这个特定定义,我们将只保留这一列。
如果有任何外键列回指向您已选择的列,此时将自动发现并添加这些外键列以维护引用完整性。
还有一个工具可以手动添加依赖列(这些列可以是在应用程序级引用屏蔽列的列),因为有些应用程序(如 Oracle E-Business Suite 和 Oracle PeopleSoft 应用程序)不使用数据库中的外键,而是喜欢在其代码级处理引用完整性。
如果按此方式使用外键列或依赖列并且也对其进行屏蔽,则可维护应用程序的完整性,即便是对于被屏蔽的数据。
在使用手动编写的屏蔽脚本的传统方式中,其他列有可能未包括在屏蔽中,从而破坏了完整性,并使得大部分手动屏蔽过程毫无用处,因为应用程序不能处理没有引用完整性的屏蔽数据。

图 9:Create Masking Definition 屏幕
在图 9 中,您已经在 HR.EMPLOYEES_TEST 表中添加了 NRIC 列。在 Format 下可以看到一个红色扳手图标,表示需要为该列设置屏蔽格式。单击该扳手图标。
将显示 Define Column Mask 屏幕(参见图 10)。该屏幕显示您要屏蔽的列以及包含该列的表和模式,在该屏幕中,您可以直接通过 Add 按钮添加屏蔽格式项,也可以单击 Import Format 按钮从 Format Library 中检索格式。
这里使用 Import Format 按钮,因为您已经为 NRIC 号定义了一个屏蔽格式。

图 10:Define Column Mask 屏幕
现在您可以从 Format Library 列表中选择所需的屏蔽格式,该列表如图 11 中所示。
选择 Singapore NRIC Number,然后继续。

图 11:Format Library 列表
这会使所选屏蔽格式返回到 Define Column Mask 屏幕中,在此可以将该格式与 NRIC 列关联。
图 12 显示从库中的 Singapore NRIC Number 屏蔽格式检索到的格式项。
如果您希望该格式与 Format Library 中定义的格式稍有不同,可以在这一阶段进行修改。

图 12:Define Column Mask 屏幕
在 Define Column Mask 屏幕中,可以设置新特性:条件数据屏蔽。为此,可单击 Add Condition 按钮,另外键入一个条件以便对该条件应用不同的屏蔽格式。
例如,在图 13 中,指定了一个新的条件“last_name like upper('%RAJAH%')”,如果满足此条件,则选定的格式项为 Preserve Original Data。
这意味着对于姓氏中包含字符串“RAJAH”的所有员工,其 NRIC 号在屏蔽过程中不会发生更改,将保持不变。
对于新条件,可以直接添加格式项,也可以在此屏幕上从库中导入格式。
在本例中,我们不需要这样的条件。无论员工姓名如何,所有 NRIC 都必须屏蔽,因此我们删除添加的条件。

图 13:条件数据屏蔽
单击 OK 按钮返回 Create Masking Definition 屏幕。扳手图标不再可见,因为您已为此列定义了屏蔽格式(参见图 14)。扳手图标现在被编辑图标(铅笔和纸)取代。
这样,如果在屏蔽定义中定义了多列,您可以通过单击扳手图标或编辑图标将屏蔽格式与各列相关联。
Create Masking Definition 屏幕上还有其他一些高级选项,这些选项允许您在屏蔽期间禁用数据库日志记录(重做日志生成)、在屏蔽过程之后刷新表和索引统计信息、删除在屏蔽期间创建的临时表,以及在可能的时候使用并行执行提高屏蔽过程在大型表上的执行速度。
如果启用了重做日志生成,万一屏蔽结果不满意,您将有机会使用数据库中的闪回技术回滚屏蔽更改。如果禁用了重做日志生成,则可能提高大型表上屏蔽过程的速度。
临时表是在屏蔽过程中生成的映射表。如果验证应用程序完整性需要,可以保留这些临时表,以允许业务用户将更改的数据映射到原始数据。
否则,如果空间很宝贵并且需要回收,可以在完成屏蔽过程后立即自动删除临时表。

图 14:高级选项
还有一点需要注意。
当在 Create Masking Definition 屏幕中添加列时,可以选择 Mask selected columns as a group。
该选项如图 15 中所示,已经选择了 FIRST_NAME 和 LAST_NAME 列,并且选择了该选项。
此过程称为混合屏蔽,它是 Oracle Data Masking Pack 中的另一个新特性。混合屏蔽允许将列关联在一起用于屏蔽过程,从而使屏蔽的数据表现出一致性。

图 15:混合屏蔽
一个更好的混合屏蔽示例是 city 和 country 之类的字段。如果屏蔽这些字段,应用程序可能仍然期望关联信息是正确的。
city 为印度名城 Mumbai,它在屏蔽后不能与作为 country 的 Iran 关联。伊朗首都 Tehera 也不能与 India 关联。Mumbai 和 India,Teheran 和 Iran 必须始终组合在一起,即使是在屏蔽过程中。
当屏蔽后的数据需要在各字段之间看起来符合这种常理时,可以使用混合屏蔽选项。
单击 Create Masking Definition 屏幕中的扳手图标时(关于此屏幕上的扳手图标,请参见图 9),可以看到将屏蔽列组合在一起的结果。
此时会要求您为这两个列定义一个组屏蔽。图 16 显示 Define Group Mask 屏幕。

图 16:Define Group Mask 屏幕
组屏蔽的格式类型只有以下可见选项:Shuffle、Substitute、Table Column 或 User Defined Function。
单列屏蔽的其他可能的格式类型(如 Random Digits 和 Random Strings)不可见,因而不能用于组屏蔽。只有可见格式类型是可以使用的。
例如,对于 City 和 Country 列的情况,可以使用 Shuffle 在不同行之间变换这些列,但同一行的列值要保持在一起。因此 Mumbai、India 将在一起,只是移动到另一行。
记住取消选择这两列的 Preserve Original Data,然后选择 Shuffle;否则这些列中的数据不会发生变化,它们不会以任何其他形式移动或更改。
返回图 14 中所示屏幕,单击 OK 保存新建的屏蔽定义。
现在显示主 Data Masking Definitions 页(参见图 17),可在列表中看到新建的 HR Employees_Test Masking Definition。现在,在 Oracle Enterprise Manager Grid Control 系统中央显示此屏蔽定义。

图 17:显示新屏蔽定义的 Data Masking Definitions 屏幕
本页上的 Export 按钮允许您将屏蔽定义导出为名为 Application Masking Template 的可移植 XML 格式的文件。然后其他 Oracle Enterprise Manager 信息库可以根据需要共享导出的定义。
应用程序供应商也可以使用导出的定义,将其与新应用程序一起提供给客户,这样客户就得到了现成的屏蔽格式到敏感数据的映射,只需几次单击即可完成部署。
现在,您可以生成实际的数据屏蔽脚本,Oracle Enterprise Manager 将用它来屏蔽数据。单击 Generate Script 按钮。
这将生成脚本。(系统将显示警告,提示生成过程可能需要 15 分钟才能完成。)
开始时,会执行一系列验证步骤以确保实际数据屏蔽过程不会出现任何错误。验证步骤包括空间可用性检查(因为在此过程中将创建替换表)以及所用屏蔽格式的验证,以确保这些格式与被屏蔽列的类型和长度匹配。
如果存在唯一性约束,这些检查还将通过为被屏蔽列生成唯一值来确保屏蔽格式符合数据库和应用程序的完整性要求。
最后,在屏幕上显示该脚本(参见图 18)。
在页面底部显示 Impact Report。此报告是验证过程的结果,显示没有错误,因此您可以继续屏蔽。
生成了一个 PL/SQL 脚本。您可以查看脚本摘要或完整脚本。在此阶段,可以将完整脚本保存在工作站上。

图 18:Script Generation Results 屏幕
您可以查看生成的脚本,了解实际的屏蔽过程。有关完整脚本,请参见清单 1。
Oracle Enterprise Manager Grid Control 显然节省了编写此 PL/SQL 代码的时间和精力。
在生成的高度优化的 PL/SQL 代码中,使用了批量操作将包含机密数据的原始表替换为该表的屏蔽数据副本。原始索引、约束、分区和授权全部保留。
使用了数据库中的高级特性(如并行执行和禁用重做日志生成)来加快屏蔽过程。最后,删除包含机密数据的原始表,代之以新的屏蔽表。
可以直接从图 18 所示的屏幕(Script Generation Results 屏幕)调度数据屏蔽作业。单击 Schedule Job 按钮。
单击此按钮可创建一个 Oracle Enterprise Manager 作业,该作业将在您指定的时间和日期执行脚本或立即执行脚本。在此阶段,还需要指定主机凭证。参见图 19。

图 19:Schedule Data Masking Job 屏幕
注意,必须先生成屏蔽脚本,然后才能调度屏蔽作业。即使主 Data Masking Definitions 页(图 17)中有 Schedule Job 按钮,除非脚本已生成,否则该按钮也不会起作用。
您还可以单击 Script Generation Results 屏幕(图 18)中的 Save Full Script 按钮将 PL/SQL 屏蔽脚本保存为外部文件。
如果您的数据库环境是基于命令行的,并且不使用 Oracle Enterprise Manager 管理数据库,则拥有外部文件让您可以使用调度程序手动运行脚本。
屏蔽作业立即执行,由于表很小,几秒钟即可成功完成。图 20 显示了成功的执行步骤。

图 20:作业运行结果
可以通过执行步骤下钻查看实际输出日志,如图 21 所示。
这是我们在代码清单中查看的脚本的执行结果。

图 21:Output Log
如果在此页中向下滚动,可以看到输出日志结尾的注释,如下所示:
Completed Data Masking. Starting cleanup phase. Starting cleanup of recovery tables Completed cleanup of recovery tables Starting cleanup of generated procedures Completed cleanup of generated procedures Script execution complete SQL> set ver on SQL> Disconnected from Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options

图 22:SQL 工作表
返回图 17 中所示的 Data Masking Definitions 屏幕并单击 Clone Database 按钮,查看在安全的克隆和屏蔽工作流中数据屏蔽过程如何与克隆过程关联。
这将显示 Clone Database 向导页(参见图 23)。
注意,使用 Oracle Enterprise Manager Grid Control 进行数据库克隆除了需要 Oracle Data Masking Pack 进行屏蔽之外,还需要 Oracle Enterprise Manager Provisioning and Patch Automation Pack 的许可。
在 Clone Database 向导的第一页中,可以指定克隆操作的源数据库。您可以生成源数据库的联机 Oracle Recovery Manager (RMAN) 备份或使用现有数据库备份。
在不使用临时区域时,RMAN 备份在后台使用 RMAN 复制特性。如果选择了临时区域,则不使用复制特性。第一页对步骤进行了详细说明。

图 23:Clone Database 向导
在下一页中,为克隆数据库过程指定源选项。为提高通过 RMAN 复制特性进行克隆的速度,可以指定并发文件复制进程。
此时还需要指定源主机凭证。参见图 24。

图 24:Source Host Credentials
如果源数据库处于 NOARCHIVELOG 模式,则必须将其关闭并重新启动进入挂载模式以便进行克隆,或者可以在过程的此阶段切换到 ARCHIVELOG 模式。参见图 25。

图 25:Archiving Mode 屏幕
该向导的下一页允许您指定要将数据库克隆到的服务器上的目标 Oracle 主目录。您还可以在此页中命名目标数据库(参见图 26)。
首先,该服务器上需要安装有 Oracle Enterprise Manager 代理,并且该代理应与中央 Oracle Enterprise Manager Management Service (OMS) 保持通信。这意味着该服务器已被发现并在 Oracle Enterprise Manager Grid Control 中作为一个目标可见。
其他要求是源服务器与目标服务器的操作系统应匹配,并且源和目标上的 Oracle 主目录也应在数据库软件的版本级相匹配。

图 26:Select Destination 屏幕
单击 Next 前进到 Destination Options 页(图 27),可以在此指定文件位置,并对其进行定制或使用标准的 Oracle 最佳灵活架构 (OFA) 布局。
最简单的方法是使用 Database Area and Flash Recovery Area 选项存储所有数据库文件、控制文件、重做文件、存档文件和备份文件。

图 27:Destinations Options
在下一页可以看到克隆和屏蔽工作流的关键之处。
在 Clone Database 向导的这一页中(如图 28 所示),您可以指定屏蔽定义作为克隆数据库过程的一部分执行。
选择 Execute masking steps after cloning the database,然后添加先前定义的屏蔽定义以及为源数据库生成的脚本。在本例中,添加 HR Employees_Test Masking Definition。
在同一页中,还可以指定网络配置文件、克隆后脚本(如果需要)以及是否在 Oracle Enterprise Manager Grid Control 中注册新克隆的数据库(以便其显示为新的数据库目标)。

图 28:Database Configuration 屏幕
继续下一步,您可以使用 Oracle Enterprise Manager 作业调度程序调度 Clone Database 作业,使其立即执行或在某个未来的日期和时间执行。参见图 29。

图 29:Schedule 屏幕
最后,将显示 Clone Database:Review 屏幕(图 30)。您可以在该页的 Database Storage 部分下验证克隆过程信息,包括要创建的文件。
在 Review 页中,屏蔽定义状态显示为“Specified”。
提交 Clone Database 作业后,将创建新的数据库作为原始数据库的副本。作为克隆数据库过程的一部分,将生成屏蔽脚本并将其应用于新数据库。
这种克隆和屏蔽工作流是安全的,因为当克隆过程完成后,新数据库将以 RESTRICTED 模式打开,该模式只允许管理员访问该数据库。然后执行屏蔽过程,工作流将在打开新数据库进行正常使用前验证屏蔽过程是否已成功完成。
此过程可确保在过程结束时甚至在过程期间机密数据在新数据库中不可见。
至此已创建了一个屏蔽数据库,该数据库可以安全用于开发服务器、测试服务器或异地供应商(如果已使用所述技术正确放置和屏蔽所有机密列,如 NRIC)。

图 30:Review 屏幕
Oracle Enterprise Manager 11g Grid Control 第 1 版于 2010 年 4 月发布。在该版本中,对数据屏蔽进行了如下增强:
Oracle Data Masking Pack 需要支付额外的许可费才能使用,但考虑到以下优点,这一代价非常值得:以安全、集中的方式定义可在整个企业范围使用的屏蔽格式,并且可以将屏蔽应用于由集中安装的 Oracle Enterprise Manager Grid Control 管理的任何数据库中任何表中的任何列。
您可以保护数据的机密性,同时还可以满足合规性要求。
将屏蔽与数据库克隆集成是一项受人欢迎的附加功能,该功能需要 Oracle Enterprise Manager Provisioning and Patch Automation Pack 许可。如果恰当地定义了屏蔽格式并通过为数据库创建的屏蔽定义将其应用于相应列,这种集成可杜绝克隆数据库中出现机密数据。
数据屏蔽脚本将自动生成,屏蔽定义可以在不同 Oracle Enterprise Manager Grid Control 安装之间进行传输。通过自动发现(通过外键列)机密数据以及自动屏蔽过程,DBA 的工作效率得到极大提高。
这些特性组合起来,首次实现了可以通过 Oracle Enterprise Manager Grid Control 轻松设置和应用的企业级数据屏蔽和机密性策略。
当然,Oracle 的这一旗舰企业管理产品还有许多其他功能;它实在是个巨无霸。如果您想了解如何对您环境中所有的 Oracle Real Application Clusters (RAC) 或非 Oracle RAC 数据库、Oracle 自动存储管理 (ASM) 实例和 Oracle Clusterware 自动打补丁,请阅读作者最近的一篇题为使用 Oracle Enterprise Manager Grid Control 修补数千个数据库的文章。有关如何使用 Oracle Enterprise Manager Grid Control 为您公司的数据库轻松建立 Oracle Recovery Manager (RMAN) 备份的信息,请阅读 Oracle RMAN 备份:提供简单方式。
如果您还对数据集成感兴趣,可阅读使用 Oracle GoldenGate 进行实时数据集成。另外,要了解使用 Oracle Enterprise Manager Grid Control 进行 Oracle Data Guard 的安装、管理(包括转换和故障切换)和监视如何能够节省大量的时间和资源,请阅读作者最近发表的另一篇文章使用 Grid Control 轻松预防生产灾难。
现在是 DBA 2.0 的时代,明智的 DBA 将认识和了解到 Oracle Enterprise Manager Grid Control 在这一时代不可或缺。
Porus Homi Havewala 是 Oracle 新加坡的一名高级经理(企业技术),之前他是 S&I Systems Singapore(Oracle 白金合作伙伴)的首席顾问。他在 2008 年荣获 Oracle 总部颁发的 Oracle ACE 总监头衔,现在是一名 Oracle 员工 ACE。自 1994 年来,他在 Oracle 技术领域积累了丰富的工作经验,曾经担任高级生产 DBA、首席数据库顾问、数据库架构师、电子商务技术 DBA、开发 DBA 和数据库设计建模人员(当然,使用 Oracle Designer)。Porus 还是《Oracle Enterprise Manager Grid Control – Advanced Techniques for the Real World》一书的作者。