在 GBase 8c 里做权限治理，我更倾向先把角色边界拆清楚，而不是给用户直接发权限

我最近看 GBase 8c 的一些权限管理资料时，一个感觉越来越明显：很多数据库权限问题，不是因为语法不会写，而是因为账号、角色、对象权限、默认权限、管理员边界从一开始就没拆清楚。上线初期图省事，往往是直接给业务用户发对象权限，或者干脆让几个公共账号共用一套高权限；短期看确实推进快，但到了后面，谁能建对象、谁能改权限、谁能查敏感表、谁该为一次误授权负责，边界都会越来越模糊。GBase 8c 本身有比较完整的用户、角色、权限体系，也支持三权分立、默认权限继承、对象级与列级授权，甚至还能配合行级访问控制来做更细的边界。真正落地时，这些能力更适合拿来做“最小权限治理”，而不是只当成几个 GRANT / REVOKE 命令。

从实际场景看，GBase 8c 的权限治理更适合按下面这条线去做：先定义管理员边界，再抽象业务角色，再把对象权限挂到角色上，最后用默认权限补齐后续新增对象的继承问题。 这样做的好处是，后面不管是新表上线、应用扩容、人员调整，还是审计追责，权限体系都不会越长越乱。GBase 8c 社区对这一点讲得很清楚：对象创建后，默认只有对象所有者或者系统管理员可以查询、修改、销毁对象并继续授权；如果希望其他用户使用对象，就应该向用户或角色授予必要权限，而不是把高权限账号长期直接暴露给业务。

一、先别急着授权，第一步应该先把“谁是什么身份”定义清楚

我自己理解下来，GBase 8c 里至少要把三个概念分开：

• 用户（User）：认证实体，用来登录数据库和执行操作；

• 角色（Role）：权限容器，用来承载一组可复用的能力；

• 权限（Privilege）：对数据库对象或系统能力的具体访问授权。

这个拆分非常重要。因为如果直接给“用户”发权限，最后通常会出现三种问题：

1）权限发散

同一类业务用户，本来应该共用一套读写边界，结果每个人手里都略有不同，后面谁多了什么、少了什么，越来越难核对。

2）新对象容易漏授权

今天表建好了记得 GRANT，明天新建一张表忘了授权，应用又开始报错。

3）人员变化时回收困难

用户离职、岗位变更，本来只该收掉角色关系，结果要一张张表去核查直接授权。

所以从治理角度看，我更倾向于把权限设计成这套关系：

用户只绑定角色，角色再绑定对象权限。

一个最简单的分层可以长这样：

这套结构看起来多了一层，但后面运维会轻很多。

二、GBase 8c 的权限不只是表级读写，很多边界其实在数据库、Schema 和函数层

社区对 GBase 8c 权限体系的说明比较完整。它支持的对象权限不只是表上的 SELECT、INSERT、UPDATE、DELETE，还包括 TRUNCATE、REFERENCES、ALTER、DROP、COMMENT、INDEX、VACUUM；同时数据库对象还可以有 CREATE、CONNECT、TEMPORARY、ALTER、DROP 等权限，Schema 还有 USAGE、CREATE 等控制项，函数对象则涉及 EXECUTE。另外，某些语义上看似“只改数据”的操作其实还依赖额外权限，比如 UPDATE、DELETE 通常也需要 SELECT 来先定位行，SELECT ... FOR UPDATE 还需要 UPDATE 权限。

这个点我个人比较在意，因为很多权限问题，表面看像“表没授权”，实际上根因在上面两层：

• 用户没有数据库的 CONNECT；

• 用户有表权限，但没有 Schema 的 USAGE；

• 应用要调用函数，却没给 EXECUTE。

所以我更常用的判断方式是：

真正落到线上时，这种分层视角比“给它补个 ALL PRIVILEGES”有用得多。

三、我更倾向先建业务角色，再决定谁能继承谁

GBase 8c 允许把角色授予其他角色或用户，并支持 WITH ADMIN OPTION 这种管理选项。也就是说，你可以把“权限使用者”和“权限分发者”分开处理。社区里对 GRANT role_name TO role_name ... [WITH ADMIN OPTION] 的说明就很明确。

从落地角度看，我更常把业务角色拆成三层：

1）只读角色

用于查询、报表、核对、审计只读访问。

2）读写角色

用于应用写入、修正状态、业务处理。

3）管理角色

用于对象维护、建表、建索引、必要的结构变更，但不直接给业务程序绑定。

示例我一般会这样写：

-- 角色层
CREATE ROLE app_read_role;
CREATE ROLE app_rw_role;
CREATE ROLE app_ddl_role;

-- 用户层
CREATE USER app_reader IDENTIFIED BY 'Example#2026';
CREATE USER app_writer IDENTIFIED BY 'Example#2026';
CREATE USER app_owner  IDENTIFIED BY 'Example#2026';

-- 绑定关系
GRANT app_read_role TO app_reader;
GRANT app_rw_role   TO app_writer;
GRANT app_ddl_role  TO app_owner;

然后再把对象权限挂到角色上，而不是直接挂给用户：

GRANT CONNECT ON DATABASE bizdb TO app_read_role, app_rw_role, app_ddl_role;
GRANT USAGE ON SCHEMA billing TO app_read_role, app_rw_role, app_ddl_role;

GRANT SELECT ON TABLE billing.settle_result TO app_read_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE billing.settle_result TO app_rw_role;
GRANT CREATE, USAGE ON SCHEMA billing TO app_ddl_role;

这套方式最大的好处，是后面账号调整只改绑定关系，不用重做对象授权。

四、默认权限这件事，在 GBase 8c 里特别值得早点用，不然后续新表会一直漏

我最近看资料时发现，GBase 8c 社区对 ALTER DEFAULT PRIVILEGES 专门做过场景实践。核心问题很典型：手工 GRANT 只能作用于已有对象，后续新建的表不会自动继承这些授权；解决思路就是通过默认权限，让未来新建对象也自动拥有预设访问边界。这个能力对共享 Schema、多团队协作、持续上线新表的环境特别有用。

这个点几乎是权限治理里最容易被忽略的一层。因为刚开始对象不多，大家手动授权还能撑住；等对象数量一上来，问题就会变成：

• 老表能查，新表不能查；

• 新表授权总靠人记忆；

• 某次变更窗口漏掉授权，业务半夜报警。

如果 Schema 里会持续建表，我更倾向于直接把默认权限补上：

ALTER DEFAULT PRIVILEGES IN SCHEMA billing
GRANT SELECT ON TABLES TO app_read_role;

ALTER DEFAULT PRIVILEGES IN SCHEMA billing
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_rw_role;

ALTER DEFAULT PRIVILEGES IN SCHEMA billing
GRANT USAGE, SELECT ON SEQUENCES TO app_rw_role;

这里更适合这样理解：

默认权限不是“省一次授权动作”，而是在给未来对象设边界。

这跟临时补 GRANT 的思路完全不一样。前者是在做制度化授权，后者更像事后修补。

五、三权分立更适合放在治理层看，不是所有环境都必须上，但高要求场景很值得用

GBase 8c 支持三权分立。社区的最新解析把这件事讲得很直白：它本质上是把原先单一的超级权限拆成彼此制衡的几条线，典型包括系统管理员（SYSADMIN）负责系统运维、安全管理员（CREATEROLE + POLADMIN）负责角色和安全策略边界等，从而避免“一权独大”。同时，普通权限管理文章也提到，默认情况下如果未开启三权分立，数据库系统管理员会具备和对象所有者相同的能力。

从实际场景看，我不认为所有环境都必须一上来就把三权分立开满。
但下面这几类环境，我会更认真评估：

• 金融、政企、运营商类高审计要求环境；

• 数据库管理员和安全管理员职责本来就分离的团队；

• 需要避免单个超级账号既管运维又能无限看数、改权、清痕迹的场景。

更直白一点说，如果一个环境里：

• 运维负责实例稳定；

• 安全团队负责账号和策略；

• 审计团队负责留痕和核查；

那三权分立的收益就会很明显。因为它不是“多几个角色名”，而是把责任边界从制度上落到系统里。

六、最小权限不是“权限越少越好”，而是“刚好够做这件事”

这个概念说起来简单，真正落到现场时最容易被误用。

我自己理解下来，最小权限有两个常见误区：

1）图省事，直接给大权限

比如给应用账号直接发 ALL PRIVILEGES，或者干脆让多个程序共用高权限账号。
短期看部署快，后面一旦误删、误改、越权访问，边界就全没了。社区也明确提到，ALL PRIVILEGES 是一次性赋予对象全部可赋予权限，且系统管理员才有权执行 GRANT ALL PRIVILEGES。

2）抠得太细，导致系统难运维

比如只给 UPDATE 不给 SELECT，结果应用在更新前定位数据时就报权限不足；
或者只给表权限，不给 Schema 的 USAGE，最后对象存在但还是访问不了。

所以“最小权限”更适合按动作链来设计：

这套组合看起来比“一把梭全给”更麻烦一点，但后期稳定性会高很多。

七、别把权限治理只理解成 SQL 语法，连接入口本身也是权限边界的一部分

GBase 8c 官方文档里在数据库使用和连接部分提到，客户端接入数据库前，需要配置认证方式、listen_addresses 和 pg_hba.conf，远程接入控制本身就是数据库安全的一部分；而管理员指南也把“直接手改 pg_hba.conf 导致客户端连不上”列为高危操作之一，强调要严格按手册和工具方式处理。

这个点我个人比较在意，因为很多权限问题并不发生在对象层，而是发生在“入口层”：

• 哪些 IP 能连；

• 哪些用户能连某个库；

• 认证方式是不是合规；

• 是否还残留临时放开的信任配置。

所以真正做治理时，我更倾向把权限边界分成两层：

1. 接入边界：谁能从哪里进来；

2. 对象边界：进来以后能看什么、改什么。

如果只做后者，不做前者，权限体系还是会留很大口子。

八、我更常用的一套 GBase 8c 权限治理顺序

如果把前面的内容压成一套更实战的顺序，我一般会这么做。

第一步：把管理员职责拆开

先决定是不是需要三权分立，至少也要把系统运维、权限管理、审计核查这几类职责分开。默认未开启三权分立时，系统管理员能力边界会更大，这一点要先想清楚。

第二步：按岗位设计角色，不按人设计权限

比如：

• finance_read_role

• finance_rw_role

• finance_ddl_role

• ops_audit_role

这样后面人变了，角色模板不用变。

第三步：先发数据库和 Schema 级权限，再发对象权限

至少把 CONNECT 和 USAGE 这两层先补齐，再做表、视图、函数授权。

第四步：把默认权限补上

尤其是会持续新增表、序列、函数的 Schema，尽量别靠人工补授权。ALTER DEFAULT PRIVILEGES 非常值得尽早用。

第五步：尽量不直接给用户发对象权限

用户只挂角色，角色承载权限。这样清晰、可复用，也方便审计。

第六步：把接入控制一起纳入治理

数据库对象权限之外，还要检查连接入口配置是不是和权限策略一致。

九、我更认可的一种结论：权限体系一旦一开始偷懒，后面会用很多次补丁去还债

我自己理解下来，GBase 8c 的权限能力本身并不弱。它支持对象级、列级、函数级、数据库级、Schema 级授权，支持角色复用、默认权限继承，也支持三权分立这种更偏治理层的能力。问题通常不在“数据库做不到”，而在于项目一开始没把权限当成结构性设计，而是当成几条上线前补一补的 SQL。

真正落到现场，我更看重的是下面这几件事：

• 业务用户是不是只拿到了完成工作所需的那一层权限；

• 新对象上线以后，权限能不能自动延续，不靠人记；

• 管理员边界是不是分得清，不让一个账号什么都能做；

• 接入控制和对象权限是不是同一套治理思路。

如果这几层都能压住，权限治理就不会只是“某个人今天查不到表”的临时修补，而会慢慢变成一套长期稳定的数据库边界。
这种事情平时看起来不显山不露水，真正到事故、追责、交接、合规检查的时候，差距会特别明显。

参考资料

[1] 南大通用GBase 8c用户、角色、权限体系详解
https://www.gbase.cn/community/post/8134

[2] 南大通用GBase 8c SQL语法之权限管理
https://www.gbase.cn/community/post/4896

[3] 南大通用GBase 8c数据库权限管理场景实践
https://www.gbase.cn/community/post/6117

[4] 南大通用GBase 8c三权分立功能解析
https://www.gbase.cn/community/post/6949

[5] 数据库使用 | GBASE南大通用
https://www.gbase.cn/docs/gbase-8c/03%20%E5%BC%80%E5%8F%91%E8%80%85%E6%8C%87%E5%8D%97/%E6%95%B0%E6%8D%AE%E5%BA%93%E4%BD%BF%E7%94%A8

[6] 高危操作 | GBASE南大通用
https://www.gbase.cn/docs/gbase-8c/02%20%E7%AE%A1%E7%90%86%E5%91%98%E