保护Oracle数据库的安全

每个组织都应该制定一份安全准则，安全无对错之分，这只是遵从或违反约定程序的问题。管理员只要按规则中的要求和建议行事，任何安全纰漏将不再是他们的责任。过去的经验表明，出现任何安全问题时，总有人心中燃烧着将责任推卸给他人的强烈欲望。管理员必须拿出安全准则，以及示范执行方式的程序和记录(测试的过程记录或恢复文档)，这样责任将转嫁到规范说明和安全准则的制定者身上。如果没有这样的手册，那么责任往往会推到数据库管理员身上。Oracle系列产品提供了多项功能，来实施达到或超过任何组织制定的最高标准的安全性。

1数据库安全和最小权限原则
访问计算机系统时需要遵循的最重要的安全原则是"最小权限"原则，即用户应当只拥有执行其任务所需的最小权限，并禁止所有未被特别允许的权限。Oracle遵循了最小权限原则，在默认情况下，只有用户SYS和SYSTEM才拥有所有权限。授予PUBLIC帐户的权限以及一些实例参数，来帮助实现最小权限原则。

1.1PUBLIC权限
PUBLIC角色将隐式授予每位用户。只要为PUBLIC授予任何权限，相应的权限实际上就会授予可以连接到数据库的每个人；创建的每个帐户都有权访问这些权限。默认方式下，PUBLIC用户拥有大量权限，尤其是拥有能够执行许多PL/SQL实用程序包的权限。

虽然应用软件可以为PUBLIC用户授予执行UTL程序包的权限，但是应当取消PUBLIC用户的这个权限，下面权限可以取消该权限：
SQL>revoke execute on utl_file from public;
较不安全的程序包：
UTL_FILE：允许用户读写操作系统Oracle所有者可以访问的任何文件和目录，这些文件与目录包括所有的数据库文件以及Oracle_HOME目录。
UTL_TCP：允许用户为了连接网络中所有可访问的地址而打开服务器上的TCP端口。
UTL_SMTP：使用UTL_TCP调用编写的这个程序包允许用户发送邮件消息。受UTL_SMTP_SERVER参数限制，此参数给出了出站邮件服务器的地址。
UTL_HTTP：使用UTL_TCP调用进行编写，允许发送HTTP消息和接收响应，结果是将数据库转换为Web浏览器。
[提示]PUBLIC是授予所有人的角色-但是在使用AS SYSOPER语法连接到实例时，看似是连接到PUBLIC帐户。

1.2对安全性至关重要的实例参数(静态参数)
UTL_FILE_DIR：默认为NULL，允许PL/SQL通过UTL_FILE补充程序包来访问服务器计算机的文件系统。参数为一个用逗号分隔的目录列表，使用下面语法设置这个参数：
SQL>alter system set utl_file_dir='/oracle/tmp','/oracle/interface' scope=spfile; --可以使用通配符，不要设置为"*"。
REMOTE_OS_AUTHENT：默认为FALSE，控制某个用户是否能够在不需要给出口令的情况下从远程计算机上连接数据库。目前系统不需再需要执行这种操作，但仍保留了该功能。之前为了避免用户两次提供用户名与口令(操作系统与数据库)，通常使用如下语法创建Oracle用户：
SQL>create user jon identified externally;
这样身份验证操作被委托给服务器的操作系统完成，如下所示，做为操作系统用户"jon"登入服务器的任何人都能够在不需要进行身份验证的情况下连接数据库：
$ sqlplus /
Connected to:Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
SQL> show user;
USER is "JON"
SQL>
[提示]启用远程操作系统身份验证并非是一种好做法。
OS_AUTHENT_PREFIX：默认值为"OPS$"的OS_AUTHEN_PREFIX参数指定了一个前缀，操作系统名在映射为Oracle用户名之前必须应用这个前缀，下例中，使用如下语法清空了这个参数：
SQL>alter system set os_authent_prefix='' scope=spfile;     ------否则，Oracle用户名肯定为OPS$JON
O7_DICTIONARY_ACCESSIBILITY：因在Oracle7版本中开始使用而得名。控制使用ANY关键字授予对象权限的效果。默认值为FALSE，这意味着ANY权限不被授予SYS拥有的对象，保护了数据字典。，如果参数修改为TRUE，，这意味着所有对象都被授予了ANY权限。使用下例为用户JON授予查看数据库中所有表的权限：
SQL>grant select any table to jon;
[提示]安装某个软件产品时，必须将O7_DICTIONARY_ACCESSIBILITY实例参数设置为TRUE，然后再将其恢复为默认值FALSE。可以将这些用户授予SELECT ANY DICTIONARY的权限。
REMOTE_LOGIN_PASSWORDFILE：控制具有SYSDBA或SYSOPER权限的用户能否通过网络连接实例。默认值NONE，将参数值设为EXCLUSIVE或SHARED，用户能够作为SYSDBA连接实例。V$PWFILE_USERS视图显示其口令被输入口令文件的用户以及这些用户是否具有SYSOPER权限或SYSDBA权限。

[提示]做为SYSDBA连接实例时，即使使用了用户名和密码，最终仍然是做为用户SYS进行连接，做为SYSOPER连接实例时，实际上是做为PUBLIC用户进行连接。
[提示]启用口令文件并不能提高安全性，相反，由于允许用户除了始终可用的本地操作系统身份验证外，还能以其它方式获取具有权限的连接，这样会降低安全性。但是，标准的做法是启用口令文件，如果没有此文件，不能在远程管理数据库。某些计算机审计者不了解操作系统和口令文件身份验证，甚至声称必须创建口令文件来提高安全性。

1.3 练习：研究数据库和应用环境
本练习将生成一个脚本，可以从PUBLIC删除一些更具危险性的权限。使用SQL*PLUS。
以用户SYSTEM的身份连接到数据库。
编辑SQL*Plus，从其输出中删除无关的字符:
set headers off
set pagesize 0
set feedback off
将输出打印到适当目录的文件中，下面是Unix和Windows系统中的示例:
spool $HOME/oracle/scripts/clear_public_privs.sql
spool c:/oracle/scripts/clear_public_privs.sql
通过运行以下语句生成SQL命令文件:
select 'revoke execute on '||table_name||' from public;' from dba_tab_privs where table_name like 'UTL_%';
停止正在进行的后台打印:
spool off
使用自己选择的编辑器打开生成的文件。注意，可能需要做几处编辑，然后才能运行操作来删除第一行和最后一行；由于站点情况不同，某些权限(如果有)可能无法真正取消。

2使用标准数据库审计
无论安全策略多么完善，总是存在使用策略显得不足的场合。可能不得不接受具有潜在危险权限的用户，能够做到的就是监视用户的权限使用以及跟踪通过这些权限进行的实际操作。上述情况的最极端示例就是数据库管理员。具有SYSDBA权限的任何人可以在数据库内进行任何操作。为了让人相信数据库管理员不会滥用权利，有必要审计所有的SYSDBA活动。对于普通用户来说，数据库管理员也可能希望跟踪他们所进行的操作。虽然可能无法阻止这些用户违反与数据访问相关的公司规定，但数据库管理员却能够跟踪他们的违规行为。Oracle提供了4种审计技术：
SYSDBA审计：
数据库审计：能够跟踪特定权限的使用、特定命令的执行、对特定表的访问以及登录尝试。
基于值的审计：使用了数据库触发器，在插入、更新或删除记录时，就会运行一个包括记录事件全部细节的PL/SQL代码块。
细粒度审计：允许根据所访问的记录来跟踪对表的访问。细粒度审计更为精确，并且可以将生成的审计记录的范围限制为感兴趣的审计记录。
[提示]任何一种审计都会增加数据库必须完成的工作量。为了限制这种工作量，应当进行重点审计，同时不跟踪不重要的事件。

2.1审计SYSDBA活动
参数AUDIT_SYS_OPERATIONS参数为TRUE(默认值DEFAULT)，做为SYSDBA、SYSOPER连接数据库的用户所发出的每条语句都会被写入操作系统的审计跟踪，审计跟踪必须受到保护，如果DBA能够删除审计记录，那创建这些记录将无意义。所以要避免“责任分离(separation of duties)”，需要对系统进行配置，使DBA不能访问跟踪DBA活动的审计记录，这些审计记录只能被计算机系统管理员访问。如果DBA是系统管理员，那么这种审计就毫无作用，所以对于审计人员应当始终坚持这种观点：DBA不拥有系统的“超级用户”或“管理员”口令。
Windows系统中，审计记录文件夹为Windows Application Log。Unix系统中，目的文件夹由AUDIT_FILE_DEST参数控制。

2.2数据库审计
设置数据库审计前，必须设置AUDIT_TRAIL参数：
NONE(或FALSE)：无论试图配置哪一种审计，这个参数都会禁用数据库审计。
OS：审计记录会被写至操作系统的审计跟踪，通过使用适当的编辑器，查看在操作系统审计跟踪中创建的文件，可以查看审计结果。
DB：审计记录会被写入数据字典表SYS.AUD$。
DB_EXTENDED：与DB作用大致相同，不过包含生成审计记录的、具有绑定变量的SQL语句。审计记录会被写入数据字典表SYS.AUD$。
XML：与OS的作用大体相同，但使用XML标记设置格式，通过使用适当的编辑器，查看在操作系统审计跟踪中创建的文件，可以查看审计结果。
XML_EXTENDED：与XML的作用大体相同，但使用SQL语句和绑定变量。
审计对没有成功执行的命令特别有用，此时生成的任何记录都会说明用户试图违反自己的访问权限。使用AUDIT命令可以配置数据库审计，例如：
SQL> audit create any trigger;
SQL> audit select any table by session;
如果编程人员需要被授予CREATE ANY TRIGGER权限时应特别注意，这时一个可以被恶意使用的危险权限。有时需要SELECT ANY TABLE和UPDATE ANY TABLE权限。默认方式下，审计会为违法审计条件的每个会话生成一条审计记录，而不考虑违法条件的次数。这相当于为AUDIT命令追加关键字BY SESSION，这会为每次违反条件的情况生成一条记录。
[提示]BY SESSION通常并不是需要的设置，但此设置将生成的审计记录数量限制为更易于管理的数据。
设置面向对象的审计：
SQL> audit insert on ar.hz_parties whenever successful; --WHENEVER SUCCESSFUL记录限制为操作成功的记录；WHENEVER NOT SUCCESSFUL会审计所有操作；
SQL> audit all on ar.ra_interface_lines_all;  --审计针对指定表执行DDL语句的每个会话；
使用AUDIT SESSION命令可以审计登录，如：
SQL> audit session whenever not successful; --会话审计记录针对数据库的每次连接，这可能十分有用，记录尝试是否正在侵入数据库；
DATABASE CONTROL的审计系统的图形界面：

DBA_AUDIT_TRAIL是一个重要视图，下图是常用的列：

审计视图DBA_AUDIT_OBJECT、DBA_AUDIT_STATEMENT、DBA_AUDIT_SESSION显示DBA_AUDIT_TRAIL视图的一个子集，仅显示与其相关的某些审计记录和列。
[提示]数据库的安全性对所有站点都至关重要。所有DBA都必须了解“最小权限”准则；未特定授予的所有权限都必须予以禁止。创建数据库时针对PUBLIC角色的某些默认授权视为潜在的安全风险。一般情况，默认设置是安全的，但始终应检查这些设置及其记录的值。用户需要的权限可能导致滥用，审计是一种管理方式：知道用户可能破坏安全，将他们所做的事实记录下来，可以起到威慑作用，允许用户捕获此类操作。将系统管理员与数据库管理员的职责分开意味着，也可以对DBA本人进行审计。

2.3使用触发器执行基于值的审计
用户无法阻止触发器的激发，如果需要捕获被改变行的实际值，就需要使用数据库触发器。
考虑以下创建触发器的语句：
SQL> CREATE OR REPLACE TRIGGER system.creditrating_audit
2 AFTER UPDATE OF creditrating
3 ON oe.customers
4 REFERENCING NEW AS NEW OLD AS OLD
5 FOR EACH ROW
6 BEGIN
7 IF :old.creditrating != :new.creditrating THEN
8 INSERT INTO system.creditrating_audit
9 VALUES (sys_context('userenv','os_user'),
10 sys_context('userenv','ip_address'),
11 :new.cust_id ||' credit rating changed from
12 '||:old.creditrating||
13 ' to '||:new.creditrating);
14 END IF;
15 END;
16 /
[提示]与数据库审计相比较，通过触发器的审计是一个很缓慢的过程，不过能够提供更多的信息，允许实施复杂的业务规则。

2.4细粒度审计(FGA)
数据库审计可以捕获对某个表的所有访问，包括SELECT与DML操作。细粒度审计可以被配置为只在访问特定行或特定行的特定列时生成审计记录，还可以被配置为在违反审计条件时运行一个PL/SQL代码块。配置FGA将会涉及程序包DBMS_FGA。为了创建一个FGA审计策略，需要使用ADD_POLICY过程，这个过程接受下表所示的参数：

其他DBMS_FGA过程用于启用、禁用或删除FGA策略。可以查询DBA_FGA_AUDIT_TRAIL视图来查看FGA结果。
SQL> describe dba_fga_audit_trail;
Name Null? Type
----------------------------- -------- ---------------------------
SESSION_ID NOT NULL NUMBER
TIMESTAMP DATE
DB_USER VARCHAR2(30)
OS_USER VARCHAR2(255)
USERHOST VARCHAR2(128)
CLIENT_ID VARCHAR2(64)
EXT_NAME VARCHAR2(4000)
OBJECT_SCHEMA VARCHAR2(30)
OBJECT_NAME VARCHAR2(128)
POLICY_NAME VARCHAR2(30)
SCN NUMBER
SQL_TEXT NVARCHAR2(2000)
SQL_BIND NVARCHAR2(2000)
COMMENT$TEXT VARCHAR2(4000)
STATEMENT_TYPE VARCHAR2(7)
EXTENDED_TIMESTAMP TIMESTAMP(6) WITH TIME ZONE
PROXY_SESSIONID NUMBER
GLOBAL_UID VARCHAR2(32)
INSTANCE_NUMBER NUMBER
OS_PROCESS VARCHAR2(16)
TRANSACTIONID RAW(8)
STATEMENTID NUMBER
ENTRYID NUMBER

此过程调用将创建POL1策略，此策略将捕获读取HR.EMPLOYEES表SALARY列的所有SELECT语句(如果检索到的行至少有一个在部门80)：
SQL> execute dbms_fga.add_policy(-
> object_schema=>'HR',-
> object_name=>'EMPLOYEES',-
> policy_name=>'POL1',-
> audit_condition=>'department_id=80',-
> audit_column=>'SALARY');
[提示]标准数据库审计结果视图(DBA_AUDIT_TRAIL)，细粒度审计结果视图(DBA_FGA_AUDIT_TRAIL)，两者审计结果的视图(DBA_COMMON_AUDIT_TRAIL)。要查看使用触发器审计的结果，必须创建处理自己的表的自定义视图。

2.5练习：使用标准数据库审计

1. 以用户SYSTEM的身份连接到数据库，并创建本练习使用的用户和表:
create user sabine identified by oracle;
create table system.audi as select * from all_users;
grant create session, select any table to sabine;
grant select on audi to sabine;
2. 使用SQL*Plus，启用对SABINE使用SELECT ANY PRIVILEGE的审计，以及对表AUDI的所有访问的审计:
audit select any table by access;
audit all on system.audi by access;
在使用Database Control时,可在Audit Settings窗口中执行此操作。
3. 以用户SYS的身份连接到数据库。这是必须的，因为此步骤需要重新启动实例。将审计跟踪目标设置为DB，启用权限用户的审计，关闭并重启实例，使用如下的SQL*Plus:
alter system set audit_trail='DB_EXTENDED' scope=spfile;
alter system set audit_sys_operations=true scope =spfile;
startup force;
使用Database Control时，数据库主页可能的导航路径为：选择Server选项卡，然后单击Security区域中的Audit Settings。如果单击Configuration区域中的Audit Trail链接，将弹出一个窗口，允许修改spfile中的参数设置。另外，在Server选项卡上，单击Database Configuration区域的Initialization Parameters链接，可以直接进入Initialization Parameters窗口.
在spfile中设置两个参数，此后，在数据库主页中关闭并重新启动数据库。
4. 以SYS身份连接时，将审计所有的语句。运行以下语句:
select count(*) from system.audi;
5.如果使用Linux 或Unix, 可通过查询AUDIT_FILE_DEST参数来确定系统审计跟踪的位置。这将用于审计SYS操作，而不考虑AUDIT_DEST设置。使用SQL*Plus运行以下语句:
select value from v$parameter where name='audit_file_dest';
Using an operating system utility, navigate to this directory and open the
most recently created file.
如果使用Microsoft Windows, 请在Event Viewer中打开Application Log。无论如何，都将看到以SYS身份执行的SELECT语句，以及操作系统用户和主机名的详细信息。
6. 以SABINE的身份连接到数据库，并运行以下查询:
select count(*)from system.audi;
select count(*) from system.product_user_profile;
7. 以用户SYSTEM的身份，运行查询来查看审计事件:
select sql_text,priv_used,action_name from dba_audit_trail
where username='SABINE';
注意，这里使用了最低权限：通过对象权限来访问AUDI表，而非功能更强大的系统权限(获取PRODUCT_USER_PROFILE需要此权限)。
8. 进行整理:
drop user sabine;
drop table system.audi;
[提示]应对计算机安全审计：审计者想要看到系统像平常一样运行。应与审计者密切合作，严格的计算机审计十分有用，实现任何建议需要做大量工作。
[提示]启用标准数据库审计会影响性能，紧盯审计的重点，只审计确有价值的事件的记录。尽可能按会话(而非访问)进行审计。如果审计数据库，SYS.AUD$表可能增加到数GB：这需要定期执行删除。

3小结
应将“最小权限”原则和“职责分离”应用于所有Oracle安装。过去的经验表明，用户有时滥用完成工作所需的权限。设计用于对此进行管理：实际上，无法阻止用户触犯规则，但可将他们的所作所为记录下来。
数据库审计可以捕获与权限使用、某些语句的执行和某些对象的访问有关的事件。细粒度审计更精确：它可以注意到对特定行和列的访问。使用DML触发器进行审计较完善：它可以捕获执行DML语句时需要的任何操作。