透明数据加密 (TDE)常见问题解答
问题
任何人只要有权访问加密数据就能对其进行解密吗?
TDE 会带来哪些开销?
哪些加密算法可与 TDE 一同使用?
可使用第三方加密算法代替 TDE 提供的算法吗?
能够对外键约束中使用的列采用 TDE 列加密吗?
能够对联接中使用的列进行加密吗?
能够对已建索引的列进行加密吗?
TDE 列加密支持哪些数据类型和数据长度?
数据在网络上传输时仍处于加密状态吗?
数据库内存 (SGA) 中包含的是明文数据仍是加密数据?
如何知道要加密哪些数据呢?
须要加密的数据都在哪里?
对于 Oracle Database 11gR1,什么时候使用 TDE 列加密或 TDE 表空间加密?
TDE 与 Oracle 早前提供的加密工具包有何不一样?
如何得到 TDE 许可?
钱夹管理
什么是钱夹?
如何保护 TDE 钱夹?
能否使用 Oracle Wallet Manager (OWM) 为 TDE 建立加密钱夹和主密钥?
能够更改钱夹密码吗?
如何建立(本地)自动打开的钱夹?
使用 Oracle Secure Backup 时,如何避免将 Oracle TDE 钱夹备份到 RMAN 数据库备份所在的磁带上?
钱夹备份优秀实践
跨组件集成
哪些 Oracle 应用经过了透明数据加密认证?
能否对 Exadata 中存储的数据进行加密?
什么是 Oracle Secure Backup (OSB)?
Oracle RMAN 如何处理加密数据?
能否使用 Oracle Secure Backup 对发送至磁盘的备份进行加密?
可传输表空间能否与 TDE 表空间加密协同工做?
压缩能否与 TDE 协同工做?
TDE 能否与 Data Guard、Streams 和 Oracle Golden Gate 协同工做?
是否有数据库特性不能与 TDE 列加密协同工做?
能否使用带有直接路径的 SQL*Loader 将数据加载到包含加密列的表中?
优秀实践
使用 TDE 列加密对敏感信息进行加密后,为何有时仍能看到明文数据?
如何更改(轮换、更新)加密密钥?
如何快速加密超大型表(包含数十亿行)中的列?
如何将明文应用表空间的内容迁移到加密表空间中?
其余问题
TDE 能否将主加密密钥存储到使用 PKSC11 接口的外部设备中?算法
解答
任何人只要有权访问加密数据就能对其进行解密吗?
是的,TDE 旨在让客户可以透明地在数据库中进行加密,而不会影响现有应用。以加密格式返回数据会破坏大多数现有应用。TDE 的优点在于,加密不会产生传统数据库加密解决方案所产生的开销,传统的方案一般须要对应用进行更改,包括使用数据库触发器和视图,于是费时费力,成本高昂。不过,客户可使用 Oracle Database Vault 保护应用数据,防止 DBA 及其余超级用户的不当使用,还能够对数据库和应用实施强大的访问权限控制。
--------------------------------------------------------------------------------
TDE 会带来哪些开销?
TDE 表空间加密(Oracle Database 11g) TDE 列加密(Oracle Database 10gR二、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.四、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 版中。
--------------------------------------------------------------------------------
哪些加密算法可与 TDE 一同使用?
TDE 支持 AES25六、AES192(列加密默认算法)、AES128(表空间加密默认算法)和 3DES168。
--------------------------------------------------------------------------------
可使用第三方加密算法代替 TDE 提供的算法吗?
不能够,不能插入其余加密算法。Oracle 提供人们普遍接受的加密算法,而且将会引入新的可用标准算法。
--------------------------------------------------------------------------------
能够对外键约束中使用的列采用 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';
--------------------------------------------------------------------------------
能够对联接中使用的列进行 TDE 列加密吗?
能够。即便联接条件的列已加密,联接表对于应用和用户也是透明的。
--------------------------------------------------------------------------------
能够对已建索引的列进行加密吗?
TDE 表空间加密透明地支持全部索引。
而对于 TDE 列加密,索引必须是用于等式搜索的普通 B 树索引。若是是基于函数的复合索引,则不能对相应函数使用的列进行加密。当对已有索引的列进行加密时,建议首先利用 dbms_metadata.get_ddl 获取索引定义,而后丢弃该索引,使用“no salt”选项对该列进行加密,最后重建索引。
--------------------------------------------------------------------------------
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)
--------------------------------------------------------------------------------
数据在网络上传输时仍处于加密状态吗?
使用 TDE 加密后的数据在从数据库文件中读回时会被解密。所以,若是在网络上传输该数据,它将处于明文状态。不过,客户可使用 Oracle 的网络加密解决方案(示例)对这些数据进行加密,该方案和 TDE 一同包含在 Oracle Advanced Security 选件中。Oracle 的网络加密解决方案能够对经过 SQL*Net 与数据库往来传输的全部数据进行加密。
--------------------------------------------------------------------------------
数据库内存 (SGA) 中包含的是明文数据仍是加密数据?
对于 TDE 列加密,加密数据在 SGA 中仍保持加密状态,可是对于 TDE 表空间加密,数据在 SGA 中已被解密,从而提供 100% 的透明性。
--------------------------------------------------------------------------------
如何知道要加密哪些数据呢?
若是客户必须遵照 PCI-DSS 标准,那么信用卡号码(亦称 主帐号,即 PAN)须要加密后再保存。
若是须要遵照几乎无处不在的数据泄露通知法案(如 CA SB 138六、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 表空间加密:
您但愿加密解决方案具备极佳的性能。TDE 表空间加密在大多数状况下具备更好、更稳定的性能特色。此外,表空间加密还在容许的状况下特别利用了硬件密码加速,从而进一步将性能影响减小至近乎为零。对于支持 AES-NI 的 Intel? XEON? 5600 CPU,Oracle Database 11g 第 2 版补丁集 1 (11.2.0.2) 提供硬件密码加速支持。
您没法一一找出包含敏感内容的全部列。
TDE 列加密不支持敏感列的数据类型和/或数据长度。
敏感列用做外键。
应用对已建索引的加密列执行范围扫描。
对于加密列,您须要不一样于 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 集成式软硬件体系一部分的应用及其余第三方应用。下表总结了这些应用认证结果。有关详细信息,请参见连接页面和文件。
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 提供的超强加密性能归功于如下独到之处:
Exadata 系统中优化的 Oracle 硬件和软件
各个存储和计算节点间的分布式加密处理
智能扫描和混合列压缩 (EHCC) 等 Exadata 原生特性
提供硬件密码加速
例如,光是 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 如何处理加密数据?
应用数据 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 起支持该特性)
--------------------------------------------------------------------------------
能否使用带有直接路径的 SQL*Loader 将数据加载到包含加密列的表中?
能够。若是目标表包含加密列,数据将在加载时进行加密。如下简单示例说明了如何使用带有直接路径的 SQL*Loader。只需将 ulcase6.sql 中的一行从
sal number(7,2),
更改成
sal number(7,2) encrypt,
并使用 SQL*Loader 的正确语法:
$ sqlldr USERID=scott/tiger CONTROL=ulcase6.ctl LOG=ulcase6.log DIRECT=TRUE
--------------------------------------------------------------------------------
使用 TDE 列加密对敏感信息进行加密后,为何有时仍能看到明文数据?
这种状况与即便已删除表或文件、但仍然会在磁盘上看到数据的状况相同。在一个表的生命周期内,数据可能会在表空间内分段、从新整理、排序、复制和移动,这会在数据库文件中留下数据的“幽灵副本”。加密现有列时,仅对新的“有效”副本加密,而在“幽灵副本”中留下较旧的明文版本。若是绕过数据库的访问控制而直接访问包含表空间的数据文件(例如,使用十六进制编辑器),那么在这些块被数据库覆盖以前,有时就会看到旧的明文值。为了尽量下降此等风险,请遵循下面的建议:
在新的数据文件中建立一个新的表空间 (CREATE TABLESPACE ... )
对原始表空间和数据文件中的明文值进行加密 (ALTER TABLE ...ENCRYPT )
对包含加密列的全部表执行第 2 步
将原始表空间中的全部表移到新的数据文件中 (ALTER TABLE ....MOVE... )
删除原始表空间 (DROP TABLESPACE ),不要使用 “and datafiles” 参数,Oracle 推荐对操做系统级操做使用更有力的方法,参见第 6 步
针对您的平台使用 “shred” 或其余 OS 命令,以便在 OS 级别上删除旧数据文件
建议您使用第 6 步操做来下降数据库文件出现幽灵副本的几率,不论这些副本是由操做系统生成仍是由存储固件生成。
--------------------------------------------------------------------------------
如何更改(轮换、更新)加密密钥?
数据库版本 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 文件的密钥库)。sql
使用 PKCS11 时,由第三方供应商提供存储设备、PKCS11 软件客户端库、设备与 PKCS11 客户端(在数据库服务器上运行)之间的安全通讯、身份验证、审计及其余相关功能。而且由供应商负责测试和确保 TDE 主加密密钥在各类数据库服务器环境和配置下的高可用性。客户应与设备供应商联系,得到帮助以解决任何相关问题。
--------------------------------------------------------------------------------数据库
上机操做
透明数据加密
配置自带的网络加密功能
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
安全特性
数据加密
虚拟专用数据库
数据库审计
备份加密
导出文件加密
代理身份验证
企业用户安全
安全应用角色
细粒度审计
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
论坛
安全性
Audit Vault
数据库
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
技术信息
透明数据加密优秀实践
产品介绍
概述白皮书
常见问题解答
技术白皮书
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
安全选件
Oracle Database Vault
Oracle Advanced Security
Oracle Label Security
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
相关技术
Database Firewall
Audit Vault
Data Masking (pdf)
Secure Backup
配置管理
Information Rights Management
Identity Management
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------安全