以下是满足责任分离的主要要求。

DBA 必须是可信任的：很难限制某个DBA 去做什么。为了完成工作，DBA 需要很高的权限。DBA 是受信任的职位，因此必须接受全面检查。即使是受信任的DBA 也必须承担责任。

考虑以下因素：

? 滥用信任：DBA 可能会滥用DBA_USERS视图中的加密密码。

? 用审计线索保护受信任位置：谨慎实施审计且遵守准则之后，审计线索会指出特定人员没有违反规程，也没有破坏性行为。

如果有恶意用户试图让人怀疑受信任的用户，设计良好的审计线索可捕获该行为。

 

Oracle Database Vault：在下面的情况下，可以使用Oracle Database Vault 选件：数据库必须强制执行责任分离，或者不允许DBA 查看某些或所有数据库方案中的数据。

安全的系统可确保所包含数据的机密性。有以下几方面的安全性功能：

? 限制对数据和服务的访问

? 验证用户

? 监视可疑活动

数据库安全性

Oracle Database 11g提供了业界最佳的安全系统框架。但是，要让这个框架起作用，数据库管理员必须遵循最佳实践并持续监视数据库活动。

 

不是所有用户都应对所有数据具有访问权。根据数据库中存储的内容，可按业务需要、客户期望以及日益增加的法律限制条款来强制实施有限制的访问。必须保护信用卡信息、医疗保健数据、身份识别信息等，使之免受未授权访问的侵害。Oracle DB 通过提供细粒度的授权控制来限制数据库访问。限制访问必须包括应用最少权限原则。

为了强制对敏感数据实施访问控制，系统必须首先知道是谁尝试访问数据。如果验证机制有漏洞，就会导致所有其它安全预防措施变得无用。

最基本的用户验证方式是要求用户提供知道的验证信息，如口令。如果可以保证口令遵循简单规则，就可极大地增强系统的安全性。

比较严格的验证方法包括要求用户提供掌握的某些验证信息，如令牌或公共密钥基础结构(PKI) 证书。

更严格的验证方法是，通过诸如指纹、虹膜、骨组织模式等唯一生物学特征来识别用户。

Oracle DB 支持通过高级安全选件来使用高级验证技术（如基于令牌、生物学和证书的身份识别技术）。

为了防止有人钻验证漏洞，必须锁定当前未使用的用户帐户。

 

即使经过授权和验证的用户有时也会钻系统漏洞。为了查到信息失窃的原因，第一步就是要找出不寻常的数据库活动，如某个雇员突然开始查询大量的信用卡信息、研究结果或其它敏感信息。为了跟踪用户活动和确定可疑活动的变化趋向，Oracle DB 提供了很多审计

工具。

监视或审计是安全过程不可缺少的一部分。

请复查下列各项：

监视合规性

审计意味着捕获并存储系统上所发生情况的信息，这会增加系统必须执行的工作量。

审计必须有重点，以便只捕获有意义的事件。如果审计重点设置适当，则会最大程度地减少对系统性能的影响。

如果审计重点设置不当，则会对系统性能产生明显的影响。

 

? 强制性审计：不管其它审计选项或参数如何设置，所有Oracle DB 都会审计特定的操作。由于数据库需要记录诸如授权用户连接等数据库活动，所以存在强制性审计日志。

 

? 标准数据库审计：通过使用AUDIT_TRAIL初始化参数在系统级别启用。启用审计之后，选择要审计的对象和权限，并使用AUDIT命令设置审计属性。

 

? 基于值审计：扩展了标准数据库审计的功能，不仅会捕获发生的审计事件，还会捕获插入、更新或删除的实际值。

 

? 细粒度审计(FGA)：扩展了标准数据库审计的功能，从而可捕获发出的实际SQL 语句，而不仅仅是发生事件的情况。

 

? SYSDBA（和SYSOPER）审计：将DBA 与审计者或安全管理员的审计责任分离开，审计者或安全管理员在操作系统审计线索中负责监视DBA 的活动。

 

要使用数据库审计，必须先将静态AUDIT_TRAIL参数设置为指向审计记录的存储位置。这样做可启用数据库审计。

启用数据库审计并指定审计选项（登录事件、行使的系统和对象权限或使用的SQL 语句）后，数据库开始收集审计信息。

 

 

如果将AUDIT_TRAIL设置为OS，审计记录存储在操作系统的审计系统中。

在Windows 环境下，审计记录存储在事件日志中。

在UNIX 或Linux 环境下，审计记录存储在使用AUDIT_FILE_DEST参数指定的文件中。

 

如果将AUDIT_TRAIL参数设置为DB或DB, EXTENDED，可以在DBA_AUDIT_TRAIL视图（SYS方案的一部分）中查看审计记录。

 

如果AUDIT_TRAIL设置为XML或XML,EXTENDED，审计记录会写入AUDIT_FILE_DEST参数指向的目录中的XML 文件。使用V$XML_AUDIT_TRAIL视图可查看此目录中的所有XML 文件。

 

维护审计线索是一项重要的管理任务。审计线索可能会迅速地增长，具体取决于审计选项的审计重点。

如果维护不当，审计线索会创建过多的记录，以至影响系统的性能。审计开销与生成的记录号直接相关。

sys@TEST0924> show parameter AUDIT_TRAIL

 

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

audit_trail string DB

 

Oracle DB 进行标准审计和细粒度审计时跟踪相同的字段，这可以轻松分析数据库活动。

为实现这一点，标准审计线索和细粒度审计线索包含了彼此互补的属性。

通过标准审计收集的额外信息包括：

? 系统更改号(SCN)，记录对系统的每一项更改。

? 用户执行的确切SQL 文本及与SQL 文本一起使用的绑定变量。只有已指定AUDIT_TRAIL=DB, EXTENDED的情况下，这些列才会出现。

 

通过细粒度审计收集的额外信息包括：

? 每个审计记录的序列号。

? 将源自一条语句的多个审计条目联系起来的语句编号。

 

? 用全球标准时间(UTC) 表示的全球时间戳。这个字段在监视不同地理位置和不同时区中的数据库时特别有用。

? 每个Real Application Cluster (RAC) 实例的唯一实例编号。

? 用于将一个事务处理的审计记录组成一组的事务处理标识符。

DBA_COMMON_AUDIT_TRAIL视图中组合了标准审计日志记录和细粒度审计日志记录。

SQL 语句审计：AUDIT table;

上面显示的语句可审计影响表的任何数据定义语言(DDL) 语句，包括CREATE TABLE、DROP TABLE和TRUNCATE TABLE等。

也可按用户名或者按成功或失败来设置SQL 语句审计的重点：

SQL> AUDIT TABLE BY hr WHENEVER NOT SUCCESSFUL;

 

系统权限审计：可用来审计行使的任何系统权限（如DROP ANY TABLE）。可按用户名或者成功或失败设置审计的重点。

默认情况下，审计设置为BY ACCESS。

每次行使经审计的系统权限时，都会生成一条审计记录。

可选择使用BY SESSION子句将这些记录组成一组，以便每个会话只生成一条记录。

（这样，如果一个用户针对另一个用户的表发出了多条更新语句，则只收集一条审计记录。）

使用BY SESSION子句来限制由于审计系统权限而对性能和存储产生的影响。

 

系统权限审计（非重点和重点）：

 

这种审计类型可按成功或失败设置审计的重点，而且可以按会话或访问权限分组。

与系统权限审计不同，默认情况下，对象权限审计按会话分组。

如果要为每个操作分别生成一条审计线索记录，必须显式指定BY ACCESS。

AUDIT ALL on hr.employees;

AUDIT UPDATE,DELETE on hr.employees BY ACCESS;

 

在Oracle Database 11g中启用审计时，将默认审计那些对安全性非常重要的特定权限和语句。

系统将针对所有用户，按成功、失败以及访问来审计上面列出的这些权限和语句。

在Database Control 主页中，通过单击“Server（服务器）”选项卡，然后单击“Security（安全性）”区域中的“Audit Settings（审计设置）”链接，可访问“Audit（审计）”页。

 

“Audit（审计）”页上包含下列区域：

? Configuration（配置）：显示当前的配置参数值，包含用于编辑参数值的链接

? Audit Trails（审计线索）：可轻松访问已收集的审计信息

可使用以下选项卡页来设置和取消设置审计选项：

? Audited Privileges（审计的权限）：显示审计的权限

? Audited Objects（审计的对象）：显示审计的对象

? Audited Statements（审计的语句）：显示审计的语句

最佳实践提示

审计会造成性能下降，其幅度与审计线索的写入数量成比例。要定制满足站点需求的审计选项，可只启用那些满足安全策略所需的选项。设置审计重点，以减少审计线索条目的数量。

进行数据库审计时会记录审计对象中发生的插入、更新和删除操作，但是不会捕获更改的实际值。

要扩展数据库审计，可使用基于值的审计，利用数据库触发器（事件驱动的PL/SQL 构造）来捕获更改的值。

 

用户在连接了相应触发器的表中插入、更新或删除数据时，触发器在后台将审计信息复制到包含审计信息的表中。

因为审计触发器代码在每次插入、更新或删除操作发生时都必须执行，所以与标准数据库审计相比，使用基于值的审计时，性能下降幅度比较大。

性能下降幅度取决于触发器代码的效率。只在标准数据库审计捕获的信息不足的情况下，才使用基于值的审计。

基于值的审计由用户或第三方代码实施。Oracle DB 提供了可用来构建基于值的审计系统的PL/SQL 构造。

基于值的审计的关键部分是审计触发器，这是一个单纯为了捕获审计信息而构造的PL/SQL 触发器。

以下是一个审计触发器的典型示例：

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 INTO system.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;

/

这个触发器将审计的重点设置为捕获hr.employees表薪水列的更改。更新某行后，触发器就会检查薪水列。

如果新旧薪水不相等，则触发器会在audit_employees表（通过在SYSTEM方案中单独执行一项操作而创建）中插入一条审计记录。

审计记录中包括了用户名、执行更改的IP 地址、标识所更改记录的主键及更改的实际薪水值。

如果标准数据库审计收集的数据不足，还可使用数据库触发器来捕获关于用户连接的信息。

通过使用登录触发器，管理员可以捕获用来标识连接到数据库的用户的数据。

包括下列各项：

? 登录人员的IP 地址

? 用于连接到实例的程序名的前48 个字符

? 用于连接到实例的终端名

参考“SYS_CONTEXT”

在许多情况下，会使用细粒度审计(FGA) 功能，而不会使用基于值的触发器。

? 根据内容监视数据访问

? 审计SELECT、INSERT、UPDATE、DELETE和MERGE

? 可链接到表或视图中的一列或多列

? 可以执行某个过程

? 使用DBMS_FGA程序包进行管理

SELECT name,salary

FROM employees

WHERE

department_id = 10;

细粒度审计

数据库审计会记录已发生某个操作这一事实，但是不会捕获关于导致操作的语句的信息。

细粒度审计(FGA) 扩展了审计功能，可捕获查询或处理数据的实际SQL 语句。

与标准数据库审计或基于值的数据库审计相比，FGA 将重点审计的范围设置得更窄。

可将FGA 选项设置为按表或视图中的各个列进行审计，还可将其设置为条件选项，以便只在符合管理员定义的特定规范时才捕获审计。FGA 策略支持多个相关列。默认情况下，如果其中任何一列出现在SQL 语句中，就会审计该语句。

通过使用DBMS_FGA.ALL_COLUMNS和DBMS_FGA.ANY_COLUMNS，可对语句中是否使用了任何或全部相关列来进行审计。

可使用DBMS_FGA PL/SQL 程序包来创建对目标表或视图的审计策略。

如果查询块中返回的任何行与审计列和指定的审计条件相匹配，则审计事件会导致在审计线索中创建并存储审计记录。

此外，审计事件还可执行某个过程。FGA 自动将审计重点放在语句级别。一个SELECT语句会返回数千行，但只生成一条审计记录。

上图中的示例显示了使用DBMS_FGA.ADD_POLICY过程创建细粒度审计策略的流程，

该过程接受以下参数。

创建每个FGA 策略时将指定其名称。上图中通过使用以下参数来命名AUDIT_EMPS_SALARY策略：

policy_name => ‘audit_emps_salary‘

 

审计条件是一个SQL 谓词，用于定义审计事件何时必须触发。上图中，通过使用以下条件参数来审计部门10 中的所有行：

audit_condition => ‘department_id = 10‘

注：细粒度审计查看查询的结果集，因此，使用上图显示的FGA 策略时，返回与策略规范相匹配行的查询将导致创建一个审计记录。

例如，查询“select * from employees”会返回所有行，包括那些department_id 中含有“10”的行，因此将创建一个审计行。

审计列定义了要审计的数据。如果此列包括在SELECT语句中或是审计条件允许的选择，就会发生审计事件。

上图示例通过使用以下参数来审计两个列：

audit_column => ‘SALARY,COMMISION_PCT‘

此参数是可选参数。如果未指定此参数，则只由AUDIT_CONDITION参数确定审计事件是否必须发生。

 

对象是要审计的表或视图。可通过以下两个参数传递对象：

? 包含对象的方案

? 对象的名称

上图通过使用以下参数来审计hr.employees表：

object_schema => ‘hr‘

object_name => ‘employees‘

 

可选的事件处理程序是一个PL/SQL 过程，用于定义在审计期间必须执行的附加操作。

例如，事件处理程序可向管理员发送一个预警页。

如果未定义审计事件处理程序，则在审计线索中插入审计事件条目。

如果定义了审计事件处理程序，则在审计线索中插入审计条目并执行审计事件处理程序。

 

审计事件条目包括导致事件的FGA 策略、执行SQL 语句的用户、SQL 语句及其绑定变量。

可通过以下两个参数传递事件处理程序：

? 包含PL/SQL 程序单元的方案

? PL/SQL 程序单元的名称

 

上图示例通过使用以下参数来执行SECURE.LOG_EMPS_SALARY过程：

handler_schema => ‘secure‘

handler_module => ‘log_emps_salary‘

 

默认情况下，审计线索总是将SQL 文本和SQL 绑定信息写到LOB。可以更改此默认设置（例如，系统遇到性能下降时）。

 

状态指示是否启用了FGA 策略。上图示例中，使用以下参数启用了此策略：

enable => TRUE

审计的DML 语句：注意事项

为DML 语句定义了FGA 策略时，如果要处理的数据行（包括新行和旧行）符合策略谓词标准，就会审计DML 语句。

但是，如果同时在策略定义中指定了相关列，则当数据符合FGA 策略谓词并且语句引用了定义的相关列时，才会审计语句。

 

对于DELETE语句，在定义策略期间指定相关列是没有用的，这是因为DELETE语句会访问表中的所有列。因此，不管相关列是什么，总是要审计DELETE语句。

 

FGA 支持MERGE语句。如果基础INSERT、UPDATE和DELETE语句满足所定义的INSERT、UPDATE或DELETEFGA 策略，则对会对这些语句进行审计。

 

使用前面定义的FGA 策略时，会审计第一个语句而不审计第二个语句。部门10 中没有雇员收到佣金，但是employee_id=200指定了部门10 中的一个雇员。

UPDATE hr.employees

SET salary = 1000

WHERE commission_pct = .2;

 

 

对于SELECT语句，FGA 会捕获语句本身而不是实际行。

但是，当FGA 与闪回查询组合在一起时，会按实际行在该时间点存在的形式重新构造这些行。

 

SYSDBA和SYSOPER用户有权启动和关闭数据库。因为这些用户可以在数据库处于关闭状态时进行更改，所以这些权限的审计线索必须存储在数据库外部。

Oracle DB 会自动捕获SYSDBA和SYSOPER用户的登录事件。这为跟踪授权或未授权的SYSDBA和SYSOPER操作提供了一种宝贵方法，但只在查看操作系统审计线索时才有用。

 

Oracle DB 始终捕获授权用户的登录事件。

如果专门启用了DBA 审计，则还会捕获其它操作。

 

通过设置以下初始化参数可启用对SYSDBA和SYSOPER用户的审计：

AUDIT_SYS_OPERATIONS=TRUE（默认设置为FALSE。）

如果对SYS操作进行审计，则AUDIT_FILE_DEST初始化参数会控制审计记录的存储位置。

在Windows 平台上，默认情况下，审计线索存储在Windows 事件日志中。

在UNIX 和Linux 平台上，审计记录存储在AUDIT_FILE_DEST位置。

应根据最佳实践准则来维护审计线索：

? 复查和存储旧记录。

? 避免出现存储问题。

? 避免记录丢失。

维护审计线索

必须维护每种类型的审计线索。基本维护必须包括复查审计记录及删除数据库或操作系统中较旧的记录。审计线索会不断增长，可填满可用的存储空间。如果文件系统已满，系统可能会崩溃或只是导致出现性能问题。如果数据库审计线索填满了表空间，则不能完成审计的操作。如果审计线索填满了系统表空间，在审计操作停止之前，其它操作的性能会受到影响。

 

标准审计的审计线索存储在AUD$表中。FGA 的审计线索存储在FGA_LOG$表中。默认情况下，这两个表都是在SYSTEM表空间中创建的。通过使用数据泵导出和导入实用程序可将这两个表移到另一表空间中。

注：不支持将审计表移到SYSTEM表空间外部。

在从审计表中删除记录的过程中，可能会丢失审计记录。

 

? 合并和保护审计数据

– Oracle 9i 发行版2 和更高的版本

– SQL Server 2000、2005

– IBM DB2 UDB 8.5 和9.2

– Sybase ASE 12.5 - 15.0

– 安全且可伸缩

– 清理源Oracle 审计数据

? 集中式报告

– 报表界面进行了更新，

使用广受欢迎的Oracle Application Express

– 合规性标准报表

– 新增定制报表

? 安全威胁预警

– 检测和警告安全相关事件

Oracle Audit Vault

Oracle Audit Vault 的主要优点如下：

? 从Oracle9iDatabase 发行版2 开始，Oracle Audit Vault 可以从Oracle DB、Microsoft SQL Server 2000 和2005、IBM DB2 Unix、Linux、Windows 8.2 和9.5 以及Sybase ASE 12.5 - 15.0 中透明地收集和合并审计数据。

? Oracle Audit Vault 提供内置报表和定制报表，帮助公司简化了制作合规性报表的工作。此外，Oracle Audit Vault 提供了可以从Oracle BI Publisher、Oracle Application Express 或任何第三方报表工具访问的开放式审计仓库方案。

? Oracle Audit Vault 对可疑活动发出预警，从而帮助检测和防范内部威胁。

? Oracle Audit Vault 的核心是一个安全且可伸缩的审计仓库，它基于Oracle 数据仓库技术构建并由Oracle 的数据库安全产品（包括Oracle Database Vault 和Oracle 高级安全选件）保护安全。Oracle Audit Vault 包括Oracle 分区功能，以提高易管理性和性能。

? Oracle Audit Vault 集中管理数据库审计设置（策略），可帮助公司降低IT 成本，同时使IT 安全负责人和内部审计人员能够更轻松地执行其工作。