例如，在我审计过的许多安装中，STATSPACK 作为 shell 脚本运行，如下所示：

export ORACLE_HOME=/u01/app/oracle/10.1/db
export ORACLE_SID=MYSID
cd $ORACLE_HOME/bin
$ORACLE_HOME/bin/sqlplus -s perfstat/perfstat @statspack.sql

然后，通过 cron 或 Windows 计划程序计划此 shell 脚本。该方法存在两个主要风险：

• 入侵者可能会找到文件 statspack.sh 并看到用户 perfstat 的口令。
• 当 shell 脚本正在运行时，*nix 服务器上的某人可以执行 ps -aef 命令，并在查看该命令运行的同时清楚地看到口令。

当我询问使用该方法的原因时，得到的答案几乎完全相同：因为以前的 DBA 就是如法炮制的。无论原因如何，威胁都是显而易见的，并且必须予以清除。

sqlplus -s scott/$SCOTTPASSWORD @script.sql

其中的 SCOTTPASSWORD 是在执行该脚本前定义的一个环境变量。当用户执行 /usr/ucb/ps uxgaeww 命令时，他可以看到将曝露口令的过程中使用的所有环境变量。因此，必须通过某种方法有效地隐藏口令。下面将对这些方法加以介绍。

方法 1.一种简单的方法是在 SQL*Plus 中使用 nolog 参数。在此方法中，前面的脚本应改为

export ORACLE_HOME=/u01/app/oracle/10.1/db
export ORACLE_SID=MYSID
cd $ORACLE_HOME/bin
$ORACLE_HOME/bin/sqlplus /nolog @statspack.sql

使用此脚本可以建立一个 SQL*Plus 会话，但该会话尚未连接到数据库。在 statspack.sql 脚本内部，应设置用户 ID 和口令：

connect perfstat/perfstat
... the rest of the script comes here ... 

这样一来，当某人执行 ps -aef 命令时，他将看不到用户 ID 和口令。（顺便提一下，对于以交互方式启动 SQL*Plus 会话而言，这也是一个最佳实践。）

方法 2.以上方法的这一小小变化形式在以下场合下很有用：SQL 语句不在 SQL 脚本中，而是直接嵌套入到 shell 脚本中，例如：

$ORACLE_HOME/bin/sqlplus user/pass << EOF
... SQL statements come here ... 
EOF

可以将此 shell 脚本改为

$ORACLE_HOME/bin/sqlplus /nolog << EOF
connect user/pass
... SQL statements come here ... 
EOF

该方法对于构建快捷而质量不高的 shell 脚本（用来处理 SQL）而言也是一个最佳实践。

方法 3.在该方法中，您可以创建一个包含用户 ID 和口令的口令文件，并可以在运行时间读取它们。首先，创建一个名为 .passwords 并包含所有用户 ID 和口令的文件（注意文件名前面的句点）。由于该文件名以句点开头，因此某人在使用 ls -l 命令时将看不到该文件名（但在使用 ls -la 命令时可以看到该文件名)。然后，将权限更改为 0600，以便只有拥有者能够读取它。

该文件应包含由空格分隔的用户 ID 和口令（每行一个）。

scott tiger
jane tarzan
... 等等... 

现在使用以下代码行创建另一个文件，即一个名为 .getpass.sh 的 shell 脚本（注意句点）。

fgrep $1 $HOME/.passwords | cut -d " " -f2

将此脚本的权限设置为 0700，以便任何其他人都无法看到以及执行该脚本。随后，当需要以 scott 的身份运行脚本时，您只需按如下所示对这些行进行编码即可：

.getpass.sh scott | sqlplus -s scott @script.sql

这将从文件中获得 scott 的口令并将其传递给 sqlplus 命令。如果有人执行 ps 命令，他将看不到该口令。

作为一个额外的好处，您现在已经实现了一个灵活的口令管理机制。每当 scott 的口令更改（作为一个良好的习惯，它应当定期更改）时，您只需编辑口令文件即可。

方法 4.该方法涉及由 OS 验证的用户。（在第 2 阶段您对其已经有所了解。）简单地说，如果有一个名为 ananda 的 *nix 用户，则可以使用以下语句创建一个 Oracle 用户：

create user ops$ananda identified externally;

此处，用户可以使用以下命令登录数据库

sqlplus /

注意，以上命令没有用户 ID 和口令。数据库实际上并不验证用户；它假设用户 ananda 已经在 OS 级别得到了正确地验证。尽管这不并是一个很棒的实践，但却是一个极具吸引力的实践 - 例如，对于 shell 脚本来说。您的脚本可能如下所示：

sqlplus -s / @script.sql

由于未传递用户名和口令，因此不存在通过 ps 命令将其曝露的风险。

可能的影响
无；使用口令管理系统替换硬编码的口令不会影响脚本的功能，只会影响提供口令的方式。但请确保备份口令文件或保存其副本，并且不断对其进行更新。

操作项目

1. 使用硬编码的口令标识脚本。
2. 为实施挑选一种方法：
   1. 在 SQL 脚本内部使用 Connect 命令
   2. 在 shell 脚本内部使用 Connect 命令（无 SQL 脚本）
   3. 使用口令文件
   4. 使用 OS 验证的帐户
3. 修改脚本以删除口令。

3.2 从 RMAN 中删除口令

背景
硬编码的口令并不局限于脚本。恢复管理器 (RMAN) 脚本容易受到相同不良习惯的影响。

下面是一个用于备份的脚本内部的典型 RMAN 命令：

rman target=/ rcvcat=catowner/catpass@catalog_connect_string

在该命令中，connect 字符串 catalog_connect_string 中引用了目录数据库，该目录的用户 ID 和口令分别是 catowner 和 catpass。如前所述，如果某人执行 ps 命令，则会清楚地看到该用户 ID 和口令。

删除这些硬编码的口令有两种方法：

方法 1.在该方法中，请在 RMAN 脚本内部使用 connect 字符串，如下所示：

connect target /
connect catalog catowner/catpass@catalog_connect_string
run {
	allocate channel ...
... 等等... 

这显然是首选方法 - 不仅是因为它从过程列表中隐藏了口令，还因为它使得检查目录 connect 字符串中的错误更加容易了。

方法 2.另一种方法是对目录连接使用 OS 验证。但是您需要进行一些额外的更改。首先，目录可能位于不同的数据库中，而不是位于正被备份的数据库中。要在这种情况下启用 OS 验证，您需要对目录数据库启用远程 OS 验证。

在目录数据库上，添加下列初始化参数，然后重新启动。

remote_os_authent=TRUE

现在，在 catalog 数据库上创建一个用户 ID OPS$ORACLE，如下所示。

create user ops$oracle identified externally;

现在，您的 RMAN 连接将如下所示：

rman target=/ rcvcat=/@catalog_connect_string

这将不会显示 RMAN 用户的口令或口令。

由于您现在是以 OPS$ORACLE 而不是 catowner 的身份连接的，因此必须重建信息库。连接之后，使用

RMAN> register database;

命令重建目录。您现在准备在 RMAN 备份中使用此脚本。

有多种方法可以避免这样的进入。最简单的方法是启用节点过滤（如 3.8 所述），以防任何随机服务器连接到该节点。

此外，您还应意识到，源数据库服务器上的 Oracle 软件所有者可能具有不同的名称。如果您在数据库服务器 A 上使用“orasoft”，而在数据库服务器 B 上使用“oracle”，则您需要在目录数据库上创建的用户分别是 OPS$ORASOFT 和 OPS$ORACLE。因此，将存在两个信息库，而不是一个。这并不一定是坏事。但是，如果您想要对目录中的备份进行报告，则您必须知道数据库中的所有信息库。

1. 选择一种用于隐藏 RMAN 目录所有者口令的方法：
   1. 在脚本内部使用 Connect 命令
   2. 以 OS 验证的用户身份连接
2. 如果选择 b.，则
   1. 对目录数据库启用远程 OS 验证（需要重新启动）。
   2. 在目录数据库中启用节点验证，以拒绝除已知的少数几个节点之外的所有节点。
   3. 创建名为 OPS$ORACLE 的用户。
   4. 修改 RMAN 目录连接字符串以使用 OPS$ORACLE。
3. 重建目录。

(编辑:aniston)