9I新特性之细粒度访问原则
分区细粒度访问控制例如:在一个控制环境中,这个特性被用来控制两个公司对sales表的访问.每一个公司拥有的独立的应用程序sell_it和prod_opt,需要拥有不同的安全策略.第一个公司的sell_it应用程序认证的用户需要只能访问表中来自他们相同地区的记录;那就是sales.cust_id+customer.country的联合校验必须符合这个用户的地区相吻合.第二个公司的prod_opt应用程序的访问权限被设置为只能访问最近事务提交的记录上.也就是与sales.time_id相关联.在8i中,在一个细粒度访问控制中拥有这两个策略将需要开发公司共同协作部署.如果两个产品来自竞争的两个公司,这实际上是不可行的.依靠定义"应用程序设置"来强行控制对基本objects的一些特殊规定,每一个应用程序现在能够实现一系列私有的安全策略.
二:细粒度审计.
...一个提供扩展的入侵检测,捕获sql执行语句,而不是返回数据的工具.
...可以将审计策略捆绑在带有where条件的select语句的表或视图上.
...oracle用自治事务来处理用户自定义的审计事件.
...一个基于列的审计特性减少了错误审计的发生.
数据库管理系统中的审计经常被用来监控数据的访问.审计纪录是验证违反数据访问权限的基础.新的细粒度审计机制从事于执行更细小级别的审计.
新的审计原则是基于简单的用户定义关于表的查询条件的sql谓词. 谓词可以在当查询结果中返回了指定的值得时候进行审计.
在基于查询值的审计中,也有一些情形下管理员只关心某一个特定的被引用和访问列情况.因为无论一个列的查询审计发生在dml的任何部分都可以进行审计,所以oracle对这个查询的审计将不存在任何问题.
在8i中,审计项只能被设置用来监控对对象的访问权,只有一些固定的情况,比如用户id,时间戳,对象名称会被记录在审计跟踪里. 细粒度审计可以调用一个存储过程来作为审计过程的一部分.
-----------------------------------------------------------------------------------
如何进行细粒度审计
...安全管理员用dbms_fga包来为有问题的表建立审计原则.
dbms_fga.add_policy(),dbms_fga.enable_policy(),dbms_fga.disable_policy(),dbms_fga.drop_policy().
-------------------------------------------------------------------------------------
PROCEDURE ADD_POLICY
参数名称 类型 输入/输出默认值？
OBJECT_SCHEMA VARCHAR2 IN DEFAULT
OBJECT_NAME VARCHAR2 IN
POLICY_NAME VARCHAR2 IN
AUDIT_CONDITION VARCHAR2 IN DEFAULT
AUDIT_COLUMN VARCHAR2 IN DEFAULT
HANDLER_SCHEMA VARCHAR2 IN DEFAULT
HANDLER_MODULE VARCHAR2 IN DEFAULT
ENABLE BOOLEAN IN DEFAULT
--------------------------------------------------------------------------
PROCEDURE DISABLE_POLICY
参数名称 类型 输入/输出默认值？
OBJECT_SCHEMA VARCHAR2 IN DEFAULT
OBJECT_NAME VARCHAR2 IN
POLICY_NAME VARCHAR2 IN
------------------------------------------------------------------------------
PROCEDURE DROP_POLICY
参数名称 类型 输入/输出默认值？
OBJECT_SCHEMA VARCHAR2 IN DEFAULT
OBJECT_NAME VARCHAR2 IN
POLICY_NAME VARCHAR2 IN
------------------------------------------------------------------------------
PROCEDURE ENABLE_POLICY
参数名称 类型 输入/输出默认值？
OBJECT_SCHEMA VARCHAR2 IN DEFAULT
OBJECT_NAME VARCHAR2 IN
POLICY_NAME VARCHAR2 IN
ENABLE BOOLEAN IN DEFAULT
-------------------------------------------------------------------------------
...用表dba_audit_policies来列出已定义的原则.
...用表dba_fga_audit_trail来放置审计纪录.这个表包括触发审计的用户名,SQL语句,
审计名称,会话ID号,时间戳,和其他一些属性.
...管理员可以定义审计事件处理器来处理发生的时间,比如像管理员传送警告页.
--------------------------------------------------------------------------------------
下面列举一个新的细粒度原则的例子,从这个例子我们可以看出9I细粒度审计原则与8I的区别. 如果我们的原则设为:AUDIT_CONDITION='SALARY>;10000'
这个时候我们看一下我们执行
SELECT last_name,salary FROM employees WHERE last_name = ’Russell’
尽管我们选择的查询条件中没有包含SALARY列,但是由于我们的对SALARY列进行查询,如果RUSELL的SALARY值大于10000,那么这条记录将被审计.
审计纪录如下
'SELECT LAST_NAME,SALARY FROM EMPLOYEES WHERE LAST_NAME='RUSSELL',<TIMESTAMP>;,<SCN>;,
<USERNAME>;,........
如果我们执行
SELECT LAST_NAME,SALARY FROM EMPLOYEES WHERE SALARY<9000
那么尽管这条语句访问,查询了SALARY列,但是由于他访问的值未达到审计阀值,那么将不被审计.
-------------------------------------------------------------------------------------
细粒度审计只对一个有WHERE条件的SELECT语句有效,并且只能设定一个被审计的列.
上面的查询语句触发的事件不是造成用户无法查询到这些语句,这些SALARY>;10000实际上被返回
给查询用户,但是同时一个审计事件被写到审计跟踪里,包括完整的SQL语句,时间戳等信息.
细粒度审计并不自动的捕获返回给查询用户的查询结果,但是你可以用细粒度审计原则结合闪回
查询重建返回给用户的纪录.
细粒度审计能够实现数据库系统的入侵监测功能.例如,开发人员可以为一个审计增加一个事件处理器来通知管理员,是否有被审计的事件发生.非SQL的访问是不被审计的,例如:如果你使用DIRECT PATH EXPORT,这种方式绕过了数据库的SQL层,审计条件将不被触发.
------------------------------------------------------------------------------------
细粒度审计事件处理器
如何创建.
CREATE PROCEDURE catchlog (schema_name VARCHAR2,table_name VARCHAR2,policy VARCHAR2)
AS BEGIN
-- send an alert note to my pager
UTIL_ALERT_PAGER(’CatchLog:’||Table_name||SYSDATE);
END;
/
如何添加
DBMS_FGA.ADD_POLICY ( ...HANDLER_SCHEMA=>;’HRMGR’, HANDLER_MODULE=>;’CATCHLOG’);
细粒度审计事件处理器总结:
在上面的例子中,用户HRMGR创建了一个存储过程CATCHLOG,参数的类型和我们的例子必须
一致,但是名字可以改变.
审计事件处理器的添加需要一个拥有权限的用户
当第一个我们关心的行被取得时,审计事件纪录将被记录并存放下来,审计函数HRMGR.CATCHLOG
被调用. 表的查询语句用普通触发器是检测不到的，除非开启数据库审计，但是从ORACLE9i开始，提供了一个DBMS_FGA包，可以在线对单个的表进行审计并查询审计资料。但是这个包的审计过程要求数据库运行在CBO优化模式下，如果不是，可能会有意想不到的结果，这就要求对审计的表进行分析。
下面将就这个包的使用做简单的介绍，这个包共有四个过程，先介绍一下该包中的第一个过程：
PROCEDURE add_policy(object_schema IN VARCHAR2 := NULL,
object_name IN VARCHAR2,
policy_name IN VARCHAR2,
audit_condition IN VARCHAR2 := '1=1',
audit_column IN VARCHAR2 := NULL,
handler_schema IN VARCHAR2 := NULL,
handler_module IN VARCHAR2 := NULL,
enable IN BOOLEAN := TRUE);
object_schema：要审计的用户的名称，默认是本用户
object_name：要审计的对象的名称
policy_name：这次审计的策略名称，每次审计都有一个名称，区别于别的审计策略
audit_condition：审计条件（谓语动词），默认全部，如规定a=1，那么当返回的结果集中显式包含（指定该字段）或隐式包含（不指定该字段）a=1的行的时候，该查询语句将被审计。
audit_column：表示审计那些列，默认全部，如果指定列，那么只有select或者是where指定该列的时候才被审计，如果是select * 也算是隐式的指定了该列，因为*本身是包含任意列。
注：如果同时指定了audit_column与audit_condition，那么必须都满足的情况下，才能被审计，也就是说，这两个条件是一个并的关系而不是或的关系。
handler_schema：我们还可以规定在策略执行的时候，执行一个指定用户的存储过程，这里是存储过程的所有者
handler_module：指定这个策略执行的时候，执行的存储过程的名称
enable：确定审计策略是否马上生效。
很明显，该包的作用就是增加一个审计策略，object_schema、object_name与policy_name唯一确定一个审计策略，光看policy_name不能唯一确定一个策略名，不同的对象，策略名可以一样。
我们再来看第二个过程
PROCEDURE drop_policy(object_schema IN VARCHAR2 := NULL,
object_name IN VARCHAR2,
policy_name IN VARCHAR2);
object_schema、object_name与policy_name的含义和第一个包一样，只要指定这三个参数，就可以唯一的删除一个指定的审计策略。
第三、四个过程enable_policy、disable_policy第二个过程相似，就是根据object_schema、object_name与policy_name来禁止或者开启审计策略，这样对于需要多次使用同样的审计策略是很有用的，没有必要删除后重新创建，不用的时候，只需要disable就可以了，用的时候，只要enable就可以了
如果开启了handler_schema与handler_module，则需要一个handler_schema用户下的存储过程，假定名称是sp_chk_mytable，这个过程可以类似为：
CREATE PROCEDURE sp_chk_mytable (
p_object_schema VARCHAR2,
p_object_name VARCHAR2,
p_policy_name VARCHAR2) AS
BEGIN
INSERT INTO audit$proc (login_user,audit_time,ip_address,audsid,
object_schema, object_name, policy_name )
VALUES (ora_login_user,sysdate,sys_context('USERENV','IP_ADDRESS'),
userenv('SESSIONID'),p_object_schema,
p_object_name, p_policy_name );
EXCEPTION
WHEN OTHERS THEN
sp_write_log('Audit Exception:'||SQLERRM);
END sp_chk_mytable;
当然，在创建该过程之前还需要建立一个audit$proc的表，因为并不是我们讨论的重点，这个就不多说了，存储过程可以根据自己的要求来改写，以便获取信息。
以下我们将用一个例子来说明DBMS_FGA包的使用，在这个例子里面，并不包含执行指定的存储过程，也就是说，仅仅对表的审计做一个示例。
首先，我们假定我们存在表Test，包含记录为
SQL>; select * from manager.test;
A B
-- --
1 2
2 3
3 4
4 5
5 6
6 7
6 rows selected
分析该表，让其使用CBO优化模式
SQL>; analyze table test compute statistics;
Table analyzed
检查以前的审计策略与审计日志
SQL>; select t.object_schema,t.object_name,t.policy_name from dba_audit_policies t;
OBJECT_SCHEMA OBJECT_NAME POLICY_NAME
------------------------------ ------------------------------ ------------------------------
SQL>;select t.object_schema,t.object_name,t.policy_name,t.sql_text from Dba_Fga_Audit_Trail t;
OBJECT_SCHEMA OBJECT_NAME POLICY_NAME SQL_TEXT
------------------------- --------------------- --------------------- --------------------------------------
dba_audit_policies用来存放审计策略，其基表是sys.fga$，而Dba_Fga_Audit_Trail则用来存放审计日志，即执行了那些SQL语句，其基表是sys. fga_log$，其日志可以手工删除。通过以上的查询，我们也可以看到，以前没有审计策略，也没有审计日志
现在，我们在manager.Test表增加一个审计策略 SQL>; BEGIN
2 dbms_fga.add_policy( object_schema =>; 'MANAGER',
3 object_name =>; 'test',
4 policy_name =>; 'chk_test',
5 audit_condition =>; 'a = 1',
6 audit_column =>; 'b',
7 enable =>; TRUE );
8 END;
9 /
PL/SQL procedure successfully completed
我们再查询dba_audit_policies，就可以发现这条审计策略了。
SQL>; select t.object_schema,t.object_name,t.policy_name,t.enabled from dba_audit_policies t;
OBJECT_SCHEMA OBJECT_NAME POLICY_NAME ENABLED
------------------------------ ------------------------------ ------------------------------ -------
MANAGER TEST CHK_TEST YES
那么就让我们看看该审计策略怎么生效，假定我们执行如下的一些语句，这些语句都有很普遍的代表性：
SQL>; select count(*) from test where a=2;
COUNT(*)
------------
1
可以看到，该查询返回的结果集中显然没有a=1的行，所以，该查询不能被审计。
SQL>; select count(*) from test where a=1;
COUNT(*)
----------
1
有人说这个语句包含了a=1，该被审计了吧，其实不然，我们的审计条件中还有一个是审计列必须要有b，count(*)不是说是包含了b，所以该语句还是没有被审计。
SQL>; select count(*) from test where b=2;
COUNT(*)
----------
1
这个语句被审计了，因为已经包含了列b在where中，而b=2正好是a=1的行，所以a=1是被隐式包含的。
SQL>; select * from test where a=1;
A B
-- --
1 2
该语句肯定被审计，所有列肯定包含审计列b，谓语条件正好是a=1。
SQL>; select a from test where a=2;
A
--
2
这个语句肯定就不被审计了，典型的什么都不满足
SQL>; select b from test where b=2;
B
--
2
这个语句也被审计，为什么呢？这个语句包含审计列，而且隐式包含了a=1（因为a=1与b=2是同一行）
SQL>; select b from test where b=4;
B
--
4
这个语句没有被审计，因为虽然满足了审计列的条件，但是没有显式或隐式包含a=1，但是如果在您的环境中，这个语句如果被审计了，就请您确信是否分析过表，该查询是否是使用的CBO优化计划。
综合以上结果，以上被审计的语句应当是3个，检查一下了
SQL>;select t.object_schema,t.object_name,t.policy_name,t.sql_text from Dba_Fga_Audit_Trail t;
OBJECT_SCHEMA OBJECT_NAME POLICY_NAME SQL_TEXT
------------------------- --------------------- ------------------ -------------------------------------
MANAGER TEST CHK_TEST select * from test where a=1
MANAGER TEST CHK_TEST select b from test where b=2
MANAGER TEST CHK_TEST select count(*) from test where b=2
对于越来越多的审计记录，我们必须手工维护，删除没有参考价值的记录，我们可以运行如下查询来删除审计记录（需要delete any table的权限或在sys下执行）：
delete from sys.fga_log$
or
delete from Dba_Fga_Audit_Trail
到这里，大家总该明白了怎么样审计表的Select语句，同普通审计与DML触发器一样，对过多的表进行审计，将会严重影响性能。但是，在特定的情况下，如果想跟踪一个表的Select语句已便于优化，也还是可以的。
页:
[1]