openGauss作为新一代自治安全数据库，提供了丰富的数据库基础安全能力，并逐步完善各类高阶安全能力。这些安全能力涵盖了访问登录认证、用户权限管理、审计与追溯及数据安全隐私保护等。本章节将围绕openGauss安全机制进行源码解读，以帮助数据库内核开发者在进行内核开发时正确的理解和使用安全功能接口，持续为产品提供安全保护能力，或基于当前安全能力进一步开发新的安全能力。

1 openGauss安全整体架构

不同于数据库其他业务模块，安全管理模块并非逻辑集中的。安全管理模块中的安全能力是分散化的，在数据库整个业务逻辑的不同阶段提供对应的安全能力，从而构建数据库整体纵深安全防御能力。一个完整的安全管理整体架构如图1下所示：

图1 openGauss安全机制体系

虽然整个安全机制是分散化的，但是每一个安全子模块都独立负责了一个完整的安全能力。如安全认证机制模块主要解决用户访问控制，登录通道安全问题；用户角色管理模块解决用户创建及用户权限管理问题。因此整体的安全管理体系架构的代码解读也将根据整个体系的划分来进行描述。

认证机制子模块从业务流程上看主要包括认证配置文件管理、用户身份识别、口令校验等过程，其核心流程及接口定义如图2所示。

图2 openGauss安全认证代码接口

用户角色管理子模块从业务流程上看主要包括角色创建、修改、删除、授权和回收，由于openGauss并未严格区分用户和角色，因此用户的管理与角色管理共用一套接口，仅在部分属性上进行区分。角色管理子模块涉及的功能及其对应的接口如图3所示。

图3 openGauss角色管理代码接口

对象访问控制子模块从业务流程看主要包括对象授权、对象权限回收以及实际对象操作时的对象权限检查，其核心流程及接口定义如图4所示。

图4 openGauss对象权限管理代码接口

审计机制子模块主要包括审计日志的创建和管理，以及数据库的各类管理活动和业务活动的审计追溯。审计日志管理包括新创建审计日志、审计日志轮转、审计日志清理。审计日志追溯包括活动发生时的日志记录以及审计信息查询接口，其核心流程及接口定义如图5所示。

图5 openGauss审计线程(左)及审计日志记录(右)接口

2 安全认证

安全认证是数据库对外提供的第一道防线，数据库访问者只有完成身份识别，通过认证校验机制，才可以建立访问通道从事数据库管理活动。在整个安全认证过程中，涉及到用户身份管理识别、用户口令安全存储以及完善的认证机制3大模块，下面的小节将围绕这3个子模块进行涉及原理介绍和代码解析。

2.1 身份标识

安全认证机制要解决的核心问题是谁可以访问数据库的问题。因此在定义身份时，除了描述谁，还要清晰定义整个过程中哪个用户以何种方法访问、从何处访问，访问哪个数据库的问题，因此本小节重点介绍身份识别概念及源码。

身份识别是一个广义的概念，实际上定义了数据库系统的访问规则。openGauss的访问规则信息主要被记录在配置文件HBA（Host-Based Authentication File，主机认证）中，HBA文件中的每一行代表一个访问规则，其书写格式如下：

hostssl   DATABASE USER ADDRESS METHOD [OPTIONS]

其中第1列代表套接字方法，第2列代表允许被访问的数据库，第3列代表允许被访问的用户，第4列代表允许访问的IP地址，第5列代表访问的认证方式，第6列则作为对第五列认证信息的补充。在定义访问规则时，需要按照访问的优先级来组织信息。对于访问需求高的规则建议写在前面。

在openGauss源码中，定义了存储访问规则的关键数据结构HbaLine，核心元素如下所示：

typedef struct HbaLine

其中，字段conntype，database，roles，hostname以及auth_method分别对应HBA配置文件中的套接字方法、允许被访问的数据库、允许被访问的用户，IP地址以及当前该规则的认证方法。

当系统管理员配置完HBA文件后，配置文件被存放在数据库服务端侧。当某个用户通过数据库用户发起认证请求时，连接相关的信息都存放在关键数据结构Port中，如下所示：

typedef struct Port {

其中Port结构中的user_name、database_name、raddr以及对应的hba等字段就是认证相关的用户信息、访问数据库信息以及IP地址信息。与此同时Port结构中还包含了SSL认证相关的信息以及节点间做Kerberos认证相关的信息。有了Port信息，后台服务线程会根据前端传入的信息与HbaLine中记录的信息逐一比较，完成对应的身份识别。完整的身份标识过程见函数check_hba()，其核心逻辑如下所示：

/**扫描hba文件，寻找匹配连接请求的规则项 */

2.2 口令存储

口令是安全认证过程中的重要凭证。openGauss数据库在执行创建用户或修改用户口令操作时，会将口令通过单向哈希方式加密后存储在pg_authid系统表中。口令加密的方式与参数password_encryption_type的配置有关，目前系统支持md5、sha256 + md5（同时存储sha256和md5哈希值）和sha256三种方式，默认采用sha256方式加密。为兼容PostgreSQL社区和第三方工具，openGauss保留了md5方式，此方式安全性较低不推荐用户使用。

口令的加密方式与认证方式密切相关，选择不同的加密方式需要对应的修改pg_hba.conf中的认证方式。口令加密与认证方式对应关系如下表所示：

表1. 口令加密与认证方式

password_encryption_type

加密方式

（hash算法）

认证方式

（pg_hba.conf）

加密函数接口

0

md5

md5

pg_md5_encrypt

1

sha256 + md5

sha256或md5

calculate_encrypted_combined_password

2（默认值）

sha256

sha256

calculate_encrypted_sha256_password

创建用户和修改用户属性的函数入口分别为CreateRole和AlterRole。在函数内对口令加密前，会先校验是否满足口令复杂度，如果满足则调用calculate_encrypted_password函数实现口令的加密。加密时根据参数password_encryption_type配置选择对应的加密方式，加密完成后会清理内存中的敏感信息并返回口令密文。口令加密流程如下图6所示：

图6 口令加密流程图

如图9-6所示，通过调用calculate_encrypted_sha256_password函数实现sha256加密方式，通过调用pg_md5_encrypt函数实现md5方式，而calculate_encrypted_combined_password函数则融合了前面两种加密方式，加密后系统表中包含了sha256和md5两种哈希值。实现sha256加密的calculate_encrypted_sha256_password函数执行流程如图7所示。

图7 calculate_encrypted_sha256_password函数执行流程

2.3 认证机制

整个认证过程中，身份标识完成后，需要完成最后的认证识别。通过用户名和密码来验证数据库用户的身份，判断其是否为合法用户。openGauss使用基于RFC5802协议的口令认证方案，该方案是一套包含服务器和客户端双向认证的用户认证机制。

首先，客户端知道用户名username和密码password，客户端发送用户名username给服务端，服务端检索相应的认证信息，例如:salt、StoredKey、ServerKey和迭代次数。然后，服务端发送盐值salt和迭代次数给客户端。接下来，客户端需要进行一些计算，给服务端发送ClientProof认证信息，服务端通过ClientProof对客户端进行认证，并发送ServerSignature给客户端。最后，客户端通过ServerSignature对服务端进行认证。具体秘钥计算如下所示：

SaltedPassword := Hi(password, salt, iteration_count) 其中，Hi()本质上是PBKDF2。

具体秘钥衍生过程如图8所示。

图8 秘钥衍生过程

服务器端存的是StoredKey和ServerKey：

StoredKey是用来验证客户端用户身份。

服务端认证客户端通过计算ClientSignature与客户端发来的ClientProof进行异或运算，从而恢复得到ClientKey，然后将其进行HMAC（Hash-based Message Authentication Code，散列信息认证码）运算，将得到的值与StoredKey进行对比，如果相等，证明客户端验证通过。其中ClientSignature通过StoredKey和token（随机数）进行HMAC计算得到。

ServerKey是用来向客户端表明自己身份的。

类似的，客户端认证服务端，通过计算ServerSignature与服务端发来的值进行比较，如果相等，则完成对服务端的认证。其中ServerSignature通过ServerKey和token（随机数）进行HMAC计算得到。

在认证过程中，服务端可以计算出来ClientKey，验证完后直接丢弃不必存储。

防止服务端伪造认证信息ClientProof，从而仿冒客户端。

接下来详细描述在一个认证会话期间的客户端和服务端的信息交换过程。如图9所示：

图9 openGauss认证流程

客户端发送username。

服务端返回盐值salt、iteration-count(迭代次数)、ServerSignature以及随机生成的字符串token给客户端。token是随机生成字符串。服务端通过计算得到的ServerSignature返回给客户端。

ServerSignature := HMAC(ServerKey, token)

客户端认证服务端并发送认证响应。响应信息包含客户端认证信息ClientProof。ClientProof证明客户端拥有ClientKey，但是不通过网络的方式发送。在收到信息后，计算ClientProof。

客户端利用salt和iteration-count，从password计算得到SaltedPassword，然后通过图9中的公式计算得到ClientKey、 StoryKey和ServerKey。

客户端通过StoredKey和token进行哈希计算得到ClientSignature：

ClientSignature := HMAC(StoredKey,token)

通过将ClientKey和ClientSignature进行异或得到ClientProof：

ClientProof := ClientKey XOR ClientSignature

将计算得到的ClientProof和第2步接收的随机字符串发送给服务端进行认证。

服务端接收并校验客户端信息。

使用其保存的StoredKey和token通过HMAC算法进行计算，然后与客户端传来的ClientProof进行异或，恢复ClientKey，再对ClientKey进行哈希计算，得到的结果与服务端保存的StoredKey进行比较。如果相等，则服务端对客户端的认证通过。否则，认证失败。

ClientSignature := HMAC(StoredKey, token)
HMAC(ClientProof XOR ClientSignature ) = StoredKey

客户端认证的过程通过调用ClientAuthentication函数完成，该函数只有一个类型Port的参数，Port结构中存储着客户端相关信息。完整的客户端认证过程见函数ClientAuthentication ()，如下所示：

void ClientAuthentication(Port* port)

在这个ClientAuthentication函数中，通过调用函数hba_getauthmethod，然后调用check_hba函数，检查客户端地址、所连接数据库、用户名在文件HBA中是否有能匹配的HBA记录。如果能够找到匹配的HBA记录，则将Port结构中相关认证方法的字段设置为HBA记录中的参数，同时状态值为STATUS_OK。然后，根据不同的认证方法，进行相应的认证过程。具体认证方法如表2。在认证过程中可能需要和客户端进行多次交互。最后返回如果为STAUS_OK，则表示认证成功，并将认证成功的信息发送回客户端，否则发送认证失败的信息。

表2 认证方法

认证方法

值

描述

uaReject

0

无条件的拒绝连接

uaTrust

3

无条件的允许连接，这个方法允许被该HBA记录匹配的客户端直接连入数据库。

uaMD5

5

要求客户端提供一个MD5加密口令进行认证。

uaSHA256

6

要求客户端提供SHA256加密口令进行认证。

uaGSS

7

通过GSSAPI认证用户。

接下来介绍客户端认证服务端并发送认证响应。客户端根据不同的认证方法进行不同的处理过程，当前方法为AUTH_REQ_SHA256时，通过调用函数pg_password_sendauth完成对服务端的认证，如下所示：

static int pg_password_sendauth(PGconn* conn, const char* password, AuthRequest areq)

2.4 Kerberos安全认证

Kerberos是一种基于对称秘钥技术的身份认证协议，开源组件Kerberos可以解决集群内节点或者进程之间的认证问题，即当开启kerberos之后，恶意用户无法仿冒集群内节点或进程来登录数据库系统，只有内部组件才可以持有用于认证的凭证，从而保证通过Kerberos认证，消减了仿冒风险，提升了数据库系统的安全性。Kerberos协议具体交互如图10所示。

图10 Kerberos认证标准交互流程

其中各角色和定义如下，为下文描述方便，均以缩写代替：

表3 Kerberos协议角色

KDC（Key Distribution Center）

Kerberos服务程序

Client

需要访问服务的用户（principal），KDC和Service会对用户的身份进行认证

Service

集成了Kerberos的服务，被访问的服务，需要对客户端进行认证

AS(Authentication Service，认证服务)

AS服务器用于身份的校验, 内部会存储所有的账号信息

TGS(Ticket Granting Service，票据授权服务)

TGT（Ticket-Granting Ticket）票据分发服务

openGauss可在数据库系统部署完毕之后开启Kerberos模式，即Kerberos服务部署在数据库系统机器上，部署过程中会开启Kerberos相关的服务，并派发凭证给集群内部所有的节点，初始化一系列Kerberos需要用到的环境变量，数据库内核中通过调用GSS-API来实现Kebreros标准协议的通信内容，下面给出在Kerberos开启后openGauss内部进程之间认证流程，以openGauss主备之间的认证为例:

图11 数据库系统Kerberos认证流程

Kerberos提供用户(数据库管理员)透明的认证机制，数据库管理员无需感知Kerberos进程/部署情况。分两部分描述Kerberos交互，左侧虚线框内的Kerberos协议实现部分由OM（Operations Management，运维管理模块）工具完成，OM工具在Kerberos初始化的时候将KDC服务拉起（krb5kdc进程），其内置了两个服务：AS和TGS服务，客户端(openGauss主备等数据库服务进程）在登录对端之前会先和KDC交互拿到TGT（Ticket Granting Ticket，根凭证），这个步骤由OM拉起的定时任务调用Kerebros提供刷新票据工具来实现，默认24小时重新获取1次。这个获取TGT的过程对应Kerberos标准协议中AS-REQ、AS-REP、TGS-REQ和TGS-REP。

在数据库内核侧，主要是图12右侧虚线框内的AP-REQ流程实现，简化流程如图12所示。

图12 数据库系统内核认证交互

数据库内核封装GSS-API提供数据结构和API实现认证交互，关键数据结构如下：

?????typedef struct GssConn {int sock;gss_ctx_id_t gctx;        // GSS 上下文gss_name_t gtarg_nam;   // GSS 名称gss_buffer_desc ginbuf;   // GSS 输入tokengss_buffer_desc goutbuf;  // GSS 输出token
} GssConn; 
// 客户端、服务端接口, 用于封装标准kerberos协议调用, 其中客户端接口用于向服务端
// 发起访问，同时响应服务端接口GssServerAuth发起的票据请求
int GssClientAuth(int socket, char* server_host);
int GssServerAuth(int socket, const char* krb_keyfile);

图13 数据库内核Kerberos认证时序图

具体交互逻辑时序如图13所示。

• 首先服务端通过数据库配置文件决定使用Kerberos协议对客户端连接进行认证。

• 然后发起认证请求，客户端准备需要Kerberos认证的环境和票证，发’P’报文响应请求并发送票证。

• 服务端验证通过后会发送响应’R’报文，完成Kerberos认证。

以上内容从安全整体架构与安全认证两方面，对高斯数据库的高安全性能进行了详细解读，下篇我们将从角色权限方面继续介绍高斯数据库的高安全技术，敬请期待~