PostgreSQL 9.5 - 行级安全/ROLE 最佳实践
Posted
技术标签:
【中文标题】PostgreSQL 9.5 - 行级安全/ROLE 最佳实践【英文标题】:PostgreSQL 9.5 - Row level security / ROLE best practices 【发布时间】:2016-04-07 06:38:26 【问题描述】:我正在努力掌握在支持 Web 应用程序的多租户数据库中使用新行级安全功能的最佳方法。
目前,应用程序有几个不同的角色可用,具体取决于它尝试采取的操作。
一旦应用程序使用自己的 ROLE 建立连接,应用程序就会将身份验证参数(由用户提供)传递给不同的函数,这些函数会根据用户提供的身份验证参数过滤掉行。该系统旨在与成千上万的用户一起使用,并且似乎可以正常工作;然而,它显然很笨重(而且很慢)。
看来,如果我想使用新的行级安全功能,我需要为每个真实世界的用户(不仅仅是网络应用程序)创建一个新的角色来访问数据库。
这是正确的吗?如果是这样,在数据库中创建数千个 ROLE 是否是个好主意?
更新来自 a_horse_with_no_name 在 cmets 中的链接(感谢,该线程是正确的):
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
是在哪里定义的?
【问题讨论】:
postgresql.org/message-id/56840D1A.8030203@gmail.com @a_horse_with_no_name - 成功了,谢谢;但是,线程中给出的示例有点神秘......我已经更新了问题。 它是用于“配置”参数。为此使用它们本质上是一种“黑客行为”。您无需事先定义它们 - 这可以动态完成。注意current_setting('app_name.app_user')
如果之前没有定义参数会导致错误。为了防止这种情况,你可以在postgresql.conf
中定义一个虚拟值
为了完整起见,还有一个ACL extension 用于细粒度权限integrates with row level security。有no need to use ROLE。
【参考方案1】:
基于会话设置设置安全策略是一个BAD BAD BAD 的想法(我讨厌 CAPS 和 bold,所以相信我,我是认真的)。 任何用户都可以SET SESSION 'app_name.app_user' = 'bob'
,所以一旦有人发现“app_name.app_user”是大门(相信我,他们会的),那么您的整个安全措施就会被排除在外。
我看到的唯一方法是使用您的webadmin
可访问的表,该表仅存储会话令牌(想到uuid
类型,为了便于使用,转换为text
)。 login()
函数是SECURITY DEFINER
(假设所有者webadmin
),设置令牌以及会话SET
ting,然后由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
之外的任何人都无法检索。
【讨论】:
这并不完全准确。可以为给定角色指定策略,因此,在您的示例中,可以仅为“webadmin”角色创建策略,然后设置“app_name.app_user”GUC 只会影响该角色发出的查询。这可能足以满足您的安全要求,也可能不够,但它会阻止“任何用户”通过更改 GUC 来访问表中的任何记录。当然,这确实需要使用“webadmin”角色的应用程序正确验证用户并且没有 SQL 注入错误。 2nd Quadrant 提供了使用加密签名以用户无法绕过的方式管理授权的示例。以上是关于PostgreSQL 9.5 - 行级安全/ROLE 最佳实践的主要内容,如果未能解决你的问题,请参考以下文章
CentOS 7 安装配置使用 PostgreSQL 9.5
如何在 docker 上更改 postgreSQL 9.5 的时区?