适用场景

数据安全治理的第一步不是买工具，而是搞清楚「哪些数据重要」。分类分级做完，后面的加密、脱敏、审计、权限才有依据；否则就是给所有数据上同样的锁，成本高还没效果。

配置步骤（最小权限与属性控制）

# 权限模型演进
1) 基础：按账号授权（人员多了无法维护）
2) RBAC：按角色授权（推荐基线，角色与人员解耦）
3) ABAC/行级控制：在角色基础上加属性约束
   例：客服只能看自己负责的客户；区域经理只能看本区域数据

# 落地方式（以关系型数据库为例）
- 视图 + WHERE 条件（简单可控）
- 行级安全策略（数据库支持时优先）
- 应用层数据过滤（必须有统一拦截，不能各模块自己写）

# 检查点
- 是否存在共享账号（应禁止）
- 是否有超权限账号（如业务账号有 DDL 权限）
- 离职/转岗后权限是否回收

关键参数与建议

  • 分类：按业务属性（客户、合同、财务、人事、日志）分类
  • 分级：公开/内部/敏感/核心四级，明确每级的保护要求
  • 数据地图：每张表/每个字段归到某级，形成数据资产清单
  • 权限模型：按角色授权（RBAC），敏感数据再加属性约束（如仅本部门可见）
  • 审计：登录、DDL、DML 高危操作、批量导出四类必须审计
  • 脱敏：查询展示脱敏、导出脱敏、开发测试用脱敏数据
  • 生命周期：采集最小化、存储加密、到期清理、销毁留痕
  • 评审：新增系统/字段上线前做数据分级评审，纳入变更流程

容易踩的坑

  • 业务账号给 DDL 权限，误操作改表结构
  • 共享账号（如 app01 多人使用），操作无法追溯
  • 应用层过滤各写各的，漏掉一个接口就泄露
  • 岗位调整后权限没回收，越权访问长期存在
  • 只在前台限制导出，接口仍可全量拉取
  • 权限清单从未评审，实际权限远超设计

验证与巡检

# 权限检查
1) 有无共享账号？（应为 0）
2) 业务账号是否有 DDL/超级权限？（应为否）
3) 行级/字段级约束是否实测生效？
4) 权限清单季度评审记录？
  • 巡检：共享账号为 0、无超权限、越权测试通过、季度评审记录

小结

数据分级验收：抽查任意一张表，能说出它的级别、谁能访问、是否脱敏、审计是否覆盖。四项齐备才算治理落地。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。