共计 5099 个字符，预计需要花费 13 分钟才能阅读完成。
目录
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”能够在零碎中查问）：
CREATE ROLE role_name [[ WITH] option […] ] [ENCRYPTED | UNENCRYPTED] {PASSWORD | IDENTIFIED BY} {‘password’ | DISABLE};
其中设置子句 option 的选项能够是：
{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 信息来校验对象上存在的权限信息。根据理论对象的不同（如表、函数、语言），内核提供了不同的函数来实现对以后对象拜访权限的校验：
has_table_privilege_*_*(ARGS)
函数中的星号别离代表用户信息和数据库对象信息。依据 ARGS（泛指一个可变数量的参数列表）提取的诸如用户信息、表信息、须要校验的权限信息，而后根据 ACL 中记录的权限集与操作所需的权限集进行比对。如果 ACL 记录的权限集大于操作所需的权限集则 ACL 查看通过，否则失败。
当管理者对对象的权限进行受权 / 回收时，须要批改 ACL 中对应的权限信息，即在对应的权限标记位增加或删除指定的权限（权限对应的标记位被批改为 0 或者 1），实现对 ACL 的更新操作。须要留神的是，在理论权限操作中，应尽可能防止循环受权状况的产生。
未完待续 ……
