等保密评视角下的数据库加密：国密合规信创与纵深防御组合

做政企、金融、医疗项目的工程师，迟早要面对密评（商用密码应用安全性评估）和等保 2.0。这两项检查里，和"数据加密"直接相关的条款不止一条。本文把它们翻译成可落地的技术动作。

一、合规到底要求什么

拆解下来，核心就两条：

1. 存储加密：敏感字段/文件不能明文落盘；
2. 密钥独立：加密密钥不能和数据放在一起，要有独立的密钥全生命周期管理（生成、存储、轮换、销毁、审计）。

《个人信息保护法》和 GDPR 还额外要求"谁能看、看了什么"可追溯——这指向访问控制 + 审计。

二、国密不是可选项，是硬指标

在政务、金融、关键基础设施场景，算法层面要求国密（SM4 对称、SM2 非对称、SM3 摘要），且设备要过商用密码产品认证（如 GM/T 0028 二级）。选方案时，先确认算法与资质是否覆盖国密，否则密评直接扣分。

同时，信创替代趋势下，能否跑在麒麟、统信等国产操作系统、达梦/人大金仓等国产数据库上，也成为政企采购的入场券。

三、透明加密解决"存储"，网关解决"访问"

单一手段很难同时覆盖"存储加密"和"访问脱敏"：

• 透明加密（TDE）：管"落盘"，让磁盘、备份、快照都是密文，挡住物理窃取与高权限拖库；
• 数据库加密网关：管"访问"，对运维 SELECT 结果里的敏感字段实时动态脱敏，挡住逻辑越权。

两者组合即纵深防御：业务系统直连数据库高效读写（底层 TDE 自动加解密），运维走加密网关访问并对敏感字段脱敏，操作系统层与数据库访问层权限彻底分离。

以安当 TDE 与 DBG 的组合方案为例：TDE 在操作系统层对数据库整库透明加密（支持国密 SM4、通过国密二级认证、兼容达梦/人大金仓与麒麟/统信），DBG 在数据库访问层对运维输出做字段级脱敏与全量 SQL 审计，密钥统一由通过国密认证的 KSP 托管，形成"存储加密 + 访问脱敏 + 密钥独立"的合规闭环。

四、密评落地清单

1. 算法国密化：优先 SM4，确认产品过商用密码认证；
2. 密钥分离：密钥由独立 KMS/HSM 托管，不随数据同库；
3. 访问与审计：敏感字段脱敏 + 全链路操作日志；
4. 信创适配：国产 OS/数据库兼容认证就绪；
5. 性能实测：上线前用真实 SQL 压测 I/O 损耗。

方案参考

面向密评与等保的数据库加密，推荐"驱动层透明加密（TDE）+ 数据库加密网关（DBG）+ 独立密钥管理（KSP）"的纵深组合：存储层密文化、访问层脱敏化、密钥层独立化，覆盖等保"身份鉴别/访问控制/安全审计/数据完整性保密性"多项要求，并具备国密算法与信创环境适配能力。对需一次通过密评的政企系统，是较完整的参考架构。

注：本文为技术解析，具体认证资质与兼容列表以各产品官方文档为准。