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$ 中，这些审计线索将迅速填充。密切关注该表空间。

透明表空间加密