7.4 用户与权限管理入门

7.4 用户与权限管理入门

本节摘要：数据库要管谁能连、能做什么。本节讲建用户、授权、最小权限原则。具体语法各 DBMS 差异较大，本节给通用思路和常见语法。

本节地图

阅读完本节，你应当能够：

1. 创建用户并设置密码
2. 授予和收回权限
3. 理解最小权限原则
4. 区分角色和直接授权

概念脉络

一、为什么需要权限管理

生产数据库不能让所有人用 root/admin 连——一旦误操作或被攻击，全库遭殃。权限管理让不同人只做自己该做的事：开发只读测试库、运维能改配置、报表只能查不能改。

二、创建用户

各 DBMS 语法不同，下面给常见例子。

-- MySQL
CREATE USER 'app_user'@'%' IDENTIFIED BY '强密码';

-- PostgreSQL
CREATE USER app_user WITH PASSWORD '强密码';

-- SQL Server
CREATE LOGIN app_user WITH PASSWORD = '强密码';
​

'%' 表示从任何主机可连，生产环境建议限定来源 IP（如 '10.0.0.5'）。

三、授权和收回

图 7-4 权限模型

-- MySQL 授权语法
GRANT SELECT, INSERT ON shop.Orders TO 'app_user'@'%';
GRANT ALL ON shop.* TO 'admin'@'10.0.0.5';
-- 收回
REVOKE INSERT ON shop.Orders FROM 'app_user'@'%';
-- 查看权限
SHOW GRANTS FOR 'app_user'@'%';

-- PostgreSQL
GRANT SELECT, INSERT ON orders TO app_user;
GRANT USAGE ON SCHEMA public TO app_user;
REVOKE INSERT ON orders FROM app_user;
​

四、最小权限原则

只授完成任务所需的最小权限，不多授：

• 报表用户只授 SELECT，不授写权限
• 应用账号只授本库所需权限，禁用 root/admin
• 能用角色批量管理就不用逐用户授权

五、角色管理

角色是一组权限的集合，授给用户后用户获得角色所有权限，比逐用户授权清晰。

-- PostgreSQL
CREATE ROLE readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly;
GRANT readonly TO report_user;

-- MySQL 8.0+
CREATE ROLE readonly;
GRANT SELECT ON shop.* TO readonly;
GRANT readonly TO report_user;
​

人员变动只需调整角色成员，不动权限定义，便于维护。

六、生产实践要点

• 应用账号和运维账号分开，应用账号只授本库所需
• 限定来源 IP，不开放到公网
• 密码强、定期轮换、不入代码库
• 定期审计权限，清理离职用户和多余授权
• 敏感操作（DROP、TRUNCATE）谨慎授权

⚠️ 常见坑：应用用 root/admin 连库——一旦应用被攻破，全库被拿。生产应用账号只授本库所需最小权限，限定来源 IP。

💡 关键直觉：权限管理管"谁能做什么"。最小权限原则只授完成任务所需权限，用角色批量管理。应用账号和运维账号分开，生产禁用 root/admin 直连。

重点提炼

• 目的：管谁能连、能做什么，避免误操作和攻击波及全库。
• 建用户：CREATE USER，设密码，限定来源 IP。
• 授权/收回：GRANT/REVOKE，可按库/表/列授权。
• 最小权限原则：只授完成任务所需权限，报表只读、应用账号限本库、禁用 root/admin。
• 角色：一组权限集合，授给用户批量管理，人员变动只调角色不动权限。
• 生产实践：应用/运维账号分开、限定 IP、强密码、定期审计。

本书到此结束。回顾全部七章：从 SQL 与数据库概览，到关系模型核心概念，到基础查询 SELECT，到高级查询技巧，到数据操作 DML，到数据定义 DDL，最后到管理与进阶。掌握这些，你已具备 SQL 基础能力，可上手常见查询和管理任务。

常见疑问

Q1：为什么不能用 root 连生产库？

root 拥有全部权限，一旦应用被入侵或代码写错（漏写 WHERE 的 UPDATE），破坏是全局的。最小权限原则：应用只用自己需要的账号（只能读某些表/写某些表），把风险隔离在业务范围内。这是数据库安全的第一课。

Q2：GRANT 和 REVOKE 的粒度能多细？

可以细到库、表、甚至列：GRANT SELECT(列1,列2) ON 表 TO 用户。还能控制 DDL/DML 分开授（只读、只写、读写）。权限设计原则：够用就好，按角色批量管理（角色=权限集合），避免逐用户堆权限。

Q3：密码怎么管才安全？

1. 不用弱口令、定期轮换；2) 密码别写进代码库，用环境变量或配置中心；3) 应用账号限定来源主机（app@10.0.0.%），不给全开放；4) 离职人员及时撤销。权限审计要定期做。

Q4：什么是最小权限原则？

只授予完成任务所必需的最小权限。报表账号只给 SELECT，写入账号只给对应表的 INSERT/UPDATE/DELETE，管理账号才给 DDL。权限宁缺毋滥，缺了可以补，滥了收不回来的是事故。

Q5：权限操作会影响现有连接吗？

一般不影响已建立的连接，新权限对之后连接生效。MySQL 里用 FLUSH PRIVILEGES 重新加载权限表（直接 GRANT/REVOKE 会自动生效）。理解"权限变更对新会话生效"即可。

Q6：数据备份和权限有关系吗？

有。备份账号是特权账号，更要最小化+监控；备份数据本身也含敏感信息，要加密和限制访问。权限管理不仅管"谁能操作库"，也管"谁能看备份"。安全是系统工程。

动手做一做

权限管理的概念不难，但值得动手操作一遍，建立真实体感。

第一步，用管理员账号创建一个测试用户，设置密码和允许连接的主机范围。

第二步，用这个新用户登录，尝试查询一张表，观察它默认有没有权限——通常会被告知没有权限，你就体会到了"权限默认关闭"的原则。

第三步，用管理员给这个用户授予指定表的查询权限，再切回新用户查询，观察权限生效的过程。

第四步，尝试用新用户做一次写入操作，观察它有没有写入权限，体会"最小权限"是怎么落地的。

第五步，收回刚才授予的权限，再看新用户还能不能查询，观察权限收回立即生效。

这五步做完，你对"创建用户、授权、收回、最小权限"这套流程会有直观认识。权限管理是数据库安全的基础，现在动手走一遍，将来管理真实环境才不会手忙脚乱。

一句话记忆

权限管理回答三个问题：谁能连、能做什么、做多细。最小权限原则是核心，应用账号只给业务所需权限，管理员账号单独管控，密码轮换和定期审计是配套动作。