前文回顾：
1.如何掌握openGauss数据库核心技术？秘诀一：拿捏SQL引擎（1）
2.如何掌握openGauss数据库核心技术？秘诀一：拿捏SQL引擎（2）
3.如何掌握openGauss数据库核心技术？秘诀一：拿捏SQL引擎（3）
4.如何掌握openGauss数据库核心技术？秘诀一：拿捏SQL引擎（4）
5.如何掌握openGauss数据库核心技术？秘诀二：拿捏执行器技术（1）
6.如何掌握openGauss数据库核心技术？秘诀二：拿捏执行器技术（2）
7.如何掌握openGauss数据库核心技术？秘诀三：拿捏存储技术（1）
8.如何掌握openGauss数据库核心技术？秘诀三：拿捏存储技术（2）
9.如何掌握openGauss数据库核心技术？秘诀三：拿捏存储技术（3）
10.如何掌握openGauss数据库核心技术？秘诀三：拿捏存储技术（4）
11.如何掌握openGauss数据库核心技术？秘诀三：拿捏存储技术（5）
12.如何掌握openGauss数据库核心技术？秘诀三：拿捏存储技术（6）
13.如何掌握openGauss数据库核心技术？秘诀三：拿捏存储技术（7）
14.如何掌握openGauss数据库核心技术？秘诀四：拿捏事务机制（1）
15.如何掌握openGauss数据库核心技术？秘诀四：拿捏事务机制（2）
16.如何掌握openGauss数据库核心技术？秘诀四：拿捏事务机制（3）
17.如何掌握openGauss数据库核心技术？秘诀四：拿捏事务机制（4）
18.如何掌握openGauss数据库核心技术？秘诀五：拿捏数据库安全（1）
19.如何掌握openGauss数据库核心技术？秘诀五：拿捏数据库安全（2）
目录
- openGauss数据库SQL引擎
- openGauss数据库执行器技术
- openGauss存储技术
- openGauss事务机制
- openGauss数据库安全
Ⅰ.openGauss安全机制概览
Ⅱ.openGauss安全认证
Ⅲ.openGauss角色管理机制
1.角色管理模型
2.三权分立模型
3.对象访问控制
Ⅳ.openGauss审计与追踪
Ⅴ.openGauss数据安全技术
Ⅵ.openGauss云安全技术
Ⅶ.openGauss智能安全机制
三.openGauss角色管理机制
数据库发展早期，访问控制通常可以分为自主访问控制（Discretionary Access Control，DAC）以及强制访问控制（Mandatory Access Control，MAC）。在自主访问控制模式下，用户是数据对象的控制者，用户依据自身的意愿决定是否将自己的对象访问权或部分访问权授予其他用户。而在强制访问控制模式下，对特定用户指定授权，用户不能将权限转交给他人。在实际应用中，DAC模式太弱，MAC又太强，且两者工作量较大，不便于管理。基于角色的访问控制机制（Role-Based Access Control，RBAC）是一种更加灵活的机制，可以作为传统访问控制机制（DAC、MAC）的代替，也是较为有效的管理方法。
openGauss数据库继承了业界目前通用的权限管理模型，实现了基于角色的访问控制机制。整个机制中的核心概念是“角色”，其更深层次的含义是角色组，即角色所拥有的权限实际上对应着这个角色组中所有成员的权限。管理员只需要将管理所希望的权限赋给角色，用户再从角色继承相应的权限即可，而无需对用户进行单一管理。当管理员需要增加和删减相关的权限时，角色组内的用户成员也会自动继承权限变更。
基于角色管理模型，用户可具备对对象的访问操作权限，并基于此完成数据管理。而这些用户所具备的权限是会经常发生变化的，为了有效的防止诸如权限提升、利用权限漏洞进行恶意操作等行为，必须进行权限的合理管控，即对象权限管理。更重要的是，需要在对象被访问操作时对当前用户的合法权限进行有效性检查，即对象权限检查。
角色管理模型
01
在openGauss内核中，用户和角色是基本相同的两个对象，通过CREATE ROLE和CREATE USER分别来创建角色和用户，两者语法基本相同。以CREATE ROLE的语法为例进行说明，其语法为（通过“h CREATE ROLE”可以在系统中查询）：
代码语言：javascript复制CREATE ROLE role_name [ [ WITH ] option [ ... ] ] [ ENCRYPTED | UNENCRYPTED ] { PASSWORD | IDENTIFIED BY } { 'password' | DISABLE };其中设置子句option的选项可以是：
代码语言：javascript复制 {SYSADMIN | NOSYSADMIN}
| {AUDITADMIN | NOAUDITADMIN} | {CREATEDB | NOCREATEDB}
| {USEFT | NOUSEFT} | {CREATEROLE | NOCREATEROLE}
| {INHERIT | NOINHERIT} | {LOGIN | NOLOGIN}
| {REPLICATION | NOREPLICATION} | {INDEPENDENT | NOINDEPENDENT}
| {VCADMIN | NOVCADMIN} | CONNECTION LIMIT connlimit
| VALID BEGIN 'timestamp' | VALID UNTIL 'timestamp'
| RESOURCE POOL 'respool' | USER GROUP 'groupuser'
| PERM SPACE 'spacelimit' | NODE GROUP logic_cluster_name
| IN ROLE role_name [, ...] | IN GROUP role_name [, ...]
| ROLE role_name [, ...] | ADMIN role_name [, ...]
| USER role_name [, ...] | SYSID uid
| DEFAULT TABLESPACE tablespace_name | PROFILE DEFAULT
| PROFILE profile_name | PGUSER该命令仅可由具备CREATEROLE或者超级管理员权限的用户执行。对语法中涉及的关键参数做如下说明：
§ ENCRYPTED | UNENCRYPTED
用于控制密码是否以密文形态存放在系统表中。目前该参数无实际作用，因为密码强制以密文形式存储。
§ SYSADMIN | NOSYSADMIN
决定一个新创建的角色是否为“系统管理员”，缺省为NOSYSADMIN。
与该参数具有相类似概念的还包括“AUDITADMIN | NOAUDITADMIN”、“CREATEDB | NOCREATEDB”以及“CREATEROLE | NOCREATEROLE”，分别表示新创建的角色是否具有审计管理员权限、是否具有创建数据库权限以及是否具有创建新角色的权限。
§ USEFT | NOUSEFT
决定一个新角色是否能操作外表，包括：新建外表、删除外表、修改外表和读写外表，默认为NOUSEFT。
§ INDEPENDENT | NOINDEPENDENT
定义私有、独立的角色。具有INDEPENDENT属性的角色，管理员对其进行的控制、访问的权限被分离，具体规则如下：
–未经INDEPENDENT角色授权，管理员无权对其表对象进行增、删、查、改、拷贝、授权操作。
–未经INDEPENDENT角色授权，管理员无权修改INDEPENDENT角色的继承关系。
–管理员无权修改INDEPENDENT角色的表对象的属主。
–管理员无权去除INDEPENDENT角色的INDEPENDENT属性。
–管理员无权修改INDEPENDENT角色的数据库口令，INDEPENDENT角色需管理好自身口令，口令丢失无法重置。
–管理员属性用户不允许定义修改为INDEPENDENT属性。
§ CONNECTION LIMIT
声明该角色可以使用的并发连接数量，默认值为-1，表示没有限制。
§ PERM SPACE
设置用户使用空间的大小。
CREATE USER语法与CREATE ROLE基本相同，option选项范围也相同。事实上，用户和角色在openGauss内部是基本相同的两个对象。区别在于：①创建角色时默认没有登录权限，而创建用户时包含了登录权限；②创建用户时，系统会默认创建一个与之同名的schema，用于该用户进行对象管理。因此在权限管理实践中，我们建议通过角色进行权限的管理，通过用户进行数据的管理。
管理员通过GRANT语法将角色赋给相应的用户可使该用户拥有角色的权限。而在实际场景中，一个用户可以从属于不同的角色，从而拥有不同角色的权限。同样角色之间的权限也可以进行相互传递。用户在继承来自于不同角色的权限时，应尽量避免权限冲突的场景，如某一用户同时具有角色A不能访问表T的权限和角色B访问表T的权限。
为了更清晰的描述权限管理模型，需要说明openGauss系统中的权限分为两种类型：系统权限和对象权限。系统权限描述了用户使用数据库的权限（如访问数据库、创建数据库、创建用户等）。对象权限，顾名思义描述了用户操作数据库对象的权限（如增删改查表对象、执行函数、使用表空间等）。
通过上述CREATE ROLE和CREATE USER的语法发现，在创建过程中，通过指定每一个options的值就可以设定该角色的属性。而这些属性事实上定义了该角色的系统权限，以及该角色登录认证的方式。这些属性包括是否具备登录权限（LOGIN）、是否为超级用户（SUPERUSER）、是否具备创建数据库的权限（CREATEDB）、是否具备创建角色的权限（CREATEROLE）、当前角色的初始口令信息（PASSWORD）以及是否可以继承其所属角色的权限的能力（INHERIT）。
角色所有的权限都记录在系统表pg_authid里面，通过对应的字段进行描述。如pg_authid表中对应的createrole字段用于标记当前角色是否拥有创建角色的权利。角色的这些系统属性实际上定义了用户使用数据库权限的大小。如所有具有CREATEROLE权限的角色都可以创建新的角色或用户。
在整个数据库系统中，安装部署的时候会创建一个初始化用户，该初始化用户拥有最高权限。我们也称初始化用户为系统的超级用户，这也是pg_authid表中唯一一个superuser字段为true的角色。
超级用户可以按照实际的业务诉求来创建普通用户，也可以通过其所创建的管理员来创建新的普通用户，再进行权限的管理。超级用户可以随时进行权限的赋予和撤回，也可以直接参与到实际的数据管理业务中。在单用户场景的作业管理模式中使用超级用户变得非常的高效。
三权分立模型
02
如第1小节所述，openGauss安装完成后会得到一个超级用户，具有最高权限。数据库超级用户的高权限意味着该用户可以做任何系统管理操作和数据管理操作，甚至修改数据库对象，包括下一章节将要介绍的审计日志信息。对于企业管理来说，手握超级用户权限的管理人员可以在无人知晓的情况下改变数据行为，这带来的后果是不可想象的。
在上一章第1小节提到，初始化用户不允许远程登录，仅可本地登录。那么在组织行为上由IT部门严格监控拥有该权限的员工在本地的操作行为，就可有效避免诸如修改表中数据等监守自盗行为的发生。为了实际管理需要，在数据库内部就需要其他的管理员用户来管理整个系统，如果将大部分的系统管理权限都交给某一个用户来执行实际上也是不合适的，因为这等同超级用户。
为了很好的解决权限高度集中的问题，在openGauss系统中引入三权分立模型，如图5所示。三权分立角色模型最关键的三个角色为安全管理员、系统管理员和审计管理员。其中安全管理员用于创建数据管理用户，系统管理员对创建的用户进行赋权，审计管理员则审计安全管理员、系统管理员、普通用户实际的操作行为。
图5 三权分立角色模型
通过三权分立角色模型实现权力的分派，且三个管理员角色独立行使权限，相互制约制衡。使得整个系统的权限不会因为权限集中而引入安全的风险。
事实上，产品使用过程中的安全是技术本身与组织管理双重保障的结果，在系统实现三权分立模型后，需要有三个对应的产品自然人分别握有对应的账户信息，以达到真正权限分离的目的。
对象访问控制
03
数据库里每个对象所拥有的权限信息经常发生变化，比如授予对象的部分操作权限给其他用户或者删除用户在某些对象上的操作权限。为了保护数据安全，当用户要对某个数据库对象进行操作之前，必须检查用户在对象上的操作权限。仅当用户对此对象拥有合法操作的权限时，才允许用户对此对象执行相应操作。
访问控制列表（Access Control List，ACL）是openGauss进行对象权限管理和权限检查的基础。在数据内部，每个对象都具有一个对应的ACL，在该ACL数据结构上存储了此对象所有的授权信息。当用户访问对象时，只有它在对象的ACL中并且具有所需的权限时才能访问该对象。当用户对对象的访问权限发生变更时，只需要在ACL上更新对应的权限即可。
事实上，ACL是内核中ACE(Access Control Entry，访问控制项)的集合，这些存储控制单元记录了授权者OID、受权者OID以及权限位三部分信息。其中，权限位是一个32位比特位整数，每一位标记一个具体的权限操作，如ACL_SELECT（第二个bit位信息）标记查询用户是否有对对象的查询权限。每一个ACE对应一个AclItem结构，记录了完整的对象访问用户和执行单元信息。
在openGauss内部，每一个对象都对应一个ACL，用户可以依据ACL信息来校验对象上存在的权限信息。依据实际对象的不同（如表、函数、语言），内核提供了不同的函数来实现对当前对象访问权限的校验：
代码语言：javascript复制 has_table_privilege_*_*(ARGS)函数中的星号分别代表用户信息和数据库对象信息。根据ARGS（泛指一个可变数量的参数列表）提取的诸如用户信息、表信息、需要校验的权限信息，然后依据ACL中记录的权限集与操作所需的权限集进行比对。如果ACL记录的权限集大于操作所需的权限集则ACL检查通过，否则失败。
当管理者对对象的权限进行授权/回收时，需要修改ACL中对应的权限信息，即在对应的权限标记位添加或删除指定的权限（权限对应的标志位被修改为0或者1），完成对ACL的更新操作。需要注意的是，在实际权限操作中，应尽可能避免循环授权情况的发生。
未完待续......
