角色划分 数据安全中最有争议的问题之一是角色划分。 为了管理数据库，数据库管理员必须拥有某些权限，通常会赋予其 SYSDBA 角色，甚至是 DBA 角色。 然而，这一角色还有其它的一些权力：例如给别人授予权限，从任何表中选择所有数据。 该超用户权限与绝大多数法规相冲突，例如 Sarbanes-Oxley 和 GLBA，因为该权限允许个人拥有太多权力。 其实，DBA 角色是个与物理数据库相关的纯粹技术角色，一般情况下把它分配给一组用户。 如果同样的人群也能够查看并更改任何用户数据，那么这种情况就会产生数据漏洞的严重潜在安全性风险。 当数据库管理员可以删除任何数据，甚至审计线索时，责任可查性将成为问题。 然而，要实现合规性，需要明确划分职责和权限。 因此，管理物理数据库的权限不应该包括查询或修改用户数据权。 传统上，Oracle 数据库不支持这种划分。 所以，在 2006 年 Oracle 宣布了两种革新性的工具（写这篇文章时它们都处于实验阶段）。 首先，Oracle Database Vault （Oracle 数据库 10g 第 2 个企业版的一个选项）通过创建权限“域”实现权限分离。 例如，DBA 不再有无限权利 查询和修改任何表。 相反，DBA 的权限将被限制到一个具体的权限范围，即权限域。 因此，Database Vault 抛弃能删除所有跟踪的万能超级用户的理念。相似地，独立产品 Oracle Audit Vault 提供了一个安全的审计工具，该工具自成一体，位于 DBA 或者应用程序管理人员控制区域外。只有安全管理员可以控制审计线索。 可以使用这两种工具将这里的三种相关角色——管理物理数据库、管理对象权限、管理审计线索——完全分开。达到所有合规性规定的要求。

FGA 的另一个特性就是当条件满足时，FGA 还能在审计线索中进行记录之外调用存储过程。 在有额外处理（例如发送电子邮件）的情形，这一特性的效果极其显著。 这样的 SP 被称为 FGA 策略的 处理模块。 请记住，选择语句可以激活 FGA，也可以激活这些处理器模块。 在某种意义上说，这使处理器模块“选择触发器”语句。

Oracle 数据库 10g 也介绍更多的 FGA 增强特性，例如这两个值得关注的特性：

绑定变量。 使用 FGA，您可以通过在 DBMS_FGA.ADD_POLICY 过程中使用参数来捕获语句中的绑定变量。

audit_trail => DB_EXTENDED

然后您可以将它们放到数据库初始化文件中，这样 FGA 可以一直对它进行记录。

相关列。 请看以下两个语句：

select balance from accounts where account_no = 9995; 

select sum(balance) from accounts; 

很明显，第一条语句请求了具体的敏感信息（基于此信息可识别客户），您可能想编辑该信息。 第二条语句危险系数较低，用户使用该语句找不到关于该客户的任何具体的敏感数据。 按照您的安全策略，您可能希望记录第一条语句，不记录第二条语句。 这样有助于限制该线索的大小。

要完成这一任务，您可以使用另外一个参数 audit_column_opts => DBMS_FGA.ALL_COLUMNS，同时定义策略如下：

begin
   dbms_fga.add_policy (
      object_schema     => 'ANANDA',
object_name => 'EMP',
policy_name => 'ACCOUNTS_ACCESS',
audit_column => 'BALANCE',
audit_condition => 'BALANCE >= 20000'
statement_types => 'SELECT');
     audit_column_opts => DBMS_FGA.ALL_COLUMNS
   );
end;

默认情况下为 DBMS_FGA.ANY_COLUMNS,无论 哪个 列被选择，它都能触发审计线索。

到这里我们只是精浅地涉及了 FGA。 要对 FGA 有一个全面的了解，获取更多的的示例，请参阅我的系列文章“对实际问题进行细粒度审计。”，分为三章。 " 同时我在 Oracle PL/SQL for DBAs (2005, O'Reilly Media) 一书中也对此也进行详细的讨论。

您需要查找具体的敏感列和且有选择地查找这些列中的敏感值。 首先，您需要制定审计策略。 下面是一个典型的策略示例：

在 SALARIES 表中：

• 如果某个用户 仅 选择 SALARY 和 BONUS 列时，您可以进行审计。 如果选择了其它的列，则不进行审计。
• 甚至当用户仅选择一列（例如 SALARY 列），且无需任何可识别信息（例如 EMPNO）时，也进行审计。
• 无论什么时候，只要用户从 EMPNOS 低于 1000（这些 EMPNO 用于管理人员）的表中选择任何列，仍然审计。
• 如果选择了用户 SAP_PAYROLL_APP 项，则不要审计。 这是工资处理应用程序使用的用户 id， 对它进行审计将会生成大量的数据，并填满线索表。
• 人力资源助手 Monica 和 Adam 定期检查和调整工资在 1，000 以下的低等级雇员的工资。您不应该审计工资在 1，000 以下的选择语句。
• 除开审计，请您执行一个存储过程 enqueue_message，该过程向负责安全的官员发送电子邮件。

(编辑:aniston)