数据库访问控制常见误区有哪些

数据库访问控制（Authorization / Access Control）是保障数据安全的核心环节，但在实际落地中，开发、运维和安全人员常常会陷入一些常见误区。下面按“认知误区”“设计误区”“运维误区”“技术误区”几个维度梳理：

一、认知与策略类误区

1. 认为“用了数据库账号密码就安全了”

• 只做了身份认证（你是谁），忽略了授权（你能干什么）
• 很多系统用一个高权限账号（如 root / sa / admin）连接数据库，所有业务共用

2. 过度依赖网络隔离

• 认为“内网数据库的访问来源就安全”
• 忽略了：
  • 内部人员越权
  • 应用服务器被入侵后的横向移动
  • 云环境内网并不等于可信

3. 权限“一刀切”

• 要么全放开，要么全禁止
• 缺乏基于角色、场景、数据敏感度的细粒度控制

二、权限设计类误区

4. 权限过大（过度授权）

常见问题：

• 应用账号拥有 DBA 权限
• 只读需求却给了 INSERT/UPDATE/DELETE
• 测试环境权限直接复制生产环境

后果：

• 一旦应用被攻击，数据库直接“裸奔”

5. 角色设计混乱

• 角色嵌套过深、职责不清
• 一个角色既管业务又管运维
• 离职人员权限未回收，角色越积越多

6. 忽视“最小权限原则”

• 默认给权限，而不是默认无权限
• “先给着，以后再说”是典型反模式

三、账号与生命周期管理误区

7. 共享账号普遍

• 多个开发/运维共用同一个数据库账号
• 出事后无法审计到人

8. 临时账号长期化

• 排查问题开了一个临时高权限账号
• 忘了关，成为长期后门

9. 离职/转岗不回收权限

• 人员变动后权限残留
• 尤其是第三方外包、临时合作方

四、技术实现类误区

10. 只控制“连接层”，不控制“数据层”

• 能连上数据库 ≠ 能访问某张表/某行/某列
• 缺少：
  • 行级权限（Row-Level Security）
  • 列级脱敏（如手机号、身份证）

11. 忽略视图 / 存储过程带来的权限绕过

• 通过视图间接访问敏感表
• 存储过程内部以定义者权限执行，绕过调用者权限

12. 审计形同虚设

• 开了审计但没人看
• 只记录“连接成功”，不记录“执行了什么 SQL”
• 日志不可篡改能力缺失

五、应用层与数据库协同误区

13. 把权限控制全放在应用里

• 数据库本身“大门敞开”
• 应用一有漏洞，数据库直接暴露

14. SQL 拼接 + 高权限账号

• 注入风险直接转化为数据库破坏风险
• 正确做法：参数化 + 低权限 + 白名单

六、云与新技术环境下的误区

15. 云服务“托管即安全”

• 用了 RDS / 云数据库就忽视访问控制
• IAM、VPC、数据库白名单配置错误很常见

16. 忽略动态数据和静态数据区别

• 访问控制只管“在线访问”
• 备份、导出、快照缺乏同等控制

总结一句话

数据库访问控制最大的误区，是把它当成“账号密码问题”，而不是“谁、在什么场景、能看什么数据、能做什么操作、是否被记录”的系统工程。

如果你愿意，我也可以：

• 按 MySQL / PostgreSQL / Oracle / SQL Server 分别讲常见误区
• 或结合你们当前架构，做一次「访问控制体检清单」