★ FEATURED ARTICLE 之前做数据库安全加固的时候经常有人问我同一个问题GBase 8s的SSL加密到底怎么配。刚开始我觉得这不就是改个参数、开个开关的事儿真正动手才发现证书体系、密钥库、连接类型、客户端兼容哪一环没理顺都起不来。这篇笔记我把这些年配置GBase 8s SSL加密的完整过程梳理了一遍覆盖从证书制作、服务端开启、客户端接入到验证排错的整条链路适合正在做信创迁移、等保整改或者单纯不想让数据库流量裸奔的DBA和运维同学参考。1. 为什么要给GBase 8s配SSL业务驱动与加密原理1.1 明文SQL能被看到什么很多单位部署GBase 8s的时候默认走的是普通TCP连接。普通TCP意味着什么在数据库服务器和客户端之间所有传输内容都是明文。用户名、密码、SQL语句、查询结果只要有人在内网里做了端口镜像或者在你和数据库之间的交换机上抓包基本等于数据库裸奔。我见过一次真实排查某系统用户反馈数据库响应慢网络组同事顺手抓了个包结果把应用连库的密码直接看出来了。当时幸好是内网测试环境要是生产环境这事儿就大了。有人觉得内网安全没必要加密。实际上内网恰恰是最容易出事的地方。一个办公室里的普通终端被抓了马抓马程序在内网横移的时候首先嗅探的就是数据库连接一台跳板机被脱了裤所有通过跳板机转发的数据库流量一览无余。明文传输不只是合规问题是实打实的安全风险。1.2 SSL在这里解决什么问题SSL/TLS做的事本质上是三件事加密传输内容防止被窃听双向身份认证防止中间人伪装数据完整性校验防止报文被篡改。数据库连接里最常见的场景是服务端证书验证客户端连上数据库之后先校验服务器证书是否可信然后双方协商出会话密钥之后的SQL流量全部走对称加密。这个握手过程如果拿日常生活类比就像你去银行柜台办业务先要看柜员的工作证确认这是真银行然后再开始谈具体业务。工作证就是服务器证书银行总行签发的CA就是信任锚点。对GBase 8s来说SSL配置不是把数据包丢给某个代理去转一层而是数据库实例自己在监听端口上启用TLS协议。这意味着配置不仅涉及数据库自身还要考虑密钥库、证书格式、连接类型等一整套基础设施。这也是为什么很多DBA照着文档敲了半天最后连接还是失败——单改一个参数不够这玩意儿是个链路工程。1.3 GBase 8s的SSL实现结构GBase 8s的SSL功能依赖底层密钥库管理工具GSKit。GSKit负责创建密钥库、生成证书请求、导入CA证书、管理stash文件。密钥库在GBase 8s里通常是一个后缀为kdb的文件配合一个stash文件保存密钥库密码。数据库启动的时候通过配置参数找到密钥库路径和stash路径加载服务器证书和私钥然后在指定端口上开启TLS监听。理解了这个结构配置思路就清晰了先用GSKit做出一个包含服务器证书的密钥库再告诉GBase 8s这个密钥库在哪、stash文件在哪然后在连接描述文件里把连接类型标记为SSL。客户端那边同样要走一套证书信任的逻辑。整条链路是证书体系在前数据库配置居中客户端接入收尾。2. 配置前必须理清的概念与准备清单2.1 密钥库、证书、stash文件分别是什么先说密钥库。kdb文件是一个容器里面可以同时存放服务器私钥、服务器证书、CA证书、客户端信任证书等。它本身是有密码保护的但数据库实例启动时不能每次人工输密码所以会有一个stash文件相当于把密钥库密码混淆加密后存起来启动时自动读取。stash文件和kdb文件必须配套单独拷贝一个过去是会出问题的。证书链这块需要提前设计好。最推荐的方式是搭一套内部CA用内部CA给数据库服务器签发证书。客户端连接时只需要信任这个内部CA就能通过证书链验证所有由它签发的服务器证书。你要是图省事直接自签名一个服务器证书也不是不能用但客户端上要额外配置信任而且一旦私钥泄露替换范围会很大维护起来很麻烦。如果你所在单位已经有企业级CA系统直接走企业CA的证书申请流程最好合规性和可审计性都更稳。2.2 证书CN与主机名的匹配关系证书里CN字段是重点。服务器证书的CN必须和客户端连接时使用的主机名一致否则客户端会报主机名不匹配。实际环境里经常有这几种连法客户端用IP连数据库、客户端用主机名连数据库、客户端用VIP连数据库。你证书里CN写的是哪个客户端就必须用哪个去连。这里我踩过坑当时证书CN写的是服务器物理主机名客户端偏偏用VIP连结果证书校验直接失败查了大半天才反应过来。建议的做法是证书CN统一写成对外提供服务的那个名字如果是双机HA环境最好给每个节点单独签证书或者提前确认你的连接串固定用哪个主机名按那个名字签发。多节点环境下证书规划一定要在动手前想清楚不然后面每加一个节点都要重新走一遍签发流程。2.3 确认环境里GSKit工具能不能用配置之前先检查GSKit相关命令是否可用。GBase 8s安装目录下通常会带GSKit工具常见命令名是gsk8capicmd或gskit。你可以先执行一下看看有没有版本输出。如果没有需要单独安装与数据库版本对应的GSKit。这个步骤看似基础但很多环境是精简安装真到了加密配置这一步才发现工具没装临时补装又牵扯权限和路径挺耽误事。检查完工具之后再确认数据库实例当前的onconfig和sqlhosts文件路径。这两个文件一个在$INFORMIXDIR/etc下一个在$GBASEDBTDIR路径下不同环境叫法可能不一样。开始之前记得先备份我每次改配置前都会把onconfig、sqlhosts、以及系统环境变量相关文件整体拷贝一份这是最基础的保命操作。3. 证书与密钥库制作用GSKit跑通全流程3.1 创建服务器密钥库并生成证书请求先规划一个目录存放证书相关文件比如/opt/gbase8s/ssl。以下命令在GSKit环境下执行。首先创建服务器密钥库并生成stash文件gsk8capicmd -keydb -create -db server.kdb -pw ChangeMe123 -type cms -stash执行完会在当前目录生成server.kdb和server.sth两个文件。这个stash文件就是数据库启动时要用的密码文件。接着为服务器生成证书请求gsk8capicmd -certreq -create -db server.kdb -pw ChangeMe123 \ -label gbase_server -dn CNdbhost.example.local \ -size 2048 -sigalg SHA256WithRSA-label是为这条证书请求起的别名后面签发和导入都会用到。注意-CN字段这里写什么客户端连接时的主机名就得是什么。我习惯先想好连接拓扑再写CN避免返工。证书位数建议2048起步如果你的环境对安全等级有更高要求可以往上加但也要评估数据库握手性能的损耗。3.2 用内部CA签发服务器证书企业有现成CA就直接用企业CA签发。没有的话可以自己搭一套内部CA这不复杂两条命令的事。创建CA密钥库gsk8capicmd -keydb -create -db ca.kdb -pw CaPass123 -type cms -stash生成自签CA证书gsk8capicmd -cert -create -db ca.kdb -pw CaPass123 \ -label gbase_ca -dn CNGBase Internal CA \ -self -sigalg SHA256WithRSA -version 3然后用CA去签发刚才的服务器证书请求gsk8capicmd -cert -sign -db server.kdb -pw ChangeMe123 \ -label gbase_server -ca ca.kdb -ca_pw CaPass123 \ -ca_label gbase_ca -expire 730-expire是证书有效天数这里写了730天。实际生产中建议配上证书到期监控后面我会专门说这个问题。签发完成之后把CA证书导入服务器密钥库让服务器端在握手中能带出完整证书链gsk8capicmd -cert -add -db server.kdb -pw ChangeMe123 \ -label gbase_ca -file ca.crt -format ascii -trust enableCA证书一般可以导出为ASCII格式的crt文件用工具或者文本方式都能查看内容。3.3 密钥库与证书制作中的几个细节细节一文件的属主和权限。密钥库和stash文件必须让运行数据库实例的操作系统用户能读否则实例启动时加载证书会报权限错误。我之前有一次把密钥库放在了root目录下数据库用户根本访问不了日志里全是打开文件失败的报错。细节二label必须全局唯一。同一个密钥库里两个证书用了同一个label加载时会出现混乱而且GSKit的报错信息不太直观。细节三证书请求签发后原label对应的内容会从请求变成正式证书不需要再单独替换。如果你不小心把请求导出成了文件不需要去管它。细节四自签名CA的私钥安全级别要拉满。整个内网数据库的信任体系都建立在CA私钥上CA私钥泄露等同内网所有加密数据库连接都可被中间人。建议CA库单独放一个安全目录权限收紧平时不对普通运维账号开放。4. 服务端配置让实例真正启用TLS4.1 ONCONFIG中的SSL参数配置密钥库准备好之后接下来就是让GBase 8s启动时找到它。在onconfig里通常需要配置密钥库路径和stash路径。常见写法大致是SSL_KEYSTORE_FILE /opt/gbase8s/ssl/server.kdb SSL_KEYSTORE_STASH /opt/gbase8s/ssl/server.sth不同版本参数名可能略有差异有的版本可能是SSL_KEYSTOREDB、SSL_STASH_FILE之类具体以你手上版本的配置手册为准。但不管参数名怎么变核心逻辑是一致的数据库实例要知道密钥库文件在哪、stash文件在哪。配置完之后用onstat -g ssl这类命令或者日志输出可以看到SSL模块的初始化状态。这里要说一个很多人容易忽略的点服务器证书的label选择。如果一个密钥库里有多个证书数据库需要知道用哪个label的证书做服务器证书。有些版本默认取第一个可用证书有些版本需要通过额外参数指定。稳妥的做法是密钥库里只放必要的证书让数据库加载时不会产生歧义。如果看到加载证书阶段的日志里出现了多个候选就要通过参数显式指定label。4.2 SQLHOSTS连接类型如何改服务端光改了ONCONFIG还不够还得让监听端口知道这个服务要走TLS。这个动作在sqlhosts文件里体现。sqlhosts一行描述一个服务名对应的连接方式常规写法是gbase_srv onsoctcp 192.168.1.10 sqlexec启用SSL通常是在连接类型后面加一个s4标记。改完大概是这样gbase_srv onsoctcp 192.168.1.10 sqlexec s4这个标记的意思是这条连接类型的对应端口必须通过SSL握手建立连接。服务端和客户端SQLHOSTS里的对应条目都要一致地理解这个标记任何一侧漏配都会导致连接失败。棘手的场景是生产环境存量客户端很多不可能一下子全部切换成加密连接。这种情况我建议在sqlhosts里同时保留两个服务名一个走明文一个走SSLgbase_srv_plain onsoctcp 192.168.1.10 sqlexec gbase_srv_tls onsoctcp 192.168.1.10 sqlexec_tls s4新客户端逐步切到gbase_srv_tls老客户端继续用gbase_srv_plain跑一段观察期之后再清理明文入口。这样风险最小。4.3 重启实例与启动验证改完ONCONFIG和sqlhosts需要重启数据库实例让配置生效。重启之前建议先做语法检查有些版本有类似oncheck -cc的工具可以检查配置文件没有的话至少人工核对参数名和路径。实例起来之后确认端口监听情况onstat -g ssl输出里能看到SSL模块状态包括证书加载情况、当前SSL连接数等。如果输出为空或者报错说明SSL模块没起来大概率是密钥库路径或stash文件配置不对。另外一条验证路径是看数据库日志。实例启动过程中会有SSL初始化相关的记录比如证书加载成功、SSL监听已开启。不同版本日志文本不一样但关键字一般是SSL、certificate、keystore这几个。启动完别急着高兴先用一个测试客户端连一次确认握手能过才算真正配通。5. 客户端连接配置与端到端验证5.1 客户端SQLHOSTS和连接串服务端启用SSL之后客户端并不是什么都不用干它需要知道这个连接要用SSL方式协商。客户端机器上如果也配置了SQLHOSTS文件对应服务名的条目同样要加上s4标记保证客户端驱动发起的是TLS握手而不是普通TCP。有些客户端不读SQLHOSTS而是在连接串里直接指定参数。这时要看具体驱动的文档不同的驱动对SSL开关的命名可能不一样。常见的习惯是在连接URL里追加类似sslConnectiontrue或ssltrue的开关同时设置信任证书库。虽然属性名有差异但思路是一贯的告诉驱动这趟连接要验证服务器证书、要发起TLS握手。5.2 JDBC/ODBC客户端的证书信任怎么处理Java应用通过JDBC连GBase 8s除了业务连接串还要把CA证书导入应用的信任库。如果应用跑在某个服务器上可以把这个信任库放在应用服务器本地用keytool导入CA证书keytool -import -alias gbase_ca -file ca.crt -keystore truststore.jks然后在应用启动参数里指向这个信任库。ODBC/Python等客户端也会有对应的信任配置底层逻辑一致让客户端信任签发服务器证书的那个CA。这里有个常见的坑客户端只导入了服务器证书本身没有导入CA证书。这样握手时如果服务器只抛出单一证书有些客户端校验逻辑可能能过但一旦服务器把证书链完整带出来客户端缺少中间CA信任就会失败。我见过反复调不通的连接最后发现是信任库里只塞了一张叶子证书把CA证书加进去之后一切正常。所以证书链完整性要两头发力服务端导入CA证书客户端信任CA证书。5.3 端到端验证抓包和观察日志配置完成之后最好做一次端到端验证别只看到连接成功就收工。最简单的验证是在数据库服务器上抓包tcpdump -i eth0 port 9088 -w gbase_ssl.pcap然后用客户端发起一条SQL查询。抓包结果里如果能看到TLS握手过程说明流量确实已经被TLS封装。如果抓到的还是明文SQL语句说明连接没有走到SSL继续排查是哪一侧没生效。第二个验证手段是人为制造一次证书错误测试数据库是否正确拒绝。比如客户端连接串故意用一个不被信任的CA签发的证书这时握手应该失败客户端报证书校验错误。如果这个场景下连接还能成功说明服务器端或者客户端某个环节的证书校验没有真正打开。第三个手段是看onstat -g ssl里会话状态。连接成功后该会话会有SSL相关的属性显示能直观确认这条连接是不是加密连接。日志层面也可以打开连接跟踪观察握手成功和失败记录。6. 常见问题速查与避坑心得6.1 高频问题与处理建议把配置过程中最容易遇到的几类问题整理成速查表实用价值比大段文字高得多。现象大概率原因处理建议实例启动后端口没监听SQLHOSTS里s4加到了不支持的连接类型先去掉s4恢复正常检查连接类型后再加客户端报证书CN不匹配服务器证书CN与客户端连接用的主机名不一致按客户端实际使用的主机名重新签发证书握手失败但IP能通客户端信任库没有导入CA证书把CA证书导入客户端信任库重启客户端进程连接超时防火墙未放通对应端口核对服务名对应的端口是否在防火墙白名单内stash文件找不到路径配置错误或stash未同步检查ONCONFIG路径与kdb文件同目录放置证书过期导致连接中断证书有效期到了重新签发并建立证书到期监控机制除此之外还有一类隐蔽问题客户端连接池缓存了旧的连接。服务端刚切到SSL连接池里还留着切换前的明文连接应用第一次请求可能成功后续请求开始报异常看起来很像随机故障。这时候把连接池清掉重启应用一般就能恢复。我知道有一种情况运维和DBA两边互相排查了一下午最后就是连接池没刷新。6.2 上线前别忘了的几件事第一证书有效期管理。很多环境启用SSL之后就把证书的事抛到脑后直到某天早晨所有应用集体连不上库才想起来多半是证书过期。建议从一开始就把证书过期时间登记在运维日历里提前一个月、提前一周做两次提醒。有条件的环境可以做自动巡检检测kdb文件里证书的有效期。第二双机高可用场景的证书同步。两节点分别有自己的主机名和证书不要把节点A的证书文件直接拷贝到节点B否则CN不匹配的坑会在主备切换的时候突然冒出来。正确做法是每个节点分别生成请求、分别签发各用各的密钥库。第三应用服务器更换了主机名之后记得同步更新证书。现在的容器化环境里应用迁移是家常便饭迁移之后连接报证书错误很多人下意识地去改连接串其实根因是证书CN和实际主机名对不上了。第四配置变更前务必备份包括onconfig、sqlhosts、密钥库、stash文件。我见过有人连stash文件一起删了恢复的时候只能重新生成重新生成又发现kdb和stash不匹配折腾了一整晚。第五如果对性能损耗有担忧可以做一轮压测对比但根据实际经验正常业务场景下SSL的CPU开销主要在握手阶段一旦会话建立走的是对称加密性能影响通常可控。真正想优化的是握手频率比如让长连接更持久减少频繁重连。这几年配置数据库加密我的体会是SSL加密这事不难难的是把证书体系、连接方式、应用侧信任扎扎实实地贯穿起来。很多人配置失败不是命令敲错了而是对整个链路缺少整体理解。希望这篇文章能帮你把GBase 8s的SSL加密配置一次性跑通少走几步我当年走过的弯路。
阅读完成 · 觉得有帮助？
