权限管理的“三权分立”设计：从金仓数据库看企业级用户体系的构建逻辑
几年前帮一家企业做数据库权限体系梳理，发现一个有意思的现象：他们有一套几十个用户的数据库，权限配置却极其混乱。开发人员有DBA权限，运维人员能查业务数据，测试账号能访问生产库。问起来原因，回答出奇一致——“图省事，反正都是自己人”。
直到有一次，一个离职员工的账号被人恶意使用，删除了几张核心表，他们才意识到：权限管理从来不是“防自己人”，而是建立一套可预期的、可追溯的、可控的规则。
那次事故之后，我开始系统研究数据库的用户和权限管理体系。而金仓数据库在这方面的设计，给了我不少启发。
一、为什么说“权限管理”是数据库的灵魂？
在讨论具体技术之前，先想一个问题：我们为什么要管权限？
表面答案是“防止未授权访问”，但更深层的逻辑是：权限管理定义了系统内不同角色的责任边界。
一个健康的数据库系统，应该像一家运转良好的公司：每个人都有明确的职责，每个人只能访问自己职责范围内的资源，每个人的操作都能被追溯。当问题发生时，能快速定位是谁在什么时间做了什么。
这种设计理念，在数据库领域有个专门的术语——三权分立。
二、三权分立：打破超级用户的“全能神话”
传统数据库往往有一个“超级用户”——比如Oracle的SYS、MySQL的root。这个用户无所不能，可以创建用户、修改数据、查看审计日志、删除任何对象。
听起来很方便，但问题也在这里：权力过度集中，本身就是风险。
金仓数据库的安全版本引入了三权分立机制，将管理特权拆分为三个独立角色：
2.1 三权分立的三个核心角色
数据库管理员（system）
- 职责：执行数据库日常管理操作，如表创建、索引维护、性能调优
- 限制：不能修改审计参数，不能定义审计策略，不能查看审计记录
- 类比：公司的业务部门负责人，管业务，但不管财务审计
安全管理员（sso）
- 职责：制定强制访问规则，监督审计管理员和普通用户的操作
- 限制：不能创建和操作普通数据库对象
- 类比：公司的合规部门，定规则、监督执行，但不直接参与业务
审计管理员（sao）
- 职责：负责数据库审计，监督数据库管理员和安全管理员的操作
- 限制：不能进行安全功能的操作，不能创建普通对象
- 类比：公司的审计部门，查账、监督，不参与日常经营
这种设计的精妙之处在于：任何一个角色的权力都是不完整的，必须相互协作才能完成全部管理工作。数据库管理员想隐藏操作痕迹？审计管理员会记录。审计管理员想篡改记录？他没有数据库对象的操作权限。安全管理员想越权？他的操作同样会被审计。
2.2 角色的进一步细分
有意思的是，金仓在三权基础上还做了进一步细分。每个特权用户下面，又增加了对应的操作员和public角色：
-- 安全管理员（sso）下面有：
-- 安全操作员（sso_oper）：能管理安全配置，但不能创建、修改、删除安全用户
-- 安全public（sso_public）：只能查看安全配置，不能修改
这种设计考虑的是实际场景：不是所有需要查看安全信息的人，都应该有修改权限。查看和修改，是两个不同级别的操作。
三、受限DBA：当管理员也需要“被管理”
三权分立解决了权力分散的问题，但还有一个场景需要考虑：当DBA本身可能成为风险源时怎么办？
金仓提供了一个有趣的功能——受限DBA。
开启这个功能后，管理员的权限会变得和普通用户一样。也就是说，system用户也不能随意读取、修改不属于他的对象。
-- 由安全管理员开启受限DBA功能
\c - sso
ALTER system SET restricted_dba.restricted_enable = true;
SELECT sys_reload_conf();
开启后的效果是：
- system不能读取不属于它的表
- system不能修改其他用户的对象
- system的权限被限制在“自己拥有的资源”范围内
这个设计背后的理念是：即使是管理员，也应该遵循“最小权限原则”。只有在需要时才提升权限，平时以普通身份操作。
四、用户管理的实操细节
理论说完，来看点实际的。金仓的用户管理有几个值得注意的设计。
4.1 创建用户的资源限制
创建用户时，可以设置多种资源限制：
-- 设置连接数限制（最多100个并发连接）
CREATE USER app_user WITH CONNECTION LIMIT 100;
-- 设置密码有效期（2026年12月31日后密码失效）
CREATE USER temp_user WITH PASSWORD '123456' VALID UNTIL '2026-12-31';
-- 设置登录时间段（只能在9点到18点之间登录）
CREATE USER day_user WITH CONNECTION INTERVALS '09:00:00 TO 18:00:00';
-- 设置单次连接时长（每次连接最多30秒）
CREATE USER short_session WITH CONNECTION TIME 30;
这些限制在实际运维中很有用。比如给外包人员创建的临时账号，可以设置密码有效期；给批处理任务用的账号，可以限制连接数防止资源争抢；给查询分析用的账号，可以限制单次连接时长，避免长事务占用资源。
4.2 只读用户的特殊处理
金仓提供了一个系统存储过程，可以快速将用户设为只读状态：
-- 将u1用户设为只读
CALL alteruserreadonly('', 'u1', true);
-- 切换回正常状态
CALL alteruserreadonly('', 'u1', false);
只读状态下，用户不能执行CREATE、INSERT、UPDATE、DELETE等操作，但SELECT不受影响。这在需要临时限制用户权限的场景下非常有用，比如数据迁移期间的账号管控。
4.3 用户信息的查询
金仓提供了一系列系统视图，方便查询用户信息：
-- 查看所有用户
SELECT usename, usesysid, usecreatedb, usesuper FROM sys_user;
-- 查看当前会话信息
SELECT datname, pid, usename, query FROM sys_stat_activity;
-- 查看当前用户
SELECT current_user, session_user;
这些视图是日常运维的基础工具。比如要杀掉一个异常会话，可以先查到它的pid，然后用sys_terminate_backend函数终止。
五、角色管理的灵活设计
如果说用户是“具体的人”，角色就是“权限的集合”。把人分到角色里，把权限赋给角色，这种间接管理的方式，在用户量大的时候特别有用。
5.1 预定义角色
金仓提供了一些预定义角色，方便快速授权：
-- 查看所有配置变量
GRANT sys_read_all_settings TO analyst;
-- 查看统计信息
GRANT sys_read_all_stats TO monitor;
-- 执行监控函数
GRANT sys_monitor TO ops;
这些预定义角色覆盖了常见的监控和管理需求，不用自己从零定义权限集。
5.2 角色的启用和禁用
金仓有一个很实用的功能——可以临时禁用角色，而不删除它：
-- 加载插件
CREATE EXTENSION roledisable;
-- 查看角色状态
SELECT * FROM roledisable.sys_role_status;
-- 禁用r1角色
ALTER ROLE r1 DISABLE;
-- 启用r1角色
ALTER ROLE r1 ENABLE;
角色被禁用后，所有从该角色继承的权限都会失效。这在处理临时权限调整、排查权限问题时非常有用——不用删除重建角色，也不用修改用户的角色成员关系，只需禁用即可。
5.3 会话角色的切换
用户登录后，可以临时切换当前生效的角色：
-- 查看当前用户
SELECT session_user, current_user;
-- 切换到paul角色
SET ROLE 'paul';
-- 取消当前角色切换
SET ROLE NONE;
这个功能允许用户在同一个会话中，临时获得另一个角色的权限，执行完操作后再切回来。避免了频繁登录退出的麻烦。
六、权限管理的一个真实案例
最后分享一个实际项目中遇到的场景。
某金融客户的数据库里有三类用户：
- 应用账号：供业务系统使用，只能访问特定schema
- 运维账号：供DBA使用，需要查看系统状态、调整参数
- 审计账号：供合规部门使用，只能查看审计日志
他们最初的设计是：应用账号一个，所有应用共享；运维账号直接给DBA；审计账号直接给审计员。
问题很快出现：
- 应用账号密码泄露，无法追溯是哪个应用在用
- 多个DBA共用运维账号，操作记录分不清谁是谁
- 审计员想看数据，但账号只有查看审计日志的权限，需要DBA协助
解决方案是引入“用户-角色”分离：
- 每个应用创建独立用户，赋予同一个应用角色
- 每个DBA创建独立用户，赋予同一个运维角色
- 每个审计员创建独立用户，赋予同一个审计角色
这样既保持了权限的统一管理，又能区分具体操作人。当有人离职时，只需禁用他的个人账号，不影响其他人继续使用。
七、总结：权限管理的三层境界
回顾这些设计，可以把权限管理分为三个层次：
第一层：能管。能创建用户、能赋权、能收回。这是基本能力，所有数据库都有。
第二层：管得清。有清晰的职责划分、有完整的操作记录、有细粒度的权限控制。三权分立、角色细分、审计日志，都是为了让权限管理更清晰。
第三层：管得活。能临时禁用角色、能限制连接时间、能设置登录时间段。这些功能不是为了限制而限制，而是为了在保证安全的前提下，给日常运维更多灵活性。
金仓数据库在这三个层次都有对应的设计。三权分立解决了权力过度集中的问题，角色管理提供了权限复用的机制，用户资源限制则给了运维人员精细控制的能力。
说到底，权限管理不是为了“管人”，而是为了让系统的行为可预期、可追溯、可控。当出问题时，能快速定位；当需要调整时，能灵活应对；当安全合规要求时，能提供完整证据链。
这才是企业级数据库应有的设计。
更多关于数据库权限管理的技术细节和实践案例，欢迎访问金仓数据库官方技术博客：kingbase.com.cn
