分布式数据库内网访问管控禁止公网直连节点

分布式数据库一旦将节点端口暴露在公网，等同于把核心数据资产直接推到攻击面最前线。很多团队在部署TDSQL、OceanBase、GaussDB或自研中间件时，为了运维方便，习惯把管理端口和计算节点端口直接绑定公网IP，再用防火墙做IP白名单限制。这种做法的风险在于，白名单IP本身可能被突破、被伪造，或者运维人员临时加了一条0.0.0.0/0规则后忘记回收，数据库就直接裸奔。更隐蔽的问题是，即便端口不直接开放，只要节点监听了0.0.0.0，就存在被内网横向穿透后从公网侧发起代理转发的可能。所以“禁止公网直连节点”不是一句口号，而是一套从网络架构、访问链路、认证机制到审计策略的完整管控体系。

先明确一个核心原则：分布式数据库的所有计算节点、存储节点、管理节点，都应当只监听内网地址。以MySQL协议为主的分布式数据库，通常可以在配置文件中将bind-address设置为内网网卡IP，而不是0.0.0.0。例如TDSQL的proxy节点配置中，修改sqlengine的监听地址为10.x.x.x，同时确认管理控制台的API端口只在内网网卡上开放。对于使用TiDB架构的系统，tidb-server的--host参数应显式指定内网IP，PD和TiKV同样需要检查advertise-address是否泄漏了公网地址。很多云上部署的实例，即使安全组默认不放行，但如果advertise-address被设置为公网IP，客户端拿到连接串后仍然会尝试直连公网，这会给后续网络策略带来不必要的复杂度。

最有效的第一道防线是网络隔离。将分布式数据库集群放入独立的VPC或子网，通过路由表控制该子网不配置任何指向公网网关的路由。对于必须访问公网以下载补丁或同步时间的场景，单独设置NAT网关出口，但数据库节点本身不持有公网IP，也不允许入方向公网流量。在云环境下，安全组规则应默认拒绝所有入站流量，只放行来自应用服务器所在安全组的特定端口。例如只允许应用网段访问计算节点代理端口3306或4000，管理端口只允许运维跳板机网段访问。这里要特别注意，安全组规则不要使用0.0.0.0/0作为来源，哪怕端口不是数据库端口，也会给端口扫描和漏洞利用留下空间。

对于跨地域或多机房部署的分布式数据库，内网专线或云联网是唯一推荐的互联方式。如果业务方提出“临时用公网连一下测试”，应当直接拒绝，并提供基于内网VPN或专线的替代方案。这里的VPN指企业内部的加密隧道接入方案，用于让远程运维人员先进入内网，再从内网访问数据库，而不是让数据库节点暴露公网。所有访问路径都必须先经过企业内网边界的安全设备，再到达数据库。

分布式数据库通常有多个计算节点，应用直连任意节点虽然能提升性能，但会让访问管控变得极其困难。建议在应用与数据库之间部署统一的访问代理层，例如使用数据库中间件、负载均衡器或专门的数据库网关。这个代理层对内连接所有计算节点，对外只暴露一个内网虚拟IP。应用配置的连接串永远指向这个虚拟IP，而不是任何一个具体节点。这样做的另一个好处是，当节点扩缩容或故障切换时，应用无感知，同时所有访问流量都经过统一入口，便于做访问控制和审计。

如果架构上必须让应用直连多个计算节点，那么至少要在每个节点前放置内网负载均衡，并且负载均衡器只绑定内网地址。对于云上环境，可以使用云厂商的数据库代理服务，但同样要确认该代理的公网访问开关处于关闭状态。很多云数据库默认会提供一个公网地址选项，这个选项在生产环境中必须保持关闭，如果曾经开启过，需要立即关闭并检查是否已有异常连接记录。

禁止公网直连后，内网访问的认证强度同样需要提升。分布式数据库的账号体系往往比单机数据库更复杂，因为涉及多个节点之间的内部通信账号和业务访问账号。内部通信账号的密码要单独管理，不能与业务账号混用，并且要限制其来源IP只能是集群内部节点。业务账号的授权要遵循最小权限原则，禁止使用root或超级账号直接给应用使用。对于必须执行DDL的运维操作，通过独立的运维账号并限制来源IP为跳板机网段。

在认证机制上，建议启用SSL/TLS加密连接，即使在内网环境，也应该防止流量被嗅探。同时可以结合企业内部的统一身份认证系统，使用LDAP或Kerberos进行数据库登录认证，避免数据库本地密码的滥用。对于分布式数据库的管理控制台，例如TDSQL的赤兔、OceanBase的OCP，这些管理平台的Web端口绝不能暴露公网，登录认证应接入企业SSO，并开启双因素认证。管理平台一旦被攻破，攻击者可以直接下发删除节点、清空数据的指令，比直接连数据库更危险。

策略配置得再严格，如果没有审计和监控，就无法确认是否真的生效。数据库审计日志需要记录所有连接请求的来源IP、账号、客户端工具、连接时间和执行的SQL类型。对于来源IP不属于已知内网网段的连接，应触发实时告警。很多分布式数据库自带审计功能，例如OceanBase的审计视图、GaussDB的审计日志，需要确保这些审计功能处于开启状态，并且日志输出到独立的日志平台，而不是只存在本地。

网络层同样需要配合监控。在VPC流日志或云防火墙中，重点观察是否有来自公网IP的入站连接尝试访问数据库端口，即使被安全组拦截，这些尝试本身也说明有人在扫描。对于内网中出现的异常横向连接，例如某台Web服务器突然大量连接数据库管理端口，也需要及时排查。定期做一次“公网暴露面扫描”，使用企业内部的资产测绘工具，检查所有数据库节点是否意外绑定了公网IP，或者安全组规则中是否存在0.0.0.0/0的放行条目。

实际执行时，可以按照下面的清单逐项核对：第一，所有数据库节点的监听地址是否只包含内网IP，没有0.0.0.0或公网IP；第二，云控制台中数据库实例的公网访问开关是否全部关闭；第三，安全组或防火墙规则中是否存在来源为0.0.0.0/0的入站规则，如果有，是否已经清理；第四，应用连接串是否全部指向内网代理或负载均衡，没有直连具体节点的公网地址；第五，管理控制台和运维端口是否只允许跳板机网段访问；第六，数据库账号是否全部限制了来源IP，是否存在无来源限制的账号；第七，审计日志是否记录了所有连接来源，并且有异常来源告警；第八，跨地域访问是否全部走专线或内网互联，没有公网直连路径。

对于已经存在公网直连历史的集群，整改时不能直接关闭公网，否则会影响业务。需要先梳理出所有通过公网连接的客户端来源，逐一迁移到内网通道，确认业务正常后再关闭公网入口。迁移过程中可以设置一个过渡期，在安全组中只放行特定来源IP的公网连接，但过渡期必须有明确截止时间，并且每天检查连接日志，确认这些来源IP的流量是否在逐步减少。过渡期结束后，直接删除公网规则，并观察是否有业务报错。

分布式数据库的内网访问管控是一个持续的过程，不是一次配置就一劳永逸。每当有新节点加入、新应用上线、或者云资源发生变更，都需要重新检查暴露面。将“禁止公网直连节点”作为数据库上线前的强制检查项，纳入变更管理流程，才能从根本上避免因人为疏忽导致的数据暴露。安全策略的最终目标不是给运维增加麻烦，而是让正确的访问路径成为唯一路径，让错误的路径从一开始就不存在。