—— 满足等保三级与密评要求的数据库安全纵深防御体系
关键词：安当TDE、DBG数据库网关、透明数据加密、动态脱敏、字段加密、信创、等保三级、SM4、SM3
一、背景：单一加密无法满足合规与业务双重需求
在金融、政务、医疗等行业，数据库安全面临两类核心诉求：
| 需求类型 | 合规要求 | 技术挑战 |
|---|---|---|
| 静态数据保护 | 等保2.0 要求“重要数据存储时应加密” 密评要求“使用国密算法加密静态数据” | 需对整个数据库文件加密，防磁盘窃取 |
| 动态数据保护 | 《个人信息保护法》要求“去标识化处理” 内部人员越权查询需阻断 | 需在查询返回时自动脱敏敏感字段 |
然而：
- 仅用 TDE：可加密磁盘文件，但应用查询仍返回明文，无法防止 DBA 或开发人员直接读取身份证号；
- 仅用脱敏网关：可隐藏敏感字段，但数据库文件仍是明文，一旦磁盘被盗即全量泄露。
✅解决方案：
** TDE（存储层加密） + DBG（应用层脱敏） = 双模防护**
二、整体架构：分层防御，各司其职
+---------------------+ | 应用系统 | | (Web/App/BI工具) | +----------+----------+ ↓ +---------------------+ | 安当 DBG 数据库网关 | ←─ 动态脱敏、SQL审计、访问控制 | - 拦截 SQL 请求 | | - 重写 SELECT 语句 | | - 返回脱敏结果 | +----------+----------+ ↓ +---------------------+ | 目标数据库 | | (MySQL/达梦/Oracle) | +----------+----------+ ↓ +---------------------+ | 安当 TDE 加密驱动 | ←─ 透明加密数据库文件 | - 加密 ibdata1 / .dbf| | - SM4 算法 + TCM 保护| +----------+----------+ ↓ +---------------------+ | 物理存储 | | (磁盘/云硬盘) | +---------------------+🔒双保险机制：
- 落盘加密：即使数据库文件被复制，也无法读取（TDE 保障）；
- 查询脱敏：即使拥有数据库账号，也无法看到完整敏感信息（DBG 保障）。
三、 TDE透明加密：实现数据库文件的透明加密（存储层）
3.1 核心能力
- 驱动级加密：在操作系统 I/O 层拦截写入操作，自动加密；
- 无侵入部署：无需修改数据库配置或应用代码；
- 国密合规：使用 SM4 加密算法，密钥由 TCM/HSM 保护；
- 通用兼容：支持 MySQL、PostgreSQL、达梦、人大金仓等所有以文件存储的数据库。
3.2 实施示例（以达梦数据库为例）
# 1. 安装 TDEsudorpm-ivh andang-tde-3.2-kylinv10.rpm# 2. 配置加密目录（达梦数据目录）echo'MOUNT_POINTS=/dmdata'>>/etc/andang/tde.conf# 3. 迁移数据目录至加密区sudosystemctl stop DmServiceDMSERVERsudomv/opt/dmdbms/data /dmdata/sudoln-s /dmdata/data /opt/dmdbms/datasudosystemctl start DmServiceDMSERVER✅效果：
/dmdata/DAMENG/*.dbf在磁盘上为 SM4 密文；- 达梦进程读取时自动解密，应用无感知。
四、 DBG数据库网关：实现字段级动态脱敏（应用层）
4.1 核心能力
- SQL 代理：作为数据库前端代理，拦截所有 SQL 请求；
- 智能脱敏：基于字段标签自动重写
SELECT语句； - 细粒度策略：按用户角色、IP、时间控制脱敏规则；
- 审计追溯：记录原始 SQL 与脱敏后 SQL，满足等保审计要求。
4.2 脱敏策略配置（示例）
| 表名 | 字段 | 敏感类型 | 脱敏规则 | 适用角色 |
|---|---|---|---|---|
user_info | id_card | 身份证 | REPLACE(id_card, SUBSTR(id_card,7,8), '********') | 普通员工 |
user_info | phone | 手机号 | CONCAT(LEFT(phone,3), '****', RIGHT(phone,4)) | 所有非管理员 |
bank_account | card_no | 银行卡 | MASK(card_no, 4, 4) | 外包人员 |
💡支持脱敏函数：
MASK(str, left_keep, right_keep)HASH(str)（用于关联分析）NULL（完全隐藏）
4.3 部署模式
- 代理模式：应用连接
DBG:3306→ DBG 转发至DB:3306； - 旁路模式（高性能场景）：通过 eBPF 技术透明劫持流量，零改造。
4.4 查询效果对比
原始查询（无 DBG）：
SELECTname,id_cardFROMuser_infoWHEREid=1001;-- 返回：张三, 11010119900307XXXX经 DBG 脱敏后：
-- DBG 自动重写为：SELECTname,REPLACE(id_card,SUBSTR(id_card,7,8),'********')ASid_cardFROMuser_infoWHEREid=1001;-- 返回：张三, 110101********XX✅优势：
- 应用代码无需任何修改；
- DBA 使用 Navicat 直连 DBG，同样被脱敏。
五、TDE + DBG 协同价值：1+1 > 2
| 场景 | 仅 TDE | 仅 DBG | TDE + DBG |
|---|---|---|---|
| 磁盘被盗 | ✅ 数据不可读 | ❌ 明文泄露 | ✅ 安全 |
| DBA 越权查询 | ❌ 可查明文 | ✅ 返回脱敏 | ✅ 安全 |
| 开发人员调试 | ❌ 可见生产数据 | ✅ 自动脱敏 | ✅ 安全 |
| 等保合规 | 满足“存储加密” | 满足“访问控制” | ✅ 双项达标 |
| 密评合规 | 满足 SM4 加密 | 满足 SM3 审计日志 | ✅ 全面覆盖 |
📜合规映射：
- 等保2.0 8.1.4.3：“应采用密码技术保证重要数据在存储过程中的保密性” →TDE 满足；
- 等保2.0 8.1.5.3：“应提供重要数据的本地数据备份与恢复功能” → TDE 不影响备份；
- 个人信息保护法 第51条：“采取去标识化等措施” →DBG 满足。
六、信创环境全栈适配
| 组件 | 适配情况 |
|---|---|
| 操作系统 | 麒麟 V10、统信 UOS、OpenEuler |
| 数据库 | 达梦 DM8、人大金仓 Kingbase、神舟通用 |
| 加密算法 | TDE：SM4；DBG 审计日志：SM3 哈希 |
| 硬件信任根 | TDE 密钥由 TCM 2.0 芯片保护 |
| 部署模式 | 支持 ARM64（鲲鹏/飞腾）与 x86（兆芯/海光） |
🏆案例：某省级医保平台使用 TDE + DBG 方案，加密 10TB 医保数据库，对身份证、病历号动态脱敏，顺利通过等保三级与个人信息保护合规检查。
七、实施建议：分阶段落地
阶段1：部署 TDE，实现存储加密
- 优先加密核心业务库（如用户库、交易库）；
- 验证性能影响（通常 <5%）。
阶段2：部署 DBG，配置脱敏策略
- 识别敏感字段（PII/PHI）；
- 按角色定义脱敏规则；
- 与 IAM 系统对接，实现角色自动识别。
阶段3：统一审计与告警
- 将 TDE 加密日志 + DBG SQL 审计日志接入 SIEM；
- 配置异常查询告警（如高频查询身份证字段）。
八、总结：纵深防御，合规无忧
在数据安全要求日益严苛的今天，单一防护手段已无法应对复合型风险。
TDE 与 DBG 的组合，提供了一套“内防滥用、外防窃取”的完整解决方案：
- TDE 筑牢底座：确保数据“落盘即加密”，满足静态数据保护合规；
- DBG 守住出口：确保数据“查询即脱敏”，防止内部越权与外部泄露。
✅一句话价值：
让数据库既“锁得住”（TDE），又“看得见该看的”（DBG）——这才是真正的数据安全闭环。
