一、一次审计惊魂：备份硬盘丢失，患者数据险遭泄露

去年底，我院一台 SQL Server 2019 备份服务器因机房搬迁，一块存有全量患者数据的硬盘意外遗失。

虽未确认是否被恶意获取，但根据《个人信息保护法》第51条：

“发生或者可能发生个人信息泄露……应当立即采取补救措施。”

更严峻的是，等保三级测评即将开展，而我们的数据库存在两大高风险项：

1. 静态数据未加密：MDF/LDF/备份文件均为明文；
2. 敏感字段无脱敏：医生、护士可直接查询患者身份证、电话、病史。

传统方案为何不够？

• 仅用 TDE：能防磁盘窃取，但无法阻止 DBA 或应用账号越权查询明文；
• 仅用视图/RBAC：权限复杂，且开发需改代码，老旧 HIS 系统无法改造。

我们需要 “存储加密 + 查询脱敏” 双层防护，且 零代码改造。

---

二、破局思路：TDE + DBG 联合防护架构

我们设计了一套 分层防御模型：

[应用] → [DBG 动态脱敏网关] → [SQL Server + TDE]
                ↑                      ↑
        （查询时脱敏）       （存储时加密）

核心分工

组件	职责	解决什么风险
TDE（透明数据加密）	加密 MDF/LDF/备份/日志文件	防磁盘/备份被盗导致的数据泄露
DBG（动态脱敏网关）	拦截 SQL 查询，按策略返回脱敏结果	防内部人员越权查看敏感字段

优势：

• TDE 由 SQL Server 引擎原生支持（或兼容增强版）；
• DBG 以代理方式部署，无需修改应用与数据库；
• 二者互补，覆盖“静态 + 动态”全生命周期。

---

三、TDE 实施：整库加密，国密就绪

3.1 启用原生 TDE（SQL Server 2016+）

-- 创建主密钥
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Strong!Master@Key2025';

-- 创建证书
CREATE CERTIFICATE TDECert WITH SUBJECT = 'TDE Certificate';

-- 创建数据库加密密钥
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TDECert;

-- 启用 TDE
ALTER DATABASE HospitalDB SET ENCRYPTION ON;

局限：仅支持 AES，不满足密评 SM4 要求。

3.2 国产化增强：安当 TDE透明加密（SM4 算法）

为满足 商用密码应用安全性评估（密评），我们采用 兼容 TDE 接口的国产增强方案：

• 加密算法：SM4-GCM（国密标准）；
• 密钥管理：支持对接 国密 HSM / TCM 芯片；
• 兼容性：无缝替换原生 TDE，应用无感知；
• 审计：记录加密/解密操作日志，满足等保要求。

效果：
即使攻击者拿到 .bak 文件，在无密钥情况下，内容完全不可读。

---

四、DBG 动态脱敏：字段级精准 控制

4.1 为什么不用 SQL Server 原生动态数据脱敏（DDM）？

• DDM 仅对 SELECT 有效，INSERT/UPDATE 仍可见明文；
• 依赖角色权限，无法细粒度到“字段+用户+场景”；
• 老旧客户端（如 Delphi）可能绕过。

4.2 DBG 网关方案优势

DBG 作为 SQL 代理中间件，部署在应用与数据库之间：

• 协议解析：识别 SELECT * FROM patient；
• 策略匹配：根据登录用户身份，动态重写 SQL；
• 结果脱敏：返回如 身份证: 110***********1234。

脱敏策略示例（JSON）

{
  "table": "patient",
  "columns": {
    "id_card": {
      "rule": "mask_middle",
      "params": {"keep_prefix": 6, "keep_suffix": 4},
      "roles": ["doctor", "nurse"]
    },
    "phone": {
      "rule": "mask_all",
      "roles": ["intern"]
    }
  },
  "bypass_roles": ["admin", "auditor"]
}

关键能力：

• 支持 正则、掩码、哈希、替换 多种脱敏规则；
• 可按 用户、IP、时间、SQL 模式 动态生效；
• 提供 审计日志：谁查了什么字段，原始值 vs 脱敏值。

---

五、联合防护效果对比

风险场景	仅 TDE	仅 DBG	TDE + DBG
磁盘/备份被盗	✔️ 防护	✘ 无效	✔️ 防护
DBA 越权查询	✘ 明文可见	✔️ 脱敏返回	✔️ 脱敏返回
应用账号泄露	✘ 可查明文	✔️ 按策略脱敏	✔️ 脱敏返回
满足密评	△（需 SM4）	✘	✔️（TDE-SM4 + DBG 审计）
等保三级	部分满足	部分满足	完整覆盖

在我院上线后：

• 备份文件加密率 100%；
• 敏感字段查询脱敏率 100%；
• 一次性通过等保三级 + 密评。

---

六、部署架构与性能考量

架构图

[HIS 应用] → [DBG 网关（集群）] → [SQL Server（TDE 加密）]
                     ↓
               [审计日志 → SIEM]

性能优化

• DBG 采用 连接池复用，延迟增加 真正的安全，是即使数据被拿走，也看不懂；即使有权限访问，也看不到不该看的。

互动话题：

你们的 SQL Server 做了 TDE 吗？

敏感字段是如何做脱敏的？

欢迎评论区交流你的实践经验！

参考资料：

• GB/T 39786-2021《信息安全技术 信息系统密码应用基本要求》（密评标准）
• 《个人信息保护法》第51条
• Microsoft: Transparent Data Encryption (TDE)
• NIST SP 800-188: De-identification of Personal Informatio

文章作者：五台