分布式数据库节点通信加密配置

分布式数据库一旦跨节点部署，最容易被忽视也最致命的环节就是节点间通信的明文传输。多数团队把精力放在存储加密和身份认证上，却让心跳包、复制日志、事务协调消息在内部网络里裸奔。内部网络并非绝对安全，ARP欺骗、横向渗透、恶意容器逃逸都可能让攻击者直接抓取节点间流量。节点通信加密不是可选加分项，而是分布式数据库安全基线的一部分。

不同分布式数据库对通信加密的支持差异很大。TiDB、OceanBase、CockroachDB、MongoDB Sharded Cluster、Cassandra等都有各自的节点间加密机制，但配置路径和默认状态完全不同。有些数据库默认开启TLS，有些则需要手动生成证书并修改每个节点的启动参数。第一步不是盲目改配置，而是先查清楚你所用数据库的版本、组件间通信协议以及官方推荐的加密方式。比如TiDB的PD、TiKV、TiDB Server之间全部走gRPC，统一用一套TLS证书即可覆盖；而Cassandra的节点间通信分为internode messaging和streaming，两者都需要单独开启加密。

节点通信加密的核心是证书管理。很多团队图省事，给所有节点签发同一张证书，甚至直接用自签名的通配符证书。这种做法一旦某个节点被攻破，攻击者就能拿着这张证书冒充任意节点加入集群。正确做法是至少区分客户端证书和服务端证书，并且为每个节点签发独立证书。如果数据库支持mTLS，务必开启双向认证，让节点之间不仅验证对方身份，还要验证对方是否持有合法证书。证书的CN或SAN字段要严格匹配节点主机名或IP，否则握手阶段就会失败，排查起来非常痛苦。

以常见的内部CA签发流程为例，先创建CA私钥和根证书：

openssl genrsa -out ca.key 4096
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -subj "/CN=Internal-CA"

然后为每个节点生成私钥和证书签名请求，注意SAN必须包含节点实际通信使用的IP和主机名：

openssl genrsa -out node1.key 2048
openssl req -new -key node1.key -out node1.csr -subj "/CN=node1"
openssl x509 -req -in node1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out node1.crt -days 365 -extfile <(printf "subjectAltName=IP:10.0.0.11,DNS:node1.internal")

最后把ca.crt、node1.crt、node1.key分发到对应节点的配置目录，并设置严格的文件权限。私钥文件权限必须是600，证书文件可以是644，CA证书通常也是644。很多安全事故就是因为私钥文件权限过于宽松，被同机的其他进程读取。

TiDB的节点间加密需要在PD、TiKV、TiDB三个组件的配置文件中分别指定证书路径。PD的配置片段如下：

[security]
cacert-path = "/etc/tidb/certs/ca.crt"
cert-path = "/etc/tidb/certs/pd.crt"
key-path = "/etc/tidb/certs/pd.key"

TiKV的配置类似，但要注意TiKV同时作为服务端和客户端，证书的SAN必须覆盖所有可能被访问的地址。MongoDB分片集群的节点间加密则需要在mongod配置中同时设置net.tls.mode为requireTLS，并指定CA文件和PEM文件：

net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/mongo/certs/node1.pem
    CAFile: /etc/mongo/certs/ca.crt

MongoDB的certificateKeyFile要求私钥和证书合并成一个PEM文件，且私钥不能加密，否则进程无法自动读取。合并方式很简单：

cat node1.crt node1.key > node1.pem
chmod 600 node1.pem

节点间通信加密不能只满足于“用了TLS”，还要关注TLS版本和加密套件的强度。TLS 1.0和1.1已经不安全，至少要求TLS 1.2，条件允许直接上TLS 1.3。加密套件要避免使用RC4、3DES、CBC模式的旧套件，优先选择ECDHE前向保密套件。部分数据库允许在配置中指定cipher suites，比如Cassandra可以在cassandra.yaml中设置cipher_suites，只保留TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256和TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384这类高强度套件。如果数据库不支持自定义套件，至少确保它默认禁用了弱套件。

节点通信加密会带来CPU开销，尤其是在高吞吐场景下，TLS握手和对称加密都会消耗额外资源。实测中，开启TLS后节点间通信延迟通常增加5%到15%，吞吐量下降幅度取决于加密套件和硬件加速能力。现代CPU大多支持AES-NI指令集，能大幅降低对称加密的CPU消耗，但非对称握手阶段的成本依然存在。优化方向有几个：一是启用会话复用，减少重复握手的开销；二是使用TLS 1.3，它比1.2少一次往返，握手更快；三是在高并发场景下适当增加节点间连接池大小，分摊握手压力。不要因为性能顾虑就放弃加密，明文通信带来的安全风险远大于这点性能损耗。

节点证书不是配置一次就永远不管了。证书过期会导致节点间握手失败，轻则集群分裂，重则整个数据库不可用。很多生产事故就是证书到期后节点突然无法通信，运维人员排查半天才发现是证书过期。必须建立证书轮换机制，至少提前一个月开始更新流程。轮换时要考虑数据库是否支持在线重载证书，如果不支持，就需要滚动重启节点。滚动重启期间要保证集群仍然可用，这要求至少保留一个副本在线。证书轮换的另一个细节是CA证书的更新，如果CA证书也过期了，所有节点都会拒绝对方的证书，恢复起来非常麻烦。建议CA证书有效期设长一些，比如五年或十年，节点证书有效期控制在一到两年。

很多分布式数据库部署在混合云或多机房环境中，节点之间的网络链路可能跨越公网或不可信网络。这种情况下，节点通信加密就不仅是内部防护，而是必须的传输层安全措施。跨机房链路上还要考虑额外的网络层加密，比如IPsec或专线加密，但这超出了数据库本身的配置范围。数据库层面的TLS加密解决的是应用层协议的安全，网络层加密解决的是IP包的安全，两者并不冲突，可以叠加使用。在公网链路上，建议同时开启数据库TLS和网络层加密，形成纵深防御。

节点通信加密配置中最常见的错误包括：证书SAN不匹配、私钥权限错误、CA证书未分发到所有节点、TLS版本不兼容、证书链不完整。排查时先看节点日志中的TLS握手错误信息，通常能直接定位到证书问题。如果日志显示“certificate verify failed”，基本就是CA证书不一致或证书链不完整。如果显示“hostname mismatch”，就是SAN配置错误。还有一种隐蔽的问题是系统时间不同步，证书有效期校验依赖系统时钟，节点间时间偏差过大可能导致证书被误判为过期。部署NTP时间同步是节点加密的前提条件之一。

手动为几十个节点配置证书和加密参数效率低且容易出错。建议将证书生成、分发、配置文件渲染纳入自动化流程。可以用Ansible、Puppet或Chef等配置管理工具统一管理节点证书和数据库配置。证书生成可以用内部CA的API或脚本批量完成，证书分发后自动设置文件权限，并触发数据库滚动重启。自动化流程中要加入证书到期检查，定期扫描所有节点的证书有效期，提前告警。对于大规模集群，还可以考虑引入服务网格的证书管理能力，但数据库节点通信通常不走服务网格，还是需要独立的证书管理方案。

配置完成后不能只靠“能连上”来判断加密是否生效。要用抓包工具确认节点间流量确实是密文，比如用tcpdump抓取节点间通信端口的数据包，检查是否能看到明文SQL语句或复制日志内容。如果能看到明文，说明加密没有真正生效，可能是配置未加载或走了其他通信通道。定期审计节点通信加密状态也很重要，包括检查证书有效期、TLS版本、加密套件是否符合安全基线。审计结果要形成报告，作为数据库安全合规的一部分。对于等保或行业合规要求，节点通信加密通常是必查项，没有加密配置基本无法通过安全测评。