PostgreSQL 9.5 - 行级安全性/ ROLE最佳实践

我想要掌握在支持Web应用程序的多租户数据库中使用新行级安全功能的最佳方法.

目前,该应用程序有几个不同的ROLE可用,具体取决于它尝试采取的操作.

一旦应用程序使用自己的ROLE建立连接,应用程序就会将身份验证参数(由用户提供)传递到不同的函数中,这些函数根据用户提供的身份验证参数筛选出行.该系统旨在与成千上万的用户合作,它似乎工作; 然而,它是狡猾的(而且很慢).

似乎如果我想使用新的行级安全功能,我需要为每个真实世界用户(不仅仅是Web应用程序)创建一个新的ROLE来访问数据库.

它是否正确？如果是这样,在数据库中创建数千个ROLE是一个好主意吗？

---

从评论中的a_horse_with_no_name链接更新(谢谢,该线程是正确的):

CREATE USER application;

CREATE TABLE t1 (id int primary key, f1 text, app_user text);
INSERT INTO t1 VALUES(1,'a','bob');
INSERT INTO t1 VALUES(2,'b','alice');
ALTER TABLE t1 ENABLE ROW LEVEL SECURITY;
CREATE POLICY P ON t1 USING (app_user = current_setting('app_name.app_user'));
GRANT SELECT ON t1 TO application;

SET SESSION AUTHORIZATION application;

SET app_name.app_user = 'bob';

SELECT * FROM t1;

 id | f1 | app_user
----+----+----------
  1 | a  | bob
(1 row)

SET app_name.app_user = 'alice';
SELECT * FROM t1;

 id | f1 | app_user
----+----+----------
  2 | b  | alice
(1 row)

SET app_name.app_user = 'none';
SELECT * FROM t1;

 id | f1 | app_user
----+----+----------
(0 rows)

现在,我很困惑,current_setting('app_name.app_user')因为我的印象只是配置参数......在哪里app_name定义？

1> Patrick..：

---

根据会话设置设置安全策略是一个坏不好的想法(我讨厌CAPS和粗体所以相信我,我的意思是).任何用户都可以SET SESSION 'app_name.app_user' = 'bob',所以一旦有人发现"app_name.app_user"是门(信任我,他们会),那么你的整个安全就会出现.

我看到的唯一方法是使用一个webadmin只能访问哪些商店会话令牌的表(我uuid想到了类型,text为了易于使用而转换为类型).该login()函数是SECURITY DEFINER(假设所有者webadmin),设置令牌以及会话SETting,然后由(或具有适当的权限)所拥有的表webadmin引用该表及其策略中的会话设置.

不幸的是,您不能在此使用临时(会话)表,因为您无法在临时表上构建策略,因此您必须使用"真实"表.这是一个性能损失的东西,但权衡与黑客的损害......

在实践中:

CREATE FUNCTION login (uname text, pwd text) RETURNS boolean AS $$
DECLARE 
  t uuid;
BEGIN
  PERFORM * FROM users WHERE user = uname AND password = pwd;
  IF FOUND THEN
    INSERT INTO sessions SET token = uuid_generate_v4()::text, user ....
       RETURNING token INTO t;
    SET SESSION "app_name.token" = t;
    RETURN true;
  ELSE
    SET SESSION "app_name.token" = '';
    RETURN false;
  END IF;
END; $$ LANGUAGE plpgsql STRICT;

现在您的政策将链接到sessions:

CREATE POLICY p ON t1 FOR SELECT
  USING (SELECT true FROM sessions WHERE token = current_setting('app_name.token'));

(因为uuids可能被认为是唯一的,不需要LIMIT 1.排序或其他魔法,如果uuid表中的策略将通过,否则失败.)uuid无法猜测(在你的生命中,无论如何)并且不可能通过除了webadmin.

---

[第二象限](http://blog.2ndquadrant.com/application-users-vs-row-level-security/)提供了使用加密签名以用户无法绕过的方式管理授权的示例.