数据库访问控制怎么落地

数据库访问控制（Access Control）落地，通常不是“装一个工具”就能解决的，而是策略 + 技术 + 流程 + 审计的组合工程。下面按「从规划到落地」的可执行路径来讲。

一、先明确：访问控制的“控制什么”

落地前先界定范围：

1. 谁（主体）

   • 人（DBA、开发、分析师）
   • 应用（微服务、批处理、BI 工具）
   • 第三方（外包、合作伙伴）

2. 访问什么（客体）

   • 实例 / 库
   • 表 / 视图
   • 列（敏感字段）
   • 行（数据级别）

3. 能做什么（操作）

   • SELECT / INSERT / UPDATE / DELETE
   • DDL（建表、改结构）
   • 导出、备份

4. 在什么条件下

   • 时间、IP、终端
   • 是否脱敏、是否审计

二、主流落地模式（按成熟度）

模式 1：账号 + 权限（最基础）

适用：中小系统、内部系统

做法：

• 一个业务一个账号
• 按库/表授权
• 禁用 sa / root 直接业务使用

示例（MySQL）：

CREATE USER 'app_user'@'10.0.%' IDENTIFIED BY 'xxx';
GRANT SELECT, INSERT ON order_db.* TO 'app_user'@'10.0.%';

问题：

• 权限容易膨胀
• 难追溯“谁干了什么”

模式 2：角色访问控制（RBAC）

适用：多团队、中大型组织

核心：

• 人 ≠ 权限
• 人 → 角色 → 权限

常见角色：

• DBA（结构管理）
• 开发（只读/受限写）
• 分析师（脱敏读）
• 应用（最小写权限）

落地要点：

• 角色可审计
• 离职即回收
• 禁止“超级角色”泛滥

模式 3：行列级 + 动态脱敏（数据级控制）

适用：含 PII / 金融 / 医疗数据

技术手段：

• 列级：隐藏手机号、身份证
• 行级：只看自己部门数据
• 动态脱敏：不改存储，查询时脱敏

示例（行级策略思路）：

-- 只看到自己部门
WHERE dept_id = CURRENT_USER_DEPT()

工具层：

• 数据库原生（PG RLS、Oracle VPD）
• 数据中台 / 网关层

模式 4：数据库代理 / 网关（强管控）

适用：合规严、跨系统

架构：

应用 → 数据库网关 → 数据库

能力：

• 统一账号
• SQL 拦截
• 脱敏、限流
• 全量审计

代表：

• 数据库审计网关
• 云厂商 DB Proxy
• 自研 SQL 中间件

三、关键落地步骤（可照做）

Step 1：资产盘点

• 有哪些库、表
• 哪些含敏感字段
• 谁在用、怎么用

输出：

数据资产清单 + 敏感度分级

Step 2：权限最小化

原则：

• 能只读不写
• 能写不删
• 能指定表不整库

Step 3：统一入口

避免：

• 开发直连生产
• 多人共用账号

推荐：

• 堡垒机
• 数据库运维平台
• 应用统一数据源

Step 4：审计闭环

必须记录：

• 谁
• 什么时间
• 哪条 SQL
• 影响多少行

合规价值：

• 出事可回溯
• 权限可复盘

Step 5：生命周期管理

• 入职：按角色授权
• 转岗：权限变更
• 离职：立即回收
• 定期：权限复核（每季度）

四、常见坑（一定要避）

❌ 生产库用 root 跑业务
❌ 一个账号全公司共用
❌ 权限“先给后忘”
❌ 只控“能不能进”，不控“能看到什么”
❌ 有审计但没人看

五、如果你告诉我：

• 用的什么数据库（MySQL / PG / Oracle / 云）
• 是内部系统还是对外
• 当前规模（人 / 库数量）
• 是否要合规（等保 / 金融 / 医疗）

我可以直接给你一套可落地的权限模型 + 示例权限表 + 实施方案。