Question

我想要掌握在支持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定义在哪里？

Answer 1

根据会话设置设置安全策略是 BAD BAD BAD 的想法（我讨厌CAPS和粗体所以相信我，我的意思是）。 任何用户都可以SET SESSION 'app_name.app_user' = 'bob'，所以只要有人发现“app_name.app_user”是门（信任我，他们会），那么您的整个安全就会出现。< / p>

我看到的唯一方法是使用只有webadmin可访问的表格才能存储会话令牌（uuid类型，转换为text以方便使用）。 login()函数为SECURITY DEFINER（假设所有者为webadmin），设置令牌以及会话SET，然后表所拥有（或具有适当的权限） for）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'));

（因为uuid s可能被认为是唯一的，所以不需要LIMIT 1。排序或其他魔法，如果uuid在策略将通过的表中，否则失败。）uuid是无法猜测的（无论如何都是在你的生命中）并且除webadmin之外的任何人都无法检索。

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

1 个答案: