数据库权限应遵循最小必要原则，按业务角色与数据敏感度匹配，通过列级授权、角色抽象、连接层校验及审计日志实现纵深防护。
权限粒度必须按最小必要原则切分
数据库权限不是越粗越好，也不是越细越安全。关键在于业务角色和数据敏感度的匹配。比如财务系统里，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 语句，删一个离职员工要翻遍所有权限清单。用角色抽象是唯一可扩展的方式。
该系统采用多层模式开发，这个网站主要展示女装的经营，更易于网站的扩展和后期的维护，同时也根据常用的SQL注入手段做出相应的防御以提高网站的安全性，本网站实现了购物车,产品订单管理，产品展示，等等，后台实现了动态权限的管理，客户管理，订单管理以及商品管理等等，前台页面设计精致，后台便于操作等。实现了无限子类的添加，实现了动态权限的管理，支持一下一个人做的辛苦
- 建立三层角色结构：
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 都白做。