透明数据加密 (TDE) 常见问题解答

问题和解答

1. 任何人只要有权访问加密数据就能对其进行解密吗？

   是的，TDE 旨在让客户能够透明地在数据库中进行加密，而不会影响现有应用。以加密格式返回数据会破坏大多数现有应用。TDE 的优势在于，加密不会产生传统数据库加密解决方案所产生的开销，传统的方案通常需要对应用进行更改，包括使用数据库触发器和视图，因而费时费力，成本高昂。不过，客户可以使用 Oracle Database Vault 保护应用数据，防止 DBA 及其他超级用户的不当使用，还可以对数据库和应用实施强大的访问权限控制。

1. TDE 会带来哪些开销？

   表 A：TDE 会带来哪些开销？

   	TDE 表空间加密 (Oracle Database 11g)	TDE 列加密 （Oracle Database 10gR2、 Oracle Database 11g）
   存储	没有额外的存储开销。	TDE 列加密带来的存储开销为每个加密值 1 到 52 个字节。 必需：对于 AES，填充到下一个 16 字节；对于 3DES168，填充到下一个 8 字节。所以，如果一个值需要 9 个字节的存储空间，加密该值将需要额外 7 个字节的存储空间（对于 AES）。 可选：额外 20 个字节的完整性检查 可选：如果为加密列指定了"SALT"，每个值将需要额外 16 个字节的存储空间。 了解这些数字有助于进行存储规划，但 DBA 和开发人员不用手动为 TDE 列加密扩大列存储空间，因为在将某列标记为"encrypted"时，TDE 会透明地完成这项任务。 用户可以选择 'no salt' 选项来减少所需额外存储空间（可节省 16 个字节），还可以选择 'nomac' 选项（10.2.0.4、11.1.0.7 和 Oracle Database 11g 第 2 版中提供该选项）来消除为每个加密字段计算和存储 20 字节散列值而需要的额外的 CPU 周期和磁盘空间。
   性能	内部基准测试结果和来自成功生产实施的反馈结果表明，性能开销只是个位数。对于 Oracle Database 11g 第 2 版补丁集 1 (11.2.0.2)，TDE 表空间加密可自动利用基于 AES-NI 的硬件密码加速（可用于大多数 Intel? XEON? 5600 CPU），TDE 表空间加密因而成为了"几乎没有影响"的加密解决方案，特别是在数据仓库环境中。	加密或解密通用属性（如信用卡号码）带来的性能开销估计为 5% 左右。基于加密列构建索引时，将使用密文构建索引。如果 TDE 加密列建立了索引并为 SQL 语句所引用，Oracle 将用表密钥对 SQL 语句中用到的值进行透明加密并使用密文进行索引查询；如果所有索引都按照在应用 TDE 列加密之前最初设计的方式重新构建，客户报告的性能影响可以忽略不计。建议打算使用 TDE 列加密的客户升级到 Oracle Database 10gR2 10.2.0.4/5（并应用补丁 7639262）或 Oracle Database 11gR1 11.1.0.7（并应用补丁 8421211），因为这两个版本包含可减少性能开销的更改。两个相应的补丁已集成到 Oracle Database 11g 第 2 版中。

1. 哪些加密算法可与 TDE 一同使用？

   TDE 支持 AES256、AES192（列加密默认算法）、AES128（表空间加密默认算法）和 3DES168。

1. 可以使用第三方加密算法代替 TDE 提供的算法吗？

   不可以，不能插入其他加密算法。Oracle 提供人们广泛接受的加密算法，并且将会引入新的可用标准算法。

1. 可以对外键约束中使用的列采用 TDE 列加密吗？

   TDE 不支持对外键约束中使用的列进行加密。这是因为各个表有自己独有的加密密钥。以下查询可以列出数据库中存在的所有 RI（引用完整性）约束：

   SQL> select A.owner, A.table_name, A.column_name, A.constraint_name
   from dba_cons_columns A, dba_constraints B
   where A.table_name = B.table_name and B.constraint_type = 'R';

1. 可以对联接中使用的列进行 TDE 列加密吗？

   可以。即使联接条件的列已加密，联接表对于应用和用户也是透明的。

1. 可以对已建索引的列进行加密吗？

   TDE 表空间加密透明地支持所有索引。

   而对于 TDE 列加密，索引必须是用于等式搜索的普通 B 树索引。如果是基于函数的复合索引，则不能对相应函数使用的列进行加密。当对已有索引的列进行加密时，建议首先利用 dbms_metadata.get_ddl 获取索引定义，然后丢弃该索引，使用"no salt"选项对该列进行加密，最后重建索引。

1. TDE 列加密支持哪些数据类型和数据长度？

   TDE 表空间加密对于支持的数据类型没有限制；以下数据类型可使用 TDE 列加密进行加密：

   
   
   varchar2 (< 3933 characters)		nvarchar2 (< 1967 characters)
   
   char (< 1933 characters)		nchar (< 967 characters)
   
   number					raw
   
   binary_float				binary_double
   
   timestamp				date
   
   SecureFile (11gR1 and later)

1. 数据在网络上传输时仍处于加密状态吗？

   使用 TDE 加密后的数据在从数据库文件中读回时会被解密。因此，如果在网络上传输该数据，它将处于明文状态。不过，客户可以使用 Oracle 的网络加密解决方案（示例）对这些数据进行加密，该方案和 TDE 一同包含在 Oracle Advanced Security 选件中。Oracle 的网络加密解决方案可以对通过 SQLNet 与数据库往来传输的所有数据进行加密。

• 数据库内存 (SGA) 中包含的是明文数据还是加密数据？

  对于 TDE 列加密，加密数据在 SGA 中仍保持加密状态，但是对于 TDE 表空间加密，数据在 SGA 中已被解密，从而提供 100% 的透明性。

• 如何知道要加密哪些数据呢？

  如果客户必须遵守 PCI-DSS 标准，那么信用卡号码（亦称 主账号，即 PAN）需要加密后再保存。

  如果需要遵守几乎无处不在的数据泄露通知法案（如 CA SB 1386、CA AB 1950 以及美国超过 43 个州的类似法律），那么需要加密的数据还有姓氏、名称、驾照号码及其他个人身份信息 (PII)。2008 年初，CA AB 1298 将医疗和健康保险信息也列为 PII 数据。

  此外，客户所处行业特有的隐私与安全标准可能要求对特定资产进行加密，另外，客户自身的核心业务资产（如药品研究成果、油田勘探成果、金融合同、执法举报者的个人详细信息等）可能也需要加密以便安全地保存在存储介质上。在医疗卫生行业，患者数据、健康记录和 X 射线影像的私密性非常重要。X 射线影像的存储大多遵循 DICOM 标准，该标准特意将 PII 信息纳入到了影像元数据中，如果不对影像和患者数据进行适当的加密保护，入侵者很容易就能获得这些数据。在 Oracle Database 11g 中，DICOM 影像可以存储到"SecureFile"列中，TDE 可以通过列加密对这些列进行加密，也可以通过表空间加密对包含"SecureFile"列（或通常的 LOB 列）的表进行加密。

• 需要加密的数据都在哪里？

  安全团队或 DBA 团队在使用 TDE 列加密时面临的非常困难的任务是：

  如果运行的应用是内部自行开发的，那么问下开发人员可能就会知道敏感信息都在哪些表里。

  但如果运行的是商业打包软件应用，那就比较困难了。由于这类应用的每次部署都有不同的隐私和安全性要求，因此就连供应商自己都不太容易确定要加密哪些内容。如果以遵守 PCI 标准为目标，并且应用表中相应的列名类似于"CREDIT_CARD"或 "ACCOUNT_NUMBER"，那么利用 Oracle 丰富的元数据信息库即能轻松找出它们。

  但如果列名不是对列内容的描述性标识，就要通过更复杂的方法来搜索敏感数据。在这种情况下，我们只能通过模式搜索来找出敏感内容：社会保险号码始终类似于"aaa-bb-cccc"，但信用卡号码不太一致 -- 有的是 13 位数字，有的是 16 位数字，而且并非总是 4 位一组。

  如果要加密的列具有 TDE 列加密不支持的特质（在索引、数据类型或外键方面），或者无法在应用表中找到存储敏感数据的列，TDE 表空间加密是您的理想选择。

• 对于 Oracle Database 11g，何时使用 TDE 列加密或 TDE 表空间加密？

  如果下列任何一项是正确的，请使用 TDE 表空间加密：

  1. 您希望加密解决方案具有极佳的性能。TDE 表空间加密在大多数情况下具有更好、更稳定的性能特点。此外，表空间加密还在允许的情况下特别利用了硬件密码加速，从而进一步将性能影响减少至近乎为零。对于支持 AES-NI 的 Intel? XEON? 5600 CPU，Oracle Database 11g 第 2 版补丁集 1 (11.2.0.2) 提供硬件密码加速支持。
  2. 您无法一一找出包含敏感内容的所有列。
  3. TDE 列加密不支持敏感列的数据类型和/或数据长度。
  4. 敏感列用作外键。
  5. 应用对已建索引的加密列执行范围扫描。
  6. 对于加密列，您需要不同于 B 树类型的索引。

• TDE 与 Oracle 早前提供的加密工具包有何不同？

  Oracle 在 Oracle8i 中引入了加密包"dbms_obfuscation_toolkit"，后来在 Oracle 10g 第 1 版中引入了"dbms_crypto"加密包。这些 API 可用于对数据库中数据手动加密，但应用必须对加密密钥进行管理并通过调用 API 执行所需加解密操作。

  与 dbms_obfuscation_toolkit 和 dbms_crypto 加密包不同的是，TDE 列加密（从 10gR2 起引入）和 TDE 表空间加密（从 11gR1 起引入）无需更改应用，对于最终用户来说是透明的，并且提供内置的自动化密钥管理。

• 如何获得 TDE 许可？

  TDE 是 Oracle Advanced Security 选件的一部分，该选件还包含网络加密和强身份验证。Oracle 企业版客户可以使用该选件。

• 什么是 Oracle 钱夹？

  钱夹是一个加密的容器，用于存储身份验证和签名凭证，包括 SSL 所需的密码、TDE 主密钥、PKI 私钥、证书和可信证书。借助 TDE，可以在服务器上使用钱夹保护 TDE 主密钥。除非使用 Diffie-Hellman，否则 Oracle 要求在 SSL 上通信的实体包含一个钱夹，该钱夹应当含有 X.509 版本 3 证书、私钥、可信证书列表。

  Oracle 提供两种类型的钱夹：加密钱夹和（本地）自动打开的钱夹。我们建议对 TDE 使用加密钱夹（文件名为 ewallet.p12）。数据库启动后和访问 TDE 加密数据前，需手动打开该钱夹。由于数据在 REDO 日志、UNDO 和 TEMP 表空间中处于加密状态，因此在打开数据库前需要为其提供 TDE 主加密密钥：

  
  
  $ sqlplus / as sysoper
  
  PUBLIC> startup mount;
  
  ORACLE instance started.
  
  Database mounted.
  
  PUBLIC> alter system set encryption wallet open identified by "wallet_password";
  
  System altered.
  
  PUBLIC> alter database open;
  
  Database altered.

  如果未打开该钱夹，查询受 TDE 保护的数据时数据库将返回错误。（本地）自动打开的钱夹（文件名是 cwallet.sso）在访问加密数据时会自动打开，因此它适用于无人值守的 Data Guard 环境（Oracle 10gR2：仅物理备用数据库；Oracle 11g：物理和逻辑备用数据库），在这类环境中加密后的数据会传送到辅助站点。在创建自动打开的钱夹后，永远不要删除加密钱夹，否则，主加密密钥更新操作将会失败。
  本地自动打开的钱夹是在 Oracle Database 11g 第 2 版中引入的，该钱夹只能在创建它的服务器上自动打开。

• 如何保护 TDE 钱夹？

  在 Unix 上，应当使用适当的目录 (700) 和文件权限 (600) 只允许"oracle:oinstall"用户:组访问该钱夹。不过，即使 root 用户有权访问钱夹文件，但如果该用户不知道钱夹密码，仍然无法访问主加密密钥。在所有平台上，钱夹密码（用于加密该钱夹的密码）应至少包含 8 个字母和数字字符。钱夹密码可通过 Oracle Wallet Manager 或 orapki 实用程序来更改。强烈建议在更改钱夹密码之前对 Oracle 钱夹进行备份。更改钱夹密码不会更改 TDE 主密钥（它们彼此独立）。
  在 Linux 平台上，从 Oracle Database 11g 第 2 版 (11.2.0.2) 起，我们建议将 Oracle 钱夹存储在 ACFS（基于 ASM 的集群文件系统，适用于单实例、单节点 RAC、多节点 RAC，但不适用于 Exadata X2）中，因为该文件系统新的安全特性提供出色的钱夹保护和职责分离。有关如何在 ACFS中创建访问控制策略（含职责分离）的详细分步指南，请参阅频繁更新的 TDE 优秀实践文档。

• 可否使用 Oracle Wallet Manager (OWM) 为 TDE 创建加密钱夹和主密钥？

  不能。如果您使用 Oracle Wallet Manager 创建钱夹，该钱夹不包含 TDE 所需的主密钥。只有以下 SQL 命令：

  
  
  SQL> alter system set encryption key identified by "wallet_password";

  能够创建加密钱夹（若其在 sqlnet.ora 文件中指定的位置不存在）并为其添加 TDE 主密钥。

  在 Oracle 11gR1 中，TDE 及其他安全特性已迁移到 Enterprise Manager Database Control 中，因此可以使用 Enterprise Manager 基于 Web 的 GUI 来生成钱夹和主密钥。

  Oracle 11g 第 2 版中引入了新的统一主加密密钥，该密钥可同时用于 TDE 列加密和表空间加密；您可以在 Oracle 钱夹中创建、存储和更新（轮换）此密钥。

• 可以更改钱夹密码吗？

  可以，您可以通过 Oracle Wallet Manager (OWM) 更改钱夹密码。在尝试更改钱夹密码前，请创建备份。更改钱夹密码不会更改主密钥（它们彼此独立）。在 Oracle 11gR1 11.1.0.7 中，orapki 已得到增强，允许通过命令行更改钱夹密码：

  
  
  $ orapki wallet change_pwd -wallet <wallet_location>

• 如何创建（本地）自动打开的钱夹？

  当需要在无人干预的情况下保持数据库可用性时（无人值守的运营），对 TDE 主密钥使用密码保护的加密钱夹可能并非合适的解决方案；而（本地）自动打开的钱夹在数据库启动后无需钱夹密码，让授权用户和应用可以访问加密数据。

  （本地）自动打开的钱夹 (cwallet.sso) 需要用现有的加密钱夹 (ewallet.p12) 创建，以便将主密钥传给新建的自动打开钱夹。

  您可以在 Oracle Wallet Manager (OWM) 中打开加密钱夹，选中 Auto Login 复选框，然后选择 Save 将自动打开的钱夹写入磁盘，也可以使用命令行工具 orapki：

  
  
  $ orapki wallet create -wallet <wallet_location> -auto_login

  创建本地自动打开钱夹的命令语法如下所示：

  
  
  $ orapki wallet create -wallet <wallet_location> -auto_login_local

  两种情况（Oracle Wallet Manager 和 orapki）都要求提供钱夹密码。请保留加密钱夹，因为主密钥更新操作需要使用该钱夹，并且该钱夹可能包含弃用主密钥列表。

• 使用 Oracle Secure Backup 时，如何避免将 Oracle TDE 钱夹备份到 RMAN 数据库备份所在的磁带上？

  RMAN 只会将数据库文件、重做日志等添加到备份文件中，因此加密钱夹或自动打开的钱夹不会成为数据库备份的一部分。Oracle Secure Backup (OSB) 使用数据集定义待备份的操作系统文件。OSB 自动排除自动打开的钱夹 (cwallet.sso)，但不会自动排除加密钱夹 (ewallet.p12)，您需要使用排除数据集语句来指定备份过程中需要跳过的文件：

  
  
  exclude name .p12

• 钱夹备份优秀实践

  请在发生以下情况时立即备份 Oracle 钱夹：创建钱夹后、每次钱夹内容发生更改时（例如由于主密钥更新操作），以及每次更改钱夹密码后。始终将钱夹（加密钱夹或本地自动打开的钱夹）存储到远离数据库备份的位置。

• 哪些打包应用通过了透明数据加密认证？

  Oracle 投资于各种软件解决方案的兼容性测试，其中包括作为 Oracle 集成式软硬件体系一部分的应用及其他第三方应用。下表总结了这些应用认证结果。有关详细信息，请参见链接页面和文件。

  表 B：通过透明数据加密认证的应用

  TDE 表空间加密 (Oracle Database 11g)	TDE 列加密 （Oracle Database 10.2.0.4/5 或 Oracle Database 11g）
  Oracle E-Business Suite（产品介绍）单击这里了解更新
  Oracle PeopleSoft Enterprise 8.48 及更高版本 （产品介绍 | 红皮书 | 迁移指南）	Oracle PeopleSoft Enterprise 8.46 及更高版本（产品介绍）
  Oracle Siebel CRM 8.0 及更高版本（产品介绍）	Oracle Siebel CRM 7.7 及更高版本
  Oracle JD Edwards EnterpriseOne（产品介绍）	Oracle Financial Services (iFlex) FlexCube 10.0
  	Oracle 零售应用 (Retek)： ReSA 12.0 及更高版本和 13.0 (10gR2) ReSA 13.1 (11gR1)
  	Infosys Finacle
  SAP 6.40_EX2 及更高版本（仅 UNIX 和 Linux）	SAP 6.40 及更高版本（SAP 说明 974876）
  Oracle Internet Directory 10.1.4.2（白皮书）

  ---

• 可否对 Exadata 中存储的数据进行加密？

  可以。透明数据加密是在大规模 Exadata 环境中保护敏感数据的一种好办法。Exadata 让大幅提高加密性能成为可能。Exadata 提供的超强加密性能归功于以下独到之处：

  1. Exadata 系统中优化的 Oracle 硬件和软件
  2. 各个存储和计算节点间的分布式加密处理
  3. 智能扫描和混合列压缩 (EHCC) 等 Exadata 原生特性
  4. 提供硬件密码加速

  例如，光是 Exadata 中的硬件密码加速就可将性能提高多达 10 倍（相对于没有硬件加速的情况）

  下表总结了 Exadata X2 系统计算和存储节点上的性能特点。该表重点介绍了可以启用硬件密码加速的情况。

  增速比较根据使用和不使用硬件加速情况下测量的加密/解密吞吐量得出

  Exadata 型号	X2-2		X2-8
  节点	加密	解密	加密	解密
  计算	在 Intel Xeon X5670（含补丁 10080579）中启用硬件加速	在 Intel Xeon X5670 中默认启用硬件加速	在 Intel? X7560 中通过 Nehalem 技术实现硬件加速
  存储	不适用	在 Intel Xeon L5640 中默认启用硬件加速	不适用	在 Intel Xeon L5640 中默认启用硬件加速

  注：在 Oracle Exadata V2 和 X2 中，表密钥（用于TDE 列加密）或表空间密钥（用于 TDE 表空间加密）被发送到存储单元，以便首先解密内容，然后应用智能扫描。内容加密在计算节点中进行。解密通常在计算节点中进行，但是当查询被推送到存储节点时，解密会在存储节点中进行，以便启用智能扫描。

  ---

• 什么是 Oracle Secure Backup (OSB)？

  Oracle Secure Backup 为 Oracle 数据库提供了一种优化、高效的磁带备份解决方案。OSB 能够以加密的格式在磁带上存储数据，从而防范备份磁带被盗窃。

• Oracle RMAN 如何处理加密数据？

  表 B：Oracle 透明数据加密和 Oracle RMAN

  应用数据	RMAN 压缩备份	RMAN 加密备份	RMAN 压缩和加密备份
  未加密	压缩数据	加密数据	数据先压缩再加密
  使用 TDE 列进行加密	压缩数据；将加密列视为未加密	加密数据；对加密列双重加密	数据先压缩再加密；将加密数据视为未加密；对加密列双重加密
  使用 TDE 表空间加密进行加密	对加密的表空间进行解密、压缩和重新加密	加密的表空间原样传送给备份	对加密的表空间进行解密、压缩和重新加密

  当存在本地 TDE 主加密密钥时"透明"加密[和压缩]的示例：

  
  
  RMAN> connect target <ORACLE_SID>/<SYS pwd>
  
  RMAN> set encryption on;
  
  RMAN> backup [as compressed backupset] database;

  无论使用 TDE 主加密密钥还是密码短语对文件进行加密，对发送到磁盘的 RMAN 备份进行加密都需要 Advanced Security 选件的许可。

• 可否使用 Oracle Secure Backup 对发送至磁盘的备份进行加密？

  不能。不过，Oracle RMAN 可与 Oracle Advanced Security 一起使用，对发送至磁盘的数据库备份进行加密。这需要 Oracle Advanced Security 选件的许可。

• 可传输表空间可否与 TDE 表空间加密协同工作？

  可以，不过这需要将包含主密钥的钱夹复制到辅助数据库。如果移动表空间但不提供主密钥，在访问表空间数据时，辅助数据库将返回错误。

• 压缩可否与 TDE 协同工作？

  可以。数据块在压缩后进行加密，因此使用 TDE 表空间加密的客户可获得压缩（标准压缩、高级压缩以及 Exadata 混合列压缩 (EHCC)）的全部好处。使用 TDE 列加密的客户只能在不加密的表列上获得压缩的全部好处。使用 TDE 列加密的各个表列只能获得很低的压缩水平，因为它们是在 SQL 层进行加密之后再进行高级压缩处理。

• TDE 可否与 Data Guard、Streams 和 Oracle Golden Gate 协同工作？

  可以。当 TDE 用于 Data Guard 物理备用数据库（10gR2 及更高版本）时，在向辅助数据库传输数据的过程中加密数据在日志文件中仍保持加密状态，此时可以选择使用 ASO 网络加密在传输过程中对磁盘上未加密的数据进行加密。请参阅 Metalink 说明 749947.1 了解如何配置 ASO 自带的网络加密，并参阅 Metalink 说明 1143443.1 了解如何配置基于 SSL 的加密。对此，必须将包含主密钥的钱夹复制到全部物理备用数据库站点并打开该钱夹，不管是仅应用重做日志、以只读方式打开、在 Active Data Guard 中打开（只读和应用重做日志），还是进行角色转换（切换或故障切换）都是如此。

  当 TDE 用于 Data Guard 逻辑备用数据库 (11gR1) 时，必须将包含主密钥的钱夹复制到辅助站点并打开该钱夹，以便 SQL Apply 可以对从日志文件中读取的数据进行解密。在将传入数据写入逻辑备用数据库时，可以使用同样的主加密密钥对数据进行加密。加密数据在日志文件中保持加密状态，并且在日志文件被传送到辅助数据库的传输过程中仍保持加密状态；Oracle 网络加密是可选的。请参阅 Metalink 说明 749947.1 了解如何配置 ASO 自带的网络加密，并参阅 Metalink 说明 1143443.1 了解如何配置基于 SSL 的加密。

  当 TDE 与 11gR1 中的 Streams 一起使用时，在活动数据库之间以明文传输数据，以允许数据转换（字符集、数据库版本、平台等）。当无法到达接收端且需要临时存储数据时，加密列以加密形式存储在磁盘上。在 11gR1 之前的数据库版本中，Streams 将加密列视为"不受支持的数据类型"，因此跳过这些表。

  Oracle Golden Gate 版本	TDE 列加密	TDE 表空间加密
  11.1.1.1 之前的版本	对所有 Oracle 数据库版本提供部分支持，支持两者同用的前提是相应表具有主键或唯一索引，并且加密列为： CHAR 或 VARCHAR2 数据类型 不是表的主键	不支持
  11.1.1.1	Oracle Database 10.2.0.5 和 11.2.0.2 中内置的 Golden Gate 11.1.1.1 支持 TDE 加密；在 11.1.0.7 中则需要补丁 9409423。

  可以使用 blowfish 或 SSH 端口转发来加密流量。

• 是否有数据库特性不能与 TDE 列加密协同工作？

  TDE 表空间加密对表空间中存储的所有内容进行加密，不会与任何其他数据库特性冲突。TDE 列加密是在数据经过 SQL 层时对数据进行透明的加密和解密。Oracle 的某些特性会绕过 SQL 层，因此不能利用 TDE 列加密，比如以下特性：

  • 物化视图日志（Oracle 11g 第 2 版本支持该特性）
  • 数据仓库的同步和异步更改数据捕获 (CDC)
  • 可传输表空间
  • LOB（从 11gR1 起支持 SecureFiles）
  • Streams（从 11gR1 起支持该特性）

1. 可否使用带有直接路径的 SQLLoader 将数据加载到包含加密列的表中？

   可以。如果目标表包含加密列，数据将在加载时进行加密。以下简单示例说明了如何使用带有直接路径的 SQLLoader。只需将 ulcase6.sql 中的一行从

   
   
   sal number(7,2),

   更改为

   
   
   sal number(7,2) encrypt,

   并使用 SQLLoader 的正确语法：

   
   
   $ sqlldr USERID=scott/tiger CONTROL=ulcase6.ctl LOG=ulcase6.log DIRECT=TRUE

• 使用 TDE 列加密对敏感信息进行加密后，为什么有时仍能看到明文数据？

  这种情况与即使已删除表或文件、但仍然会在磁盘上看到数据的情况相同。在一个表的生命周期内，数据可能会在表空间内分段、重新整理、排序、复制和移动，这会在数据库文件中留下数据的"幽灵副本"。加密现有列时，仅对新的"有效"副本加密，而在"幽灵副本"中留下较旧的明文版本。如果绕过数据库的访问控制而直接访问包含表空间的数据文件（例如，使用十六进制编辑器），那么在这些块被数据库覆盖之前，有时就会看到旧的明文值。为了尽可能降低此等风险，请遵循下面的建议：

  1. 在新的数据文件中创建一个新的表空间 (CREATE TABLESPACE ... )
  2. 对原始表空间和数据文件中的明文值进行加密 (ALTER TABLE ...ENCRYPT )
  3. 对包含加密列的所有表执行第 2 步
  4. 将原始表空间中的所有表移到新的数据文件中 (ALTER TABLE ...MOVE... )
  5. 删除原始表空间 (DROP TABLESPACE )，不要使用 "and datafiles" 参数，Oracle 推荐对操作系统级操作使用更有力的方法，参见第 6 步
  6. 针对您的平台使用 "shred" 或其他 OS 命令，以便在 OS 级别上删除旧数据文件

  建议您使用第 6 步操作来降低数据库文件出现幽灵副本的概率，不论这些副本是由操作系统生成还是由存储固件生成。

• 如何更改（轮换、更新）加密密钥？

  表 C：密钥更新功能（Oracle 钱夹）

  数据库版本	TDE 列加密		TDE 表空间加密
  	主加密密钥	各个表密钥	主加密密钥	各个表空间密钥
  10gR2	是	是	不适用	不适用
  11gR1	是	是	否()	否()
  11gR2	是	是	是	否()

  ^(*)：可以将内容从一个加密表空间移到一个新的加密表空间，在新的表空间中使用新的表空间密钥进行加密。

  TDE 采用两层密钥机制。在对某个现有应用表列进行 TDE 列加密时，系统会创建一个新的表密钥并将该密钥存储在 Oracle 数据字典中。在使用 TDE 表空间加密时，系统会将各个表空间密钥存储在底层 OS 文件头部。表密钥和表空间密钥使用 TDE 主加密密钥进行加密。主加密密钥在 TDE 初始化时生成并且存储在数据库之外的 Oracle 钱夹中。主密钥和表密钥都可以依据公司安全策略单独进行更改（轮换、更新）。表空间密钥不能更新（轮换），对此的变通方法是将数据移动到新的加密表空间。Oracle 建议在每次主密钥更改前后对钱夹进行备份。

  更改钱夹密码不会更新 TDE 主加密密钥。

• 如何快速加密超大型表（包含数十亿行）中的列？

  对现有表中的列进行加密是一种"更新"操作，允许对该表进行读取访问，而不允许进行其他 DML 操作。由于有数十亿行，这一可用性有限的窗口会持续很长时间。不过 Oracle 数据库提供了一个成熟的高可用性特性 -- 联机表重定义，利用该特性，仅需要一个持续时间非常短的窗口对表进行独占式锁定。该时间长度与表的大小及重定义的复杂性无关，并且对用户和应用是完全透明的，不会导致任何数据损失。

• 如何将明文应用表空间的内容迁移到加密表空间中？

  • 使用"dbms_metadata.get_ddl"提取用于创建原始应用表空间的 DDL 并将输出另存为一个 SQL 脚本。
  • 在每个"create tablespace"语句中添加"ENCRYPTION DEFAULT STORAGE(ENCRYPT)"（无需更改 SIZE 参数，因为 TDE 表空间加密不会增加存储需求）
  • 用 Data Pump (expdp) 导出整个数据库，或拥有应用表空间的模式
  • 用"with contents and datafiles"删除应用表空间。
  • 运行 SQL 脚本创建加密应用表空间，其他特性保持不变。
  • 用 Data Pump (impdp) 导入转储文件。

• TDE 可否将其主加密密钥存储到使用 PKSC11 接口的外部设备中？

  从 Oracle Database 11g 第 2 版起，Oracle Advanced Security 透明数据加密 (TDE) 客户可以选择将 TDE 主加密密钥存储到使用 PKCS11 接口的外部设备中。在此配置下，主密钥直接存储在第三方设备中，而非所含 Oracle 钱夹中（注意：Oracle 钱夹是大多数 TDE 客户使用的基于 PKCS12 文件的密钥库）。
  
  使用 PKCS11 时，由第三方供应商提供存储设备、PKCS11 软件客户端库、设备与 PKCS11 客户端（在数据库服务器上运行）之间的安全通信、身份验证、审计及其他相关功能。并且由供应商负责测试和确保 TDE 主加密密钥在各种数据库服务器环境和配置下的高可用性。客户应与设备供应商联系，获得帮助以解决任何相关问题。