适用场景

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

配置步骤（数据库审计落地）

# 审计范围（四类必审）
1) 登录：成功/失败、来源 IP、账号
2) DDL：建表、改表、删表、授权变更
3) 高危 DML：无条件 UPDATE/DELETE、批量删除
4) 批量导出：select into、导出工具、异常大结果集

# 落地方式
- 数据库自带审计（开启并配置审计策略）
- 旁路审计设备（镜像流量，独立于数据库，难以被篡改）
- 审计日志集中存储，保留 ≥6 个月，禁止被运维账号删除

# 告警规则示例
- 非工作时间大批量删除
- 生产库账号从非授权网段登录
- 单次查询返回行数超过阈值（如 10 万行）

关键参数与建议

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

容易踩的坑

  • 审计只开登录，删库删表没记录
  • 审计日志与数据库同机，被入侵后一起删
  • 运维账号权限过大，可以关闭审计
  • 告警规则没有，审计只存不用
  • 审计日志保留 7 天，事故复盘时已丢失
  • 审计开启后性能下降，被业务方要求关闭，实际是策略没优化

验证与巡检

# 审计检查
1) 四类操作均有日志且可查询
2) 日志集中存储、保留 ≥6 个月、不可删除
3) 告警规则存在且有人处理
4) 审计性能开销可接受（< 5%）
  • 巡检：审计覆盖率、日志留存、告警处理记录、性能开销实测

小结

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

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