3. 数据库支持概览：四大数据库TDE的差异

TDE 这东西呢，说白了就是让数据库自己在写入磁盘前把数据加密，读出来时自动解密。你想想看，应用层完全无感，DBA 不用改一行代码。但不同数据库的 TDE 实现细节差异非常大——有些是表空间级，有些是库级，密钥管理方式也完全不同。我在项目里见过不少团队，因为没搞清楚这些差异，集成时踩了大坑。

3.1 Oracle TDE：表空间级加密的标杆

Oracle 的 TDE 是最成熟的，我最早接触 TDE 就是在一套 Oracle 11g 核心交易库上。它的核心思路：加密发生在表空间层面。你创建一个加密表空间，里面所有对象自动加密。

• 加密算法：AES128/192/256，3DES，默认 AES128。
• 密钥体系：主密钥（存储在外部安全模块或 Oracle Wallet）→ 表空间加密密钥（TDE 自动生成、管理）。
• 性能影响：读写约 5%~10% 开销，在 OLTP 场景下可接受。
• 透明性：完全透明，应用无需改造，备份文件直接加密。

-- 创建加密表空间（Oracle 11g+）
CREATE TABLESPACE enc_ts
DATAFILE '/u01/oradata/enc_ts01.dbf' SIZE 500M
ENCRYPTION USING 'AES256'
DEFAULT STORAGE(ENCRYPT);

3.2 SQL Server TDE：数据库级加密的典型代表

SQL Server 的 TDE 是 数据库级的加密。你开启后，整个数据库的 MDF/NDF/LDF 文件都被加密。关键在于：它不仅加密数据文件，还加密日志文件。这在 Oracle 里是需要额外配置的。

• 算法：AES128/192/256，默认 AES128。
• 密钥链：服务主密钥（SMK）→ 数据库主密钥（DMK）→ 证书/非对称密钥→ 数据库加密密钥（DEK）。
• 性能影响：缓冲区中的页被访问时加解密，对只读查询影响较小；写操作有 3%~8% 开销。
• 局限性：不能单独加密某个表或列；备份集自动加密，但必须保留证书才能还原。

-- SQL Server TDE 启用步骤（摘要）
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TDECert;

ALTER DATABASE MyDB SET ENCRYPTION ON;

3.3 MySQL TDE（InnoDB）：表空间加密，需插件

MySQL 自 5.7 起通过 InnoDB 表空间加密支持 TDE，但依赖于 keyring 插件（如 keyring_file、keyring_encrypted_file、keyring_aws 等）。说白了，它不像 Oracle 那样原生集成，需要额外配置密钥管理。

• 加密粒度：表空间级别（独立表空间 .ibd 文件）。你可以选择只加密某些敏感表，灵活性更高。
• 密钥管理：keyring 插件存储主密钥，表空间加密密钥由 InnoDB 自动管理。
• 性能影响：15~25% 的开销（我测试过），主要是加解密发生在 InnoDB 页面层。
• 注意：双写缓冲区、重做日志不会被加密！这可能会泄露部分数据路径。

-- 启用 keyring 插件（my.cnf）
early-plugin-load=keyring_file.so
keyring_file_data=/var/lib/mysql-keyring/keyring

-- 创建加密表
CREATE TABLE t1 (c1 INT) ENCRYPTION='Y';

3.4 PostgreSQL TDE（pg_tde 等）：社区方案，仍在演进

PostgreSQL 官方内核一直没有原生 TDE。目前主要靠第三方扩展：pg_tde（由 CyberTec 开发）、pg_crypto（函数级，非透明）、以及云厂商的自研补丁（如 AWS RDS 的 TDE）。pg_tde 是比较完善的开源实现。

• pg_tde 加密粒度：表空间级别，但可选加密单个索引。
• 密钥管理：使用外部密钥管理服务器（Vault 或文件），主密钥不由数据库维护。
• 性能影响：看测试环境，读操作影响较小（约 5%），写操作 10%~20%。
• 局限性：不支持流复制中的 WAL 加密（需额外配置），社区版本更新较慢。

-- pg_tde 启用示例（假设已安装扩展）
CREATE EXTENSION pg_tde;
SELECT pg_tde_set_master_key('my_master_key', 'file');
CREATE TABLESPACE encrypted_ts LOCATION '/data/encrypted'
WITH (tde_encryption = 'AES-256');

3.5 四大数据库 TDE 核心差异对比

我整理了一张表，把关键差异列了出来——你做个参考，选型时直接对照。

特性维度	Oracle TDE	SQL Server TDE	MySQL TDE (InnoDB)	PostgreSQL TDE (pg_tde)
加密粒度	表空间级	数据库级（整个库）	表空间级（独立表空间）	表空间/索引级
是否原生自带	是（企业版）	是（企业版/标准版）	是（社区版也支持）	否（需要扩展）
日志是否加密	重做日志未加密11g，12c后可配置	事务日志和备份均加密	重做日志不加密	WAL 未加密（需额外）
主密钥存储	Wallet / HSM	证书 + DMK	keyring 插件（文件/云）	外部 KMS / Vault
对应用的透明性	完全透明	完全透明	完全透明（需建表时指定）	完全透明
典型性能开销	5%~10%	3%~8%	15%~25%	5%~20%

3.6 选型思考：我怎么选？

你想想看，如果团队已有 Oracle 企业版，那直接用 TDE 最省事，密钥管理也成熟。SQL Server 强在日志全加密，合规审计很友好。MySQL 的 TDE 虽然开销大一点，但社区版也能用，适合预算敏感的项目。PostgreSQL 的话，我一般只在不能换数据库、又必须通过 TDE 合规的场景下推荐它，因为管理复杂度和兼容性风险确实高一些。

另外，所有 TDE 产品都遵循“密钥链”原则：应用层不直接接触数据加密密钥。这点在做接口集成时尤其重要——你不需要在中间件层处理加解密，只需要确保密钥存储的可用性和备份策略。