从事IT基础架构多年,发现自己原来更合适去当老师……喜欢关注新鲜事物,不仅限于IT领域。
分类: Oracle
2007-02-05 10:18:53
前两天同事突然问我有没办法对查询进行审计,想了想似乎只有FGA了,转贴一篇oracle官网的文章,说明一下简单的使用方法,在oracle联机文档上有详细的使用说明.
传统的 Oracle 数据库审计选件允许您在宏观级别上跟踪用户在对象上所执行的操作 — 例如,如果您审计对某个表的 SELECT 语句,则可以跟踪是谁从表中选择了数据。但是,您不知道他们选择了什么。利用数据操纵语句 — 如 INSERT、UPDATE 或 DELETE — 您可以通过使用触发器或使用 Oracle LogMiner 实用程序来分析归档日志,从而捕获任何的更改。因为简单的 SELECT 语句是不操纵数据的,它们既不启动触发器,也不记入到那些以后可以进行挖掘的归档日志中,所以这两种技术在涉及到 SELECT 语句的地方无法满足要求。
推出了一种称为细粒度审计 (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 语句。利用 ,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 的余额时,才会审计该操作。如果这两个条件中有一个不为真,则该操作不会被写入到审计线索中。 中的示例演示了何时审计操作和何时不审计操作的各种情况。
优化器模式
FGA 需要基于开销的优化 (CBO),以便正确地工作。在基于规则的优化时,只要用户从表中进行选择,无论是否选择了相关的列,都始终生成审计线索,增加了误导项目出现的可能性。为使 FGA 正确地工作,除了在实例级启用 CBO 之外,在 SQL 语句中应该没有规则暗示,并且必须至少使用评估选项对查询中的所有表进行分析。
管理 FGA 策略
在前文中您看到了如何添加 FGA 策略。要删除策略,您可以使用以下语句:
begin dbms_fga.drop_policy ( object_schema => 'BANK', object_name => 'ACCOUNTS', policy_name => 'ACCOUNTS_ACCESS' ); end;
对于更改策略而言,没有随取随用的解决方案。要更改策略中的任何参数,必须删除策略,再使用更改后的参数添加策略。
有时您可能需要临时禁用审计收集 — 例如,如果您希望将线索表移动到不同的表空间或者要删除线索表。您可以按如下方法禁用 FGA 策略:
begin dbms_fga.enable_policy ( object_schema => 'BANK', object_name => 'ACCOUNTS', policy_name => 'ACCOUNTS_ACCESS', enable => FALSE ); end;
要重新启用它,可使用同一函数,但是将参数 enable 设置为 TRUE。
处理器模块
FGA 的功能不只是记录审计线索中的事件;FGA 还可以任意执行过程。过程可以执行一项操作,比如当用户从表中选择特定行时向审计者发送电子邮件警告,或者可以写到不同的审计线索中。这种存储代码段可以是独立的过程或者是程序包中的过程,称为策略的处理器模块。实际上由于安全性原因,它不必与基表本身处于同一模式中,您可能希望特意将它放置在不同的模式中。由于只要 SELECT 出现时过程就会执行,非常类似于 DML 语句启动的触发器,您还可以将其看作 SELECT 语句触发器。以下参数指定将一个处理器模块指定给策略:
handler_schema 拥有数据过程的模式
handler_module 过程名称
处理器模块还可以采用程序包的名称来代替过程名称。在这种情况下,参数 handler_module 在 package.procedure 的格式中指定。
FGA 数据字典视图
FGA 策略的定义位于数据字典视图 DBA_AUDIT_POLICIES 中。 包含该视图中一些重要列的简短描述。
审计线索收集在 SYS 拥有的表 FGA_LOG$ 中。对于 SYS 拥有的任何原始表,此表上的某些视图以对用户友好的方式显示信息。DBA_FGA_AUDIT_TRAIL 是该表上的一个视图。 包含该视图中重要列的简短描述。
一个重要的列是 SQL_BIND,它指定查询中使用的绑定变量的值 — 这是显著增强该工具功能的一项信息。
另一个重要的列是 SCN,当发生特定的查询时,它记录系统更改号。此信息用于识别用户在特定时间看到了什么,而不是现在的值,它使用了闪回查询,这种查询能够显示在指定的 SCN 值时的数据。我将在本系列的第 2 部分中详细说明这种功能强大的特性。
视图和 FGA
到目前为止我已经讨论了在表上应用 FGA;现在让我们来看如何在视图上使用 FGA。假定在 ACCOUNTS 表上定义视图 VW_ACCOUNTS 如下:
create view vw_accounts as select * from accounts;
现在,如果用户从视图中而不是从表中进行选择:
select * from vw_accounts;
您将看到以下审计线索:
select object_name, sql_text from dba_fga_audit_trail; OBJECT_NAME SQL_TEXT ----------- ------------------------------------------------- ACCOUNTS select * from vw_accounts
注意,是基表名称而不是视图名称出现在 OBJECT_NAME 列中,因为视图中的选择是从基表中进行选择。但是,SQL_TEXT 列记录了用户提交的实际语句,而这正是您希望了解的。
如果您只希望审计对视图的查询而不是对表的查询,可以对视图本身建立策略。通过将视图名称而不是表的名称传递给打包的过程 dbms_fga.add_policy 中的参数 object_name,可以完成这项工作。随后 DBA_FGA_AUDIT_TRAIL 中的 OBJECT_NAME 列将显示视图的名称,并且不会出现有关表访问的附加记录。
其它用途
除了记录对表的选择访问,FGA 还可用于某些其它情况:
结论
FGA 使您在 Oracle 数据库中支持隐私和职能策略。因为审计发生在数据库内部而不是应用程序中,所以无论用户使用的访问方法是什么(通过诸如 SQL*Plus 等工具或者应用程序),都对操作进行审计,允许进行非常简单的设置。
SQL 语句 | 审计状态 |
select balance from accounts; | 进行审计。用户选择了在添加策略时所指定的审计列 BALANCE。 |
select * from accounts; | 进行审计。即使用户没有明确指定列 BALANCE,* 也隐含地选择了它。 |
select cust_id from accounts where balance < 10000; | 进行审计。即使用户没有明确指定列 BALANCE,where 子句也隐含地选择了它。 |
select cust_id from accounts; | 不进行审计。用户没有选择列 BALANCE。 |
select count(*) from accounts; | 不进行审计。用户没有明确或隐含地选择列 BALANCE。 |
OBJECT_SCHEMA | 对其定义了 FGA 策略的表或视图的所有者 |
OBJECT_NAME | 表或视图的名称 |
POLICY_NAME | 策略的名称 — 例如,ACCOUNTS_ACCESS |
POLICY_TEXT | 在添加策略时指定的审计条件 — 例如,BALANCE >= 11000 |
POLICY_COLUMN | 审计列 — 例如,BALANCE |
ENABLED | 如果启用则为 YES,否则为 NO |
PF_SCHEMA | 拥有策略处理器模块的模式(如果存在) |
PF_PACKAGE | 处理器模块的程序包名称(如果存在) |
PF_FUNCTION | 处理器模块的过程名称(如果存在) |
SESSION_ID | 审计会话标识符;与 V$SESSION 视图中的会话标识符不同 |
TIMESTAMP | 审计记录生成时的时间标记 |
DB_USER | 发出查询的数据库用户 |
OS_USER | 操作系统用户 |
USERHOST | 用户连接的机器的主机名 |
CLIENT_ID | 客户标识符(如果由对打包过程 dbms_session.set_identifier 的调用所设置) |
EXT_NAME | 外部认证的客户名称,如 LDAP 用户 |
OBJECT_SCHEMA | 对该表的访问触发了审计的表所有者 |
OBJECT_NAME | 对该表的 SELECT 操作触发了审计的表名称 |
POLICY_NAME | 触发审计的策略名称(如果对表定义了多个策略,则每个策略将插入一条记录。在此情况下,该列显示哪些行是由哪个策略插入的。) |
SCN | 记录了审计的 Oracle 系统更改号 |
SQL_TEXT | 由用户提交的 SQL 语句 |
SQL_BIND | 由 SQL 语句使用的绑定变量(如果存在) |