17370845950

SQL权限控制须遵循最小权限原则，按角色分层授权，精确到列与行，写操作严格隔离，禁用高危语句，并定期审计回收闲置权限。

SQL权限控制的核心是“按需赋权”，不是谁都能用SELECT，更不能让业务账号拥有DROP TABLE能力。最小权限原则不是限制开发，而是守住数据安全的底线——只给完成任务所必需的权限，不多一分，不少一厘。

按角色分层授权，不按人头授予权限

直接给用户账号赋权容易失控，应先抽象出稳定的角色（如report_reader、order_writer、admin_backup），再把权限赋予角色，最后把角色分配给用户。这样权限变更只需调整角色定义，无需逐个修改用户。

• 建角色：CREATE ROLE report_reader;
• 授查询权（仅指定库表）：GRANT SELECT ON sales.orders TO report_reader;
• 绑定用户：GRANT report_reader TO 'bi_user'@'%';

精确到列与行，避免“全表可读”惯性

敏感字段（如身份证、手机号、薪资）默认不可见；高频但低敏字段（如订单号、状态）才开放。MySQL 8.0+ 支持列级权限，PostgreSQL 可通过视图+行级策略（RLS）实现行级过滤。

• MySQL 列级示例：GRANT SELECT(order_id, status, amount) ON sales.orders TO 'app_user'@'%';
• PostgreSQL 行级示例：为user_id = current_setting('app.current_user_id')自动加WHERE条件，用户查不到他人数据

写操作严格隔离，禁用高危语句默认权限

INSERT/UPDATE/DELETE必须限定在明确业务场景下，且禁止跨表批量更新。所有DROP、TRUNCATE、ALTER类操作一律禁止授予应用账号，仅DBA通过审批流程临时启用。

• 写权限只给具体表：GRANT INSERT, UPDATE(status, remark) ON sales.orders TO 'order_service'@'10.20.%';
• 用存储过程封装复杂逻辑，权限只给执行过程（EXECUTE），不放开底层表写权限
• 应用连接字符串中禁止使用root或sa等超级账号

定期审计与自动回收，权限不“一劳永逸”

权限不是设完就结束。每月扫描未登录超90天的账号、长期未使用的角色、超出业务范围的权限组合。可用脚本自动比对“当前权限”和“最小权限清单”，标记异常项。

• MySQL 查闲置账号：SELECT user, host FROM mysql.user WHERE password_last_changed
• 生成权限报告：SELECT grantee, table_schema, table_name, privilege_type FROM role_table_grants WHERE role_name = 'report_reader';
• 新员工入职：仅继承预置角色，不复制他*限

最小权限不是靠感觉判断，而是靠角色定义、列/行约束、操作白名单和周期审计四层落地。做得细，风险才真的可控。