一、一个真实困境：客户问你，“身份证号怎么保护？”

作为软件开发商或 DBA，你一定被这样问过：

“我们数据库里有用户身份证、手机号、银行卡号，该怎么保护？
是加密？还是脱敏？能不能既满足开发测试，又防生产泄露？”

很多人第一反应是：“用 AES 加密字段！”
但很快发现：

• 模糊查询失效（WHERE phone LIKE '138%' 不可用）；
• 索引性能暴跌；
• 运维无法排查问题（全是密文）；
• 开发要改大量代码。

而如果只做“脱敏”，又担心：

• 生产库明文存储，一旦被拖库，全盘皆输；
• 备份文件外泄，等于直接送数据给攻击者。

关键认知：
脱敏 ≠ 加密，二者目标不同，应分层使用！

---

二、脱敏 vs 加密：本质区别与适用场景

维度	动态脱敏（Dynamic Masking）	静态加密（Static Encryption）
目的	控制“谁能看到明文”	控制“数据是否可读”
数据状态	磁盘上仍是明文	磁盘上为密文
查询能力	支持模糊查询、索引	加密后无法直接查询
典型场景	开发/测试环境、BI 分析、外包人员访问	生产库静态存储、备份归档
合规依据	《个保法》第51条“去标识化”	《等保2.0》8.1.4.3“存储保密性”

最佳实践：
生产库 → 静态加密（防脱库） + 动态脱敏（控权限）
测试库 → 仅动态脱敏（保留查询能力）

---

三、MySQL 下的落地挑战

3.1 方案1：应用层加密（如 AES_ENCRYPT()）

INSERT INTO users (id_card) VALUES (AES_ENCRYPT('11010119900307XXXX', 'key'));

问题：

• 无法 WHERE id_card LIKE '110%'；
• 密钥管理困难（硬编码 or KMS？）；
• 所有业务逻辑需重写。

3.2 方案2：视图 + 函数脱敏

问题：

• 仅对特定角色有效，DBA 仍可查基表；
• 无法防止 SQL 注入直接读 users 表；
• 不支持复杂脱敏规则（如按角色定制）。

结论：原生 MySQL 能力不足以满足企业级安全需求。

---

四、推荐架构： DBG数据库加密网关 + TDE透明加密 分层防护

我们建议采用 “加密保底 + 脱敏控权” 的组合策略：

+---------------------+
|      应用系统        |
+----------+----------+
           ↓
+---------------------+
|   安当 DBG（代理）   | ←─ 动态脱敏 + SQL 审计
+----------+----------+
           ↓
+---------------------+
|     MySQL 实例       |
+----------+----------+
           ↓
+---------------------+
|   安当 TDE（驱动）   | ←─ SM4 静态加密
+----------+----------+
           ↓
    物理磁盘（全密文）

4.1 TDE透明加密：确保“即使脱库也看不懂”

• 对 /var/lib/mysql 目录全量 SM4 加密；
• 身份证、手机号等字段在磁盘上为密文；
• 即使黑客导出 .ibd 文件，也无法还原。

4.2 DBG数据库加密网关：确保“不该看的人看不到”

• 应用连接 3307 端口，DBG 自动识别敏感字段；
• 根据用户身份返回不同结果：

-- DBA 查询
SELECT id_card FROM users; 
→ 11010119900307XXXX

-- 外包人员查询
SELECT id_card FROM users;
→ 110***********1234

• 同时阻断高危 SQL（如 SELECT * FROM users）。

效果：

• 生产库：数据加密存储 + 按需脱敏展示；
• 测试库：仅启用 DBG 脱敏，保留查询能力；
• 全链路满足等保 + 个保法。

---

五、ISV 如何快速集成？

作为软件开发商，你只需三步：

步骤1：交付包嵌入安当组件

your-installer/
├── app/
├── andang-dbg/      # 数据库网关
├── andang-tde/      # 透明加密驱动
└── install.sh       # 自动配置脚本

步骤2：修改数据库连接地址

# application.yml
spring:
  datasource:
    url: jdbc:mysql://localhost:3307/mydb  # ← 改为 DBG 端口

步骤3：配置脱敏策略（JSON 示例）

{
  "database": "mydb",
  "tables": {
    "users": {
      "columns": {
        "id_card": { "type": "id_card", "roles": ["admin"] },
        "phone":   { "type": "mobile", "roles": ["admin", "support"] }
      }
    }
  }
}

优势：0 代码改造，1 小时完成集成！

---

六、信创与合规支持

• 算法：SM4（加密）、SM3（日志签名）、SM2（密钥交换）；
• OS：麒麟 V10、统信 UOS、OpenEuler；
• 合规：
  • 等保2.0：8.1.4.3（存储加密）、8.1.5.2（操作审计）；
  • 个保法：第51条“去标识化与加密”；
  • 密评：通过国家商用密码认证。

---

七、结语：安全不是功能，而是责任

对于存储用户敏感信息的系统，“能跑起来”只是起点，“保得住”才是底线。

通过 TDE（静态加密） + DBG（动态脱敏）的组合，你可以在不牺牲业务功能的前提下，构建纵深防御体系：

• 防外部攻击：脱库无用（TDE 加密）；
• 防内部滥用：越权不可见（DBG 脱敏）；
• 过合规审计：日志可追溯（完整审计）。

让每一行敏感数据，都得到应有的保护。

欢迎留言讨论：你在项目中是如何处理敏感字段的？遇到过哪些坑？

文章作者：五台