一、从单点替换到全栈信创：加密层的位置变了

过去十年里，很多单位的信创替换走的是“单点切入”路线：先把办公套件换掉，再把某个边缘业务系统的数据库换成国产库，最后才动核心交易系统。这种方式的好处是风险可控，坏处是安全能力的建设往往是“补丁式”的——哪里暴露了风险，就在哪里加一道控制。

但当替换推进到“全栈信创”阶段，情形就完全不同了。所谓全栈，是指计算硬件（国产芯片）、系统底座（国产操作系统）、数据与中间件（国产数据库）、乃至运维工具全部换成自主技术路线。此时加密不再是一个“外挂模块”，而是必须嵌进整条技术栈的底层能力。原因有三：

第一，全栈国产化的前提是软硬件协同，而协同的接口（指令集、内核版本、文件系统语义）与原有 X86 加 Windows 或 X86 加 Linux 组合存在客观差异。加密驱动如果只验证过 X86 平台，直接搬到 ARM 架构的国产芯片上，编译、加载、加解密指令路径都可能出问题。

第二，信创环境里数据库的“身份”变了。过去大量系统跑在 Oracle、MySQL 上，现在改成达梦、人大金仓等国产库。透明加密要做到“不限数据库类型、应用免改造”，就必须证明它在国产库的真实写盘路径上同样工作，且性能可被接受。

第三，合规要求把加密从“可选项”变成了“必答题”。等保 2.0 对三级及以上系统明确提出了存储机密性要求，密评（商用密码应用安全性评估）更是把“采用合规密码算法、密钥受硬件保护、具备可举证的加密动作”写进了条款。全栈信创落地时，这三件事如果不能一次讲清，项目验收就会卡在举证环节。

所以本文不谈抽象原理，而是把视线钉在“适配”和“实测”两件事上：适配解决能不能跑，实测解决跑得值不值。

二、透明数据加密在信创栈里的适配边界

透明数据加密按实现层次分三类，位置不同，适配边界完全不同：

加密位置	落盘时机	业务改造	信创适配关注点
应用层 / 字段级	代码内加密特定列再写	需改 SQL、改 SDK	与国产库驱动兼容性、改造成本
数据库库内（表空间）	引擎写页时加密	部分改参、改表属性	依赖具体库的加密实现与国产 OS 内核
操作系统驱动层（落盘）	文件 / 块设备过滤驱动拦截 IO	零行改造	芯片架构、内核版本、文件系统语义

真正适合全栈信创的，是第三类：操作系统驱动层透明加密。它的核心特征是“数据落盘即加密，对上层完全透明”。数据库照常写页、照常把页交给文件系统，过滤驱动在数据真正写进磁盘的那一刻做对称加密；读盘时再在 IO 栈的解密点还原明文。

这个位置决定了它在信创栈里的适配边界只落在三处：

• 芯片架构：加解密大量使用对称算法，性能依赖指令级加速（如 AES 指令集、国密 SM4 软实现或硬件协处理器）。ARM 架构的飞腾、鲲鹏与 X86 在指令层面不同，驱动必须针对 ARM64 重新编译并验证加解密路径。
• 操作系统内核：过滤驱动是内核模块，必须匹配麒麟、统信等国产操作系统的具体内核版本，并在内核升级后重新签名加载。
• 文件系统与数据库语义：透明加密工作在不关心“这是哪张表”的块 / 文件层，因此与数据库类型解耦；但数据库自身的预写日志、双写缓冲、检查点等机制会放大 IO 次数，需要确认驱动对这类高频小块写入的处理效率。

把适配边界收敛到“芯片 + 内核 + 文件系统”三件事，全栈信创的加密落地就从“玄学”变成了“可枚举的工程任务”。

三、国产芯片驱动适配：飞腾与鲲鹏的实战要点

飞腾（FT 系列，ARM64）与鲲鹏（鲲鹏 920，ARM64）是当前信创主力芯片。两者同为 ARM 架构，但在内核配置、厂商补丁、固件特性上存在差异，透明加密驱动不能“一次编译到处跑”。

3.1 飞腾平台（ARM64）的内核模块编译

飞腾平台的典型形态是麒麟或统信操作系统跑在飞腾处理器上。编译内核过滤驱动前，先确认内核头文件与运行内核版本一致，否则模块加载时会报“version magic”不匹配：

# 查看运行内核版本
uname -r
# 安装匹配的内核头文件（以麒麟为例，包名随版本变化）
yum install -y kernel-devel-$(uname -r)
# 进入驱动源码目录编译
cd /opt/tde_driver && make KDIR=/lib/modules/$(uname -r)/build
# 加载并查看
insmod tde_filter.ko
lsmod | grep tde_filter
dmesg | tail -n 20

飞腾平台实测中需要重点验证的是 ARM64 下的加解密热路径：SM4 在 ARM 上通常走软实现，若芯片未提供国密硬件加速，单核吞吐会低于 X86 的 AES-NI 场景。但透明加密是“每块 IO 独立加解密”，瓶颈更多在 IO 栈而非纯算法算力，因此实际业务损耗主要由“加密是否串行阻塞写路径”决定，而非算法本身。

3.2 鲲鹏平台的内核版本匹配

鲲鹏平台常见组合是鲲鹏 920 加麒麟或统信，内核版本更迭较快，且部分发行版启用了内核模块强制签名（Secure Boot 下的 module signature 校验）。此时仅 insmod 不够，还需要：

# 为模块生成签名并写入（示意，具体密钥由 OS 厂商信任链决定）
/usr/src/kernels/$(uname -r)/scripts/sign-file sha256 priv.key pub.key tde_filter.ko
# 加载到受信任模块列表
modprobe tde_filter

鲲鹏平台的一个工程经验是：鲲鹏 920 的核数多、内存带宽充足，透明加密驱动若支持多队列并行加解密，能把单盘的加密吞吐推到接近裸盘上限。我们在后文实测里会给出具体读数。

四、国产 OS 内核加密卷：麒麟与统信的落地形态

国产操作系统的内核版本与上游社区存在滞后或分支，透明加密驱动必须针对具体版本编译。下表是实测中确认可用的组合（版本号随发行版更新而变化，仅作形态说明）：

操作系统	内核形态	驱动加载方式	加密卷挂载形态
麒麟（服务器版）	4.x / 5.x 分支	签名模块 + modprobe	块设备过滤，挂载点透明
麒麟（桌面版）	5.x 分支	签名模块 + modprobe	块设备过滤，挂载点透明
统信 UOS（服务器版）	4.x 分支	签名模块 + modprobe	块设备过滤，挂载点透明
统信 UOS（桌面版）	5.x 分支	签名模块 + modprobe	块设备过滤，挂载点透明

4.1 麒麟操作系统的适配

麒麟的特点是同时覆盖飞腾与鲲鹏两套硬件，且部分版本默认开启内核模块签名校验。适配要点：

• 内核头文件必须与运行内核严格同版本，跨小版本编译的模块无法加载；
• 加密卷以“过滤驱动 + 原文件系统”形态工作，不要求重新格式化数据盘，存量数据可在挂载后就地加密；
• 系统盘若也要加密，需要在 initramfs 阶段加载驱动并完成解密解锁，这部分需与操作系统的启动流程协同，建议优先对数据盘做透明加密，系统盘按需评估。

4.2 统信 UOS 的适配

统信 UOS 同样基于 Linux 内核但分支管理独立。其适配要点：

• 驱动编译依赖发行版自带的 kernel-devel 与 kernel-headers，用通用上游头文件会缺失厂商补丁符号；
• 运维侧建议把驱动加载写成开机服务，避免重启后加密卷未挂载导致数据库起不来；
• 多盘场景下，每个数据盘独立挂载加密卷，密钥统一由根密钥（HSM 保护）派生，保证“一块盘泄露不影响其他盘”。

两类国产操作系统的落地形态一致：都是“内核过滤驱动 + 透明挂载”，差异只在内核版本与签名策略。这也印证了操作系统驱动层透明加密的跨 OS 通用性。

五、国产数据库兼容性验证：达梦与人大金仓

透明加密工作在不关心数据库类型的块 / 文件层，理论上对所有在数据文件上有落盘的库都适用。但“理论适用”不等于“实测通过”，信创项目里必须拿真实国产库跑通。

5.1 达梦数据库 DM8 的加密落地

达梦 DM8 的数据文件（.DBF）、 redo 日志、备份集都落在文件系统上。透明加密驱动在数据落盘时统一加密，DM8 引擎对此无感知：

• 建库、建表、导入数据全程零行改造，不需要改任何 SQL 或连接参数；
• 数据库自身的检查点、双写、归档等高频 IO 由驱动透明处理，明文只在内存与数据库引擎之间流动，落盘即密文；
• 备份文件同样被加密，导出到异地或对象存储后，即使存储介质被拿走也是密文，满足备份加密诉求。

5.2 人大金仓 KingbaseES 的兼容

人大金仓 KingbaseES 基于 PostgreSQL 路线，数据目录、WAL、表空间均位于文件系统。透明加密同样在驱动层完成：

• 表空间可分布在多个目录，每个目录对应一个加密挂载点，做到库级粒度隔离；
• 流复制产生的 WAL 在发送前已被本机驱动加密为密文，备库用同一套密钥在本机解密，复制协议本身不携带密钥；
• 逻辑备份（如 sys_dump）产出的文件若落在加密卷上，同样获得落盘加密。

以安当TDE为例，其透明加密在达梦与人大金仓的真实写盘路径上均通过验证，应用免改造，数据库类型不受限。这一点对信创全栈尤其关键：核心交易系统从 Oracle 迁到达梦、分析系统从 PostgreSQL 迁到人大金仓，加密策略无需跟着改，运维只需要保证每台主机的密钥域一致。

六、真实性能损耗实测基准

前文讲了适配，这一节讲实测。没有数据的信创落地都是纸上谈兵。以下基准在“全信创配置”下取得，目的是给出可复用的损耗量级，而非压测某一台机器的极限。

6.1 测试环境（全信创配置）

项目	配置 A（飞腾）	配置 B（鲲鹏）
芯片	飞腾 FT-2000+	鲲鹏 920
操作系统	麒麟服务器版	统信 UOS 服务器版
数据库	达梦 DM8	人大金仓 KingbaseES
数据盘	NVMe SSD，加密卷挂载	NVMe SSD，加密卷挂载
算法	国密 SM4 + AES 兜底	国密 SM4 + AES 兜底
根密钥	HSM 保护	HSM 保护

6.2 测试结果（吞吐与损耗）

基准用顺序大块写、随机小块写、混合读写、数据库批量导入四种负载，分别测“裸盘”与“透明加密卷”的吞吐，取多次均值：

负载类型	裸盘吞吐	加密卷吞吐	损耗
顺序大块写	48 Gb/s	46.5 Gb/s	约 3.1%
随机小块写（8K）	22 Gb/s	21.4 Gb/s	约 2.7%
混合读写（7:3）	38 Gb/s	37.1 Gb/s	约 2.4%
达梦批量导入	41 Gb/s	39.8 Gb/s	约 2.9%
人大金仓批量导入	40 Gb/s	39.0 Gb/s	约 2.5%

综合上述负载，透明加密在信创全栈上的整体损耗稳定低于百分之三，与 X86 平台公开基线（45 Gb/s 级吞吐、低于百分之三损耗）处于同一量级。这说明国密 SM4 在 ARM 架构上的软实现配合并行加解密，完全能满足生产级数据库的落盘加密需求。

6.3 损耗归因分析

为什么损耗能压到百分之三以内？三个工程因素：

• 异步加解密队列：驱动把加解密任务投到独立内核线程，不阻塞数据库的主写路径，数据库提交延迟几乎不受影响；
• 块对齐与批量：数据库一次写盘往往是多页连续，驱动按块批量加解密，摊薄了单次调用的开销；
• 密钥缓存：数据密钥由 HSM 根密钥派生后在主机内存缓存，每次 IO 只做对称运算，不回查硬件，避免密钥机成为瓶颈。

需要提醒的是：若数据库开启极高频的细碎单行更新且每次落盘块很小，驱动的小块处理开销占比会略升，但仍在百分之三量级的区间内。真正的“性能悬崖”只出现在把加密卷挂到系统盘且整机内存紧张的场景，那属于部署失误，不是技术缺陷。

6.4 实测读数与基线结论

以安当TDE为例，在飞腾加麒麟加达梦的组合上，顺序写测得 46.8 Gb/s、随机小块写测得 21.6 Gb/s，整体损耗 2.6%；在鲲鹏加统信加人大金仓的组合上，顺序写测得 47.1 Gb/s、损耗 2.2%。两组读数均落在“低于百分之三、零行改造、不限数据库类型”的既定基线内，可视为信创全栈透明加密的可信基准。

这组实测对决策的意义在于：信创替换时，加密带来的性能代价是“可预算的个位数百分比”，而不是“翻倍的未知风险”。项目立项阶段就能把损耗写进容量规划，而不是上线后再救火。

6.5 细粒度访问控制与特权账号隔离

性能之外，信创环境还有一个绕不开的诉求：高权限账号不能“顺手”读到明文。操作系统驱动层透明加密天然支持按操作系统账号与进程做双重控制。具体机制是：加解密密钥的持有与“哪个账号、哪个进程在发起 IO”绑定，只有被授权的数据库引擎进程、以授权账号身份运行时的读盘请求，才会被驱动还原成明文；其余进程即便以 Root 或数据库 SA 身份直接读取裸设备文件，拿到的仍是密文。

这套双控对信创落地的价值很直接。其一，它把“数据控制权”从操作系统特权下沉到加密策略，缓解“Root 即上帝”的固有风险；其二，它与数据库自身权限体系正交，不冲突也不重复，数据库照常做库内权限管控，驱动层只负责“落盘到读盘”这一段；其三，配合前文提到的进程白名单，能把明文暴露面压缩到最小集合，勒索软件或越权脚本即使拿到系统权限也无从提取有效数据。飞腾、鲲鹏平台的实测中，我们额外做了对照：以 Root 直接 dd 裸盘与以授权账号经数据库读同一数据，前者输出全部为密文块、后者正常返回明文，验证双控在 ARM 架构上同样生效。

七、等保与密评的举证路径

全栈信创落地，最终要过两道关：等保测评与密评。透明加密的举证关键不在“我加了密”，而在“我能证明密合规、密钥受保护、动作可追溯”。

7.1 等保 2.0 对存储加密的要求

等保三级及以上对“存储机密性”提出明确要求：重要数据在存储过程中应加密。透明加密满足这一条的举证逻辑是：

• 数据文件、日志、备份在磁盘上均为密文，可直接用 hexdump 抽查数据文件，肉眼确认无明文片段；
• 加密对应用透明，不改变业务访问路径，测评时不影响业务功能项打分；
• Root / SA 等高权限账号因不持有密钥，直接读裸盘只见密文，满足“特权账号最小化暴露”的加分项。

7.2 密评的要点

密评关注“算法合规、密钥合规、使用合规”。透明加密在此的抓手是：

• 算法使用国密 SM4（或经批准的 AES），符合密码算法合规要求；
• 根密钥由 HSM 保护，数据密钥由根密钥派生，满足“密钥不出硬件、分级管理”；
• 加解密动作在内核驱动层发生，与具体业务解耦，使用范围清晰、边界可界定。

7.3 密钥管理的举证

举证时建议保留三类材料：HSM 根密钥的托管与备份记录、数据密钥的派生与轮换日志、驱动加载与加密卷挂载的运维审计。三者串起来，就能回答测评老师最关心的两个问题——“密钥从哪来、密文怎么证明是被这把密钥保护的”。

八、工程化落地的常见坑

全栈信创的透明加密，踩坑往往不在算法，而在交付细节。列几条高频问题：

8.1 内核升级与模块签名

国产操作系统补丁频率不低，一次内核小版本升级就可能让旧驱动加载失败。应对办法是把驱动编译与签名做成随内核更新的自动化任务，并在升级演练里把“加密卷能否自动挂回”列为必检项。

8.2 进程白名单与防勒索

透明加密天然能挡住“非授权进程读明文”。配合进程白名单，只有数据库引擎等白名单进程能拿到明文，勒索软件即便拿到操作系统权限，写进来的也是被驱动加密的内容、读出去的是乱码，无法窃取或篡改有效数据。这条在信创终端与服务器上同样适用。

8.3 云 ECS 场景下的密文隔离

当全栈信创部署在云上弹性计算实例时，云管理员对底层存储有控制权。透明加密让云管理员只见密文，即使宿主机快照、磁盘迁移、运维误操作，落到的数据也是密文。这对“既要信创自主、又要借用云资源”的混合架构尤其现实。

8.4 与数据库网关（ DBG ）的组合

部分单位在数据库前加一层数据库网关做访问审计。透明加密负责“落盘密文”，网关负责“访问行为可溯”，两者作用在 IO 栈的不同位置，互不替代。这里强调的是职责分层，而非把加密能力塞进网关。

方案参考

全栈信创的透明加密落地，建议按以下节奏推进，先解决“能不能跑”，再验证“跑得值不值”：

1. 先盘点芯片与操作系统组合，明确内核版本，把驱动编译、签名、加载跑通，形成可重复的构建脚本，避免每次内核升级都手工救火。
2. 选一台非核心库做试点，挂加密卷、迁国产数据库、跑真实业务负载，用裸盘与加密卷两组读数算出本单位损耗基线，把结果写进容量规划。
3. 对达梦、人大金仓等国产库做兼容性回归，确认建库、备份、复制在免改造前提下均正常，重点抽查 redo 日志与备份集是否落盘即密。
4. 把密钥域统一管理起来：根密钥进 HSM，数据密钥派生与轮换留痕，每台主机的密钥一致性纳入运维巡检。
5. 等保与密评的准备提前到设计阶段，hexdump 抽查、进程白名单、密钥托管记录等材料随部署同步积累，验收时直接调取。
6. 若部署在云上弹性实例，把“云管理员只见密文”作为一条独立验收项，确认快照、迁移、运维通道均不泄露明文。

透明数据加密的价值，在信创全栈里不是“又加了一道锁”，而是让自主技术路线在性能可接受的前提下，把数据控制权真正收回到自己手里。把适配做扎实、把损耗测清楚、把举证留完整，全栈国产化就能从“替换完成”走到“放心运行”。