PostgreSQL作为企业级开源数据库，常被用于承载核心业务数据。在部署和运维过程中，安全加固的重点往往落在网络隔离与密码策略上，而权限设计却容易被忽略。最小权限原则要求任何账号仅拥有执行业务所必需的最低权限，这在PostgreSQL里意味着要理清角色、schema与对象之间的授权链路，避免权限过度集中。
一、PostgreSQL权限模型基础
PostgreSQL使用基于角色的访问控制（RBAC），用户和组在内部都被称为角色（role）。一个角色可以拥有数据库对象，也可以通过GRANT命令将权限赋予其他角色。理解这一模型是实施最小权限的前提，因为很多过度授权正是源于对角色继承关系的误用。
在默认配置下，任何新建的角色会自动成为_public_角色的成员，而_public_通常在schema public中对表拥有CREATE和USAGE权限。这导致普通用户也能在public模式下建表，甚至读取其他用户创建的表。如果不显式回收这些默认权限，就违背了最小权限原则。我们可以通过ALTER DEFAULT PRIVILEGES与REVOKE命令重塑基线。
1.1 角色与组的区别
早期版本中LOGIN属性区分用户与组，现在统一为角色：带LOGIN的角色可连接，带INHERIT的角色继承父角色权限。利用NOINHERIT可以控制权限传递，适合临时高权场景。例如审计员角色平时无业务权限，仅在审查时切换并显式继承。
使用继承时要注意，子角色执行操作时以自身权限叠加父角色权限进行检查。如果父角色是超级用户，子角色虽不能登录但可通过SET ROLE获得全部控制权，因此永远不要把超级用户作为业务组的父角色。
二、最小权限的实施步骤
落地最小权限需要从账号分类、schema规划和细粒度授权三方面推进。先按业务职能划分只读、读写、管理三类角色，再为每个应用分配专属账号并归入对应组，最后收缩public模式的默认权限。
下面脚本展示了如何创建只读组并回收public模式权限，再将应用账号加入该组。注意REVOKE要针对特定schema，否则遗留权限仍会被利用。
-- 回收 public 在 public schema 的建表与使用权限 REVOKE CREATE ON SCHEMA public FROM PUBLIC; -- 创建只读角色组 CREATE ROLE app_readonly WITH NOLOGIN; -- 创建应用账号 CREATE ROLE app_user WITH LOGIN PASSWORD 'strong_password' IN ROLE app_readonly; -- 授权某张表给只读组 GRANT SELECT ON TABLE orders TO app_readonly; -- 禁止该账号修改数据 REVOKE INSERT, UPDATE, DELETE ON TABLE orders FROM app_user;
2.1 列级与行级控制
当某些字段如手机号、身份证需要特殊保护时，可使用列级GRANT只开放非敏感列。更进一步，PostgreSQL的行级安全（RLS）能限制用户只能访问特定条件的行，适合多租户系统。
开启RLS后，即便角色拥有表的SELECT权限，也必须通过策略函数过滤数据。以下示例限制用户仅看自己租户的数据：
ALTER TABLE tenant_data ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON tenant_data
USING (tenant_id = current_setting('app.tenant_id')::int);
三、常见误区与加固检查
一个典型误区是认为限制IP白名单就足够安全，实际上内部威胁与注入攻击可绕过网络层。另一个误区是给ETL账号超级用户权限，理由是方便建表，这应使用CREATEDB与特定schema授权替代。
建议定期运行权限审计查询，列出偏离最小权限的账号。如下语句可找出具有superuser属性的角色：
SELECT rolname FROM pg_roles WHERE rolsuper = true;
结合pg_privileges视图梳理每张表的授权情况，将结果纳入变更评审，才能保证加固持续有效。
四、总结
最小权限原则不是一次配置而是一套运维习惯。在PostgreSQL中，它通过角色分层、默认权限回收、列与行级控制实现数据面的收缩。把账号按职能隔离、杜绝超级用户滥发、周期性审计，才能构建经得起渗透测试的数据库环境。
PostgreSQL最小权限原则数据库安全修改时间：2026-08-10 12:27:32