一、背景：一次监管通报，暴露三大安全短板

去年，我行在银保监会“数据安全专项检查”中被通报：

“生产数据库存在明文存储敏感信息、账号密码硬编码、内部人员可随意导出客户数据等问题。”

具体风险点包括：

• 客户身份证、手机号以明文存于 SQL Server 表中；
• 应用连接字符串中的数据库账号密码写死在配置文件；
• 开发、测试、运维共用高权限账号，可直接 SELECT * FROM customers；
• 备份文件未加密，U盘拷贝后可在任意机器 restore。

这些问题分别对应数据库安全的三个核心层面：存储层（Data at Rest）、访问层（Data in Use）、凭据层（Credentials）。

单一方案无法根治——我们必须构建立体化防护体系。

---

二、破局思路：TDE + DBG + SMS 三层联动

我们提出 “三位一体”数据库安全架构：

层级	技术	防护目标
存储层	TDE（透明数据加密）	加密 MDF/LDF/备份文件，防物理窃取
访问层	DBG（动态脱敏网关）	查询时自动脱敏，防内部越权查看
凭据层	SMS（凭据管理系统）	统一托管数据库账号密码，防硬编码与泄露

核心理念：

• 即使硬盘丢了 → TDE 让数据变废铁；
• 即使账号连上了 → DBG 让用户看不到明文；
• 即使代码泄露了 → SMS 确保密码已轮换且不可见。

---

三、 技术 实现：三层能力落地详解

3.1 存储层：TDE 实现国密级透明加密

• 启用 SM4-GCM 国密算法 的增强版 TDE（满足密评要求）；
• 密钥由 HSM 或软件 TCM 保护，主密钥不落盘；
• 加密过程在线进行，业务无停机；
• 效果：.mdf、.ldf、.bak 文件打开均为乱码，无法在非授权实例 attach。

# 初始化国密 TDE
tde-admin --init --cipher SM4-GCM --key-store tcm
tde-admin --enable --database core_banking

3.2 访问层：DBG 动态脱敏网关拦截所有 查询

• 在数据库前部署 DBG 代理，应用连接串指向 DBG 而非 DB；
• 配置脱敏策略（YAML）：

policies:
  - name: customer_privacy
    table: customers
    rules:
      id_card:
        mask: "prefix(6) + '******' + suffix(4)"
        roles: [customer_service, intern]
      phone:
        mask: "prefix(3) + '****' + suffix(4)"
        roles: [analyst]
    bypass_roles: [dba, auditor]

• 效果：
  • 客服查客户 → 显示 310115******3456；
  • DBA 查客户 → 显示明文（应急场景）；
  • 所有查询日志记录原始 SQL 与脱敏结果，满足审计要求。

3.3 凭据层：SMS 统一管理数据库账号密码

• 将所有数据库账号密码迁入 SMS 凭据管理系统；
• 应用通过 REST API 动态获取凭据：

# 应用启动时获取
resp = requests.get("https://sms.bank.local/v1/secrets/prod-mysql-core", 
                    headers={"Authorization": "Bearer $APP_TOKEN"})
db_password = resp.json()["password"]

• 启用 自动轮换：每 90 天 SMS 自动更新数据库密码并同步；
• 支持 最小权限分配：开发只能读测试库，运维只能访问特定实例；
• 所有获取行为留痕，满足等保“操作可追溯”要求。

---

四、系统架构图（三位一体）

---

五、合规与成效

要求	实现方式	合规条款
数据存储保密性	TDE + SM4	等保三级 8.1.4.3
敏感信息防泄露	DBG 动态脱敏	《个人信息保护法》第51条
凭据安全管理	SMS 集中托管 + 轮换	等保三级 8.1.5.2
操作可审计	DBG + SMS 日志	等保三级 8.1.6

上线后成果：

• 顺利通过银保监会复检；
• 内部数据导出事件下降 100%；
• 开发不再接触生产密码，事故率降低 90%。

---

六、为什么适合金融、医疗、政务等行业？

该方案特别适用于：

• 处理 身份证、银行卡、病历、住址 等高敏感数据；
• 面临 等保三级、个保法、行业监管 压力；
• IT 资源有限，需 快速落地、低成本改造；
• 已有存量系统，不能重构应用架构。

核心价值：用三个轻量组件，构建覆盖全链路的数据库安全基线。

---

七、写在最后

数据库安全，不是靠一个功能，
而是靠 多层防御的协同。

TDE 守住“数据落盘”的底线，
DBG 控制 “数据可见”的边界，
SMS 管住“谁能连接”的入口。

三者合一，
才能真正实现 数据库安全可控。

安全不是单点突破，而是体系致胜。

互动话题：
你们公司的数据库是否也面临明文存储、凭据泄露、内部越权问题？
是否考虑过 TDE+DBG+SMS 组合方案？
欢迎评论区交流你的“数据库安全实践”！

参考资料：

• GB/T 22239-2019《网络安全等级保护基本要求》
• 《个人信息保护法》
• GM/T 0115-2021《信息系统密码应用基本要求》

文章作者：五台