现实中的细粒度审计(1)

现实中的细粒度审计(1)

作者：Arup Nanda

了解如何使用 Oracle 数据库的细粒度审计特性来跟踪对表中特定行的只读访问 — 以及更多信息

传统的 Oracle 数据库审计选件允许您在宏观级别上跟踪用户在对象上所执行的操作 — 例如，如果您审计对某个表的 SELECT 语句，则可以跟踪是谁从表中选择了数据。但是，您不知道他们选择了什么。利用数据操纵语句 — 如 INSERT、UPDATE 或 DELETE — 您可以通过使用触发器或使用 Oracle LogMiner 实用程序来分析归档日志，从而捕获任何的更改。因为简单的 SELECT 语句是不操纵数据的，它们既不启动触发器，也不记入到那些以后可以进行挖掘的归档日志中，所以这两种技术在涉及到 SELECT 语句的地方无法满足要求。

Oracle9i Database 推出了一种称为细粒度审计 (FGA) 的新特性，它改变了这种局面。该特性允许您将单个的 SELECT 语句联同用户提交的确切语句一起进行审计。除了简单地跟踪语句之外，FGA 还通过在每次用户选择特定的数据集时执行一段代码，提供了一种方法来模拟用于 SELECT 语句的触发器。在分为三部分的这一系列文章中，我将说明如何使用 FGA 解决实际问题。这第一部分的主要内容是构建基本的 FGA 系统。

示例安装

我们的示例基于一个银行系统，已经通过应用程序级的审计按照传统提供了用户访问特定数据的审计线索。但是，只要用户使用诸如 SQL*Plus 等工具从应用程序以外的地方访问数据，该系统就不能满足要求。在本文中，我将说明作为 DBA 的您能够如何使用 FGA 来完成捕获用户对特定行的 SELECT 访问的任务，无论访问的工具或机制是什么。

在我们的示例中，数据库有一个名为 ACCOUNTS 的表，由模式 BANK 拥有，其结构如下：

Name              Null?    Type
 ---------------- -------- ------------
ACCT_NO           NOT NULL NUMBER
CUST_ID           NOT NULL NUMBER
BALANCE                    NUMBER(15,2) 

为了构造一个能够对任何在此表中选择的用户进行审计的系统，您需要定义对该表的 FGA 策略如下：

begin
dbms_fga.add_policy (
object_schema=>'BANK',
object_name=>'ACCOUNTS',
policy_name=>'ACCOUNTS_ACCESS'
  );
end;

这段代码必须由具有执行程序包 dbms_fga 权限的用户来执行。但是，为了提高安全性，建议不要对用户 BANK（将要被审计的表的所有者）授予执行权限；而应该将权限授予一个安全的用户（比如 SECMAN），此用户应该执行添加策略的过程。

在定义了策略以后，当用户以通常的方式对表进行查询时，如下所示：

select * from bank.accounts; 

审计线索记录此操作。您可以使用以下语句查看线索：

select timestamp, 
db_user,
os_user,
object_schema,
object_name,
sql_text
from dba_fga_audit_trail;

TIMESTAMP DB_USER OS_USER OBJECT_ OBJECT_N SQL_TEXT
--------- ------- ------- ------- -------- ----------------------
22-SEP-03 BANK    ananda  BANK    ACCOUNTS select * from accounts

注意名为 DBA_FGA_AUDIT_TRAIL 的新视图，它记录细粒度的访问信息。其中显示了审计事件的时间标记、查询者的数据库用户 ID、操作系统用户 ID、查询中所使用表的名称和所有者，最后还有确切的查询语句。在 Oracle9i Database 之前不可能得到这种信息，但随着 FGA 的推出，获得此信息变得轻而易举。

在 Oracle9i Database 中，FGA 只能捕获 SELECT 语句。利用 Oracle Database 10g，FGA 还可以处理 DML 语句 — INSERT、UPDATE 和 DELETE — 使其成为完整的审计特性。在本系列的第 3 部分，我将详细说明这些新的功能。

审计列和审计条件

让我们更详细地检查前面的示例。我们要求审计对该表所使用的任何 SELECT 语句。但是在现实中，可能不必要这样做，并且这样可能会使存储线索的审计表承受不起。当用户选择含有敏感信息的余额列时，银行可能需要进行审计，但当用户选择特定客户的帐号时，可能不需要进行审计。列 BALANCE（选择它可触发审计）称为审计列，在此情况下，dbms_fga.add_policy 过程的参数指定该列如下：

audit_column => 'BALANCE'

如果每次用户从表中选择时都记录审计线索，则线索的大小将增长，导致空间和管理问题，因此您可能希望只有在满足特定条件时进行审计，而不是每次都进行审计。也许只有当用户访问极为富有的户主帐号时，银行需要审计 — 例如，只有当用户选择了余额为 11,000 美元或更多的帐号时需要审计。这种类型的条件称为审计条件，并作为一项参数传递到 dbms_fga.add_policy 过程，如下所示：

audit_condition => 'BALANCE >= 11000'

让我们来看这两个参数如何起作用。现在策略定义的形式类似于：

begin
dbms_fga.add_policy (
object_schema=>'BANK',
object_name=>'ACCOUNTS',
policy_name=>'ACCOUNTS_ACCESS',
audit_column => 'BALANCE',
audit_condition => 'BALANCE >= 11000'
  );
end;

在此情况下，只有当用户选择列 BALANCE 并且检索的行包含大于或等于 $11,000 的余额时，才会审计该操作。如果这两个条件中有一个不为真，则该操作不会被写入到审计线索中。表 1 中的示例演示了何时审计操作和何时不审计操作的各种情况。

优化器模式

FGA 需要基于开销的优化 (CBO)，以便正确地工作。在基于规则的优化时，只要用户从表中进行选择，无论是否选择了相关的列，都始终生成审计线索，增加了误导项目出现的可能性。为使 FGA 正确地工作，除了在实例级启用 CBO 之外，在 SQL 语句中应该没有规则暗示，并且必须至少使用评估选项对查询中的所有表进行分析。