3.3 将 DBA 脚本移动到计划程序

背景
那些需要登录数据库来执行统计数据收集、索引重建等操作的非常常见的 DBA 脚本如何？以往，DBA 使用 cron（或在 Windows 中使用 AT）作业方法运行工作，但是该方法存在两个风险：

1. 如果此脚本需要登录到数据库（大部分 DBA 脚本均如此），则必须在脚本中设置用户 ID 和口令，或者以某种方式将其传递到脚本。因此，任何可以访问该脚本的用户都能够知道该口令。
2. 更糟糕的是，任何可以访问服务器的用户都可以执行 ps -aef 命令来查看过程名称中的口令。

您需要防止口令曝露！

在 Oracle 数据库 10g 第 1 版以及更高版本中，您可以通过数据库作业来管理此过程，这是一个极好的方法。注意，在 Oracle 数据库 10g 之前，对数据库作业的管理是通过 dbms_job 提供的程序包进行的，该程序包可以执行一个 PL/SQL 程序包、代码段或普通的 SQL，但无法执行 OS 可执行文件。在 Oracle 数据库 10g 中，新的作业管理系统是提供的程序包 dbms_scheduler（简写为 Scheduler）。除了提供一个明显改进的用户界面以外，该工具还有一个很大的优点：它甚至可以执行 OS 可执行文件 - 全部从 Oracle 数据库中执行！此功能使得实施一站式作业管理系统变得非常容易。

下面是一个例子。假设您有一个收集优化程序统计数据的 cron 作业，如下所示。

00 22 * * 6 /proprd/oracle/dbawork/utils/bin/DbAnalyze -d PROPRD1 -f DbAnalyze_PROPRD1_1.cfg 2>&1 1> /tmp/DbAnalyze1.log 

您可以看到，以下作业：

• 运行一个名为 /proprd/oracle/dbawork/utils/bin/DbAnalyze -d PROPRD1 -f DbAnalyze_PROPRD1_1.cfg 的程序。
• 在每周六午夜零点 22 分运行
• 将输出写入文件 /tmp/DbAnalyze1.log

现在，为将该作业转换为一个 Scheduler 工作，您将使用下列代码段：

1  BEGIN
2   DBMS_SCHEDULER.create_job
3     (job_name        => 'Dbanalyze',
4      repeat_interval => 'FREQ=WEEKLY; BYDAY=SAT BYHOUR=0 BYMINUTE=22',
5      job_type        => 'EXECUTABLE',
6      job_action      => '/proprd/oracle/dbawork/utils/bin/DbAnalyze -d
PROPRD1 -f DbAnalyze_PROPRD1_1.cfg',
7      enabled         => TRUE,
8      comments        => 'Anlyze'
  9   );
10  END;

该过程的参数具有自我说明性；日历语法与英语几乎相同。（有关 Scheduler 的更多详细信息，请参阅此 OTN 文章或我撰写的图书 Oracle PL/SQLfor DBA （O'Reilly Media，2005）

既然功能强大的 cron 可供使用，为什么还要为 Scheduler 而费心呢？实际上，原因是多方面的：

• 仅当数据库可用时 Scheduler 才运行作业，这是支持以数据库为中心的作业的一大特性。您不必为检查数据库是否打开而担心。
• 各个 OS 之间的 Scheduler 语法是一致的。如果要移植，只需将代码移动到新的服务器上即可，并且只需执行一个非常简单的导出导入操作便可以启用您的计划作业。
• 与对象一样，Scheduler 作业归用户所有，这使您可以实现更好级别的权限（例如，由不同的用户执行一项作业），这一点与 cron不同，后者通常是由单个 Oracle 软件拥有者帐户使用的。
• 最值得称道的是，由于您不必在任何位置设置口令，因此并不存在意外泄露口令的风险。由于口令未存储在任何位置，因此即使 SYS 用户也无法知道用户的口令。此功能使 Scheduler 这一工具对于安全地管理 DBA（或常规用户的）的工作极具吸引力。
• 此外，您不必担心所做的更改，如用户口令更改。

可能的影响
无，只要作业与数据库相关。有一点可以肯定的是，即使当数据库不可用时，某些作业也必须运行 - 例如，将警报日志移动到不同的位置或检查数据库是否启动并正在运行的作业。这些作业应位于数据库的外部以及 cron 的内部。

操作计划

1. 标识 cron 中的数据库作业。
2. 确定即使在数据库关闭时仍应运行的工作（例如：每天将监听器日志移动到其他位置的作业）
3. 对于其余的作业，创建 Scheduler 作业，这些作业最初通过在 CREATE_JOB 过程中声明 ENABLED=FALSE 而被禁用。
4. 使用 dbms_scheduler.run_job() 过程测试作业的执行情况。
5. 如果成功，则关闭 cron 作业并使用 dbms_scheduler.enable() 过程启用 Scheduler 作业。

背景
程序包、过程、函数、类型主体以及对象方法等编程对象包含企业的业务逻辑。对它们所做的任何改动都可能会影响总体处理逻辑，并且根据其配置情况，对生产系统的影响可能是灾难性的。

许多企业通过实施一个安全的更改-控制过程来解决此问题。在此过程中，更改首先经过讨论和审批（理想情况下在至少两个人之间进行），然后才能实施。所面临的难题是让系统自动运行，这实际上也是许多辖区和行业中的要求。

• 应用程序超级拥有者（如果需要，可以是 DBA）将要更改的程序“解锁”
• 应用程序拥有者更改程序主体
• 超级拥有者锁定程序

鉴于 Oracle 数据库不包含适用于 DDL 的原生锁定机制，您将如何实施该过程？

方法之一是撤消模式拥有者的 create session 系统特权，使其始终无法登录以进行更改。取而代之的是，由有权更改指定模式的对象的应用程序拥有者进行更改。这是一个非常不错的关键数据库对象保护方法，具体体现在它支持为对象更改创建审计跟踪，而其中的跟踪可以追溯到实际用户，而非一般的模式名称。

例如，假设模式为 BANK，表名称为 ACCOUNTS。通过撤消 BANK 的 create session 权限可以禁止其登录数据库。取而代之的是，您允许拥有 create session 权限的 SCOTT 修改 ACCOUNTS。Oracle 用户 SCOTT 实际上由真人用户 Scott 拥有，任何其他人都无法访问此用户 ID。SCOTT 对 ACCOUNTS 所做的任何更改都可以直接归因于用户 Scott，从而使职责性成为安全基础架构可行性的主要组成部分。

通常情况下，要使用该方法锁定程序，您应当撤消 SCOTT 的权限。当需要更改程序时，您可以再次赋予该权限（即允许 SCOTT 更改程序），然后再次撤消该授权。

可以肯定的是，这并不是一个处理安全性的巧妙方法。很快您就会遇到问题 - 权限管理并不像“每个对象一个用户”那样简单。在典型的数据库基础架构中，数以百计的用户将获得数以千计的对象的多种类型的权限。撤消权限将消除复杂的依赖关系并带来令人头痛的管理问题。

一个可管理性更高的解决方案是使用 DDL 触发器。使用此方法，您可以根据需要建立授权，但通过 DDL 触发器控制更改。

例如，假设您想要保护模式 ARUP 中一个名为 SECURE_PKG 的程序包。您将创建一个 DDL 模式触发器，如下所示：

1  create or replace trigger no_pkg_alter
2  before ddl
3  on arup.schema
4  begin
5     if (
6          ora_dict_obj_name = 'SECURE_PKG'
7          and
8          ora_sysevent = 'CREATE'
  9     )
10     then
11          raise_application_error (-20001,'Can''t Alter SECURE_PKG');
12     end if;
13  end;
 14  /

在第 6 行和第 8 行中，您检查是否对该程序包进行了更改。注意，对程序包的更改是由 create or replace package 语句做出的；因此，检查的事件是 create。如果您要确保表不受更改，可以在该值中使用 alter。在第 11 行中，当程序包被更改时将产生错误。

设置该触发器后，当拥有权限的用户尝试更改此程序包，甚至当对象的拥有者 (ARUP) 尝试通过运行程序包创建脚本重新创建该程序包时：

create or replace package secure_pkg

他将收到错误：

ERROR at line 1:
ORA-00604:error occurred at recursive SQL level 1
ORA-20001:Can't Alter SECURE_PKG
ORA-06512:at line 8

如果您确实要修改此程序包，可以请求 DBA 通过禁用触发器对它解锁：

alter trigger no_pkg_alter disable
/ 

现在，程序包创建脚本将开始运行。完成运行后，请求 DBA 启用触发器以将其锁定。基础权限保持不变。即便当您允许模式拥有者登录并修改他们所拥有的对象时，该方法也会保护这些对象。此策略支持对更改管理采用一种二人方法。

可能的影响
无，只要每个人都知道当对象准备更改时，DBA 必须解除对象锁定即可。如果您在正式的更改控制过程中加入了此步骤，它将以最主动的方式对可靠性产生影响。

操作计划

1. 为所有应锁定的对象创建一个列表。注意，并非所有对象都需要进行如此严格的控制，例如，应用程序所有者为保存中间值而创建的临时表就不需要。
2. 根据列表中的所有这些对象名称创建触发器。使该触发器在初始状态下处于禁用状态。不要将此功能添加到现有触发器中。您应该能够独立控制此触发器。
3. 标识应解除对象的用户。该用户也许是您。
4. 记录应何时锁定和解除锁定对象、工作流等。
5. 启用该触发器。

背景
在设计任何安全性系统时，最初都应彻底、准确地了解用户如何访问该系统及其访问模式，否则您将没有比较“基线”。作为一名 DBA，您应了解用户及其应用程序和访问机制（如访问源、涉及的 DDL 等）。

策略
在这种情况下使用 Oracle 审计将非常方便。您不必编写大量登录/注销触发器以及复杂的 PL/SQL 代码片断。相反，只需在数据库初始化参数文件中设置以下参数即可启用审计：

audit_trail = db 

然后重新利用数据库。设置后，请以 DBA 用户的身份执行以下命令。

audit session;

该语句将对所有会话级的活动（如登录和注销）启用审计。它至少显示了登录用户、登录时间、登录源自的终端、IP 地址、主机等等。

打开审计后，可以通过执行以下 SQL 监视活动。

select to_char(timestamp,'mm/dd/yy hh24:mi:ss') logon_ts,
username,
os_username,
userhost,
terminal,
to_char(logoff_time,'mm/dd/yy hh24:mi:ss') logoff_ts
from dba_audit_trail
where logoff_time is not null;

LOGON_TS           USERNAME        OS_USERNAM USERHOST        TERMINAL        LOGOFF_TS
------------------ --------------- ---------- --------------- --------------- ------------------
01/11/06 20:47:06  DELPHI          sgoper     stcdelpas01     unknown         01/11/06 20:48:46
01/11/06 20:48:21  DELPHI          sgoper     stcdelpas01     unknown         01/11/06 20:48:38
01/11/06 20:48:41  DELPHI          sgoper     stcdelpas01     unknown         01/11/06 20:49:19
01/11/06 20:36:03  STMT            crmapps    stcdwhpd        pts/3           01/11/06 20:36:03
01/11/06 20:36:04  STMT            crmapps    stcdwhpd        pts/3           01/11/06 20:37:40

从该输出中您可以清楚地看到连接到数据库的用户 ID、他们的 OS 用户 ID (OS_USERNAME) 以及他们注销的时间。如果他们从与数据库服务器相同的服务器中连接，则他们的终端 ID 将显示在 TERMINAL 列的下方 (pts/3)。如果他们从其他服务器连接，则此终端 ID 将显示在 USERHOST 列 (stcdelpas01) 中。

了解如何显示该信息后，可以构造查询来获得更有用的信息。例如，一个典型的问题是“用户通常从哪些计算机连接？”以下 SQL 语句将快速获得答案：

select userhost, count(1)
from dba_audit_trail
group by userhost
order by 2
/

audit select, insert, update, delete on ccmaster.credit_cards;

USERHOST          COUNT(1)
--------------- ----------
stccampas01            736
stcdwhpd              1235
stcdelpas01           2498

您可以看到，该输出表明大多数连接均来自客户机 stcdelpas01，而下一个最大连接数来自 stcdwhpd（数据库服务器本身的名称）。您可能对此感到吃惊，因为您可能已经假设连接来自外部。

下一个问题可能是：“哪个用户直接从服务器访问数据库？”另一个 SQL 片断将为您提供该信息：

select os_username, username, count(1)
from dba_audit_trail
where userhost = 'stcdwhpd'
group by os_username, username
order by 3
/

OS_USERNAME USERNAME COUNT(1)
----------- -------- --------
oracle      SYS           100
oracle      DBSNMP        123
oracle      PERFSTAT      234
infrap      DW_ETL       1986

该输出清楚地表明 OS 用户 infrap 在服务器本身中运行了某个程序并以 DW_ETL 的身份连接。这是否正常？请询问该用户。如果未收到合理的响应，则应收集更多信息。关键是要知道有关用户的所有信息：他们的身份、他们来自哪里以及他们执行了什么操作。

另一个可以从审计跟踪中获得的重要信息部分是关于过去可能进行的攻击的证据。当恶意攻击者发起攻击时，他可能不会每次都获得正确的口令，因此他可能采用强行攻击方法，即不断尝试猜测口令，然后登录。

可以通过从审计跟踪中标识用户名/口令组合的模式来检测此类攻击。线索体现在 RETURNCODE 列，该列存储用户在进行连接尝试时引发的 Oracle 错误代码。如果提供了错误口令，则用户将引发以下错误：

ORA-1017:invalid username/password; logon denied

select username, os_username, terminal, userhost, 
to_char(timestamp,'mm/dd/yy hh24:mi:ss') logon_ts
from dba_audit_trail
where returncode = 1017;

USERNAME        OS_USERNAM TERMINAL        USERHOST        LOGON_TS
--------------- ---------- --------------- --------------- ------------------
ABCD_APP        jnelson    STJNELSONT40    STJNELSONT40    01/11/06 10:42:19
ABCD_APP        jnelson    STJNELSONT40    STJNELSONT40    01/11/06 10:42:28
ABCD_APP        jnelson    STJNELSONT40    STJNELSONT40    01/11/06 10:43:11
PERFSTAT        oracle     pts/5           stcdwhpd        01/11/06 12:05:26
ARUP            jnelson    STANANDAT42     STJNELSONT40    01/11/06 14:09:20
ARUP            jnelson    STANANDAT42     STJNELSONT40    01/11/06 14:23:41

在该输出中，您可以清楚地看到哪个用户曾尝试使用错误口令进行连接。许多尝试可能属于正常的错误，而其他尝试可能需要调查。例如，OS 用户 jnelson 在短时间内从同一客户机以 ABCD_APP 的身份重复尝试登录并失败。紧接着，jnelson 尝试以用户 ARUP 的身份登录。现在，这一点比较可疑。注意，由于大多数攻击均来自企业内部的合法用户，因此任何模式都不值得掩盖。

在相同代码行中，您可以监视使用可能已“猜中”的用户 ID 尝试进行的登录。

select username from dba_audit_trail where returncode = 1017
minus
select username from dba_users;
(编辑:aniston)