分布式数据库负载均衡安全配置要点

分布式数据库一旦上了规模，负载均衡和安全配置就不是两件可以分开考虑的事。很多团队在配置负载均衡时只盯着流量分发和会话保持，结果把数据库端口、内部服务地址甚至管理接口一并暴露到了均衡层，等于在防护最薄弱的入口开了一扇后门。真正要解决的是：流量如何被正确、安全地分发，同时每一次连接、每一条SQL请求都经过可信验证，并且故障切换不会成为权限提升的跳板。

分布式数据库通常由多个计算节点、存储节点和协调节点组成，负载均衡器只应暴露业务所需的计算服务端口。管理端口、监控端口、内部RPC端口一律不接入公网或业务网段的均衡规则。实际配置中，先梳理每个节点上监听的端口清单，明确哪些是外部客户端需要访问的，哪些是节点间通信和运维使用的。负载均衡器的监听器只绑定计算服务端口，其余端口在安全组或防火墙层面直接拒绝。很多安全事故的起点不是数据库被直接攻破，而是管理端口被扫描到后通过弱口令或未授权接口进入。

负载均衡器转发TCP连接时，如果仅依赖数据库自身的用户名密码，攻击者一旦绕过应用服务器，就能直接向数据库发起认证尝试。应在负载均衡层启用客户端证书验证或至少限制来源IP段。对于支持mTLS的负载均衡方案，要求客户端携带由内部CA签发的证书，验证通过后才建立到后端数据库节点的连接。这样即使数据库账号泄露，没有有效证书的连接也会在负载均衡层被丢弃。证书的吊销和更新要有自动化流程，避免因证书过期导致全链路中断。

负载均衡器需要定期探测后端数据库节点的健康状态，但健康检查使用的账号权限必须最小化。很多配置为了方便，直接使用root或admin账号执行健康检查SQL，这相当于把最高权限凭证长期存放在负载均衡器的配置文件中。正确做法是创建一个仅具备连接权限和极少量查询权限的专用账号，例如只允许执行SELECT 1或查询系统心跳表。健康检查的间隔和超时时间也要合理设置，过短会放大瞬时抖动，过长则影响故障切换速度。

分布式数据库的负载均衡经常需要区分读请求和写请求，或者将同一会话的请求固定到某个计算节点。在配置会话保持时，要明确会话标识的来源。如果基于客户端IP做会话保持，攻击者可能通过伪造源IP或利用NAT环境下的共享IP来干扰路由。更安全的方式是基于数据库协议层的会话ID或应用层提供的标识。读写分离场景下，读节点和写节点的权限必须分开配置，读节点账号不应具备写权限，写节点也不应被普通读请求直接访问。负载均衡器可以根据SQL类型或端口进行分流，但SQL解析在均衡层会带来性能开销和误判风险，更稳妥的做法是应用层显式指定读写入口。

如果负载均衡器终止TLS，那么负载均衡器到后端数据库节点之间的流量是否加密就变得关键。很多内网环境认为内部流量不需要加密，但分布式数据库节点间通信一旦被监听，SQL语句中的敏感数据和认证信息就会泄露。建议负载均衡器与后端节点之间也启用TLS，即使内网也要保持加密。如果负载均衡器不终止TLS而是直接透传，那么证书管理和TLS握手压力会落在数据库节点上，这时需要确保所有节点证书的CN或SAN与节点实际地址匹配，避免证书校验失败导致连接中断。

应用服务器通常会维护自己的数据库连接池，而负载均衡器又维护着到后端节点的连接池，两层连接复用会让安全审计变得复杂。一条经过负载均衡器转发的SQL，在后端节点上看到的源地址是负载均衡器的地址，而不是真实客户端地址。这给审计和溯源带来困难。解决办法是在数据库协议层开启代理协议或类似机制，让负载均衡器向后端传递真实客户端IP。同时，连接池的空闲连接超时、最大连接数、连接重用策略要与数据库节点的资源限制匹配，防止某个节点因连接数耗尽而拒绝服务。

分布式数据库发生节点故障时，负载均衡器会自动将流量切到其他节点。如果各节点的账号权限配置不一致，切换后可能出现部分请求因权限不足而失败，或者某个节点上的账号权限过高，成为攻击者利用的薄弱点。必须通过配置管理工具保证所有节点的账号、权限、白名单和参数设置完全一致。定期进行配置比对，发现漂移立即修正。故障切换后的回切过程也要验证权限状态，不能因为节点恢复就自动接入流量，除非确认其安全配置与集群其他节点一致。

负载均衡器是进入数据库的第一道关口，在这里实施限流和异常检测比在数据库内部更高效。针对单个源IP、单个账号或单个会话设置最大连接数和请求速率限制，可以有效缓解暴力破解和异常扫描。当某个源IP在短时间内发起大量失败认证请求时，负载均衡器应能自动将其加入临时黑名单。同时，对SQL请求的大小、频率和模式进行基础检测，发现异常流量时先阻断再告警。限流阈值要结合业务实际峰值设置，避免误伤正常用户。

数据库节点自身的审计日志记录的是已经到达数据库的请求，而负载均衡层可以记录更早的流量信息，包括被拒绝的连接、TLS握手失败、来源IP和端口等。这些信息对于事后溯源和发现攻击行为非常重要。负载均衡器的日志要包含时间戳、源地址、目标地址、连接结果和关键协议字段，日志本身要集中存储并设置访问控制，防止被篡改。日志保留周期要满足合规要求，同时注意日志中不要记录完整的SQL语句或敏感参数，避免二次泄露。

负载均衡器本身也有管理接口，用于修改配置、查看状态和下发策略。这个管理接口绝不能与数据转发接口共用同一个网络路径。最佳实践是使用独立的带外管理网络，或者至少通过严格的ACL限制管理接口只能从指定的运维跳板机访问。管理接口的认证应启用多因素认证，所有配置变更操作要有审批和审计记录。很多负载均衡器支持API方式管理，API的密钥和令牌要定期轮换，并且不同角色使用不同权限的令牌。

# 负载均衡器后端节点配置片段（示意）
backend db_compute_nodes
    balance roundrobin
    option mysql-check user haproxy_check post-41
    server node1 10.0.1.11:3306 check inter 5s fall 3 rise 2 ssl verify required ca-file /etc/ssl/db-ca.pem
    server node2 10.0.1.12:3306 check inter 5s fall 3 rise 2 ssl verify required ca-file /etc/ssl/db-ca.pem
    server node3 10.0.1.13:3306 check inter 5s fall 3 rise 2 ssl verify required ca-file /etc/ssl/db-ca.pem

# 前端监听配置片段（示意）
frontend db_frontend
    bind 10.0.0.10:3306 ssl crt /etc/ssl/db-server.pem ca-file /etc/ssl/client-ca.pem verify required
    mode tcp
    default_backend db_compute_nodes
    tcp-request connection reject if !{ src -f /etc/haproxy/allowed_clients.lst }
    tcp-request content reject if !{ req_ssl_sni -i db.internal.example.com }

上述配置中，前端监听强制客户端证书验证，同时通过ACL限制来源IP，后端节点之间的TLS也强制校验CA。健康检查使用专用账号haproxy_check，该账号在数据库端仅被授予USAGE权限和SELECT 1的执行权限。这种配置将安全边界从数据库内部前移到了负载均衡层，同时保持了故障切换的可用性。

安全配置不是一次设置就永久有效。分布式数据库的节点增减、应用版本更新、网络策略调整都可能引入新的风险。应定期进行配置审查和渗透测试，重点验证负载均衡层是否真的拒绝了未授权连接、证书校验是否在所有路径上生效、故障切换后权限是否保持一致。可以编写自动化脚本模拟异常连接和恶意请求，检查负载均衡器的阻断行为是否符合预期。只有持续验证，才能确保负载均衡和安全配置在动态变化的分布式环境中始终可靠。