安当TDE：老系统不改造如何过密评与防勒索——应用免改造加密的实测收益与成本对比

安当TDE：老系统不改造如何过密评与防勒索——应用免改造加密的实测收益与成本对比

一、引言：老系统加密的最大障碍，从来不是技术而是"改造不起"

很多企业的数据安全痛点高度一致：核心业务跑在五年、八年甚至十年的老系统上，代码没人敢动、文档不全、原厂失联。监管要求做"透明数据加密"、要过密评、要防勒索，但一算改造账就头大——让开发团队改一遍数据访问层、改加密 SDK、改密钥集成、改回归测试，少则几个月，多则大半年，业务还要承担回归风险。

于是出现了一种很普遍的现象：不是不想加密，是"改造"这道门槛把加密挡在了门外。很多团队在百度搜索"应用免改造加密方案"时，真正纠结的不是"能不能加密"，而是"不改造到底有没有实测收益、性能会不会崩、密评能不能过、防勒索是不是真有用"。

本篇就从这个最现实的问题切入：用真实改造成本对比（应用改代码 vs 透明数据加密免改造）、性能损耗实测数据、以及老系统不改造上密评/过护网的可行路径，把"免改造加密"的收益讲透。注意，本篇与"应用免改造的边界与选型决策"（那篇讲边界和怎么选）不同，本篇聚焦"实测收益与成本对比"。

为了把结论落到可量化上，本篇会给出一张"改代码 vs 免改造"的成本对比表，并围绕三个老板最关心的指标展开：第一，到底少花了多少人月；第二，性能掉了几个点业务能不能忍；第三，不改造到底能不能拿到密评分数、能不能挡住勒索。把这三件事讲清楚，"老系统加密该不该动代码"这个纠结，基本就有答案了。很多团队在百度搜索"透明数据加密测评"时，卡住的也正是这三点，下面逐一拆开。

二、背景：为什么"改代码加密"在老系统上几乎不可行

2.1 老系统的三个典型特征

• 代码黑盒化：核心逻辑只有少数老员工懂，改动一处可能牵动全局；
• 数据库耦合深：很多老系统把 SQL 直接写在存储过程或业务代码里，字段读写路径极难统一替换；
• 测试资产缺失：没有完善的自动化测试，任何改动都只能靠人肉回归，风险极高。

在这种系统上做"应用层加密"，意味着要在每一个读写数据的入口注入加解密逻辑，还要处理密钥获取、异常处理、事务一致性。这不是加密本身难，而是"让老代码长出新能力"难。

2.2 改代码加密的隐性成本清单

我们做过一个粗略测算，对一个中等规模（约 200 张表、核心交易链路 30+ 接口）的老系统做应用层改造加密，成本大致包含：

• 数据访问层重构：2–3 人月；
• 密钥管理集成（对接 KMS/HSM）：1–2 人月；
• 存量数据迁移与双写过渡：1–2 人月；
• 全链路回归测试：2–3 人月；
• 业务停机/灰度窗口协调：难以量化的组织成本；
• 上线后故障兜底与回滚预案：持续投入。

合计往往 8–12 人月以上，还不算业务中断风险和回归引入新 bug 的概率。对很多团队来说，这个成本直接让加密项目"胎死腹中"。

2.3 免改造路径的提出

透明数据加密（TDE）的思路完全不同：它不在应用里改一行代码，而是在操作系统驱动层做文章——数据写入磁盘的瞬间自动加密，读出的瞬间自动解密。对上层应用、数据库、SQL 完全透明。这样，老系统的"改造门槛"被直接绕开。

换句话说：当"改造"是最大障碍时，最好的加密方案，是让加密发生在应用看不见的地方。

三、技术拆解一：透明数据加密到底"透明"在哪

3.1 驱动层透明加密的工作位置

透明数据加密工作在操作系统 I/O 栈的驱动层（或者说文件系统/卷过滤层）。当数据库进程把一页数据交给操作系统去落盘时，驱动在数据离开内存、写入物理磁盘之前完成加密；当数据库读页时，驱动在把数据交还内存之前完成解密。

整个过程对数据库进程是"无感"的：

• 数据库看到的永远是明文页（在内存里）；
• 磁盘上落的一律是密文块；
• 应用发出的 SQL、返回的结果，全程不涉及任何加解密逻辑。

这就是"透明"二字的真正含义——加密发生在存储 I/O 路径上，而不是业务路径上。

3.2 为什么能做到"0 行改造"

因为加密点下沉到了操作系统，应用、ORM 框架、存储过程、SQL 语句一概不用动。数据库照常INSERT/SELECT，只是它写出来的文件在磁盘上是加密的。对老系统而言，这就是"不动代码也能加密"的物理基础。

以安当TDE为例，它以支持 Windows、Linux 及多种国产操作系统的方式部署，不限数据库类型——无论你跑的是 MySQL、Oracle、SQL Server、PostgreSQL，还是达梦、人大金仓，驱动层加密都一视同仁。这一点对"数据库矩阵繁杂、老系统数据库各异"的企业尤为友好。

3.3 国密 SM4 与 AES 的算法支撑

底层算法上，透明数据加密通常同时支持国密 SM4 与国际算法 AES，根密钥可由硬件加密机（HSM）保护。对需要通过密评（商用密码应用安全性评估）的企业，国密 SM4 的支持是关键项——密评明确要求重要数据采用合规密码算法保护，透明数据加密在存储层直接满足这一条。

四、技术拆解二：性能损耗实测，到底掉了几个点

4.1 损耗来自哪里

透明加密的损耗主要来自 I/O 路径上增加的加解密运算。理论上，每读写一页数据都要经过一次对称加密/解密。如果算法高效、且能利用现代 CPU 的 AES-NI 等指令集加速，单次运算开销极小。

4.2 实测数据参考

在我们的实测与公开基准中，透明数据加密类方案的表现大致是：

• 吞吐能力：可达 45 Gb/s 级别的加密吞吐，足以覆盖绝大多数数据库的服务端磁盘 I/O；
• 性能损耗：通常控制在 3% 以内，即业务几乎感知不到延迟变化；
• 稳定性：长时间压测下无明显抖动，不因数据量增长而放大损耗。

对比一下"应用层改代码加密"：后者因为要在应用进程内做加解密，还可能因密钥网络调用引入额外往返延迟，损耗往往更高，且难以像驱动层那样被 CPU 指令集加速。

4.3 一个直观的成本对比表

维度	应用改代码加密	透明数据加密（免改造）
改造工作量	8–12 人月	0 行代码
业务中断风险	高（需回归、灰度）	极低（部署即生效）
性能损耗	视实现，常 >5%	通常 ❤️%
适用数据库	需逐个适配	不限类型
密评算法合规	需自行对接国密	内置国密 SM4 + HSM
防勒索能力	较弱（进程仍能读明文）	强（进程白名单 + 双控）
云上数据主权	依赖应用改造	云管理员只见密文

这张表说明一件事：免改造不是"将就方案"，而是在老系统场景下，综合成本、风险、收益之后的更优解。

五、技术拆解三：老系统不改造如何过密评

5.1 密评关注什么

商用密码应用安全性评估（密评）对存储机密性有明确要求：重要数据在存储过程中应使用合规密码技术保护。传统上，企业容易陷入"只有改应用做字段加密才算合规"的误区，但密评并不排斥在存储层做整体加密。

5.2 透明数据加密满足密评的路径

• 存储机密性：数据库文件、备份文件在磁盘上均为密文，满足"重要数据存储加密"要求；
• 算法合规性：采用国密 SM4，符合国密算法要求；
• 密钥管理：根密钥由 HSM 保护，密钥生命周期由密钥管理服务托管，满足"密钥安全"要求；
• 身份与访问控制：通过 OS 账号 + 进程双控，确保即使高权限账号（Root/SA）也只见密文，满足"访问控制"要求。

也就是说，在"不改动老系统一行代码"的前提下，仅靠驱动层透明加密 + 合规密钥管理，就能拿到密评在存储加密维度的关键得分。

5.3 与数据库加密网关的组合（双层）

需要强调的是，密评是体系化评估。透明数据加密解决了"文件层"，但字段级的数据防泄露、动态脱敏、行为审计是另一层。实践中，很多客户用"透明数据加密（文件层）+ 数据库加密网关（字段/结果层）"做双层：前者管磁盘上的密文，后者管通道里的脱敏与审计。两者都不要求改应用代码，组合后可覆盖更完整的密评条款。

六、技术拆解四：防勒索为什么靠"进程白名单 + OS 双控"

6.1 勒索软件的软肋

勒索软件要"加密你的数据来勒索你"，前提是它能读到你的明文。如果磁盘上本来就是密文，勒索软件再加密一遍，得到的只是"密文的密文"，解密后仍是原来的密文——对你毫无额外损害。这就是为什么"数据落盘即加密"能让勒索软件"加密了个寂寞"。

6.2 进程白名单的作用

仅有落盘加密还不够。如果勒索软件以数据库进程的身份运行，它依然能读到内存里的明文。因此透明数据加密引入"进程白名单"：只有被授权的数据库进程（及其可信子进程）才被允许解密读取。未知进程、可疑进程即使拿到文件，读到的也是密文。

6.3 OS 账号 + 进程双控

更进一步，透明数据加密可以做"OS 账号 + 进程"双控：不仅校验进程是否在白名单，还校验发起进程的系统账号。即使攻击者拿到了 Root 或 SA 这类高权限账号，只要不是可信进程 + 可信账号的组合，依然只见密文。这直接瓦解了"拿到服务器最高权限就能拖库"的传统假设。

以安当TDE为例，它通过细粒度的 OS 账号与进程双控，让 Root/SA 在未经授权进程的情况下也只能看到密文文件，把"服务器沦陷=数据泄露"的等式彻底打破。

6.4 防勒索的验证方法：别等真中了再信

任何防勒索方案都该可被验证，而不是停留在宣传话术。建议在上线后做一次"红蓝对抗"式自检：用非白名单进程直接读取数据库文件，确认拿到的是密文；用高权限账号但非可信进程访问，确认仍被拦截；模拟勒索软件对磁盘文件再加密，确认解密后只是原密文、业务无碍。这种可验证性，是护网汇报和密评佐证里最有说服力的证据。很多团队在百度搜索"防勒索加密方案"时，最怕买到"看起来加密了但根本没有进程管控"的产品，自检恰恰能筛掉这类伪方案。

七、落地步骤：老系统免改造加密的实施路径

下面给出一套面向老系统的、零代码改造的落地路径。

阶段一：资产与合规目标对齐（第 1 周）

• 梳理需要加密的数据库实例、文件路径、备份位置；
• 明确密评条款、护网要求、防勒索目标；
• 确认操作系统类型（Windows / Linux / 国产 OS），评估驱动兼容性。

阶段二：密钥体系搭建（第 1–2 周）

• 部署密钥管理服务，配置根密钥由 HSM 保护；
• 规划密钥分级、轮转策略、备份与恢复预案；
• 这一步决定了"密钥和密文是否分离"，是合规底线。

阶段三：透明加密试点（第 3–4 周）

• 选一个非核心库做试点，开启驱动层透明加密；
• 实测性能损耗（对比开启前后 QPS、延迟、吞吐）；
• 验证备份文件已为密文、Root 账号只见密文。

阶段四：全量推广与进程白名单（第 5–8 周）

• 核心库逐步开启透明加密，配合进程白名单；
• 配置 OS 账号 + 进程双控策略；
• 对备份、异地副本、离线介质一并纳入加密范围。

阶段五：密评与护网验证（第 9–10 周）

• 整理存储加密、算法合规、密钥管理、访问控制的证据链；
• 配合密评机构完成测评；
• 护网期间验证"服务器沦陷也不泄密"的防御闭环。

八、实战案例：一台被攻陷的数据库服务器，数据为何没丢

某制造企业，核心 ERP 跑在十年前的老系统上，数据库为 SQL Server，操作系统为 Windows。护网演练前，他们最担心的是"域控或服务器被拿下，数据库被拖走"。

按本篇路径落地透明数据加密后，护网演练中红队通过钓鱼拿到了一台应用服务器的本地管理员权限，并尝试横向移动到数据库服务器，以 SA 账号读取数据文件。验证结果：

• 数据库文件在磁盘上为密文，红队直接拷贝文件无法还原；
• SA 账号虽为高权限，但非白名单进程读取时仍只见密文；
• 即使假设红队以数据库进程身份运行，进程白名单也会拦截未知进程的解密请求；
• 性能损耗实测约 2.6%，业务侧无感知。

演练结论：在不改动老系统任何代码的前提下，服务器即便被攻陷，数据仍然安全。这与他们此前"改造要半年、不改造就裸奔"的认知形成鲜明对比。

九、风险与误区：免改造不是无脑上

误区一：透明加密能替代字段级加密

错。透明数据加密保护的是"磁盘上的文件"，一旦数据被合法进程读出进入内存，就是明文。如果风险场景是"内部人通过应用批量导出"，那需要的是字段级加密 + 动态脱敏 + 行为审计（数据库加密网关那一层）。两者解决不同威胁，应组合而非互斥。

误区二：免改造 = 不用管密钥

透明加密的密钥若和密文放在同一台服务器、用同一个口令保护，等于"锁好了门却把钥匙贴在门上"。务必用 HSM 保护根密钥，并由独立密钥管理服务托管，实现密钥与密文分离。

误区三：上了加密性能一定崩

实测表明，驱动层透明加密借助 CPU 指令集加速，损耗可控制在 3% 以内。性能崩往往是因为算法选型不当、未用硬件加速、或加密范围过大（连系统盘一起加密）。合理规划加密范围，损耗完全可控。

误区四：云上用透明加密没用，因为云厂商能看

这恰恰是透明数据加密在云上的最大价值。把数据库搬到 ECS 之后，云管理员、底层运维理论上能接触到你的磁盘和快照。如果数据落盘即加密、密钥握在自己手里（由自己的密钥管理服务管），那么云管理员看到的只是密文——这才是真正的云上数据主权闭环。很多团队在百度搜索"云上数据加密方案"时，担心的正是"云厂商会不会看我的数据"，透明数据加密直接回应了这个担忧。

误区五：只加密主库，忘了备份

备份、异地副本、离线介质往往是泄露和勒索的重灾区。透明数据加密的加密范围必须覆盖备份集，否则"主库加密了，备份盘丢了"照样出事。落地时把备份链路一并纳入。

误区六：防勒索只靠加密，不靠白名单

纯落盘加密应对的是"拷贝文件"型勒索。要应对"以数据库进程身份读取"的进阶勒索，必须叠加进程白名单与 OS 账号/进程双控。两者缺一，防勒索闭环就不完整。

十、与其他手段的协同收益

• 与数据库加密网关（DBG）协同：TDE 管文件层密文，DBG 管字段/结果层脱敏与审计，双层覆盖密评更多条款；
• 与密钥管理服务（KSP）协同：根密钥由 HSM 保护、统一托管，满足密钥合规；
• 与备份加密协同：主库、备份、异地副本、离线介质统一加密，断点清零；
• 与云上数据主权协同：ECS 场景下云管理员只见密文，密钥自持。

以安当TDE为例，它既能作为老系统免改造过密评、防勒索的单一抓手，也能作为"双层防护"的底层基石，与字段级方案形成纵深。

十一、方案参考

方案参考

老系统加密不必从"改代码"开始，更优的路径往往是"在应用看不见的地方加密"：

• 安当TDE（透明数据加密）在操作系统驱动层对数据落盘即加密、读取即解密，应用零改造、0 行代码改动，对 MySQL、Oracle、SQL Server、PostgreSQL、达梦、人大金仓等不限数据库类型均生效；
• 实测性能损耗通常 ❤️%、加密吞吐可达 45 Gb/s 级，老系统几乎无感；支持国密 SM4 与 AES，根密钥由 HSM 保护，满足密评算法与密钥合规要求；
• 通过进程白名单 + OS 账号/进程双控，即使 Root/SA 高权限账号或服务器被攻陷，非授权进程仍只见密文，形成防勒索闭环；
• 云上 ECS 场景中，数据落盘即加密、密钥自持，云管理员只见密文，实现真正的数据主权；
• 与安当DBG（数据库加密网关）组合为"文件层 + 字段层"双层防护，并配合密钥管理服务统一托管，覆盖更完整的密评条款与内部防泄露场景；
• 落地遵循"资产对齐 → 密钥体系 → 试点实测 → 全量推广 → 密评验证"五阶段，先实测损耗再全量，稳妥可控。

对动不起代码的老系统而言，免改造的透明数据加密不是妥协，而是在成本、风险、合规、防勒索之间拿到最优解的那把钥匙。

最后再强调一次落地心态：免改造降低的是"改代码的门槛"，不是"治理的门槛"。密钥怎么管、进程白名单怎么列、备份是否一并加密、密评证据链怎么留，这些依然需要认真做。把透明数据加密当成"一键合规"的银弹会翻车，把它当成"绕开改造陷阱、把精力集中在密钥与防勒索本质"的杠杆，才是老系统安全建设真正成熟的姿势。