共计 4069 个字符，预计需要花费 11 分钟才能阅读完成。
二.openGauss 平安认证
平安认证通道 03
首先 openGauss 反对 SSL 标准协议（TLS1.2），SSL 协定是安全性更高的协定规范，它们退出了数字签名和数字证书来实现客户端和服务器的双向身份验证，保障了通信单方更加平安的数据传输。
openGauss 在装置部署实现后，默认开启 SSL 认证模式。安装包中也蕴含了认证所须要的证书和密钥信息。这些证书由 CA 可信核心颁发。假设服务器的私钥为 server.key，证书为 server.crt，客户端的私钥为 client.key，证书为 client.crt，CA 根证书名称为 cacert.pem。这些证书信息寄存在“/home/ommdbadmin”目录。
须要阐明的是，集群装置部署实现后，服务端证书、私钥以及根证书均已默认配置实现。用户只须要配置客户端相干的参数。
-
配置客户端参数
客户端参数配置根据理论场景分为单向认证配置和双向认证配置，整个配置信息存储在客户端工具所在的环境配置文件中（如.bashrc 文件）。单向认证须要配置如下参数：export PGSSLMODE="verify-ca" export PGSSLROOTCERT="/home/ommdbadmin/cacert.pem"双向认证需配置如下参数：
export PGSSLCERT="/home/ommdbadmin/client.crt"
export PGSSLKEY="/home/ommdbadmin/client.key"
export PGSSLMODE="verify-ca"
export PGSSLROOTCERT="/home/ommdbadmin/cacert.pem"- 批改客户端密钥的权限
客户端根证书、密钥、证书以及密钥明码加密文件的权限，需保障为 600。如果权限不满足要求，则客户端无奈以 SSL 连贯到集群。
chmod 600 cacert.pem
chmod 600 client.key
chmod 600 client.crt
chmod 600 client.key.cipher
chmod 600 client.key.rand在理论利用中，应联合场景进行配置。从安全性思考，倡议应用双向认证形式，此时客户端的 PGSSLMODE 变量倡议设置为 verify-ca。但如果自身数据库处在一个平安的环境下，且业务场景属于高并发、低时延业务则可应用单向认证模式。
除了通过 SSL 进行平安的 TCP/IP 连贯外，openGauss 还反对 SSH 隧道进行平安的 TCP/IP 连贯。SSH 专为近程登录会话和其余网络服务提供安全性的协定。从 SSH 客户端来看，SSH 提供了两种级别的平安验证：
§ 基于口令的平安验证：应用帐号和口令登录到近程主机。所有传输的数据都会被加密，然而不能保障正在连接的服务器就是须要连贯的服务器。可能会有其余服务器假冒真正的服务器，也就是受到“中间人”形式的攻打。
§ 基于密钥的平安验证：用户必须为本人创立一对密钥，并把公钥放在须要拜访的服务器上。这种级别的认证不仅加密所有传送的数据，而且防止“中间人”攻击方式。然而整个登录的过程可能须要 10 秒。
在理论执行过程中，SSH 服务和数据库服务应运行在同一台服务器上。
RFC5802 认证协定 04
在理论利用过程中，仅仅选定认证办法是不够的，还须要用一套残缺的认证机制。这个机制要能够很好的解决客户端和服务端认证交互过程中的通信危险，还要解决客户端接管到加密口令后的验证问题。
openGauss 目前选用规范的 RFC5802 认证机制来解决相干问题。它实际上是 SCRAM（Salted Challenge Response Authentication Mechanism）规范流程中的协定。SCRAM 是一套蕴含服务器和客户端双向确认的用户认证体系，配合信道绑定能够防止中间人攻打。上面咱们将着重介绍该协定内容。
§ 首先，客户端晓得用户名 username 和明码 password，客户端发送用户名 username 给服务端，服务端检索相应的认证信息，例如：salt、StoredKey、ServerKey 和迭代次数 i（留神，服务端可能对于所有的用户都是用雷同的迭代次数）。而后，服务端发送盐值 salt 和迭代次数 i 给客户端。
§ 接下来，客户端须要进行一些计算，给服务端发送 ClientProof 认证信息，服务端通过 ClientProof 对客户端进行认证，并发送 ServerSignature 给客户端。
§ 最初，客户端通过 ServerSignature 对服务端进行认证。
具体密钥计算公式如下：
SaltedPassword := Hi (password, salt, i) 其中，Hi()实质上是 PBKDF2。
ClientKey := HMAC(SaltedPassword, “Client Key”)
StoredKey := Hash(ClientKey)
AuthMessage := client-first-message-bare + “,” +
server-first-message + “,” +
client-final-message-without-proof
ServerKey := HMAC(SaltedPassword, “Server Key”)
其中：
§ AuthMessage 通过连贯认证替换的信息来计算的。
§ client-first-message-bare 次要蕴含客户端给服务端发送的用户名 username 和随机字符串 C -Nonce。
§ server-first-message 次要是盐值 salt、迭代次数 i 以及随机生成的字符串 Nonce。
§ client-final-message-without-proof 不蕴含认证信息 ClientProof，蕴含随机字符串 Nonce。
具体密钥衍生过程如图 3 所示。
图 3 密钥衍生过程
在这里，服务器端存的是 StoredKey 和 ServerKey。
§ StoredKey 是用来验证 Client 客户身份，服务端认证客户端。通过计算 ClientSignature 与客户端发来的 ClientProof 进行异或运算，从而复原失去 ClientKey，而后将其进行 hash 运算，将失去的值与 StoredKey 进行比照。如果相等，证实客户端验证通过。
§ ServerKey 是用来向客户端表明本人身份的，客户端认证服务端。通过计算 ServerSignature 与服务端发来的值进行比拟，如果相等，则实现对服务端的认证。
在认证过程中，服务端能够计算出来 ClientKey，验证完后间接抛弃不用存储。避免服务端伪造认证信息 ClientProof，从而仿冒客户端。要做到非法的登录，必须晓得 Password、SaltedPassword 或者 ClientKey。如果 StoryKey 和 ServerKey 泄露，无奈做到非法登录。
图 4 形容在一个认证会话期间的客户端和服务端的详细信息替换过程：
图 4 服务端、客户端认证规范流程
(1) 客户端发送 username 和随机生成的挑战值 C -Nonce 给服务端。
(2) 服务端返回盐值 salt、迭代次数 i 以及随机生成的挑战值 Nonce 给客户端。Nonce 是将从客户端收到的 C -Nonce 和随机生成字符串组合造成的新挑战值。
(3) 客户端发送认证响应。响应信息蕴含客户端认证信息 ClientProof 和挑战值 Nonce。ClientProof 证实客户端领有 ClientKey，然而不通过网络的形式发送。在收到信息后，首先须要校验传来的挑战值 Nonce，校验通过后，计算 ClientProof。
客户端利用 salt 和 iteration-count（迭代次数），从 password 计算失去 SaltedPassword，而后通过密钥计算公式计算失去 ClientKey、StoryKey 和 ServerKey。计算 AuthMessage、ClientSignature。通过将客户端首次发送的信息，服务端首次发送的信息以及客户端的响应信息（不蕴含认证信息）连接起来失去 AuthMessage。
AuthMessage := client-first-message-bare + “,” +server-first-message + “,” + client-final-message-without-proof
ClientSignature := HMAC(StoredKey, AuthMessage)
客户端通过将 ClientKey 和 ClientSignature 进行异或失去 ClientProof：
ClientProof := ClientKey XOR ClientSignature
将计算失去的 ClientProof 和第 2 步接管的随机字符串 Nonce 发送给服务端进行认证。
(4) 服务端认证 Nonce 和 ClientProof，并且发送本人的认证信息 ServerSignature。首先须要校验 Nonce，校验通过后，计算 ServerSignature。应用其保留的 StoredKey 和 AuthMessage 通过 HMAC（Hash Message Authentication Code）算法进行计算，而后与客户端传来的 ClientProof 进行异或，复原 ClientKey，再对 ClientKey 进行哈希计算，失去的后果与服务端保留的 StoredKey 进行比拟。如果相等，则服务端对客户端的认证通过。
ClientSignature := HMAC(StoredKey, AuthMessage)
H(ClientProof XOR ClientSignature) == StoredKey
(5) 服务端通过计算失去的 ServerSignature 返回给客户端。
ServerSignature := HMAC(ServerKey, AuthMessage)
(6) 客户端通过将 ServerKey 和 AuthMessage 进行 HMAC 计算失去的 ServerSignature 与服务端传来的 ServerSignature 进行比拟。如果相等，则客户端实现对服务端的认证。
未完待续 ……
