|
4.4 对敏感的数据进行加密
背景
正如我前面提到的，安全就好比在寒冷的冬天里，您穿上好几件衣服或穿最庞大的冬天使用的夹克御寒。 但是，构建各防御层可能阻止不了最坚决的恶意入侵者，当然这也不会总能够防御合法用户盗窃公司财产。 这里的组最后一道防线是加密，通过加密，用户（或者恶意入侵者）只有使用密码才可以访问到数据。 没有密码的数据是无效的。 如果您保护了密码，您就保护了数据。
请记住，加密不能替代其它层次的安全性。 不管怎样，您必须有那些防御。
而且，加密是一个很大的课题，但是我将在这里给您一个可引发操作的概述。
Oracle 提供两种加密方式:
- 加密 API 例如包 dbms_obfuscation_toolkit 和 dbms_crypto （在 Oracle 数据库 10g 第 1 版和更高版本中）。 使用这些包，您可以构建您自己的基础架构，对数据进行加密。 这种方法的灵活性最强，但是构建和管理却相当复杂。
- 透明的数据加密是 Oracle 数据库 10g 第 2 版和更高版本的一个特性；使用该特性后，您就不必手动进行密码管理了。 数据库管理密码，但是正如名称所指，加密是透明的——数据仅仅以加密的方式存储而已。 当您选择了这种方式，就会明白的。
我建议在您阅读策略部分之前，请分别察看 Oracle 文档（Oracle 数据库安全指南的 第 17 章 和 Oracle 数据库高级安全管理员指南的 第 3 章）。 策略
选择常规加密，还是透明的数据加密是很重要的。 （然而，在 Oracle 数据库 10g 第 2 版之前, 您只能选择常规加密。）
- 不论哪种方式，您都必须识别要加密的表，尤其是要加密的列。 因为例行加密毁坏 CPU 周期，所以对所有列进行加密可能并不好。
- 下一步是选择加密算法。 通常是选择 156 位加密的三重数据加密标准 (DES3)。 然而，以 Oracle 数据库 10g 第 1 版开始，您可以访问更新、更快和更安全的高级加密标准 (AES) 算法，使用该算法要有 128 位密码。
- Oracle9i 数据库提供 dbms_obfuscation_toolkit；您可以使用 Oracle 数据库 10g 第 1 版访问一个更好的工具 dbms_crypto。 您仍然可用更老的包，但是如果您第一次构建加密基础架构，请不要使用。
- 在这一点，您必须选择 TDE 或您自己的例行使用的（如果可以应用的话）。 下表可以帮助您作出决定。
| |
透明的数据加密 |
用户构建的加密 |
|
灵活性 |
最小 — 例如，如果 SALARIES 表中的 SALARY 列加密了，那么 任何 能够对该表进行访问的用户都将能够清晰地察看数据。 您不能按照角色和级别对那个列进行有选择性的控制。 该数据库中的数据可以加密，但是用户访问时要能解密。 |
强健 — 例如，只有 用户为经理时，您才可以定义以明文方式显示列；否则进行加密。 这将确保不同的用户使用同样的应用程序察看不同的数据。 这种灵活性也可以扩展到其它变量，例如访问数据库的时间和客户机器。 |
|
设置 |
最小 — 该工具的确是透明的 — 您只需执行该命令（假定所有一次性的工作都已经完成，例如创建钱夹）：
ALTER TABLE SALARIES MODIFY (SALARY ENCRYPT) |
广泛的 — 要向用户提供无缝的界面，您必须创建对列进行解密的视图。 接着应该对该视图进行授权。 在管理上这添加了复杂性。 |
|
密码管理 |
自动化—该数据库使用钱夹处理密码管理。 |
人工—因为您必须管理密码，所以您必须决定如何平衡两种相互冲突的需求：
- 确保密码的安全，恶意入侵者无法获取该密码。
- 应用程序可以访问密码。
|
|
对列的限制 |
一些—某些列不能加密，例如有些列有分区密钥、数据类型 BLOB，等等，这样的列不能加密。 |
仅仅限制为 LONG。 |
|
对索引的支持 |
N/A—因为数据是以加密的方式存储的，所以在查询中索引不可能发挥作用。 |
支持—因为您控制了加密，所以您创建替代列构建索引。 |
如果您决定使用 TDE，请采取以下步骤：
- 配置钱夹： 钱夹一般位于文件夹 $ORACLE_BASE/admin/$ORACLE_SID/wallet 中，但是您可以通过将以下行放入文件 SQLNET.ORA 中使用任何位置：
ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=file)
(METHOD_DATA=
(DIRECTORY=/orawall) ) )
在这里，将钱夹位置设置为 /orawall。
- 打开该钱夹，分配一个密码： 执行以下命令：
alter system set encryption key authenticated by "53cr3t";
- 选择的密码要难以猜测，容易记忆。 （为了安全，您可能不想让 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%'。该谓词应该已经在未加密的列中使用索引范围扫描，但是还将使用全面的表扫描。
- 密码管理是一个很重要的问题。 如果您丢失了密码，就访问不到该数据。
操作计划
操作计划位于策略部分。
4.5 安全备份
背景
许多情况下，DBA 会忽略最容易受到攻击的要害： 数据库备份。 一旦数据不在服务器的安全范围内，您将不再能控制这些数据。 如果恶意入侵者可以盗窃磁带，他就可以将它们安装到一个不同的服务器上，恢复数据库，再慢慢地浏览数据。 幸运地是，即使这样您只要使用加密备份还是可以消除这种风险的。
策略
在 Oracle 数据库 10g 第 2 版和更高版本中，您可以以三种不同的模型在 RMAN 上对备份进行加密: 透明模式、基于密码的模式和混合模式。
透明模式。 按照这种方法（也是最常用的方法），RMAN 从加密钱夹中获取加密密码（在前面讨论过了），并使用它对备份集进行加密。 不必说，在备份和恢复中钱夹必须是打开的。 如果钱夹没有打开，您将看到以下错误： ORA-19914: unable to encrypt backup
ORA-28365: wallet is not open
- 执行以下命令打开钱夹：
alter system set encryption wallet open authenticated by "53cr3t";
当然，可以设置不同于 "53cr3t" 密码。 请记住，这是区分大小写的，因此必须带有双引号。
- 确保启动整个数据库的加密。 您可以执行以下命令启动加密：
RMAN> configure encryption for database on;
- 另外，如果您想对几个表空间进行加密，您可以为所有的表空间执行以下命令。
RMAN> configure encryption for tablespace users on;
- 之后，您可以使用常规的备份命令而无需其他用户的干预。
RMAN> backup tablespace users;
- 当您恢复该备份时，该钱夹必须是打开的。 如果钱夹没有打开，恢复备份时您将看到以下错误：
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
错误信息是很清楚的；该钱夹必须是打开的。 如果您需要在其它服务器上恢复表空间，您必须拷贝该钱夹，使用正确的密码打开该钱夹。 如何恶意入侵者盗窃了磁带，他将不能恢复备份。
(编辑:aniston)
|
