关键词：数据脱敏、数据脱敏工具、动态数据脱敏、敏感数据保护、数据安全

引言

"开发说要查一下用户表调试 bug。"

你给了他 SELECT 权限。然后他查出了 10 万条包含手机号、身份证号、银行卡号的记录。

数据没有泄露——但如果这个开发把笔记本丢了呢？如果他截了个图发到群里呢？如果他离职了呢？

这就是数据脱敏要解决的问题：让需要数据的人拿到数据，但看不到敏感信息。

一、什么是数据脱敏

数据脱敏（Data Masking）是指对敏感数据进行变形处理，使其在保留一定格式和特征的前提下，不暴露真实值。

原始数据：13812345678
脱敏后：  138****5678

原始数据：320106199001011234
脱敏后：  320106********1234

原始数据：6222021234567890123
脱敏后：  6222****0123

脱敏后的数据可以用于开发调试、测试验证、数据分析等场景，但无法还原出真实数据。

二、静态脱敏 vs 动态脱敏

静态脱敏

把数据从生产库导出时进行脱敏，生成一份脱敏后的数据副本。

生产库（真实数据）→ 脱敏处理 → 测试库（脱敏数据）

适用场景：测试环境数据准备、数据仓库脱敏

优点：一次脱敏，多次使用 缺点：需要额外存储空间；数据有时效性，需要定期更新

动态脱敏

数据存储不变，在查询时实时脱敏。不同用户看到不同的结果。

DBA 查询   → SELECT * FROM users → 张三 | 13812345678 | 320106199001011234
开发 查询  → SELECT * FROM users → 张三 | 138****5678 | 320106********1234

适用场景：日常运维查询、开发调试

优点：不需要额外数据副本；权限精细控制 缺点：每次查询都要处理，有微量性能开销

推荐：动态脱敏为主，静态脱敏为辅。

日常使用堡垒机查询时走动态脱敏；给测试环境导数据时走静态脱敏。

三、常见敏感数据类型与脱敏规则

四、不用工具怎么做脱敏

方案 A：数据库视图

在数据库里创建脱敏视图：

CREATE VIEW v_users AS
SELECT 
  id,
  CONCAT(LEFT(name, 1), '**') AS name,
  CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) AS phone,
  CONCAT(LEFT(id_card, 6), '********', RIGHT(id_card, 4)) AS id_card
FROM users;

然后给开发授权视图而不是原表。

问题：

• 每张有敏感字段的表都要建视图，维护成本高
• 脱敏规则写死在 SQL 里，修改不方便
• 不同用户要看不同级别的脱敏，视图管不了

方案 B：应用层脱敏

在代码里对返回结果做脱敏处理。

问题：

• 只控制了应用，DBA/开发直连数据库还是能看到原始数据
• 每个项目都要写脱敏逻辑，容易遗漏

方案 C：数据库堡垒机脱敏

在堡垒机层做动态脱敏：

• 配置脱敏规则（手机号、身份证、银行卡...）
• 配置哪些角色需要脱敏
• 查询经过堡垒机时自动处理，用户无感知

优点：

• 不用改数据库，不用改代码
• 按角色灵活控制脱敏级别
• 所有数据库类型统一处理

五、SQLDEV 数据脱敏实践

5.1 配置脱敏规则

在 SQLDEV 管理后台配置脱敏规则：

1. 选择脱敏算法（保留前N后M、全替换、哈希、随机替换等）
2. 配置匹配条件（按字段名匹配，如包含 "phone"、"mobile"、"id_card" 的字段）
3. 选择生效范围（全局 / 指定数据库 / 指定表）

5.2 按角色控制

• DBA 角色：不脱敏（需要看到原始数据排查问题）
• 开发角色：脱敏（手机号、身份证、银行卡）
• 临时查询：重度脱敏（所有敏感字段全替换为 ***）

5.3 自动发现敏感数据

SQLDEV 的 SDDP（敏感数据发现）功能可以自动扫描数据库，发现哪些表的哪些字段包含敏感数据，帮你快速建立脱敏规则。

而不是等出了数据泄露事故才发现"原来这张表里有身份证号"。

六、脱敏方案选型建议

如果你的主要需求是保护日常查询中的敏感数据，数据库堡垒机的动态脱敏是最省事的方案——不改库、不改代码、按角色灵活控制。

七、合规要求

数据脱敏不是可选的安全加固，在很多场景下是法律要求。

SQLDEV 社区版免费下载，内置动态数据脱敏和敏感数据发现： https://www.sqldev.info

本文首发于 SQLDEV 官方博客。