7.2 数据加密

7.2 数据加密

本节摘要：加密解决"数据被带走后读不懂"的问题：TDE 透明加密守住静态数据（磁盘、备份、导出文件），网络加密守住传输链路，脱敏守住"有权看但不必看真值"的场景。本节讲清三者的边界、TDE 的上线流程与密钥库的保管纪律。

从一份数据合规清单说起

等保与个保法的整改清单里，加密相关的要求通常有三行：静态数据加密、传输加密、展示脱敏。很多团队的第一反应是"应用层加解密"，做完发现三个坑：应用改造量大、已有系统改不动、索引与查询全部失效（加密后的值没法等值匹配）。Oracle 的答案是把这些下沉进内核与驱动：TDE 在存储层透明加密，应用无感知、索引照常工作；网络加密在驱动层协商；脱敏在返回结果时动态处理。三者各管一段，混为一谈是选型阶段最常见的混乱。

一、TDE：透明数据加密的两档形态

TDE（Transparent Data Encryption）的"透明"指应用无感知：数据写盘前在存储层自动加密、读出时自动解密，SQL 原样跑、索引原样建。它有两档：

列加密（Column Encryption）：只加密敏感列（身份证、卡号、手机号）。粒度最细、开销最小，但只保护这一列——同表的其他列、以及整库文件里散落的元数据，不在保护范围。适合"敏感字段明确且少"的库。

表空间加密（Tablespace Encryption）：整个表空间的所有数据块加密，新版本甚至支持全库 SYSTEM 表空间加密。粒度粗、覆盖全、性能开销摊薄，是当前新建库的默认推荐。老的顾虑（索引失效、性能骤降）在表空间加密上不成立——块内加密对优化器完全透明。

上线流程与代价要点：

-- 第一步：创建并打开密钥库（软件密钥库；生产建议外部密钥管理设备）
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/etc/oracle/keystore'
  IDENTIFIED BY "密钥库口令";
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "密钥库口令" WITH BACKUP;
-- 第二步：新表空间直接带加密属性创建
CREATE TABLESPACE enc_ts DATAFILE SIZE 10G
  ENCRYPTION USING 'AES256' ENCRYPT;
-- 第三步：存量表空间在线转换（12.2 之后支持，不中断业务）
ALTER TABLESPACE users ENCRYPTION ONLINE USING 'AES256' ENCRYPT;
-- 密钥库开启与自动登录配置（重启后无需人工输口令的权衡见下文）
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "密钥库口令";
ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE
  FROM KEYSTORE '/etc/oracle/keystore' IDENTIFIED BY "密钥库口令";
​

两笔账要在上线前算清。性能账：表空间加密的吞吐损耗通常在个位数百分比，AES 硬件加速（较新 CPU 都有）普及后更小——为加密损耗拒绝 TDE 在今天多半站不住脚。密钥账：密钥库文件和口令就是新命门——丢了密钥，整库变成乱码；备份策略要把密钥库备份纳入（口令与文件分开保管），高可用环境里主备库要共享密钥库（Data Guard 环境备库才能正常应用加密数据）。

二、传输加密与脱敏：另外两段防线

传输加密防止链路窃听：客户端与服务器之间的流量可用原生网络加密（配置加密类型与校验级别）或 TLS 证书认证。内网要不要开？看威胁模型——运维段与办公段共用的网络、跨数据中心同步链路（日志里明文飘过专线）、以及任何"合规清单写了传输加密"的环境，都该开。开销同样在个位数。

**脱敏（Data Redaction）**回答另一个问题：应用查询有权拿数据，但页面展示没必要见全量——客服看卡号尾四位即可。脱敏在查询返回时动态改写（全遮、部分遮、随机替代、按表达式），底层表不变，应用不改 SQL。它与 TDE 的分工要分清：TDE 防"存储被扒"，脱敏防"有权读的人多看了"——审计师的第二问（导出笔记本）靠 TDE 回答，客服页面是否露卡号靠脱敏回答。测试环境用真实数据刷数的老毛病，则用数据脱敏工具（Data Masking）做一份不可逆变形的副本，不属于运行时脱敏的辖区。

三、案例：一次 TDE 全库整改的实账

背景。 某保险中介按合规要求给 4.2TB 的核心库上 TDE，窗口只有周末 20 小时，主备双机（Data Guard）环境。

操作。 周三预演：测试库按同样步骤全流程走一遍，实测在线转换 2.1TB 用时 7 小时、吞吐损耗 3.8%。正式窗口的顺序经过设计：先备份密钥库并同步到备库，再逐表空间在线转换（从业务低峰的大表空间开始），每个表空间完成后核对主备应用状态；最后切一次 Data Guard，验证备库升主后加密数据读写正常——这一步验证的是密钥共享，不验证等于没上密。

结果。 17 小时完成全部表空间转换与双机验证，周一日均负载复核损耗 3.2%，合规项关闭。解读。 这个案子的关键不是转换命令，是三处容易翻车的细节：密钥库备份先于一切（密钥丢失=整库报废）；备库密钥同步在转换前完成（否则主备数据块加密密钥不一致，备库应用直接报错）；切换验证不可省（真正的故障日不会提前通知你密钥没同步好）。变式。 若是老版本（12.1 及以前）没有在线转换，只能"新建加密表空间、数据搬迁、切换"——窗口按搬迁全量数据估，4TB 库通常要按天计，合规整改排期时别按在线转换估。

💡 关键直觉：加密的强度上限是密钥保管的强度。密钥库和数据库放在同一台存储、口令和脚本一起进代码仓——这两件事让前面所有加密动作归零。密钥管理的第一课：密钥与数据，物理上永远分开住。

问题一：密钥库口令忘了怎么办？ 有备份密钥库的，从备份恢复口令或用备份库重开；两者都没有的，数据只能等价于丢弃——这不是危言耸听，加密体系的崩溃模式就是"密钥丢失等于整库报废"。所以密钥口令的托管（保险柜加双人分段保管）要作为上线验收的最后一项。

问题二：TDE 上了之后备份也要加密吗？ 要，而且这常是整改的真正动机：明文备份拷贝是加密库最容易忽视的数据出口。RMAN 的加密备份与 TDE 用同一套密钥体系，开启成本很低——库上加密做的第一层保护，很可能在备份磁带上被绕过。

本节要点回顾

• 三段防线各管一段：TDE 管存储被扒、网络加密管链路窃听、脱敏管有权者多看——别混为一谈。
• 表空间加密是默认推荐：覆盖全、开销摊薄、对优化器透明；列加密留给"敏感列明确且少"的增量加固。
• 密钥是新的命门：备份分开保管、主备共享、丢失即报废——密钥管理先于加密动作。
• 验证要含切换：加密整改的最后一步永远是主备切换验证，不是转换完成。

守住了看不看得到，最后一问是"谁动过"。下一节配置审计，让每一笔敏感操作都有不可抵赖的记录。