GaussDB(DWS)数据库用户权限设计与管理

举报
半岛里有个小铁盒 发表于 2024/01/09 20:46:53 2024/01/09
【摘要】 本文将介绍DWS基于RBAC(Role-Based Access Control,基于角色的访问控制)的数据库用户权限管理。简单地说,一个用户拥有若干角色,每一个角色拥有若干权限。这样,就构造成“用户-角色-权限”的授权模型。在这种模型中,用户与角色之间,角色与权限之间,一般是多对多的关系。

GaussDB(DWS)数据库用户权限设计与管理

1. 前言

  • 适用版本:【8.1.3及以上】

  本文将介绍DWS基于RBAC(Role-Based Access Control,基于角色的访问控制)的数据库用户权限管理。简单地说,一个用户拥有若干角色,每一个角色拥有若干权限。这样,就构造成“用户-角色-权限”的授权模型。在这种模型中,用户与角色之间,角色与权限之间,一般是多对多的关系。

2. 对象基本概念

  集群: 集群是由一组服务器和其它资源组成的一个单独的系统,可以实现高可用性。有的情况下,可以实现负载均衡及并行处理。

  数据库: 数据库是存储在一起的相关数据的集合,这些数据可以被访问,管理以及更新。一套集群包含一个或多个已命名数据库。

  用户和角色: 用户和角色在整个集群范围内是共享的,但是其数据并不共享。即用户可以连接任何数据库,但当连接成功后,任何用户都只能访问连接请求里声明的那个数据库。

  模式: 数据库对象集,包括逻辑结构,例如表、视图、序、存储过程、同义名、索引、集群及数据库链接。

  表: 表是由行与列组合成的。每一列被当作是一个字段。每个字段中的值代表一种类型的数据。

它们之间的关系如下:

  集群中可以创建多个库,库与库之间物理隔离,集群中的用户和角色是唯一并且全局共用的,访问库的权限通过用户进行控制,同一个库中,schema是唯一的,不同schema下可以创建同名表,表与表之间通过schema进行区分,不同用户之间的数据访问通过权限控制进行隔离,不同用户间表的访问权限通过用户进行维护,通过角色进行权限统一管理,一个用户下可创建不同schema区别不同的业务模块,通过不同用户提供给不同业务使用。

  使用CREATE USER和ALTER USER可以创建和管理数据库用户。数据库集群包含一个或多个已命名数据库。用户和角色在整个集群范围内是共享的,但是其数据并不共享。即用户可以连接任何数据库,但当连接成功后,任何用户都只能访问连接请求里声明的那个数据库。

  非三权分立下,DWS用户帐户只能由系统管理员或拥有CREATEROLE属性的安全管理员创建和删除。三权分立时,用户帐户只能由初始用户员和安全管理员创建。

  在用户登录DWS时会对其进行身份验证。用户可以拥有数据库和数据库对象(例如表),并且可以向用户和角色授予对这些对象的权限以控制谁可以访问哪个对象。除系统管理员外,具有CREATEDB属性的用户可以创建数据库并授予对这些数据库的权限。

  角色是一组用户的集合。通过GRANT把角色授予用户后,用户即具有了角色的所有权限。推荐使用角色进行高效权限分配。例如,可以为设计、开发和维护人员创建不同的角色,将角色GRANT给用户后,再向每个角色中的用户授予其工作所需数据的差异权限。在角色级别授予或撤消权限时,这些更改将作用到角色下的所有成员。

  Schema又称作模式。通过管理Schema,允许多个用户使用同一数据库而不相互干扰,可以将数据库对象组织成易于管理的逻辑组,同时便于将第三方应用添加到相应的Schema下而不引起冲突。

  每个数据库包含一个或多个Schema。数据库中的每个Schema包含表和其他类型的对象。数据库创建初始,默认具有一个名为public的Schema,且所有用户都拥有此Schema的权限。可以通过Schema分组数据库对象。Schema类似于操作系统目录,但Schema不能嵌套。

  相同的数据库对象名称可以应用在同一数据库的不同Schema中,而没有冲突。例如,a_schema和b_schema都可以包含名为mytable的表。具有所需权限的用户可以访问数据库的多个Schema中的对象。

3. 角色、用户与用户组

  • 角色(ROLE)本质上是一组权限的集合,通常情况下使用ROLE来组织权限,使用用户进行权限的管理和业务操作。

  • 角色之间的权限可以继承,用户组的所有用户可自动继承对应角色的权限。

  • 数据库中USER与ROLE的关系为,USER的权限来自于ROLE。

  • 用户组包含了具有相同权限的用户集合。

  • 用户可以看作是具有登录权限的角色。

  • 角色可以看作是没有登录权限的用户。

  根据不同业务场景需要,管理员使用 “管控面”创建并管理不同用户组。用户组通过绑定角色获取操作权限,用户加入用户组后,可获得用户组具有的操作权限。用户组同时可以达到对用户进行分类并统一管理多个用户。最大支持5000个用户组(包括系统内置用户组)。

  DWS提供的权限包括“管控面”和各组件的操作维护权限,在实际应用时需根据业务场景为各用户分别配置不同权限。为了提升权限管理的易用性,“管控面”引入角色的功能,通过选取指定的权限并统一授予角色,以权限集合的形式实现了权限集中查看和管理。

  这样一方面对普通用户屏蔽了内部的权限管理细节,另一方面对管理员简化了权限管理的操作方法,提升了权限管理的易用性和用户体验。

  集中权限管理中权限、角色和用户的关系例如下图所示。

  DWS提供多种权限,根据业务场景实际需要选择指定的权限授予不同角色,可能是一个或者多个权限对应一个角色。

  • 角色A:授予操作权限A和B,用户A和用户B通过分配角色A取得对应的权限。

  • 角色B:授予操作权限C,用户C通过分配角色B取得对应的权限。

  • 角色C:授予操作权限D和F,用户C通过分配角色C取得对应的权限。

  通过GRANT把角色授予用户后,用户即具有了角色的所有权限。推荐使用角色进行高效权限分配。只对自己的表有所有权限,对其他用户放在属于各自模式下的表无权限。

4. 基于角色的权限管理模型

  • 系统中的权限:
    系统权限:系统规定用户使用数据库的权限。
    对象权限:在表、序列、函数等数据库对象上执行特殊动作的权限。

  • 借助角色机制:
    当给一组权限相同的用户授权时,不需对这些用户逐一授权。
    通过将角色付给一个用户可是的该用户拥有这个角色中的所有权限。
    一个用户可以属于不同的角色,拥有不同角色的权限。

  • 普通模式下:
    数据库管理员和业务用户(只读用户、只写用户、读写用户)

说明:
在角色机制下,角色被视为一个数据库用户或者一组数据库用户。
数据库用户主要用途是连接数据库、访问数据库对象和执行SQL语句。
通常使用ROLE来组织权限,使用用户进行实际用户操作。
角色之间的权限可以继承,用户组的所有用户自动继承角色的权限。

5. 权限种类及对象列表

5.1 角色权限与对象权限

  • 角色是权限的集合,权限限制了用户的行为

  • 通过为用户分配角色,限定用户的权利范围

  • 使用角色管理权限,更加有效

  • 使用角色管理其所有用户权限,更加统一

  • 角色可以被派生(开启资源管控,层级两层)

  • 角色的对象权限集合可以被继承,系统权限无法继承

5.2 涉及权限的数据库对象

  数据库(DATABASE)、用户(USER)、模式(SCHEMA)、表(TABLE)、函数(FUNCTION)、表空间(TABLESPACE)、类型(TYPE)、角色(ROLE)

类别
标志
INSERT ‘a’
SELECT ‘r’
UPDATE ‘w’
DELETE ‘d’
TRUNCATE ‘D’
CREATE ‘C’
CONNECT ‘c’
TEMPORARY ‘T’
EXECUTE ‘X’
USAGE ‘U’

5.3 查看对象权限

通过系统表字段查看对象权限变化:

  1. 用户mytbl1为用户along1所拥有的表,且表along2对mytbl1有select®查询权限。
#select relname,relacl from pg_class where relname = 'mytbl1';
 relname |                 relacl                 
---------+-----------------------------------------
 mytbl1  | {along1=arwdDxt/along1,along2=r/along1}
  1. 将mytbl1的插入权限赋给along2。
# grant insert on along1.mytbl1 to along2;
  1. 查看到用户along2已经拥有了对mytbl1的insert(a)权限。
# select relname,relacl from pg_class where relname = 'mytbl1';
 relname |                  relacl                 
---------+------------------------------------------
 mytbl1  | {along1=arwdDxt/along1,along2=ar/along1

6. 权限管理

6.1 权限机制

  数据库对象创建后,进行对象创建的用户就是该对象的所有者。集群安装后的默认情况下,未开启三权分立,数据库系统管理员具有与对象所有者相同的权限。也就是说对象创建后,默认只有对象所有者或者系统管理员可以查询、修改和销毁对象,以及通过GRANT将对象的权限授予其他用户。

  为使其他用户能够使用对象,必须向用户或包含该用户的角色授予必要的权限。

  DWS支持以下的权限:SELECT、INSERT、UPDATE、DELETE、TRUNCATE、REFERENCES、CREATE、CONNECT、EXECUTE和USAGE。不同的权限与不同的对象类型关联。可以使用GRANT。

  要撤消已经授予的权限,可以使用REVOKE。对象所有者的权限(例如ALTER、 DROP、GRANT和REVOKE)是隐式的,无法授予或撤消。即只要拥有对象就可以执行对象所有者的这些隐式权限。对象所有者可以撤消自己的普通权限,例如,使表对自己以及其他人只读。

  系统表和系统视图要么只对系统管理员可见,要么对所有用户可见。标识了需要系统管理员权限的系统表和视图只有系统管理员可以查询。

6.2 系统管理员

  系统管理员是指具有SYSADMIN属性的帐户。集群安装后,默认情况下系统管理员具有与对象所有者相同的权限。

  集群安装过程中自动生成的帐户称为初始用户。初始用户也是系统管理员,其拥有系统的最高权限,能够执行所有的操作。该帐户与进行集群安装的操作系统用户omm同名。

  初始用户会绕过所有权限检查。建议仅将此初始用户作为DBA管理用途,而非业务应用。

6.3 系统权限与对象权限

  权限表示用户访问某个数据库对象的操作是否被允许,数据库对象包括表、函数、模式、序列等等,操作包括:创建、增、删、改、查等等。权限是用户对一项功能的执行权利,在DWS中,根据系统管理方式的不同,可将权限分为系统权限与对象权限两类。

6.3.1 系统权限

  数据库系统特定操作的能力,系统权限又称为用户属性,包括SYSADMIN、CREATEDB、CREATEROLE、AUDITADMIN和LOGIN。

  系统权限一般通过CREATE/ALTER ROLE语法来指定。其中,SYSADMIN权限可以通过GRANT/REVOKE ALL PRIVILEGE授予或撤销。但系统权限无法通过ROLE和USER的权限被继承,也无法授予PUBLIC。

查看特殊系统表权限
权限作用
能否GRANT/REVOKE
SYSADMIN 查看特殊系统表权限
CREATEDB 创建数据库DATABASE
CREATEROLE 创建用户与角色
AUTITADMIN 是否可以查看审计日志
LOGIN 是否有连接数据库权限

6.3.2 对象权限

  数据库对象操作的能力,如SELECT、INSERT、UPDATE、DELETE等。
  对象权限可以有对象所有者或者管理员通过GRANT/REVOKE对其他角色分配或撤销。

6.4 授权操作

  对象权限管理主要通过GRANT/REVOKE赋予或收回用户/角色在某个对象上的权限,PUBLIC特质为所有角色赋权
  权限操作示例:
  示例1: 将系统权限授权给用户或者角色。
  创建名为joe的用户,并将sysadmin权限授权给他。

CREATE USER joe PASSWORD 'Bigdata123@';
GRANT ALL PRIVILEGES TO joe;

  授权成功后,用户joe会拥有sysadmin的所有权限。

  示例2: 将对象权限授权给用户或者角色。

  1. 撤销joe用户的sysadmin权限,然后将模式tpcds的使用权限和表tpcds.reason的所有权限授权给用户joe。

注:将Schema中的表或者视图对象授权给其他用户或角色时,需要将表或视图所属Schema的USAGE权限同时授予该用户或角色。否则用户或角色将只能看到这些对象的名字,并不能实际进行对象访问。

REVOKE ALL PRIVILEGES FROM joe;
GRANT USAGE ON SCHEMA tpcds TO joe;
GRANT ALL PRIVILEGES ON tpcds.reason TO joe;

  授权成功后,joe用户就拥有了tpcds.reason表的所有权限,包括增删改查等权限。
2. 将tpcds.reason表中r_reason_sk、r_reason_id、r_reason_desc列的查询权限,r_reason_desc的更新权限授权给joe。

GRANT select (r_reason_sk,r_reason_id,r_reason_desc),update (r_reason_desc) ON tpcds.reason TO joe;

  授权成功后,用户joe对tpcds.reason表中r_reason_sk,r_reason_id的查询权限会立即生效。
3. 如果joe用户需要拥有将这些权限授权给其他用户的权限,可以通过以下语法对joe用户进行授权。

GRANT select (r_reason_sk, r_reason_id) ON tpcds.reason TO joe WITH GRANT OPTION;
  1. 将数据库postgres的连接权限授权给用户joe,并给予其在postgres中创建schema的权限,而且允许joe将此权限授权给其他用户。
GRANT create,connect on database postgres TO joe WITH GRANT OPTION;
  1. 创建角色tpcds_manager,将模式tpcds的访问权限授权给角色tpcds_manager,并授予该角色在tpcds下创建对象的权限,不允许该角色中的用户将权限授权给其他人。
CREATE ROLE tpcds_manager PASSWORD 'Bigdata123@';
GRANT USAGE,CREATE ON SCHEMA tpcds TO tpcds_manager;
  1. 将表空间tpcds_tbspc的所有权限授权给用户joe,但用户joe无法将权限继续授予其他用户。
CREATE TABLESPACE tpcds_tbspc RELATIVE LOCATION 'tablespace/tablespace_1';
GRANT ALL ON TABLESPACE tpcds_tbspc TO joe;

  示例3: 将用户或者角色的权限授权给其他用户或角色。

  1. 创建角色manager,将joe的权限授权给manager,并允许该角色将权限授权给其他人。
CREATE ROLE manager PASSWORD 'Bigdata123@';
GRANT joe TO manager WITH ADMIN OPTION;
  1. 创建用户senior_manager,将用户manager的权限授权给该用户。
CREATE ROLE senior_manager PASSWORD 'Bigdata123@';
GRANT manager TO senior_manager;
  1. 撤销权限,并清理用户。
REVOKE manager FROM joe;
REVOKE senior_manager FROM manager;
DROP USER manager;

6.5 权限规划

6.5.1 系统最小授权规划原则

步骤 描述 规划原则
1 规划系统权限 默认情况下,只有系统管理员具备系统权限。在数据库安装成功后,可以使用系统管理员给其他用户分配系统权限。从安全性考虑,系统权限应该分别赋予可信赖的用户。
2 规划对象权限 对象权限的规划比较灵活,系统管理员可以将某些数据库对象的所有权限赋予某个用户,也可以将某些数据库对象的部分权限(比如:SELECT权限和UPDATE权限等)分别赋予不同的用户。
3 规划角色 在实际工作中,如果有两个以上的用户具有相同的对象权限,则建议将这几个用户规划为一个角色,并将这些权限赋予此角色。
4 赋予用户权限 根据以上规划
通过语句CREATE/ALTER USER将系统权限赋予指定用户。
通过语句GRANT/REVOKE将对象权限赋予指定用户。

6.5.2 权限授予使用建议

1) 权限授予最小化,只需要SELECT权限的不需要授予其他权限。
2) 不要为了方便随便授予ALL PRIVILEGES权限。
3) 谨慎授予可能改变表内容的操作(update、insert)等权限。
4) 管理好权限周期,超过时间及时使用REVOKE回收权限。

7. 业务用户权限示例

7.1 业务操作权限

步骤1: 先建一个角色

create role data_mgr password 'Gauss_234';

步骤2: 登陆schema所属的用户u2赋予角色data_mgr对所属schema s2的使用权限以及所有表的数据操作权限

  • 赋予角色data_mgr对s2的使用权限
grant USAGE,CREATE on schema s2 to data_mgr;
  • 角色data_mgr对u2已创建的表赋予查询权限
grant SELECT,insert,delete,update on all tables in schema s2 to data_mgr;
  • 角色data_mgr对u2以后创建的新表赋予查询权限
alter default privileges in schema s2 grant SELECT,insert,delete,update on tables to data_mgr;

7.2 只读操作权限

步骤1: 创建只读角色

create role read_only  password 'Gauss_234';

步骤2: 登陆schema所属的用户u2赋予角色 read_only 对schema s1和s2的使用权限以及所有表的查询权限

  • 赋予角色read_only对s1,s2的使用权限
grant USAGE on schema s1,s2 to read_only;
  • 角色read_only拥有对s1,s2已创建的表赋予查询权限
grant SELECT on all tables in schema s1,s2 to read_only;
  • 角色read_only拥有对s1,s2以后创建的新表赋予查询权限
alter default privileges in schema s1,s2 grant SELECT on tables to read_only; 

7.3 赋权操作

  • 给用户u1赋予对用户u2的schema s2的数据操作权限。
grant data_mgr to u1;
  • 给用户u3赋予对用户u2的schema s1和s2的只读权限。
grant read_only to u3;

7.4 权限回收操作

7.4.1 角色的权限回收

  • 回收角色data_mgr对s2的使用权限
revoke USAGE,CREATE on schema s2 from data_mgr;
  • 回收角色data_mgr对u2已创建的表查询权限
revoke SELECT,insert,delete,update on all tables in schema s2 from data_mgr;
  • 回收角色data_mgr对u2以后创建的新表赋予查询权限
alter default privileges in schema s2 revoke SELECT,insert,delete,update on tables from data_mgr;

7.4.2 用户的权限回收

  • 回收用户u1对u2的schema s2的数据操作权限
revoke data_mgr to u1;
  • 回收用户u3对u2的schema s1、s2的只读权限
revoke read_only from u3;

7.5 赋权与回收

  把当前用户下某个schema下的表的查询权限赋给其他用户,既需要把schema的usage权限给其他用户,也要赋予其他用户对于表的查询权限(可以指定特定表来赋权查询操作,也可以赋予一次性赋予所有表的查询权限)。
  对于将来新建表的查询权限想要一次性的赋予权限,则需要通过alter default privileges赋予默认权限来操作。
  回收权限的话,需要回收schema的usage权限,也要回收表的查询权限,还有回收默认权限。
  可以通过\ddp来查看默认赋权信息。

8 总结

  通过本文,可以系统了解DWS数据库权限管理相关知识,从而为数据库管理和业务开发提供技术支撑。通过更加有效和细致的权限管理,制定完善的数据安全机制,保证数据安全。

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。