背景
正如我前面提到的，安全就好比在寒冷的冬天里，您穿上好几件衣服或穿最庞大的冬天使用的夹克御寒。 但是，构建各防御层可能阻止不了最坚决的恶意入侵者，当然这也不会总能够防御合法用户盗窃公司财产。 这里的组最后一道防线是加密，通过加密，用户（或者恶意入侵者）只有使用密码才可以访问到数据。 没有密码的数据是无效的。 如果您保护了密码，您就保护了数据。

请记住，加密不能替代其它层次的安全性。 不管怎样，您必须有那些防御。

而且，加密是一个很大的课题，但是我将在这里给您一个可引发操作的概述。

Oracle 提供两种加密方式:

1. 加密 API 例如包 dbms_obfuscation_toolkit 和 dbms_crypto （在 Oracle 数据库 10g 第 1 版和更高版本中）。 使用这些包，您可以构建您自己的基础架构，对数据进行加密。 这种方法的灵活性最强，但是构建和管理却相当复杂。
   
   
2. 透明的数据加密是 Oracle 数据库 10g 第 2 版和更高版本的一个特性；使用该特性后，您就不必手动进行密码管理了。 数据库管理密码，但是正如名称所指，加密是透明的——数据仅仅以加密的方式存储而已。 当您选择了这种方式，就会明白的。

我建议在您阅读策略部分之前，请分别察看 Oracle 文档（Oracle 数据库安全指南的 第 17 章 和 Oracle 数据库高级安全管理员指南的 第 3 章）。

• 不论哪种方式，您都必须识别要加密的表，尤其是要加密的列。 因为例行加密毁坏 CPU 周期，所以对所有列进行加密可能并不好。

• 下一步是选择加密算法。 通常是选择 156 位加密的三重数据加密标准 (DES3)。 然而，以 Oracle 数据库 10g 第 1 版开始，您可以访问更新、更快和更安全的高级加密标准 (AES) 算法，使用该算法要有 128 位密码。

• Oracle9i 数据库提供 dbms_obfuscation_toolkit；您可以使用 Oracle 数据库 10g 第 1 版访问一个更好的工具 dbms_crypto。 您仍然可用更老的包，但是如果您第一次构建加密基础架构，请不要使用。

• 在这一点，您必须选择 TDE 或您自己的例行使用的（如果可以应用的话）。 下表可以帮助您作出决定。

如果您决定使用 TDE，请采取以下步骤：

1. 配置钱夹： 钱夹一般位于文件夹 $ORACLE_BASE/admin/$ORACLE_SID/wallet 中，但是您可以通过将以下行放入文件 SQLNET.ORA 中使用任何位置：

   ENCRYPTION_WALLET_LOCATION=
    (SOURCE=
       (METHOD=file)
       (METHOD_DATA=
          (DIRECTORY=/orawall)     )  ) 
   

   在这里，将钱夹位置设置为 /orawall。

2. 打开该钱夹，分配一个密码： 执行以下命令：
   

   alter system set encryption key authenticated by "53cr3t";

3. 选择的密码要难以猜测，容易记忆。 （为了安全，您可能不想让 DBA 了解钱夹密码，所以需要另一个人打开该钱夹。） 现在，从现在开始，每次数据库打开时，您必须使用以下方式打开该钱夹：

   alter system set encryption wallet open authenticated by "53cr3t";

之后，您创建的表可以包含经过加密的列：

create table accounts
(
acc_no       number       not null,
first_name   varchar2(30) not null,
last_name    varchar2(30) not null,
SSN          varchar2(9)             ENCRYPT USING 'AES128',
acc_type     varchar2(1)  not null,
folio_id     number                  ENCRYPT USING 'AES128',
sub_acc_type varchar2(30),
acc_open_dt  date         not null,
acc_mod_dt   date,
acc_mgr_id   number
)

当用户将数据插进该表时，数据就自动转化为加密的数据并放置到磁盘上。 类似地，当选择语句检索到数据时，数据自动转化为加密的值，并且向用户显示。

提示
和任何重要的更改一样，有一些重要的提示。

• 加密是非常占用 CPU 的操作。 如果系统已经受 CPU 所限，这会使系统更糟。
• 索引不会和加密的列配合得很好，尤其是谓词，比如 WHERE <ColumnName> LIKE 'XYZ%'。该谓词应该已经在未加密的列中使用索引范围扫描，但是还将使用全面的表扫描。
• 密码管理是一个很重要的问题。 如果您丢失了密码，就访问不到该数据。

操作计划
操作计划位于策略部分。

背景
许多情况下，DBA 会忽略最容易受到攻击的要害： 数据库备份。 一旦数据不在服务器的安全范围内，您将不再能控制这些数据。 如果恶意入侵者可以盗窃磁带，他就可以将它们安装到一个不同的服务器上，恢复数据库，再慢慢地浏览数据。

策略
在 Oracle 数据库 10g 第 2 版和更高版本中，您可以以三种不同的模型在 RMAN 上对备份进行加密: 透明模式、基于密码的模式和混合模式。

透明模式。 按照这种方法（也是最常用的方法），RMAN 从加密钱夹中获取加密密码（在前面讨论过了），并使用它对备份集进行加密。 不必说，在备份和恢复中钱夹必须是打开的。 如果钱夹没有打开，您将看到以下错误：

ORA-19914: unable to encrypt backup
ORA-28365: wallet is not open

1. 执行以下命令打开钱夹：

   alter system set encryption wallet open authenticated by "53cr3t";

   当然，可以设置不同于 "53cr3t" 密码。 请记住，这是区分大小写的，因此必须带有双引号。

2. 确保启动整个数据库的加密。 您可以执行以下命令启动加密：

   RMAN> configure encryption for database on;

3. 另外，如果您想对几个表空间进行加密，您可以为所有的表空间执行以下命令。

   RMAN> configure encryption for tablespace users on;

4. 之后，您可以使用常规的备份命令而无需其他用户的干预。

   RMAN> backup tablespace users;

5. 当您恢复该备份时，该钱夹必须是打开的。 如果钱夹没有打开，恢复备份时您将看到以下错误：

   RMAN> restore tablespace users;
   
   Starting restore at 26-MAY-05
   using channel ORA_DISK_1
   
   ... messages ...
   ORA-19870: error reading backup piece C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AR
   EA\ANANDA\BACKUPSET\2006_02_09\O1_MF_NNNDF_TAG20060209T221325_1YR16QLT_.BKP
   ORA-19913: unable to decrypt backup
   ORA-28365: wallet is not open  
   

   错误信息是很清楚的；该钱夹必须是打开的。 如果您需要在其它服务器上恢复表空间，您必须拷贝该钱夹，使用正确的密码打开该钱夹。 如何恶意入侵者盗窃了磁带，他将不能恢复备份。

基于密码的模式。 这种情况下，不需要将钱夹用于密码管理。 密码加密备份，同时密码本身也使用密码加密。 命令如下：

RMAN> set encryption on identified by "53cr3t" only;
RMAN> backup tablespace users;

密码将对上面产生的备份集进行加密。 为了在恢复中对密码进行加密，您必须使用如下密码：

RMAN> set decryption identified by "53cr3t ";
RMAN> restore tablespace users;

这种方法就不需要使用钱夹了。 因此在任何服务器上恢复备份，您只需要密码，不再需要钱夹。 然而，您的密码在脚本中必须是可见的。这样，任何能访问数据库服务器的恶意入侵者将能够读取该密码。 请参阅第 2 阶段，其中涉及了如何隐藏密码的内容。

混合模式。由名称可知，该模式两种方法的结合体。 您按照以下方式进行备份：

RMAN> set encryption on identified by "53cr3t";
RMAN> backup tablespace users;

注意：在命令 set encryption 中没有“only”语句。 这样就可以使用两种方法之一来恢复备份： 使用密码“tiger”，或者打开钱包。 例如，请注意以下命令。 没有提供密码，但是成功地进行了恢复。

RMAN> sql 'alter tablespace users offline';
RMAN> restore tablespace users;

Starting restore at 26-MAY-05
allocated channel:ORA_DISK_1
... restore command output comes here ...

当您使用脚本处理备份时，经常不得不将数据库恢复到不同的服务器（例如 QA 服务器）上时，这种方法将派上大用场。 但是一般来说，这种方法通常没有太大的实际用处。

如果您使用透明模式进行备份加密，您也可以备份钱夹。 即使对手获得了钱夹，他没有密码也打不开钱夹。

问题

• 我以前提到加密是非常占用 CPU 的过程。因此，对整个 RMAN 备份集进行加密将是高度占用 CPU 的操作。 您可以通过部分地对备份进行加密缩短 CPU 周期——仅仅选择包含敏感数据的表空间。 一个更好的方法是将透明数据加密用于列级加密。

• 透明方法中的钱夹和基于密码方法的密码是很重要的。 如果您将它们都丢失了，您将不再能对备份进行加密；因此，要有一个计划对它们进行备份。

• 如果您使用基于密码的加密，该密码必须在脚本中。 但是可能很容易被盗。

操作计划

1. 确定您是否真的需要对整个备份集进行加密，而不是对某些表中的某些列加密。
2. 如果对 RMAN 备份进行加密，请选择整个数据库或特定表空间。
3. 选择基于密码的方法、透明方法，以及混合模式方法。
4. 如果采用透明方法，或混合模式方法，则
   1. 配置钱夹。
   2. 打开钱夹。
   3. 在 RMAN 中，配置表空间或者整个数据库进行备份加密。
5. 如果是基于密码的方法，或者混合模式方法，则
   1. 选择密码，并将它放入 RMAN 脚本中。 使用第 2 阶段中说明的任一密码隐藏技术。
   2. 只使用那些脚本进行备份。

4.6 从存档日志中挖掘历史

在第 3 阶段中，您了解了如何保护主要对象，所以没有 DBA 的同意是不能更改主要对象的。 但是，如果非法更改得到同意，但在后来才得知发生了攻击，该怎么办呢？ 这就要用到安全的第四个方面——责任可查性。

一个选项是开启 DDL 审计以跟踪 DDL 活动。 总而言之，这是最容易的方法——易于设置，更易于浏览，可以进行归档，等等。 然而，审计会影响性能，这是我们正试图避免的。 问题是如何重新跟踪 DDL 语句，而不用对审计进行设置。

策略
可以使用称为 Log Miner 的工具（或特性）。 Oracle8i 数据库中推出了 Log Miner，利用它可以搜索在线重做日志或者归档日志。

下文告诉您如何设置日志挖掘以挖掘 DDL 详细信息。 首先，获取要挖掘的在线日志文件或者归档日志文件，并将它们添加到 Log Miner 会话中。

sqlplus / as sysdba

begin
   dbms_logmnr.add_logfile (
           'C:\ORACLE\DATABASE\ANANDA\REDO03.LOG');
   dbms_logmnr.add_logfile (
           'C:\ORACLE\DATABASE\ANANDA\REDO02.LOG');
   dbms_logmnr.add_logfile (
           'C:\ORACLE\DATABASE\ANANDA\REDO01.LOG');
end;
/

添加文件之后，启动 Log Miner 会话。 您必须传递数据字典源；在这里我们已经将在线类别指定为源。

begin
   dbms_logmnr.start_logmnr (
      options => dbms_logmnr.dict_from_online_catalog
   );
end;

被挖掘的内容放在称为 V$LOGMNR_CONTENTS 的视图中；但是该视图是临时的——仅仅启动 Log Miner 的会话可以看到该视图。 因此，如果以后您想进行分析，您需要将它保存在永久表中。

create table lm_contents
nologging
as
select * from v$logmnr_contents;

select sql_redo
from lm_contents
where operation = 'DDL'
and seg_owner not in ('SYS','SYSTEM','PUBLIC');

下面是一个样例输出： 注意：没有 DROP TABLE 语句——在 Oracle 数据库 10g中，删除的表实际上没有被删除，而是进行了重新命名。 SQL_REDO 将反映这点。 实际上，用户使用 PURGE 子句删除表时，列 SQL_REDO 将会反映正确的命令。 为了保存空间，我已经修剪了输出，所以函数和过程的 DDL 出现了一部分。 我也已经使用 RECSEPCHAR '.'以显示多行记录中的设计行。）

SQL_REDO
-------------------------------------------------------------------------------

ALTER PACKAGE "XDB"."DBMS_XSLPROCESSOR" COMPILE SPECIFICATION REUSE SETTINGS;
ALTER PACKAGE "XDB"."DBMS_XMLDOM" COMPILE SPECIFICATION REUSE SETTINGS;
ALTER PACKAGE "XDB"."DBMS_XMLPARSER" COMPILE SPECIFICATION REUSE SETTINGS;
ALTER PACKAGE "EXFSYS"."DBMS_RLMGR_DR" COMPILE BODY REUSE SETTINGS;
truncate
table developers;
...............................................................................
create table patient_diagnosis
(
        patient_id      number,
...............................................................................
create view vw_patient_diagnosis
as
...............................................................................
create or replace view vw_patient_diagnosis
as
...............................................................................
create or replace function pd_pol
(
p_schema in varchar2,
...............................................................................
create or replace function pd_pol
(
p_schema in varchar2,
...............................................................................
create or replace function pd_pol
(
p_schema in varchar2,
...............................................................................
grant connect, resource to ananda identified by  VALUES '1DB10D95DE84E304' ;
create or replace function pd_pol
(
...............................................................................
create or replace function pd_pol
(
p_schema in varchar2,
...............................................................................
ALTER TABLE "ARUP"."TEST1" RENAME TO "BIN$JQHaX2mpSxOyrhkxAteHmg==$0" ;
drop table test1 AS "BIN$JQHaX2mpSxOyrhkxAteHmg==$0" ;

当然，该输出本身可能是没有任何意义；您必须察看更多的信息，例如　Log Miner　条目中的时间戳记、SCN、等等，在用户操作和实际事件之间进行有效的连接。

select timestamp, scn, seg_owner, seg_name
from lm_contents
where operation = 'DDL'
and seg_owner not in ('SYS','SYSTEM','PUBLIC')
/

TIMESTAMP        SCN SEG_OWNER  SEG_NAME
--------- ---------- ---------- ------------------------------
06-FEB-06    1024674 XDB        DBMS_XSLPROCESSOR
06-FEB-06    1026884 XDB        DBMS_XMLDOM
06-FEB-06    1026896 XDB        DBMS_XMLPARSER
06-FEB-06    1026918 EXFSYS     DBMS_RLMGR_DR
06-FEB-06    1029244 ARUP       DEVELOPERS
08-FEB-06    1096847 ARUP       PATIENT_DIAGNOSIS
08-FEB-06    1097057 ARUP       VW_PATIENT_DIAGNOSIS
08-FEB-06    1097920 ARUP       VW_PATIENT_DIAGNOSIS
08-FEB-06    1100059 ARUP       PD_POL
08-FEB-06    1100157 ARUP       PD_POL
08-FEB-06    1100386 ARUP       PD_POL
08-FEB-06    1100413 ANANDA
08-FEB-06    1101544 ANANDA     PD_POL
08-FEB-06    1101564 ARUP       PD_POL
09-FEB-06    1123950 ARUP       TEST1
09-FEB-06    1123953 ARUP       TEST1

注意：我使用的是　SEG_OWNER，不是　USERNAME。 由于　Oracle 数据库 10.2.0.1　中的一个缺陷没有解决，USERNAME　没有放入进去。

这只是怎样从归档日志中抽取　DDL　语句的一个示例。 您也可以使用任何语句挖掘日志——DML。 DML 语句挖掘是对审计的重要代替，因为它们对数据库不施加任何性能压力。

提示
Log Miner　是非侵入的，但是在服务器上它不占用很多　CPU　周期和　PGA　内存。 因此，请仔细地操作　Log Miner，最好在减少装载的条件下操作。 （另外一个选项是将存档日志移动到不同的服务器上，在那些挖掘存档日志。 只要有可能的时候，都应该利用该选项。）

操作计划

1. 识别您想从日志中挖掘的语句，以及挖掘频率。 一些示例可能是与删除对象有关的　DDL　语句；但是您可能需要更加有选择性。 在数据仓库环境里，应用程序暂时创建许多表，然后删除这些表，因此您可能想不选择那些模式。
2. 使用以上技术定期从归档日志中提取信息，并因为可能的滥用和模式对它们进行分析。

4.7 结论

安全要求的最重要因素是要明白您不可能在真空中求得安全。 为了有效地构建一个安全的数据库基础架构，您的行为必须和对机构独特本质的理解协调起来，您的分析必须包括业务流程，从而将敏感数据和非敏感数据隔离开来。 例如，信用卡数在任何机构都将被保护，但是销售数怎么办呢？ 在某些机构中（例如零售店），数据量相当庞大，加密保护就不适宜了。但是对冲基金商贸公司却是可行的， 在这里销售数据被严加保护。 查看敏感数据的一个分层方法可能实用于某些情况下；但是在大多数情况下，分层方法最可能按需提供。

即将结束时，我希望您已经学习到某些您现在就可以使用的有价值的工具和技巧来保护您的数据库基础架构。 如果您能花费一些时间让我了解您对第 4 阶段的反馈和改进建议，同时提供其它相关问题和资料，我将非常感谢。

(编辑:aniston)