军工涉密数据库加密：TDE还是应用层加密的合规选型

军工涉密数据库加密：TDE还是应用层加密的合规选型

某军工单位涉密图纸库，一次服务器磁盘被物理带走，事后用 strings 一查，*.ibd 里满是明文涉密数据——数据库根本没做落盘加密。复盘时团队分裂：DBA 说上 TDE 透明加密、零改造；应用组说要应用层加密、字段级才安全。两派吵了三个月，明文落盘的问题还悬着。

# 现场确认：涉密库是否明文落盘（示意）
strings /var/lib/mysql/mil_secret.ibd 2>/dev/null | grep -c "涉密"
# → 128 → 涉密数据明文落盘，拖走磁盘即可读

# 应用层有没有加密字段
grep -rc "SM4\|encrypt" /opt/oa/app/*.py 2>/dev/null | head -5
# → 0 → 应用层也没做加密

数据库加密，军工涉密场景最纠结的就是TDE 透明加密 vs 应用层加密选哪个。这篇把两条路线的原理、机制、优势短板、实测命令一次讲清，最后给一张军工涉密场景的决策表：

• 一、先分清两条技术路线
• 二、路线一：TDE 透明加密，零改造全覆盖
• 三、路线二：应用层加密，字段级强隔离
• 四、军工涉密场景怎么选：决策表
• 五、落地验证与验收清单

一、先分清两条技术路线

数据库加密的落地位置不同，效果完全不同：

关键认知：TDE 管"整库落盘被拖走"的风险，应用层加密管"关键字段高密级隔离"的风险。两者不是对立，是不同密级、不同风险用不同粒度。军工涉密库往往两个都要——全库用 TDE 兜底，最高密级字段再叠加应用层加密。

二、路线一：TDE 透明加密，零改造全覆盖

原理

TDE（Transparent Data Encryption）在数据库引擎层做落盘加密：数据写入磁盘前加密、读入内存后解密，应用和 SQL 完全无感。密评/等保检查"数据存储保密性"，直接对应 TDE 的落盘加密能力。

落地

以 MySQL 8.0 为例，开启表空间加密 + 密钥接 KSP：

# 1) 涉密库开启 TDE（示意）
mysql -e "ALTER TABLESPACE mil_secret ENCRYPTION = 'Y';"
# → 生效，落盘数据加密

# 2) 验证落盘无明文
strings /var/lib/mysql/mil_secret.ibd 2>/dev/null | grep -ci "涉密"
# → 0 → 明文串消失，落盘已加密 ✓

性能实测

TDE 加解密由引擎内建完成，对典型 OLTP 影响约 3%。用 sysbench 压测确认不影响涉密业务：

# 压测涉密库读写（示意）
sysbench --mysql-db=mil_secret oltp_read_write run
# → 关注 TPS/QPS，加密前后对比，通常下降 <5%

优势与短板

• 优势：零改造、覆盖全库、防拖库防物理窃取、密钥管理由 KSP 统一承担可审计
• 短板：SELECT 查询仍返回明文（内存/客户端侧读取防不住）；库级粒度，字段级高密级隔离弱；密钥轮换要对整库重写

产品落点：涉密库落盘加密走 安当 TDE，透明零改造；密钥由 安当 KSP 统一生成、轮换，主密钥锁 HSM 不可导出。

三、路线二：应用层加密，字段级强隔离

原理

应用层加密在应用代码里调用加密 SDK（如 安当 KADP 应用数据加密 SDK），先把敏感字段加密成密文再写库。密文落盘，应用侧按需解密，字段级权限可精细控制。

落地

改造点排查 + 加密后验证：

# 1) 排查应用里所有涉密字段的读写点（示意）
grep -rn "图纸编号\|WHERE.*ID\|INSERT INTO.*secret" /opt/oa/app/ | head -10
# → 列出所有要改造的 SQL 点

# 2) 加密后模糊查询验证（关键坑）
mysql -e "SELECT * FROM secret_meta WHERE enc_no LIKE '%2026%'"
# → 空 → 普通加密后 LIKE 失效，需 FPE 保留格式加密或 DBG 模糊查询

优势与短板

• 优势：字段级隔离、密文到应用（内存/客户端都读不到明文）、权限精细、密钥可逐字段分散
• 短板：改造量大（每个读写点都要动）、模糊查询/索引要专门方案、密钥分散后必须用 KSP 统一纳管，否则变成"一堆散钥匙"

产品落点：字段级加密走 安当 KADP（多语言 SDK、FPE 保留格式加密），模糊查询走 安当 DBG 数据库加密网关；字段密钥仍由 安当 KSP 统一签发纳管。

四、军工涉密场景怎么选：决策表

军工特别提醒：涉密场景的密钥必须物理隔离、集中管理——无论选 TDE 还是应用层加密，密钥管理都走 KSP、主密钥锁 HSM，禁止密钥裸存在应用或数据库本地。这是密评和分级保护检查最卡的环节。

五、落地验证与验收清单

# TDE 层验证：落盘无明文（实测过即可复用）
strings /var/lib/mysql/mil_secret.ibd | grep -ci "涉密"
# → 0 → 落盘加密 ✓

# 密钥轮换验证：KSP 审计留痕
grep -c "ROTATE" /var/log/ksp/audit.log
# → >0 → 密钥按策略轮换、全程留痕 ✓

# 字段加密验证：直查密文字段
mysql -e "SELECT enc_no FROM secret_meta LIMIT 1"
# → 显示密文 → 应用层加密生效 ✓

对着这份决策表，把你们军工涉密库过一遍：先 strings 查一次落盘有没有明文，再按库的密级选路线——整库先上 TDE 兜底，最高密级字段叠加应用层加密，钥匙全挂 KSP + HSM。明文落盘一天不解决，磁盘被带走就是泄密事件。你现场的涉密库是零改造 TDE 还是字段级应用层加密？评论区说说你的选型理由，一起拆。

文章作者：安当加密技术负责人