【经验分享】Oracle Serucity — Oracle审计技术介绍
-- Objectives
描述在安全和审计中DBA的职责;
开启标准的审计;
指定审计的选项;
查看那审计信息;
维护审计信息;
-- Database Security
1.限制数据和服务的访问:根据数据库中存放的数据类型,业务需要,对客户隐私的保护和法律限制,有些数据时严格受限访问的;比如信用卡信息,医疗数据,身份Zheng信息;Oracle提供了非常严格的细粒度的认证控制,但是首先要做到最小化权限的原则;
2.验证用户:做到最小化权限原则之后,有的用户必须要去访问敏感数据,那么系统必须要知道是谁要去访问数据;
验证用户的几个方向:
1.需要用户提供他们知道什么,最常用的就是密码,但是不安全;
2.强一点的验证是需要用户提供他们有什么,比如token,比如PKI(Public KeyInfrastructure,公钥加密和数字签名);
3.更强一点的就需要用户提供唯一的生理学特征,比如指纹,视网膜扫描,骨骼匹配;
3.监控可疑活动:尽管用户通过了验证,也要监控数据库中可疑的活动,比如查询大量的信用卡信息等等,可以第一时间检测数据库信息是否被盗;Oracle提供了大量的审计工具区跟踪用户的活动和判断可疑的动作;
-- Monitoring for Compliance,合规性监控
1.审计就是捕获数据库中发生的动作并存储起来,但是数据库中很多不同的活动,如果全都审计下来会影响系统的性能,所以我们只需要关心特定的活动审计;
2.Mandatory Auditing:不管其它审计选项或参数为何,所有Oracle数据库都会审计特定的操作;由于数据库需要记录系统启动/关闭数据库,用户连接的活动信息,所以存在强制性审计日志;
3.Standard Database Auditing:需要在系统级别打开AUDIT_TRAIL初始化参数,打开审计后,使用AUDIT命令审计相应的对象和权限;
4.Value-based Auditing:基于标准数据库审计的扩展,不仅会捕获已发生的审计事件,还会捕获插入,更新或删除的实际值;基于值审计是通过数据库触发器实现的;
5.Fine-grained Auditing(FGA):FGA扩展了标准数据库审计的功能,这种审计可捕获实际执行SQL语句,而不仅仅是发生的事件;
6.sysdba/sysoper Auditing:在DBA与审计者或安全管理员之间划分审计责任,审计者或安全管理员在操作系统审计中负责监视DBA的活动;
-- Audit Tool Comparisons
1.标准审计:主要是审计访问对象时候的权限,审计的结果是固定的格式;
2.基于值的审计:主要是审计DML语句,审计的结果由管理员定义;
3.FGA:主要是审计基于内容的SQL语句,审计的结果中包含执行的SQL;
-- Standard Database Auditing
1.为了使用标准审计,必须首先设置audit_trail参数用来指定审计日志存放的地方;
2.开启审计功能后,需要指定审计的选项,比如登陆事件,系统/对象权限,SQL语句的使用等等,数据库开始收集审计信息;
3.查看审计信息;
4.维护审计信息,把关心的数据给汇总,因为审计信息增长很快,要及时维护来避免影响数据库性能;
-- Configuring the Audit Trail
1.语法:ALTER SYSTEM SET AUDIT_TRAIL = {none | os | db [, extended] | xml [, extended] } SCOPE = SPFILE;
2.静态参数,设置后需要重启数据库;如果是使用dbca创建的,参数默认是db,如果是手动建库的话默认是none;
1.none:不打开审计;
2.os:记录审计日志到操作系统中,在linux中是audit_file_dest参数指定的目录/u01/app/oracle/admin/ORCL/adump;
3.db/db extended:记录审计信息到数据库中;sys.aud$表(sys.dba_audit_trail表是建立在aud$表上的视图);里面记录了用户登录登出的强制性审计信息;
4.xml/xml extended:以xml文件形式存在audit_file_dest参数指定的目录下,也可以通过SELECT * FROM v$xml_audit_trail视图查看对象目录下的xml文件;
-- Uniform Audit Trails
在dba_audit_trail视图(基表是aud$)中可以查看标准审计,在dba_fga_audit_trail视图(fga_log$)中可以查看FGA审计,但是为了方便分析数据库的活动,还提供了一个公共的视图dba_common_audit_trail,可以查看标准审计和FGA审计;
SELECT * FROM dba_audit_trail;
SELECT * FROM dba_fga_audit_trail;
SELECT * FROM dba_common_audit_trail;
-- Specifying Audit Options
1.SQL statement auditing:按照SQL语句审计,AUDIT TABLE,表示审计任何影响表的DDL语句(CREATE/DROP/TRUNC TABLE);
2.System-privilege auditing:按照系统权限来审计;可以使用[BY user][BY[SESSION | ACCESS]] [WHENEVER [NOT] SUCCESSFUL]子句,默认是BY ACCESS;
3.Object-privilege auditing:按照对象权限来审计,可以审计表/视图/存储过程/序列/目录对象/用户自定义类型;可以使用[BY user][BY[SESSION | ACCESS]] [WHENEVER [NOT] SUCCESSFUL]子句,默认是BY SESSION;
补充:打开帮助文档解释;
[BY user] [BY [SESSION | ACCESS]] [WHENEVER [NOT] SUCCESSFUL]
BY user:如果不指定是所有用户,指定的话是某一个用户;
BY SESSION:表示在同一个session中,相同类型的SQL语句和操作访问同一个schema中的对象,只会记录一个audit trail;
BY ACCESS:每一个审计的操作都会记录一条audit trails,对性能影响比较大;
WHENEVER [NOT] SUCCESSFUL:成功/失败时才会记录audit trals,如果不指定的话是不管成功失败都会记录;
查看设置的语句级别审计:SELECT * FROM dba_stmt_audit_opts;
查看设置的权限级别审计:SELECT * FROM dba_priv_audit_opts;
查看设置的对象级别审计:SELECT * FROM dba_obj_audit_opts;
使用ON DEFAULT子句设置的对象审计:SELECT * FROM all_def_audit_opts;
eg:用非sys用户做操作,然后在SELECT * FROM dba_audit_trail视图中查看;
-- Default Auditing
在11g中开启审计后,图中的权限和SQL语句就会被默认审计下来,默认子句只有BY ACCESS(即所有用户,无论成功失败,BY ACCESS);
-- EnterpriseManager Audit Page
Server->Audit Setting(Security);
-- Value-Based Auditing
1.标准审计记录了审计对象上插入/更新/删除记录的动作,但是并不能获取实际改变的值;基于值的审计使用数据库的触发器来获得改变的值;
2.当用户对一个表插入/更新/删除数据时触发相应的触发器,触发器在后台工作,把审计信息拷贝到审计表中;
3.基于值的审计会比标准审计更影响数据库的性能,因为每次都要执行触发器的代码,影响的程度取决于触发器的代码的复杂度;
4.基于值的审计用的场合很少,基本已经被FGA所替代了;
eg:
CREATE TABLE system.audit_employees(os_user VARCHAR(500), audit_timeDATE, ip_address VARCHAR(15), employee_id INTEGER, description VARCHAR(1000));
CREATE OR REPLACE TRIGGER system.hrsalary_audit
AFTER UPDATE OF salary ON hr.employees
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
IF :OLD.salary != :NEW.salary THEN
INSERT INTOsystem.audit_employees
VALUES
(sys_context('userenv', 'os_user'),
SYSDATE,
sys_context('userenv', 'ip_address'),
:NEW.employee_id,
'salary changed from ' || :OLD.salary || ' to ' || :NEW.salary);
END IF;
END;
UPDATE hr.employees SET salary = salary WHERE employee_id = 200;
COMMIT;
SELECT * FROM system.audit_employees;
UPDATE hr.employees SET salary = salary * 1.1 WHERE employee_id = 200;
COMMIT;
SELECT * FROM system.audit_employees;
-- Fine-Grained Auditing
1.标准审计值记录了操作的发生,而不捕获实际的SQL语句,FGA扩展了这个功能,不但可以捕获查询或者操作数据实际执行的SQL语句,还允许比标准审计和基于值的审计更加精细的审计;
2.FGA的选项可以审计到表/视图的列,甚至可以精确到某一个条件,更强大的是还可以调用存储过程;
3.主要通过DBMS_FGA包创建一个审计策略来完成,当满足审计条件时就会记录相应是审计条目到响应的审计表中;FGA默认是关心到语句级别,不管语句影响多少行的记录,只会产生一个审计条目;
-- FGA Policy
DBMS_FGA.ADD_POLICY(
object_schema VARCHAR2, -- 被审计对象的架构名,如果为NULL的话就是当前登陆用户;
object_name VARCHAR2, -- 被审计的对象名;
policy_name VARCHAR2, -- 审计策略名称,要唯一;
audit_condition VARCHAR2, -- 审计的条件,结果集中是否有满足条件的记录,如果有就审计,如果为NULL的话,就是返回TRUE;
audit_column VARCHAR2, -- 访问的列,如果是多列的话中间用[,]分割;默认是NULL,表示任何一列;
handler_schema VARCHAR2, -- 执行的存储过程的schema;
handler_module VARCHAR2, -- 执行的存储过程名称,当第一条满足审计条件的记录处理后调用,有固定的格式查看帮助文档;
enable BOOLEAN, -- 是否开启审计策略,默认是TRUE;
statement_types VARCHAR2, -- 审计的SQL语句种类:INSERT/UPDATE/DELETE/SELECT;
audit_trail BINARY_INTEGER IN DEFAULT, -- 审计条目存放的地方,默认是DB+EXTENDED,fga_log$表;
audit_column_opts BINARY_INTEGER IN DEFAULT); -- 指定是满足audit_column条件中指定的任何列还是所有列,DBMS_FGA.ANY_COLUMNS(默认)/DBMS_FGA.ALL_COLUMNS;
-- Audited DML Statement:Considerations
对于DML语句的审计,不管是新值还是旧值,只要是满足了审计策略就会被记录;
对于DELETE语句,策略中指定的audit_column参数无效,因为所有的列都会被删除语句影响到;
对于MERGE语句,它依赖于语句中使用的INSERT/UPDATE/DELETE语句的审计;
例子中审计和没有审计的原因是因为条件department_id = 10;
SELECT * FROM hr.employees WHERE commission_pct = .2 AND department_id =10;
SELECT * FROM hr.employees WHERE employee_id = 200 AND department_id =10
-- FGA Guidelines
1.如果要审计所有的记录,那么设置audit_condition=NULL;
2.如果想要审计所有的列,那么设置audit_column=NULL;
3.策略的名称必须唯一;
4.在创建策略之前,被审计的表或者视图必须已经存在;
5.如果策略的条件语法有错误的话,那么在访问对象时会报ORA-28112错误;
6.如果审计的列在表中不存在,那么没有列被审计;
7.如果事件处理器不存在,不会报错,并且依然会产生审计记录;
eg:
BEGIN
dbms_fga.add_policy(object_schema => 'HR',
object_name => 'EMPLOYEES',
policy_name => 'audit_emps_salary',
audit_condition => 'department_id=10',
audit_column => 'SALARY,COMMISSION_PCT',
enable => TRUE,
statement_types => 'SELECT,UPDATE');
END;
/
SELECT employee_id, job_id FROM hr.employees WHERE department_id = 20;
SELECT employee_id, salary FROM hr.employees WHERE department_id = 10;
UPDATE hr.employees SET salary = salary WHERE department_id = 10;
COMMIT;
conn / as sysdba
SELECT * FROM fga_log$;
SELECT * FROM dba_fga_audit_trail;
-- Data Dictionary Views
SELECT * FROM dba_fga_audit_trail;记录了所有fga审计的事件;
SELECT * FROM *_audit_policies;包含了fga的策略;
-- 补充:fga审计的审计记录和事务是互相独立的,也就是如果你的事务回滚了,那么审计记录还会被记录下来;(测试一下基于值的审计发现,不会记录的)
FGA审计是通过一个自动事务来插入审计记录的,这种事务在它自己的上下文中提交,当DML语句失败或者被回滚时,插入的审计记录不被回滚?
这样就会导致出现虚假的审计记录,可以通过什么办法解决?可以根据发出的SQL语句和SCN,通过闪回查询来查看修改之前和之后的值,这个时候查到了就可以请这个人喝茶了;
接来下的问题是UNDO的保存时间又是有限的?可以通过FDA解决;
SELECT employee_id, salary FROM hr.employees
AS OF SCN 1144994
WHERE department_id = 10;
--sysdba/sysoper审计:
1.sysdba/sysoper用户有启动/关闭数据库权限;因为它们可以当数据库关闭的时候做一些操作,所以它们的审计信息必须存在数据库之外;
2.Oracle自动捕获sysdba/sysoper用户的登陆信息,但是只是在audit_trail=OS时有用,因为它们可以篡改数据库中的记录;
3.默认只是捕获sysdba/sysoper用户的登陆信息,如果想要审计其它的信息的话,必须开启audit_sys_operations初始化参数;
4.如果开启sys操作审计的话,默认也是放在audit_file_dest目录下;
eg:
ALTER SYSTEM SET audit_sys_operations = TRUE SCOPE = SPFILE;
shutdown immediate;
startup
cd /u01/app/oracle/admin/ORCL/adump
sqlplus / as sysdba
ALTER USER hr IDENTIFIED BY hr;
SELECT sid FROM v$mystat WHERE rownum = 1;
然后查看对应的trace文件;
-- Maintaining the Audit Trail
1.因为审计的aud$和fga_log$都在system表空间,所以必须它们尽快归档,可以使用expdp/impdp工具;
2.也可以移动到其它的表空间上,注意表上的lob字段;
ALTER TABLE sys.aud$ MOVE TABLESPACE users;
ALTER TABLE sys.aud$ MOVE lob(sqlbind) STORE AS(tablespace USERS);
ALTER TABLE sys.aud$ MOVE lob(SQLTEXT) STORE AS(tablespace USERS);
ALTER TABLE sys.fga_log$ MOVE TABLESPACE users;
ALTER TABLE sys.fga_log$ MOVE lob(LSQLTEXT) STORE AS(tablespace USERS);
ALTER TABLE sys.fga_log$ MOVE lob(LSQLBIND) STORE AS(tablespace USERS);
-- Oracle Audit Vault
1.Oracle Audit Valut可以透明的收集和统一安全审计数据,可以兼容2.Oracle9iR;
2,MSSQL2000/2005/2008,DB2,Sybase ASE;
3.帮助组织/简化/统一报表格式,另外还提供了开放的仓库审计架构,可以被Oracle BIPublisher,Oracle;
4.Application Express和第三方报表工具;
5.Oracle Audit Vault帮助降低IT运营成本,集中化管理和设置,方便使用;
补充:
1.从宏观方面看,Vault属于Oracle数据库安全领域中-访问控制的部分;
2.和VPD,OLS不不一样的是,Vault在实际的生产环境下,最主要的目的是为了防止具有sys用户DBA滥用权限;
3.在没有Vault情况下,sys可以随意查看数据,这对于一些企业(特别是金融领域)来说是不允许的,而有了Vault,就可以控制DBA不能访问应用的核心数据;
4.现在有HR领域和Fin领域,即使拥有sys权限的DBA也无法访问这两个领域,只有相应领域的用户才能访问某特定领域的数据;这样就彻底解决了DBA权限被滥用的问题;