金仓数据库KingbaseES安全指南--5.1. 数据库的传输安全

5.1. 数据库的传输安全

Kingbase数据库通过SSL协议支持数据安全传输和数据完整性保护，来确保数据在网络传输是安全的。本节内容包括：

• SSL的传输安全

• JDBC接口的传输安全

5.1.1. SSL的传输安全

5.1.1.1. SSL传输加密的本地支持

KingbaseES对使用SSL 连接加密客户端/服务器通讯的本地支持，可以增加安全性。这个特性要求在客户端和服务器端都安装 OpenSSL 并且在编译 KingbaseES 的时候打开这个支持。

5.1.1.1.1. 基本配置

当SSL支持被编译在KingbaseES中时，可以通过将KingbaseES.conf中的 ssl设置为on让KingbaseES服务器带着SSL支持被启动。 服务器在同一个 TCP 端口监听普通连接和SSL连接，并且将与任何正在连接的客户端协商是否使用SSL。默认情况下，这是客户端的选项，关于如何设置服务器来要求某些或者所有连接使用SSL请参考 SSL客户端证书认证 。

要SSL模式中启动服务器，包含服务器证书和私钥的文件必须存在。默认情况下，这些文件应该分别被命名为server.crt和server.key并且被放在服务器的数据目录中，但是可以通过配置参数ssl_cert_file和ssl_key_file指定其他名称和位置。 如果数据目录允许组读取访问，则证书文件可能需要位于数据目录之外，以符合上面概述的安全要求。通常，启用组访问权限是为了允许非特权用户备份数据库，在这种情况下，备份软件将无法读取证书文件，并且可能会出错。

如果私钥被一个密码保护着，服务器将提示要求这个密码，并且在它被输入前不会启动。 使用密码还会禁用在不重启服务器的情况下更改服务器的SSL配置的功能。 此外，密码保护的私钥在Windows上根本无法使用。 server.crt中的第一个证书必须是服务器的证书，因为它必须与服务器的私钥匹配。“intermediate”的证书颁发机构，也可以追加到文件。假设根证书和中间证书是使用v3_ca扩展名创建的，那么这样做避免了在客户端上存储中间证书的必要。这使得中间证书更容易到期。无需将根证书添加到中server.crt。相反，客户端必须具有服务器证书链的根证书。

5.1.1.1.2. OpenSSL配置

KingbaseES读取系统范围的OpenSSL配置文件。默认情况下，该文件被命名为openssl.cnf并位于``openssl version -d``报告的目录中。通过将环境变量设置OPENSSL_CONF为所需配置文件的名称，可以覆盖此默认值。

OpenSSL支持各种强度不同的密码和身份验证算法。虽然许多密码可以在OpenSSL的配置文件中被指定，您可以通过修改KingbaseES.conf配置文件中指定专门针对数据库服务器使用密码的ssl_ciphers 配置。

注意

传递客户端和服务器之间的通信。此外，加密开销相比身份认证的开销是最小的。出于这些原因，我们建议不要使用 NULL 密码。

5.1.1.1.3. 使用客户端证书

要求客户端提供受信任的证书，把你信任的根证书颁发机构（CA）的证书放置在数据目录文件中。并且修改KingbaseES.conf中的参数ssl_ca_file到新的文件名，还要把认证选项clientcert=1加入到sys_hba.conf文件中合适的hostssl行上。然后将在 SSL 连接启动时从客户端请求该证书（一段对于如何在客户端设置证书的描述请见 SSL传输加密的远程支持 。服务器将验证客户端的证书是由受信任的证书颁发机构之一签名。

如果希望避免将链接到现有根证书的中间证书显示在ssl_ca_file文件中（假设根证书和中间证书是使用 v3_ca 扩展名创建的），则这些证书也可以显示在ssl_ca_file 文件中。如果参数ssl_crl_file被设置，证书撤销列表（CRL）项也要被检查（显示 SSL 证书用法的图标见http://h41379.www4.hpe.com/doc/83final/ba554_90007/ch04s02.html）。

clientcert认证选项适用于所有的认证方法，但仅适用于sys_hba.conf中用hostssl指定的行。 当clientcert没有指定或设置为 0时，如果配置了 CA 文件，服务器将仍然会根据它验证任何提交的客户端证书 — 但是它将不会坚持要求出示一个客户端证书。 如果你在设置客户端证书，你可能希望用cert认证方法，这样证书控制用户认证以及提供连接安全。在使用cert认证方法时，没有必要显式地指定clientcert=1，详见 SSL客户端证书认证 。

5.1.1.1.4. SSL 服务器文件用法

下表总结了与服务器上 SSL 配置有关的文件用法（显示的文件名是默认的名称。本地配置的名称可能会不同）。

文件	内容	效果
ssl_cert_file ($PGDATA/server.crt)	服务器证书	发送给客户端来说明服务器的身份
ssl_key_file ($PGDATA/server.key)	服务器私钥	证明服务器证书是其所有者发送的，并不说明证书所有者是值得信任的
ssl_ca_file	可信的证书颁发机构	检查客户端证书是由一个可信的证书颁发机构签名的
ssl_crl_file	被证书授权机构撤销的证书	客户端证书不能出现在这个列表上

服务器在服务器启动时以及服务器配置重新加载时读取这些文件。在Windows系统上，只要为新客户端连接生成新的后端进程，它们也会重新读取。 如果在服务器启动时检测到这些文件中的错误，服务器将拒绝启动。但是，如果在配置重新加载过程中检测到错误，则会忽略这些文件，并继续使用旧的SSL配置。在Windows系统上，如果在后端启动时检测到这些文件中存在错误，则该后端将无法建立SSL连接。在所有这些情况下，错误情况都会在服务器日志中报告。

5.1.1.1.5. 创建证书示例

要为服务器创建一个有效期为365天的简单自签名证书，可以使用下面的OpenSSL命令，将dbhost.yourdomain.com替换为服务器的主机名：

openssl req -new -x509 -days 365 -nodes -text -out server.crt \
  -keyout server.key -subj "/CN=dbhost.yourdomain.com"

然后执行：

chmod og-rwx server.key

如果文件的权限比这个更自由，服务器将拒绝该文件

尽管可以使用自签名证书进行测试，但是在生产中应该使用由证书颁发机构（CA）（通常是企业范围的根CA）签名的证书。

要创建其身份可以被客户端验证的服务器证书，请首先创建一个证书签名请求（CSR）和一个公共/专用密钥文件：

openssl req -new -nodes -text -out root.csr \
  -keyout root.key -subj "/CN=root.yourdomain.com"
chmod og-rwx root.key

然后，使用密钥对请求进行签名以创建根证书颁发机构（使用Linux上的默认OpenSSL配置文件位置）：

openssl x509 -req -in root.csr -text -days 3650 \
  -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
  -signkey root.key -out root.crt

最后，创建由新的根证书颁发机构签名的服务器证书：

openssl req -new -nodes -text -out server.csr \
  -keyout server.key -subj "/CN=dbhost.yourdomain.com"
chmod og-rwx server.key

openssl x509 -req -in server.csr -text -days 365 \
  -CA root.crt -CAkey root.key -CAcreateserial \
  -out server.crt

server.crt和server.key应该存储在服务器上，并且root.crt应该存储在客户端上，以便客户端可以验证服务器的叶证书已由其受信任的根证书签名。root.key应该离线存储以用于创建将来的证书。

也可以创建一个包括中间证书的信任链：

# root
openssl req -new -nodes -text -out root.csr \
  -keyout root.key -subj "/CN=root.yourdomain.com"
chmod og-rwx root.key
openssl x509 -req -in root.csr -text -days 3650 \
  -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
  -signkey root.key -out root.crt

# intermediate
openssl req -new -nodes -text -out intermediate.csr \
  -keyout intermediate.key -subj "/CN=intermediate.yourdomain.com"
chmod og-rwx intermediate.key
openssl x509 -req -in intermediate.csr -text -days 1825 \
  -extfile /etc/ssl/openssl.cnf -extensions v3_ca \
  -CA root.crt -CAkey root.key -CAcreateserial \
  -out intermediate.crt

# leaf
openssl req -new -nodes -text -out server.csr \
  -keyout server.key -subj "/CN=dbhost.yourdomain.com"
chmod og-rwx server.key
openssl x509 -req -in server.csr -text -days 365 \
  -CA intermediate.crt -CAkey intermediate.key -CAcreateserial \
  -out server.crt

server.crt和intermediate.crt应连接成一个证书文件包中并存储在服务器上。server.key还应该存储在服务器上。root.crt应将其存储在客户端上，以便客户端可以验证服务器的叶证书是否已由链接到其受信任根证书的证书链签名。root.key和intermediate.key应离线存储以用于创建将来的证书。

5.1.1.2. SSL传输加密的远程支持

5.1.1.2.1. 关于数据SSL传输加密的远程支持

KingbaseES支持通过SSL协议实现客户端和服务器之间的安全数据传输，使得数据在传输过程中难以被窃听、篡改、重放和伪造。SSL协议是加密动态数据的行业标准，SSL传输加密为服务器连接提供不可否认性，以防止第三方攻击。并且SSL认证可用于数据库身份验证。 。配置ssl传输，可与核心数据库功能加密或者数据访问控制配合使用。

在KingbaseES中，通过libkci读取系统范围的OpenSSL配置文件，默认情况下，这个文件被命名为openssl.cnf并且存放在openssl version -d报告的目录中。可以通过设置环境变量OPENSSL_CONF把这个默认值覆盖为想要的配置文件的名称。

5.1.1.2.2. 服务器证书的客户端验证

默认情况下，KingbaseES将不会执行服务器证书的任何验证。这意味着可以在不被客户端知晓的情况下伪造服务器身份（例如通过修改一个 DNS 记录或者接管服务器的 IP 地址）。为了阻止哄骗，必须使用SSL证书验证。

如果参数sslmode被设置为verify-ca，libkci 将通过检查证书链一直到一个可信的证书机构（CA）来验证服务器是可信的。如果sslmode被设置为verify-full，libkci 将还会验证服务器主机名是否匹配它的证书。如果服务器证书不能被验证，SSL 连接将失败。在大部分对安全敏感的环境中，建议使用verify-full。

在verify-full模式下，主机名与证书的Subject Alternative Name（主题备用名称)属性进行匹配，或者如果没有类型为dNSName的主题备用名称，则与Common Name（公用名称）属性进行匹配。如果证书的名称属性以星号（ * ）开头，则星号将被视为通配符，其将匹配除了点(.)之外的所有字符。这意味着证书将不会匹配子域。如果使用IP地址而不是主机名进行连接，则将匹配IP地址（不进行任何DNS查找）。

要允许服务器证书验证，一个或多个可信的CA必须被放置在用户home目录下的文件 ~/.kingbase/root.crt中。如果中间CA出现在 root.crt中，该文件必须也包含到它们的根CA的证书链 （在Windows 上该文件被命名为%APPDATA%\kingbase\root.crt）。

如果文件~/.kingbase/root.crl存在 （Windows 上的%APPDATA%\kingbase\root.crl），也会检查证书撤销列表（CRL）项。

根证书文件和 CRL 的位置可以通过设置连接参数sslrootcert和 sslcrl或环境变量KCISSLROOTCERT和KCISSLCRL改变。

注意

为了与 KingbaseES 的早期版本达到向后兼容，如果存在一个根 CA 文件， sslmode=require的行为将与 verify-ca相同，意味着服务器证书根据 CA 验证。不鼓励依赖这种行为，并且需要证书验证的应用程序应该总是使用verify-ca或者verify-full。

5.1.1.2.3. 客户端证书

如果服务器要求一个可信的客户端证书，libkci将发送用户主目录中~/.kingbase/kingbase.crt文件存储的证书。该证书必须由一个受服务器信任的证书机构（CA）签发。也必须存在一个匹配的私钥文件~/.kingbase/kingbase.key。该私钥文件不允许全局或组用户的任何访问，可以通过命令chmod 0600 ~/.kingbase/kingbase.key实现。在微软 Windows 上这些文件被命名为%APPDATA%\kingbase\kingbase.crt和%APPDATA%\kingbase\kingbase.key，不会有特别的权限检查，因为该目录被假定为安全。证书和密钥文件的位置可以使用连接参数sslcert和sslkey或者环境变量KCISSLCERT和KCISSLKEY覆盖。

在一些情况下，客户端证书可以由"中间"证书机构签名，而不是由服务器直接信任的证书机构。要使用这样一个证书，将签发机构的证书加入到kingbase.crt文件，然后是它的上级机构的证书，并且一直到一个受服务器信任的证书机构（"根"机构或者"中间"机构），即由该服务器的root.crt文件中的一个证书签发。

注意

客户端的~/.kingbase/root.crt列出了被认为可信的能用于签发服务器证书的顶层 CA。原则上不需要列出签发客户端证书的 CA，大部分情况下这些 CA 也被信任可以用于服务器证书。

5.1.1.2.4. 不同模式中提供的保护

sslmode参数的不同值提供了不同级别的保护。SSL 能够针对三类攻击提供保护：

窃听

如果一个第三方能够检查客户端和服务器之间的网络流量，它能读取连接信息（包括用户名和口令）以及被传递的数据。SSL使用加密来阻止这种攻击。

中间人（MITM）

如果一个第三方能对客户端和服务器之间传送的数据进行修改，它就能假装是服务器并且因此能看见并且修改数据，即使这些数据已被加密。然后第三方可以将连接信息和数据传送给原来的服务器，使得它不可能检测到攻击。这样做的常用载体包括 DNS 中毒和地址劫持，借此客户端被定向到预期之外的不同的服务器。还有几种其他的攻击方式能够完成这种攻击。SSL使用证书验证让客户端认证服务器，就可以阻止这种攻击。

模仿

如果第三方可以伪装成一个授权的客户端，那么它能够轻松访问它本不能访问的数据。通常这可以由不安全的口令管理所致。SSL使用客户端证书来阻止这种情况，即确保只有持有合法证书的客户才能访问服务器。

对于一个已知安全的连接，在连接被建立之前，必须在客户端和服务器端都进行SSL配置。如果只在服务器上配置，客户端在知道服务器要求高安全性之前可能会结束发送敏感信息（例如口令）。在 libkci 中，可以通过将sslmode参数设置为verify-full或verify-ca来确保安全连接，并且为系统提供一个根证书用来验证。这类似于使用https URL进行加密网页浏览。

一旦服务器已经被认证，客户端可以传递敏感数据。这意味着直到这一点，客户端都不需要知道是否证书将被用于认证，这样只需要在服务器配置中指定就比较安全。

所有SSL选项都带来了加密和密钥交换的开销，因此必须在性能和安全性之间做出平衡。表 “SSL模式描述” 说明不同sslmode值所保护的风险，以及关于安全和开销所做出的声明。

表 5.1.1 SSL模式描述

sslmode	窃听保护	MITM保护	声明
disable	否	否	我不关心安 全性，并且我不想 承担加密的开销。
allow	可能	否	我 不关心安全性，但 如果服务器坚持， 我会承担加密开销 。
prefer	可能	否	我不 关心加密，但如果 服务器支持，我希 望承担加密开销。
require	是	否	我希望我的数据加 密，我接受开销。 我相信该网络将确 保我始终连接到想 要连接的服务器。
verify-ca	是	取决于 CA-策略	我希望 我的数据加密，我 接受开销。我想要 确保我连接到的是 我信任的服务器。
verify-full	是	是	我希望我的数据 加密，我接受开销 。我想要确保我连 接到的是我信任的 服务器，并且就是 我指定的那一个。

verify-ca和verify-full之间的区别取决于根CA的策略。如果使用了一个公共CA，verify-ca允许连接到那些可能已经被其他人注册到该CA的服务器。在这种情况下，总是应该使用verify-full。如果使用了一个本地CA或者甚至是一个自签名的证书，使用verify-ca通常就可以提供足够的保护。

sslmode的默认值是prefer。如表中所示，从安全角度来看这样做是没有意义的，并且它只承诺可能的性能开销。提供它作为默认值只是为了向后兼容，在安全部署中不建议使用。

5.1.1.2.5. SSL 客户端文件使用

下表总结了与客户端 SSL 设置相关的文件。

表 5.1.2 Libkci/客户端 SSL 文件用法

文件	内容	影响
~/.kingbase/kingbase.crt	客户端证书	由服务器要求
~/.kingbase/kingbase.key	客户端私钥	证明由所有者发 送客户端证书，并不表 示证书所有者是可信的
~/.kingbase/root.crt	受信任的证书颁发机构	检查服务器证书是由一 个可信的证书机构签发
~/.kingbase/root.crl	被证 书颁发机构撤销的证书	服务器证 书必须不在这个列表中

5.1.1.2.6. SSL 库初始化

如果初始化应用libssl或libcrypto库以及libkci编译来支持SSL，应该调用KCIinitOpenSSL来告诉libkci：libssl或libcrypto库已经被你的应用初始化，这样libkci将不会再初始化这些库。

KCIinitOpenSSL

允许应用选择要初始化哪个安全库。

void KCIinitOpenSSL(int do_ssl, int do_crypto);

当do_ssl是非零时，libkci 将在第一次打开数据库连接前初始化OpenSSL库。当do_crypto是非零时，libcrypto库将被初始化。默认情况下（如果没有调用KCIinitOpenSSL），两个库都会被初始化。当 SSL 支持没有被编译时，这个函数也存在但是什么也不做。

如果你的应用使用并且初始化OpenSSL或者它的底层libcrypto库，必须在第一次打开数据库连接前以合适的非零参数调用这个函数。同时要确保在打开一个数据库连接前已经完成了初始化。

KCIInitializeSSLEnv

允许应用选择要初始化哪个安全库。

void KCIInitializeSSLEnv(int do_ssl);

这个函数等效于KCIinitOpenSSL(do_ssl, do_ssl)。这对于要么初始化OpenSSL以及libcrypto要么都不初始化的应用足够用了。

在KingbaseES V8.2 中已经支持 KCIInitializeSSLEnv因此KCIInitializeSSLEnv可能对那些需要与旧版本libkci一起工作的应用来说更合适。

5.1.1.2.7. 示例

客户端配置：

1. 把 kingbase.crt , kingbase.key 以及 root.crt 放到 ~/.kingbase 目录中, windows下放到 %APPDATA%\kingbase 目录下，并修改文件权限为0600。

服务器端配置：

1. 把 server.crt , server.key 以及 root.crt 放到 data 目录中，并修改权限为0600。

2. 修改 sys_hba.conf 文件， 增加 hostssl 配置项认证方式为 cert ,并注释掉前面与之冲突的配置项（例如前面已经有配置为192.168.4.100为Md5认证方式，如果在后面再次增加hostssl的192.168.4.100配置，则该配置不会启用）。

   举例说明：

   # IPv4 local connections:
   host    all             all             127.0.0.1/32            scram-sha-256
   host    all             all             0.0.0.0/0               scram-sha-256
   

   修改方式一(不验证证书)：

   # IPv4 local connections:
   hostssl    all             all             127.0.0.1/32            scram-sha-256
   #host    all             all             0.0.0.0/0               scram-sha-256
   

   修改方式二(验证证书)：

   # IPv4 local connections:
   hostssl    all             all             127.0.0.1/32            scram-sha-256 clientcert=1
   #host    all             all             0.0.0.0/0               scram-sha-256
   

   证书可从安装目录share下获取，获取后需将kingbase8.*重命名为kingbase.*，然后操作步骤参考客户端配置

3. 修改 kingbase.conf 配置文件中 ssl = on , ssl_ca_file = 'root.crt' ssl_key_file = 'server.key' 以及 ssl_cert_file = 'server.crt'

4. 最后启动服务器，客户端连接会提示此时使用的ssl连接。

5.1.1.3. GMSSL支持

GMSSL是支持国密算法加密套件的openssl开源项目，如果使用国密传输加密需要提供一个支持GMSSL的KINGBASE包。关于GMSSL配置使用如下：

客户端配置：

1. 把 kingbase.crt , kingbase.key 以及 root.crt 放到 ~/.kingbase 目录中, windows下放到 %APPDATA%\kingbase 目录下，并修改文件权限为0600。

服务器端配置：

1. 把 server.crt , server.key 以及 root.crt 放到 data 目录中，并修改权限为0600。

2. 修改 sys_hba.conf 文件， 增加 hostssl 配置项认证方式为 cert ,并注释掉前面与之冲突的配置项（例如前面已经有配置为192.168.4.100为Md5认证方式，如果在后面再次增加hostssl的192.168.4.100配置，则该配置不会启用）。

3. 修改 kingbase.conf 配置文件中 ssl = on , ssl_ca_file = 'root.crt' ssl_cert_file = 'server.crt' ssl_key_file = 'kingbase.key' ssl_ciphers = 'ECDHE-SM2-WITH-SMS4-GCM-SM3' ssl_ecdh_curve = 'sm2p256v1' ssl_min_protocol_version = 'TLSv1.2'

4. 最后启动服务器，客户端连接会提示此时使用的是国密算法套件进行的通讯连接。

5.1.1.4. SSL的加密算法

KingbaseES支持通过SSL加密客户端和服务器之间的通信数据，保证通信安全。采用TLS2.4协议标准，并使用安全强度较高的加密算法套件，支持的加密算法套件如下表所示:

表 5.1.3 加密算法套件

OpenSSL套件名	IANA套件名	安全程度
ECDHE-RSA-AES128-GCM-SHA256	TLS_ECDHE_RSA_WITH_AES _128_GCM_SHA256	HIGH
ECDHE-RSA-AES256-GCM-SHA384	TLS_ECDHE_RSA_WITH_AES _256_GCM_SHA384	HIGH
ECDHE-ECDSA-AES128-GCM-SHA256	TTLS_ECDHE_ECDSA_WITH_AES _128_GCM_SHA256	HIGH
ECDHE-ECDSA-AES256-GCM-SHA384	TLS_ECDHE_ECDSA_WITH_AES _256_GCM_SHA384	HIGH

5.1.2. JDBC接口的传输安全

数据库加密和强身份验证功能使java程序通过JDBC接口能安全的连接到KingbaseES数据库

5.1.2.1. 关于 Java 支持

KingbaseES数据库提供了传输加密和强身份验证的Java支持。KingbaseES数据库安全加密传输和强身份验证为JDBC 客户端提供网络身份验证、加密和完整性保护等功能，这些客户端必须与配置了KingbaseES 数据库加密传输和强身份验证的 KingbaseES 数据库进行通信。

5.1.2.2. Java 数据库连接支持

JDBC 是行业标准的 Java 接口，是用于从 Java 程序连接到关系数据库的 Java 标准。KingbaseES 使用自己的 JDBC 驱动程序来支持行业标准。KingbaseES JDBC 驱动程序用于Java 数据库应用程序以与 KingbaseES 数据库的通信。 KingbaseES 对 JDBC 的扩展包括以下特性：

• 数据访问和操作

• LOB访问和操作

• KingbaseES 对象类型映射

• 对象引用访问和操作

• 数组访问和操作

• 应用程序性能增强

5.1.2.3. JDBC 功能

KingbaseES JDBC 驱动程序提供安全功能，例如强身份验证、数据加密和数据完整性检查。KingbaseES 数据库为JDBC 提供以下特性：

• 强身份认证

• 数据加密

• 数据完整性检查

• JDBC 客户端到 KingbaseES 数据库的安全连接

• 安全传输数据

KingbaseES JDBC 驱动程序支持 KingbaseES 数据库 SSL 实施和第三方身份验证方法，例如 RADIUS 和 Kerberos。

5.1.2.4. JDBC的安全连接配置参数

KingbaseES为JDBC接口提供了用于加密、完整性和身份验证服务等安全参数。

5.1.2.4.1. 口令加密

KingbaseES JDBC连接属性中passwordEncryption参数指定密码的加密方式，默认值是null，目前只支持 base64。

5.1.2.4.2. SSL加密

KingbaseES JDBC连接属性中关于SSL的参数如下表所示：

参数	描述
sslmode	指定控制SSL使用的参数
sslfactory	指定使用SSL的SSLSocketFactory类，默认是 null。
sslfactoryarg	指定被转发到SSLSocketFactory类的构造函数的参数，默认是 null。
sslhostnameverifier	指定一个实现了 javax.net.ssl.HostnameVerifier ，且可以验证服务器的类，默认是 null。
sslcert	指定客户端SSL证书的位置，默认是null。
sslkey	指定客户端PKCS#8 SSL 密钥的位置，默认是null。
sslrootcert	指定用于对服务器进行身份验证的根证书的位置，默认是 null。
sslpassword	指定客户端ssl密钥的密码（如果设置了 sslpasswordcallback ，则忽略），默认是 null。
sslpasswordcallback	指定一个实现了 javax.security.auth.callback.CallbackHandler ，且可以为 ssl 密码处理 PasssworCallback 的类，默认是null。

5.1.2.4.3. 其他加密相关参数

KingbaseES JDBC连接属性还提供关于kerberos、GSSAPI等身份验证的参数，如下表所示：

参数	描述
kerberosServerName	指定使用GSSAPI进行身份验证时要使用的 Kerberos服务名称，默认取值为：null
useSpnego	指定是否在SSPI 身份验证请求中使用SPNEGO，默认取值为：false
gsslib	指定强制SSPI或 GSSAPI，取值可以为 auto、sspi、gssapi，默认取值为：auto
sspiServiceClass	指定用于SPN的Windows SSPI 服务类，默认取值为：null

5.1.2.5. JDBC使用SSL加密

5.1.2.5.1. 关于JDBC使用SSL加密

通过参数sslmode配置证书验证方式，该参数支持四个值：disable（禁用SSL）、require、verify-ca、verify-full。使用verify-ca和verify-full时，需通过连接参数sslrootcert指定根证书文件的位置，如不指定，Linux默认路径为$HOME/.kingbase8/root.crt，Windows默认路径为%APPDATA%kingbase8root.crt，将服务器data目录下的root.crt放到对应目录下即可。只有verify-full模式会对主机名进行验证。

通过参数sslcert配置客户端证书位置，如不指定，Linux默认路径为$HOME/.kingbase8/kingbase8.crt，Windows默认路径为%APPDATA%kingbase8kingbase8.crt，将服务器data目录下的kingbase8.crt放到对应目录下即可。

通过参数sslkey配置秘钥文件位置，如不指定，Linux默认路径为$HOME/.kingbase8/kingbase8.pk8，Windows默认路径为%APPDATA%kingbase8kingbase8.pk8，将服务器data目录下的kingbase8.pk8放到对应目录下即可。

举例：

jdbc:kingbase8://192.168.222.128:54321/TEST?sslmode=verify-ca&sslrootcert=root.crt&sslcert=kingbase8.crt&sslkey=kingbase8.pk8

5.1.2.5.2. 配置SSL加密的步骤

配置SSL加密的步骤如下：

1. 需配置连接参数ssl=true；

2. 将truststore和keystore拷贝到客户端；

3. 执行程序时指定java运行参数

-Djavax.net.ssl.trustStore=truststore -Djavax.net.ssl.trustStorePassword=123456
-Djavax.net.ssl.keyStore=keystore -Djavax.net.ssl.keyStorePassword=123456

注意

1. 生成keystore时，签发客户端证书命令，可能会对openssl的版本有一定的要求，自测使用版本为OpenSSL 1.0.1e-fips，可以通过命令openssl version查看openssl版本。

2. 如果需要不与主机名和用户名绑定，使用LibPQFactory方式，需要配置jdbc连接参数sslmode为verify-ca，指定该参数不会验证主机名，生成kingbase8.csr时，CN指定为*，可匹配不同的用户。使用SSLSocketFactory不验证主机名和用户名。

3. 使用java命令执行应用程序时，可以通过-cp或-Djava.ext.dirs指定jar包路径。但通过后者指定时，会覆盖Java本身的ext设置，如果未指定该系统属性的原加载路径，将失去一些功能，如java自带的加解密算法实现，会报NOSuchAlgorithmException的错误。故需同时在该设置下指定路径$JAVA_HOME/jre/lib/ext，如-Djava.ext.dirs=./plugin: $JAVA_HOME/jre/lib/ex。

4. 如果openssl版本太高，使用其生成的证书服务器可能会报"unknown message digest algorithm"错误，此时需将openssl.cnf配置加密算法改为sha1，并且通过环境变量OPENSSL_CONF指定该文件的位置。

openssl version 查看openssl的版本 openssl version -d 查看openssl.cnf所在目录

5.1.2.5.3. 配置SSL加密的方式

5.1.2.5.3.1. 使用LibPQFactory

示例步骤如下：

1)确保安装openssl

2)在data目录下，创建自签名的证书

为服务器创建一个快速的自签名的证书，填充那些openssl要求的信息。确保把本地主机名当做"Common Name"输入；挑战密码可以留空。该程序将生成一个用口令保护的密钥，它不会接受小于四字符的口令。

openssl req -new -text -out server.req

要移去密钥（如果你想自动启动服务器就必须这样），运行下面的命令：

openssl rsa -in privkey.pem -out server.key
rm privkey.pem

将一个证书变成自签名的证书并复制密钥和证书到服务器将要查找它们的地方

openssl req -x509 -days 3650 -in server.req -text -key server.key -out server.crt

修改文件权限，如果文件的权限比这个更自由，服务器将拒绝该文件。

chmod og-rwx server.key

生成根证书

cp server.crt root.crt

3)配置kingbase.conf文件

ssl = on                                 # (change requires restart)
#ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers
                                               # (change requires restart)
#ssl_prefer_server_ciphers = on              # (change requires restart)
#ssl_ecdh_curve = 'prime256v1'               # (change requires restart)
#ssl_cert_file = 'server.crt'               # (change requires restart)
#ssl_key_file = 'server.key'                # (change requires restart)
ssl_ca_file = ' root.crt '                       # (change requires restart)
#ssl_crl_file = ''                           # (change requires restart)

4)配置sys_hba.conf文件

hostssl    all             all             0.0.0.0/0               md5  clientcert=1

5)重启数据库服务器

6)为客户端创建所需证书

生成kingbase8.key

openssl genrsa -des3 -out kingbase8.key 1024
openssl rsa -in kingbase8.key -out kingbase8.key
chmod 400 kingbase8.key

生成kingbase8.csr，CN需要指定为要连接数据库的用户名，如需匹配不同的用户，可指定为*

openssl req -new -key kingbase8.key -out kingbase8.csr -subj '/C=GB/ST=Berkshire/L=Newbury/O=Kingbase/CN=SYSTEM'

生成kingbase8.crt

openssl x509 -req -days 3650 -in kingbase8.csr -CA root.crt -CAkey server.key -out kingbase8.crt -CAcreateserial

生成kingbase8.pk8

openssl pkcs8 -topk8 -outform DER -in kingbase8.key -out kingbase8.pk8 -nocrypt

jdbc：

5.1.2.5.3.2. 使用默认的SSLSocketFactory

示例步骤如下：

1)、2)、3)、4)、5)同上节

6)创建truststore，用于认证服务器端证书

把服务器证书转化为der格式

openssl x509 -in server.crt -out server.crt.der -outform der

创建truststore，装入服务器证书

keytool -keystore ./truststore -alias kingbase8server -import -file ./server.crt.der

7)创建keystore，保存客户端证书

生成客户端的keyPair

keytool -genkeypair -dname "cn=kingbase8client, ou=basesoft, o=basesoft, c=CN" -alias kingbase8client -keystore ./keystore -validity 180

生成证书请求

keytool -certreq -alias kingbase8client -file ./kingbase8client.csr -keystore ./keystore

用root.crt签发客户端证书

openssl x509 -sha1 -req -in ./kingbase8client.csr -CA ./root.crt -CAkey ./server.key -CAcreateserial -out ./kingbase8client.crt.der -outform DER -days 365 -passin pass:123456 -extfile /etc/pki/tls/openssl.cnf -extensions v3_req

把证书添加到keystore中

keytool -keystore ./keystore -alias kingbase8server -import -file ./server.crt.der
keytool -keystore ./keystore -alias kingbase8client -import -file ./kingbase8client.crt.der