一、解决的问题/场景

在政务信息化建设中，数据安全是底线红线。随着政务数据跨部门共享、对外查询服务的增多，敏感信息泄露风险急剧上升。以下场景亟待解决：

1.1核心痛点：
1.敏感数据暴露风险：姓名、身份证号、手机号、地址等个人信息在测试环境、数据共享、统计分析场景中明文存储和使用，一旦泄露将引发严重合规风险。
2.权限管控粗放：传统权限控制仅停留在表/字段级别，缺乏细粒度的数据访问控制，同一张表中不同敏感度的字段无法差异化授权。
3.合规监管要求：依据《数据安全法》《个人信息保护法》，政务数据必须实施脱敏处理，但手动改写代码成本高、易遗漏。
4.运维与开发矛盾：开发测试需要真实数据环境，但又不能直接使用生产数据明文，如何平衡真实性与安全性。

1.2典型场景：
测试环境导入生产数据时，敏感字段必须脱敏
第三方查询接口返回数据时，自动掩码
数据分析师查询报表时，所见即脱敏结果

二、解决方法/操作步骤

2.1 敏感数据识别与分类
首先建立敏感数据清单，明确脱敏策略：

2.2 启用KingBase数据脱敏功能
2.2.1 确认授权版本
KingBase企业版支持动态数据脱敏功能，确认已启用该模块： – 查看脱敏功能是否启用 SELECT * FROM kingbase.sys_settings WHERE name LIKE ‘%mask%’;

2.2.2 创建脱敏策略
以政务人员信息表为例：

– 创建测试表CREATE TABLE citizen_info (
id SERIAL PRIMARY KEY,
name VARCHAR(50),
id_card VARCHAR(18),
mobile VARCHAR(11),
address VARCHAR(200),
email VARCHAR(100));
– 插入测试数据
INSERT INTO citizen_info (name, id_card, mobile, address, email)VALUES (‘张三’, ‘110101199001011234’, ‘13800138000’, ‘北京市朝阳区建国路88号’, ‘zhangsan@test.com’),(‘李四’, ‘310101198505205678’, ‘13900139000’, ‘上海市浦东新区陆家嘴环路1000号’, ‘lisi@test.com’);

2.2.3 定义脱敏规则
– 创建脱敏策略（官方标准语法：anon.add_policy()）

SELECT anon.add_policy(

‘citizen_mask_policy’, – 策略名称

‘citizen_info’, – 目标表名

– 定义各字段脱敏规则

‘name’, ‘partial(name, 1, 1, ‘’*’‘)’, – 姓保留，名掩码（官方函数：partial）

‘id_card’, ‘partial(id_card, 6, 4, ‘’*’‘)’, – 前6后4保留

‘mobile’, ‘partial(mobile, 3, 4, ‘’*’‘)’, – 前3后4保留

‘address’, ‘partial(address, 6, 0, ‘’*’‘)’, – 保留前6字符

‘email’, ‘email_mask(email)’ – 邮箱脱敏（官方函数：email_mask）

);

2.2.4 应用脱敏策略
– 对特定用户应用脱敏策略

– 先为用户启用脱敏功能

ALTER ROLE test_user SET anon.masking = ‘on’;

– 绑定策略到用户与表

SELECT anon.apply_policy_to_role(‘citizen_mask_policy’, ‘test_user’, ‘citizen_info’);

– 或对表全局应用脱敏策略（所有用户访问该表均触发脱敏）

SELECT anon.apply_policy_to_public(‘citizen_mask_policy’, ‘citizen_info’);

2.3 细粒度权限控制
结合KingBase的行级安全策略，实现更精细的控制：

– 启用行级安全

ALTER TABLE citizen_info ENABLE ROW LEVEL SECURITY;
– 创建策略：管理员可见全部，其他用户仅可见脱敏数据

CREATE POLICY citizen_select_policy ON citizen_info
FOR SELECT
TO test_user
USING (true); – 允许查询但受脱敏策略影响

2.4 验证脱敏效果
– 切换至test_user身份查询

SET ROLE test_user;

SELECT * FROM citizen_info;

RESET ROLE;

– 预期结果：

– id | name | id_card | mobile | address | email

– ----±------±---------------±------------±-----------------±------------ –

1 | 张** | 1101011234 | 1388000 | 北京市朝阳区** | z***@test.com

2 | 李** | 3101015678 | 1399000 | 上海市浦东新区** | l***@test.com

2.5 持久化脱敏（静态脱敏）
– 创建脱敏后导出表

CREATE TABLE citizen_info_export AS

SELECT id,

partial(name, 1, 1, ‘*’) AS name,

partial(id_card, 6, 4, ‘*’) AS id_card,

partial(mobile, 3, 4, ‘*’) AS mobile,

partial(address, 6, 0, ‘*’) AS address,

email_mask(email) AS email

FROM citizen_info;

– 导出脱敏后的数据

COPY citizen_info_export TO ‘/tmp/citizen_info_masked.csv’ WITH (FORMAT csv, HEADER);

三、经验总结

3.1 关键成功因素
**策略先行 **：脱敏不是技术问题，是业务问题。必须先与业务部门明确哪些字段需要脱敏、脱敏强度如何，避免一刀切或过度脱敏影响业务。
**最小权限原则 **：脱敏是最后一道防线，仍需配合RBAC（基于角色的访问控制），从源头减少敏感数据接触面。
**性能权衡 **：动态脱敏会消耗计算资源，建议对高频查询字段建立索引，或在非核心查询场景使用。

3.2 常见坑点
**避免误脱敏 **：开发调试时临时关闭脱敏策略后忘记恢复，导致测试环境数据泄露。
**不可逆性 **：掩码脱敏后的数据无法恢复，如需保留原始数据用于数据分析，建议使用加密脱敏而非掩码。
**审计缺失 **：脱敏不等于无痕，仍需开启审计日志，记录敏感数据的访问行为。

扩展依赖遗漏：未提前安装 anon 扩展直接执行脱敏语法，导致语句执行失败；建议将扩展安装纳入数据库初始化脚本。

3.3 最佳实践建议
1.脱敏策略版本化管理 ：将脱敏策略定义写入版本控制，变更走审批流程。
**2.定期审计检查 ：**通过扫描工具定期检测是否有新表未应用脱敏策略。
**3.分级分类实施 ：**根据数据敏感度（L1-L4级)实施不同强度的脱敏策略，非敏感数据无需脱敏以提升性能。
4.语法兼容性校验：数据库版本升级前，先校验脱敏策略语法是否适配新版本官方规范，避免升级后脱敏功能失效。