使用PostgreSQL函数实现数据库防护是否为有效方案？

这个方案是PostgreSQL生态里非常成熟的最小权限落地方案，可靠性足够，完全可以实现你预期的权限管控目标。

方案本身的安全优势 #

• 权限边界足够清晰：PostgreSQL函数支持SECURITY DEFINER属性，开启后函数执行时使用函数创建者的权限，调用函数的低权限用户不需要持有函数内部访问的表、序列、视图的任何读写、修改权限，刚好匹配你要求的「普通用户仅持有指定函数执行权、无其他数据库操作权限」的管控目标。
• 天然降低SQL注入风险：所有数据交互逻辑都固化在数据库侧的函数中，业务层、前端不需要拼接任何原生SQL，只需要传入参数调用对应函数即可，从根源上规避了SQL拼接带来的注入风险，权限管控粒度比常规ORM层的权限校验更细、更难被绕开。

落地必须注意的风险点，否则会留安全缺口 #

• 定义函数时必须硬编码固定search_path，不要使用默认的公共搜索路径，否则攻击者可以通过创建同名对象的方式劫持函数执行逻辑，建议函数定义末尾加上SET search_path = 你的专属业务schema, pg_temp的显式配置。
• 不要图省事给public角色批量授予所有函数的执行权限，要按业务角色的实际需求，单独给每个角色授予对应需要调用的函数的EXECUTE权限，严格拆分可调用的函数范围。
• 函数内部必须做严格的参数校验，尤其是涉及数据写入、结构变更的逻辑，不要信任任何传入的参数，避免函数本身的逻辑漏洞被利用提权。
• 如果要做schema防护，绝对不要给普通业务账号任何schema的CREATE、ALTER权限；涉及DDL的schema变更逻辑要单独封装为仅管理员可调用的专用函数，绝对不要开放给普通用户。

参考权限配置 #

你可以参考下面的SQL配置普通用户权限，实现预期的管控效果：

-- 回收普通用户在public schema下的默认权限
REVOKE ALL ON SCHEMA public FROM your_biz_user;
REVOKE ALL ON ALL TABLES IN SCHEMA public FROM your_biz_user;
REVOKE ALL ON ALL SEQUENCES IN SCHEMA public FROM your_biz_user;

-- 仅授予schema的基础usage权限，保证用户可以访问授权给他的对象
GRANT USAGE ON SCHEMA public TO your_biz_user;

-- 仅给用户授予需要调用的指定函数的执行权限
GRANT EXECUTE ON FUNCTION your_func1(arg_type1, arg_type2) TO your_biz_user;
GRANT EXECUTE ON FUNCTION your_func2(arg_type1) TO your_biz_user;

-- 回收public角色对系统表的默认读权限，避免用户查看未授权的表、函数定义
REVOKE SELECT ON pg_catalog.pg_proc FROM PUBLIC;
REVOKE SELECT ON pg_catalog.pg_class FROM PUBLIC;

注意：回收系统表读权限的操作需要提前在测试环境验证，部分数据库驱动可能需要读取少量系统表元数据才能正常建立连接，你可以按需给业务用户开放必要的系统表只读权限，不要直接全量开放。

这个方案在数据安全要求较高的金融、政务类PostgreSQL业务场景已经有多年落地实践，只要把上述提到的配置风险点规避掉，安全性远高于常规给业务账号直接开放表级增删改查权限的模式。

内容的提问来源于stack exchange，提问作者Dercni