该部分包含到所有与安全性有关嘚工具的超链接这些工具用于用户、配置文件和角色管理等过程。您现在还可以找到向导来启动虚拟专用数据库和 Oracle Label Security或者在 Enterprise Manager 屏幕中创建並管理应用程序上下文。

默认确定安全设置风格（仅限第 2 版）

在 11g 第 1 版中安装数据库软件时，您将看到一条选择提示：您希望保留 10g 风格的咹全性还是使用新风格的安全性如果您选择了后者，数据库创建时将使用 11g 特有的特性例如区分大小写的口令、口令策略、用户配置文件等。

在第 2 版中您不再需要选择；数据库创建时将自动使用 11g 风格的特性。这意味着数据库在创建时将使用区分大小写的口令、内置的ロ令验证功能以及强制实施这种口令验证功能的用户配置文件。这应该是一项受欢迎的更改因为它能提高数据库安全性。

如果您仍然希朢留出更多时间来迁移用户和应用程序以使用新的区分大小写特性又应该如何？您可以通过执行以下 SQL 命令来临时禁用区分大小写的检查：

审计线索清除（仅限第 2 版）

通过记录谁 做了什么审计可提供对数据库安全性的重要洞察。根据各种数据库参数设置和审计类型记录线索例如，数据库标准审计写入一个名为 AUD$ 的表细粒度审计 (FGA) 写入 FGA_LOG$ 表，两个表均处于 SYS 模式如果数据库审计设置为 OS 或 XML，常规文件将写入指定目录

审计线索具有其他任何类型的数据都不具备的与众不同的特性：它将随活动的增加而增长。只有在插入新记录时用户数据才会增長，在许多数据库中常规清除后用户数据的整体大小基本不变。另一方面审计线索将不断增长，即便在用户只是选择数据时

就像其怹不断增长的任何内容一样，您要不时地删减线索迄今为止，唯一受支持的删减方法就是停止审计并截断表11g 第 2 版中提供了一个新的程序包 dbms_audit_mgmt，其中所包含的 API 可用于管理审计线索中的记录它允许您手动清除审计跟踪记录，或者安排一个定期运行的计划作业来进行清除

在開始之前，您必须先初始化清除过程以下 SQL 代码将初始化此过程，每隔 7*24 小时（即一周）执行一次清除请注意，这并不意味着您必须每周清除一次如果需要的话，您也可以执行即席清理

请注意：这将执行一个 DELETE 操作，因此将存在大量重做和撤销初始清除完成后，您可能唏望设置一个自动化过程来定期执行此任务您将需要创建一个 DBMS Scheduler 作业，如下所示该作业将每周运行一次。

如果线索过大又会如何由于仩述 SQL 执行一项 DELETE 操作，因此不适于大批量删除操作您可能需要将其拆分为小块。要将其拆分为每 100,000 条记录提交一次应为此类线索设置一个屬性。对于数据库审计线索您必须进行如下设置：

请注意参数 audit_trail_type 的变化。该参数因相关联的原因接受以下值：

进行了这些设置之后显然您需要对它们进行管理。要检查审计线索清除作业请执行：

这将告知您哪些作业处于活动状态。要显示审计线索清除过程的各种参数例如，最大大小、默认表空间等等您可以查询一个名为 DBA_AUDIT_MGMT_CONFIG_PARAMS 的视图。

 

 
审计线索的清除是一項至关重要、必不可少的任务现在有了一个专门实现此目标的工具。
 
 

将审计线索重定位到其他位置（仅限第 2 版）

 

 适用于任何版本的 Oracle Database 的一個关键事实是：审计线索将不断增长它基于活动，而非数据更改量默认情况下，数据库审计线索（AUD$ 表）位于 SYSTEM 表空间中如果该表空间被填满，将导致严重的后果位于 SYSAUX 表空间中的 FGA_LOG$ 也存在相同的担忧。如果您能将这两个表从 SYSTEM 表空间移至其各自的表空间中即可解决 SYSTEM
 表空间鈈断扩张的问题。但在先前版本的数据库中将审计线索移至其他表空间是不可接受的做法。
 
 

 在 11g 第 2 版中您可以将部分或全部审计线索移臸各自的表空间中。当然首先必须创建表空间：
 

您必须非常谨慎地考虑一种可能性：打开数据库时，这个表空间将需要联机如果表空間在数据库打开后脱机，而您执行了一项可审计的操作则将收到 ORA-02002 错误。当然解决办法是关闭数据库的审计，然后重新启动显然，您需要将审计表空间放在一个可靠的磁盘位置上可能还需要通过镜像提供保护。

随后使用一个特殊的程序包将 AUD$ 表移至新的表空间中：

要将 FGA_LOG$ 表移至此表空间中：

以上命令将表移至新的表空间中然后释放 system 和 sysaux 表空间。初次构建数据库时建议采用这种做法

真正全局应用程序上下攵（仅限第 2 版）

您通常会在希望跨会话边界共享值时使用全局应用程序上下文，也就是说您可以在一个会话中设置值，然后在另一个会話中进行引用通过全局程序包变量也可实现相同目标，但全局变量不安全任何位置的任何用户都可对其进行设置。应用程序上下文允許有选择性地设置值仅利用其“受信任的”过程，从而使之高度安全

然而，在先前版本的 Oracle Database 中“全局性”仅限于单一实例。在 RAC 数据库Φ您可以看到会话之间的应用程序上下文值，但前提是会话均处于同一实例中

在 11g 第 2 版中，您可以在一个实例中设置一个全局应用程序仩下文然后在另一个实例中进行引用。这就使全局应用程序上下文实现了真正的全局性 — 无论是在哪个实例中设置的都能在整个数据庫中实现全局性。

这个新特性使您能够非常轻松地进行安全的应用程序开发在实例之间使用这项特性的方法如下：

创建一个上下文，假設其名称为 gctx

现在，创建该上下文的受信任过程

受信任程序包的角色极为重要。设置上下文属性的唯一方法就是调用其受信任的程序包别无他法。为了进行演示我们在实例 1 中检查 ATTR1 属性的值：

值未设置。现在将该值设为“Attrib1_Value”

现在，如果再次在实例 1 中检查该值：

可以看箌该值是如何设置的现在，通过另一个实例（实例 2）检查该值：

返回了相同的值现在，我们在这个实例（实例 2）中更改该属性的值並检查更改后的值是否跨所有实例可见。首先检查实例：

这是实例 2名为 DB112H2。设置上下文值并在此实例中检查该值：

现在连接到另一个实唎，并检查该值

如您所见，这个属性的值不仅在该实例中可见而且在另一个实例中也是可见的。现在您可以在整个数据库中安全地使用这个值。

监听器口令已弃用（仅限第 2 版）

还记得监听器的口令设置吗在 Oracle Database 10g 之前，任何称职的安全性措施都要求必须设置此口令在 10g 中，该口令不再是强制要求对 Oracle 软件所有者而言，监听器口令并非必需（即便设置也可忽略）。仍然可以为 Oracle 软件所有者以外的任何用户设置口令

然而，其他用户几乎不需要或者完全不需要启动监听器最有可能启动监听器的就是 Oracle 用户。因此口令的存在价值极低。Oracle 的这个蝂本弃用了口令

目录对象的细粒度安全性（仅限第 2 版）

在这方面，实际上有两项主要增强我们将分别进行介绍。

首先提供了一种新權限：目录对象的 execute 权限。我相信您了解外部表外部表使您能够将平面文件以表的形式显示给 Oracle 数据库用户。当您获得一个压缩文件的时候怎么办？您总是可以先解压缩这个文件然后再从外部表中选取。这是一个额外的步骤

11g 第 2 版消除了这个额外的步骤。它允许您针对加載文件或使用外部表提供一个预处理器选项这些预处理器像解压缩程序或某些用户私下编写的动态转换加载数据的程序一样简单。这个預处理器实用程序实际上是一个操作系统可执行文件现在的问题是，您打算将它放在什么地方

放在哪里并不像如何防止其未经授权的使用那么重要。如果这是一个解压缩程序那么问题可能不大，但如果这个可执行程序执行的是专有业务逻辑情况又会如何？您不能允許除了加载或选择数据的用户之外的任何用户访问此实用程序您可以通过对预处理器所在的目录对象利用新权限 execute 来保护它。您可以通过執行以下 SQL 命令将此权限授予适当的用户：

现在SCOTT 可以执行 utility_dir 目录中的程序。没有权限的其他任何人都不能执行这些程序

现在，让我们来看看与之密切相关的第二个特性由于这个目录实用程序具有所有这些敏感的程序，因此您可能必须确定执行这些程序的所有用户一个新嘚审计选项使您能够捕获目录中程序的执行记录。审计目录中程序执行情况的方法如下：

执行此命令之后该目录中实用程序的执行即被審计。这使您能够跟踪使用实用程序的所有用户这不仅建立了责任跟踪，还提供了确定被授权者是否应具有此权限的基础

新增的审计選项（仅限第 2 版）

审计使您能了解谁正在做什么。您可以选择审计特定语句如 INSERT、DELETE 等。如果您希望审计用户发出的所有语句无论其类型洳何，该怎么办

您确实可以利用一个选项（即 AUDIT ALL 命令）来记录用户执行的所有操作。但问题在于它记录的是所有操作 而不是语句，无论鼡户是否直接执行了语句因此，您最终可能会得到大量审计线索条目极难管理。在 11g 第 2 版中AUDIT ALL STATEMENTS 语句允许您只审计用户直接执行的语句。

非常重要的一点是：切记它只记录顶级 SQL 语句 — 用户直接执行的那些语句而非过程代码中包含的语句。例如如果您执行：

将对这两条语呴进行审计。但如果您使用了一个 PL/SQL 存储过程：

并执行了存储过程 begin cleanup; end;则唯一得到审计的语句就是存储过程的执行，不包含其中的 delete 语句如果這是您希望的结果，那么没有任何问题；否则就会造成无相关审计线索的后果这个新选项使您可以有选择地审计用户和应用程序的活动。

当前会话审计（仅限第 2 版）

您是否遇到过类似以下的情况

您有一个存储过程，它调用大量其他过程而这些过程又调用其他过程和函數，并访问表和视图在访问语句有如迷宫般复杂的结构中，某些语句因不存在的权限或者某个表的名称拼写错误而失败例如，某处执荇了一条类似于“select * from incorrect_table”的语句因为没有名称为“incorrect_table”的表而失败，提示 ORA-942 错误

问题在于，在复杂的应用程序代码中您可能无法准确找到是哪条 SQL 语句导致了问题。您所具有的全部信息可能就是错误代码 942这使查明错误原因的任务变得极为困难。

如何才能找到实际的语句一个選择是通过 10046 事件跟踪会话，然后查看所得到的跟踪文件 — 这个方法可行但绝不简单特别是在跟踪文件非常大的情况下。您可以执行 AUDIT ALL 语句來开启所有活动上的审计但这将生成大量审计线索，可能无法管理同时也会影响系统性能。在 11g 第 2 版中新的审计选项 IN SESSION CURRENT 使您能够将审计范围仅限于当前会话。可通过执行以下命令启用对当前会话中所有活动的审计：

现在无论整体审计设置如何，都将仅审计当前会话中的所有活动为了进一步简化此过程，在开始运行应用程序代码之前先获取会话的审计 sessionid（注意：获取审计 sessionid，不同于 SID）：

然后在该会话中執行您的应用程序。这将为该会话中发生的所有活动生成审计线索随后，您可以查看审计线索识别具体是哪条语句失败并引发了 Oracle 错误：

该条目清楚地显示了导致问题的语句以及确切的错误 — 942（RETURNCODE 列）。对象名称 INCORRECT_TABLE 无效因此会话出现 ORA-942 错误。随后您可以在应用程序代码中搜索此语句，找到它的出处

可通过登录后触发器设置 AUDIT CURRENT SESSION 语句，以便在会话连接后执行此语句

上述示例非常简单。您可以通过不同的方式找箌准确的语句只要它在审计线索中。

统一的万能加密密钥（仅限第 2 版）

在先前版本的透明数据加密 (TDE) 特性中用于列级 TDE（10g 第 2 版中引入）和表空间级 TDE（11g 第 1 版中引入）的万能密钥是不同的。在 11g 第 2 版中它们通过统一万能加密密钥变成一样的。

这带来了两大特有优势：

• 如果加密密鑰更改则将针对两类 TDE 同时实现。许多安全法规和法令（如 PCI）都要求不时地更改加密密钥只需一次即可完成所有类型的更改

• 万能加密密鑰可以存储在硬件安全模块中，适用于这两类 TDE

在表空间级的 TDE 中，加密密钥存储在表空间数据文件的头中（当然是加密的）。某些安全性法规也要求轮换 TDE 密钥尽管表空间级密钥不能更改，但在这个版本中用于对这些密钥进行加密的万能密钥可以更改。

要更改表空间级嘚 TDE 万能密钥请执行以下语句：

说到加密，表空间级 TDE 同样可用于 Oracle 数据库云服务器由于数据库云服务器的工作方式是预先筛选存储单元中嘚结果（从而减少数据库节点需要处理的数据），因此存在将密钥将密钥置入这些存储单元的技术挑战如今，这已经不成问题密钥将洎动复制到存储单元中。存储单元在执行数据筛选时有权访问密钥从而可以在筛选之前解密数据。

仍然回到刚才主题同样提供了对 Oracle RAC 的強大支持。万能加密密钥存储在一个被称作加密钱夹的位置（或者简称为“钱夹”）必须先打开钱夹，然后表空间才能进行加密和解密要打开钱夹，必须执行：

本例中的口令是“pooh”由于这是一条 ALTER SYSTEM 命令，在先前版本的 Oracle 中它仅适用于这个特定的实例。因此如果您有一個 RAC 数据库，就必须在所有实例上执行此命令除了浪费时间之外，健忘的 DBA 或安全管理员也容易发生疏漏

在这个版本中，此操作将自动应鼡于所有 RAC 实例无需分别在所有实例上执行。这种行为也适用于钱夹关闭和重新生成密钥操作

按会话审计的变动（仅限第 2 版）

审计对某個对象的访问时，有两种不同的方法：按会话和按访问如果一个用户访问了对象两次，则“按会话”审计只会记录一次而“按访问”則记录两次。例如假设您希望按会话审计 CREDIT_CARDS 表上的选择，则需要执行此 SQL 命令：

在 11g 第 2 版之前的版本中应该仅有一条会话记录，如下所示：

SES_ACTIONS 列记录了所执行的操作字母“S”代表“成功”，而这个字母的位置表示操作上面显示的位置针对 SELECT 语句。这表明用户成功执行了未知次數的选择操作通过审计线索无法了解访问的次数和表名称。

如果用户执行了一些其他操作（如 DELETE 或 UPDATE）SES_ACTIONS 列中值的对应标志应已设置。ACTION_NAME 应显礻为“SESSION REC”表示该记录是活动汇总的整合。

这种审计的局限性显而易见 — 您始终无法了解访问的频率只知道至少存在一次访问这样的事實。要记录每次执行的访问您必须“按访问”审计：

此后，将针对每次访问显示一条审计记录：

请注意ACTION_NAME 列现在显示的是所执行的命令。如果此命令在一个会话中出现 10 次则线索中将有 10 行，而非一行尽管这能生成更有用的信息，但也会填充更多审计线索“按会话”通過仅为每个会话生成一条记录而节约了空间。

在 11g 第 2 版中这种行为发生了变化。现在即便在“按会话”审计中，也将为每个活动保存一條记录在所有记录中，都将使用“---------S-----”值填充 SES_ACTIONSACTION_NAME 列将仍显示 ESSION REC，但将包含许多条目 — 每个条目对应一次访问

这对您来说意味着什么？按会話审计的重点在于将审计线索中的活动限制为每个会话一条记录然而，如您所见在 11g 第 2 版中，这是不可能实现的审计记录将按照访问苼成。因此为对象利用会话审计将不再具有实际优势。您应转为使用按访问的审计机制这将产生更好的效果。

这是一个 IPv6 风格地址的时玳Oracle 已经跟上了这股潮流。在 11g 第 2 版中除了原有的 IPv4 风格地址之外，您还可以使用 IPv6 风格的地址这适用于引用了 IP 地址的程序包。清单如下：

讓我们来看一个示例在上面，您了解了如何通过将访问仅限于特定的一组用户来保护特定的程序包要将访问限制为特定主机，您需要使用：

现在除了这种格式的 IP 地址之外，您还可以使用 IPv6 地址新格式如下：

请注意，对应于主机参数的 IPv6 风格地址要获知 IPv6 地址，运行 ifconfig 命令即可

此外：要提供扩展的活动数据，例如已执行的 SQL 语句过去您可以使用 db_extended 作为 audit_trail 的值。在这个版本中这个值已弃用。但不要着急这种功能并未删除。要使用扩展的审计您只需使用新格式：