Oracle数据库11g新特性：安全性

Oracle数据库11g新特性：安全性默认口令2006 年，OTN 发布了我撰写的一系列题为“安全保护项目：一种分阶段的数据库基础架构保护方法”的文章。

在这些文章中，我讨论了如何应对常见的安全挑战（如用户使用默认口令）以及如何扫描您的数据库以查找这些用户。

对我而言很不幸的是，您可能已经忘记了我文章中的那一部分。

Oracle 数据库11g 现在提供一种快速识别使用默认口令的用户的方法。

该方法实施起来极为简单，只需检查单个数据字典视图：D BA_USERS_WITH_DEFPWD.（注意，DBA_ 是一个标准前缀，它不仅包含使用默认口令的DBA 用户。

）您可以执行以下命令来识别这些用户：输出如下：由于SCOTT 使用了默认口令TIGER，因此您会看到他出现在上面的清单中。

使用下面的语句进行更改：现在，如果您查看该视图：您就不会在该清单中看到SCOTT 了。

就这么简单！区分大小写的口令在版本11g 之前的Oracle 数据库中，用户口令是不区分大小写的。

例如：这种安排为支付卡行业（PCI）数据安全标准之类的标准带来了问题，这些标准要求口令区分大小写。

该问题得到了解决，在Oracle 数据库11g 中，口令也可以区分大小写。

通过DBCA 创建数据库时，系统会提示您是否希望升级到“新的安全标准”，其中之一就是区分大小写的口令。

如果您接受该标准，口令在创建时的大小写状态将被记录下来。

假如您接受了新标准，相应的操作结果如下：注意对“tiger”和“TIGER”的不同处理方式。

现在，您的某些应用程序可能无法立刻传递大小写正确的口令。

典型示例是用户输入表单：很多表单在接受口令时不会进行大小写转换。

然而，在Oracle 数据库11g中，这种登录方式可能会失败，除非用户以区分大小写格式输入口令，或者开发人员对应用程序进行了修改，使其能够进行大小写转换（这一点不可能迅速实现）。

不过，如果您希望的话，仍然可以通过更改系统参数SEC_CASE_SENSITIVE_LOGON 恢复到不区分大小写的状态，如以下示例所示。

在将现有Oracle 数据库10g 升级到11g 时，可将口令移植到新标准。

可以通过查询DBA_ USERS 视图来检查口令状态，尤其是新的PASSWORD_VERSIONS 列。

您首先会注意到PASSWORD 列为空，没有像Oracle 数据库10g 和以前的版本中那样使用散列值填充。

那么，口令出什么问题了？口令仍然存储在数据库中（在表USER$ 中），但它在D BA_USERS 视图中不可见。

当用户被创建为全局或外部认证时，其状态指示为GLOBAL 或EXTE RNAL，但不显示口令的散列值。

接下来，注意PASSWORD_VERSIONS 列，它是Oracle 数据库11g 中新增的。

该列表明口令是否区分大小写。

值“10G 11G”的意思是，用户要么是在10g 中创建然后移植到11g 中的，要么是直接在11g 中创建的。

如果您希望的话，在创建口令文件时，您也可以输入一个新参数ignorecase 来实现SYSDBA 口令的大小写区分，如下所示：在以上示例中，SYSDBA 的口令将为abc123，而不是ABC123 或任何其他大小写变体。

通过采用区分大小写的口令，不仅使得强行破解口令更为困难，同时能够使您满足更多合规性要求。

更为重要的是，您可以动态地执行口令要求而不必关闭数据库。

在进行升级或因升级原有应用程序而对登录问题进行调试时，这是非常有用的。

概要文件和口令验证功能还记得Oracle 数据库中的口令验证功能吗？很多人甚至可能都不知道它的存在，更不要说使用它了。

该功能是快速、轻松地确保数据库口令的质量—例如，口令应当包含一定数目的字符，不应当与用户名相同，等等。

也许它的最佳特色在于它是内置的，您只需要启用它即可。

但很可能的是，您并没有启用该功能。

在Oracle 数据库11g 中，口令管理功能具有新的经过改进的验证逻辑。

如果您查看$ORAC LE_HOME/rdbms/admin 下的口令验证文件utlpwdmg.sql，您会发现脚本新建了一个名为verify_f nction_11g 的口令函数。

脚本末尾的语句如下所示：脚本将该函数附加到概要文件DEFAULT 中。

除非明确分配了其他文件，该文件是所有用户的默认概要文件。

这使得认证符合许多规定的要求。

您要做的只是运行该脚本以创建11 g 版的口令检查函数，该脚本将通过将自身附加到默认概要文件中来启用口令验证功能。

改进的即需即用的审计审计是另一个常见难题。

Oracle 数据库包括强大的审计功能，可用于跟踪用户活动。

大多数人由于担心I/O 争用问题，并不利用审计功能。

但事实上，一些审计可以被安全打开而风险却很小。

相关的示例包括CREATE SESSION，它在会话开始时编写一条记录，然后在会话结束时更新该记录。

该审计对I/O 的影响极小，但带来了众多好处。

在Oracle 数据库11g 中，进行了两个简单的改动以提供更强大的审计解决方案。

首先，数据库参数audit_trail 现在默认情况下设置为DB，在以前的版本中，它的默认值为NONE.这允许您对任何对象、语句或权限打开审计，而无需重复使用数据库。

第二处改动是，默认情况下更多语句处于审计范围内。

清单如下：如您所见，审计这些活动不会导致严重的I/O 问题，因此，可将审计活动维持在可接受水平，同时对性能的影响最小。

这两处改动带来了一些强大的即需即用的审计功能。

当然，它们只是一些数据库参数和审计设置；如果需要的话，您可以轻松地关闭它们。

但如果您看看这些语句清单，您实际上会发现即使在开发数据库中，它们也是值得审计的。

不过，您可能想对它们进行细微的调整。

（例如，在数据仓库中，用户创建并删除大量临时表，因此审计CREATE/DROP TABLE 可能会在审计线索中泛滥。

）（警告：当您升级到Oracle 数据库11g 时，默认情况下上述语句的审计将打开。

因此，审计线索将写入到SYSTEM 表空间中的表AUD$ 中，这些审计线索将迅速填充。

密切关注该表空间。

透明表空间加密由于各种新的法律法规，人们现在对加密的重视程度越来越高。

您需要以某种方式对数据进行加密，但最大的问题在于如何加密？对于仍然使用Oracle 数据库10g 第 1 版和以前版本的人来说，DBMS_CRYPTO 和DBMS _OBFUSCATION_TOOLKIT 工具包允许您构建自己的加密框架。

在Oracle 数据库10g 第2 版中，该框架通过透明数据加密特性得以增强。

透明数据加密使您可以对特定列进行加密，这足以满足大多数要求。

然而，性能仍然是该特性的一个问题（或者说，任何其他加密解决方案都存在着性能问题）：索引范围扫描不能应用于加密列，这会对性能造成严重的负面影响。

这正是Oracle 数据库11g 中透明表空间加密的真正出色之处。

当表空间声明已加密时，表空间（包括透明表空间、备份等）上的任何数据都已加密，而不仅仅是单独声明为已加密的表。

但在进行索引扫描时，扫描发生在未对数据进行加密的内存中，因而不会对性能造成影响。

感觉激动吗？让我们看一下它的工作原理。

加密过程与透明数据加密过程相同：您需要创建一个钱夹以存储主加密密钥。

如果您还没有设置透明数据加密，则需要创建钱夹和密钥。

首先，创建钱夹的文件位置；默认位置为$ORACLE_BASE/admin//wallet.默认情况下钱夹子目录并不存在，您需要进行创建。

因此，在我的示例中，该目录为/home/oracle/app/admin/PRODB3/ wallet.接下来，执行下面的语句以在钱夹中创建加密密钥：该语句同时创建钱夹和密钥。

如果您现在检查该目录，您会看到刚刚创建的钱夹文件（ewallet.p12）。

钱夹要使用口令才能打开，在本例中，口令为abcd1234！。

该语句也可以打开钱夹。

以后，您无需再创建钱夹了。

数据库启动后，您只需通过执行以下语句来打开钱夹：现在创建表空间：子句“encryption using …… default storage （encrypt）”将表空间标记为经过加密的。

（注：我们对此表空间使用了AES 128 位加密算法。

其他选择包括Triple DES 168 位密钥算法、AES 192 位密钥算法和AES 256 位密钥算法。

）既然已经创建了表空间，您就可以像在常规表空间中那样创建表了。

上述语句在加密的表空间SECURE1 中创建了表。

为进行比较，以正常方式（不加密）创建另一个名为INSECURE1 的表空间，并在其中创建表INSECURE_TRANS 和INSECURE_RES.INS ECURE_TRANS 和SECURE_TRANS 在结构和数据方面相同，但位于不同的表空间中。

SECUR E_RES 和INSECURE_RES 也是如此。

现在更新这些表中的一个文本字段，以便在数据文件中搜索该字段：通过使表空间先脱机再联机，将内容强制写到磁盘上：此时，缓存中的数据已经写到磁盘上。

搜索该字段，看会发生什么？该字符串以明文形式出现在数据文件中。

现在，对经过加密的SECURE1 表空间执行同样的操作。

该操作不会返回任何结果，因为数据文件是加密的，您不会以明文形式看到各列的值。

一切都完美无缺，但性能怎么样呢？我们运行以下查询来体验一下。

运行该查询时，我们也会对其进行跟踪。

下面是跟踪文件的节选。

现在，对INSECURE_RES 和INSECURE_TEST 运行相同的测试，它们处于正常的（未加密的）表空间内。

注意各例中的执行时间，它们都是相似的。

因解密而导致的CPU 消耗也并不显著。

因此，表空间加密不会对性能产生影响。

DBA_TABLESPACES 视图有一个新列ENCRYPTED，该列用于显示某个表空间是否已加密。

此外，一个名为V$ ENCRYPTED_TABLESPACES 的新视图用于显示针对该表空间启用的加密类型。

该视图可以和V$TABLESPACE 视图的TS# 列结合，以获得完整的信息。

下面是该视图的外观：注意，ENCRYPT_IN_BACKUP 列和透明表空间加密没有任何关系。

相反，它是备份期间表空间的RMAN 加密，是在Oracle 数据库10g 第2 版中引入的。

如您所见，透明表空间加密以一种相当完美的方式解决了两个问题：它对磁盘上处于静止状态的数据进行加密，由于数据管理发生在SGA 内，因此不会影响性能。

Data Pump 转储文件的加密Oracle 数据库10g 引入了用于数据移动的最强大的特性之一：Data Pump，它用于代替原来的导出/导入工具。

除了速度更快之外，Data Pump 还具有很多优点，如并行化进程和重新映射表空间。