SQL 数据库安全权限如何设计？

数据库权限应遵循最小必要原则，按业务角色与数据敏感度匹配，通过列级授权、角色抽象、连接层校验及审计日志实现纵深防护。

权限粒度必须按最小必要原则切分

数据库权限不是越粗越好，也不是越细越安全。关键在于业务角色和数据敏感度的匹配。比如财务系统里，accounting_report 视图只应授予财务分析员，而 payment_transaction 表的 INSERT 权限必须限制在支付服务账号下，不能开放给前端应用直接调用。

• 应用连接账号一律禁用 SELECT 或 DROP 等高危权限，只授其实际执行的 DML（如 INSERT/UPDATE）且限定到具体表或视图
• DBA 账号与应用账号严格分离，禁止复用；生产环境禁止使用 root 或 sa 连接应用
• 敏感字段（如身份证、手机号）建议用列级权限控制：GRANT SELECT (name, email) ON users TO analyst;，而非整表授权

避免 PUBLIC 默认权限带来的泄漏风险

很多团队没意识到，PostgreSQL 和 SQL Server 中新建对象默认会继承 PUBLIC 的 USAGE 或 SELECT 权限，MySQL 5.7+ 虽默认关闭，但初始化脚本若显式执行了 GRANT ... TO PUBLIC，就等于给所有人开了后门。

• 创建新 schema 后立即执行：REVOKE USAGE ON SCHEMA public FROM PUBLIC;（PostgreSQL）
• 检查现有对象是否被意外暴露：SELECT table_name, privilege_type FROM information_schema.role_table_grants WHERE grantee = 'PUBLIC';
• MySQL 中确认 sql_mode 包含 STRICT_TRANS_TABLES，并禁用 skip-grant-tables 配置项

动态权限管理要用角色（ROLE），别硬编码用户权限

直接对每个用户 GRANT 权限会导致后期维护爆炸：加一个新字段要改十几条 GRANT 语句，删一个离职员工要翻遍所有权限清单。用角色抽象是唯一可扩展的方式。

• 建立三层角色结构：app_reader → app_writer → app_admin，再把用户加入对应角色
• 权限变更只改角色定义，不碰用户：GRANT UPDATE ON orders TO app_writer;
• PostgreSQL 支持角色继承，SQL Server 用数据库角色，MySQL 8.0+ 才支持角色语法，老版本需靠脚本模拟

连接层权限校验比数据库层更关键

数据库权限只是最后一道防线。如果应用用同一个账号连接、靠代码拼 SQL 做“逻辑隔离”，那再细的 DB 权限也形同虚设——因为攻击者只要绕过前端校验，就能以该账号身份执行任意允许的操作。

• 应用必须使用连接池 + 专用账号，每个微服务/模块对应独立账号，且账号名能体现用途（如 svc_payment_w）
• 禁止在应用中拼接用户输入进 SQL，所有查询走预编译参数化语句（PreparedStatement）
• 数据库开启审计日志（如 PostgreSQL

  

  的 log_statement = 'mod'），重点监控 pg_authid 修改和跨 schema 查询

权限设计最麻烦的从来不是语法怎么写，而是业务边界是否清晰、变更流程有没有卡点、离职交接时账号是否真被回收。这些地方一漏，前面所有 GRANT 和 REVOKE 都白做。