二.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.pemchmod 600 client.keychmod 600 client.crtchmod 600 client.key.cipherchmod 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进行比拟。如果相等，则客户端实现对服务端的认证。
未完待续......