SQL Server Always On高可用架构的安全配置

SQL Server Always On 可用性组是数据库高可用架构中的核心方案，但多数运维人员在部署时把精力都放在搭建步骤和故障转移测试上，安全配置往往被压缩成“能跑就行”的几条简单规则。实际上，Always On 涉及多个端点、服务账户、加密证书和跨节点通信链路，任何一个环节的疏忽都可能让整个高可用集群暴露在横向移动、凭据窃取或数据篡改的风险之下。下面直接拆解每个安全层面该做什么、怎么做。

Always On 通过数据库镜像端点在各节点间同步数据，这个端点的安全配置直接决定数据在网络上是否以明文传输。在创建端点时，很多人习惯使用默认的加密设置，但默认行为取决于 SQL Server 版本和操作系统补丁级别，不能靠运气。创建端点时必须显式指定加密算法和身份验证方式。推荐使用 AES 算法，并强制基于证书的身份验证，而非 Windows 身份验证，因为证书认证不依赖域账户的可用性，且在跨域或工作组集群中更可控。具体配置时，先在 master 数据库中创建主密钥和证书，然后创建端点时绑定该证书。

-- 创建主密钥
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '强密码字符串';

-- 创建用于端点认证的证书
CREATE CERTIFICATE AG_Endpoint_Cert
   WITH SUBJECT = 'AlwaysOn Endpoint Certificate',
   EXPIRY_DATE = '2026-12-31';

-- 创建端点，强制使用 AES 加密和证书认证
CREATE ENDPOINT Hadr_endpoint
   STATE = STARTED
   AS TCP (LISTENER_PORT = 5022)
   FOR DATABASE_MIRRORING (
      AUTHENTICATION = CERTIFICATE AG_Endpoint_Cert,
      ENCRYPTION = REQUIRED ALGORITHM AES,
      ROLE = ALL
   );

创建完成后，必须将证书备份并安全地分发到其他副本节点，在每个节点上创建相同的证书（从备份文件还原），并授予相应用户对证书的访问权限。证书私钥的保护是重中之重，备份文件应存储在只有 SQL Server 服务账户和授权管理员能访问的路径下，且备份密码需满足复杂度要求并纳入企业密码管理流程。

Always On 集群中每个 SQL Server 实例的服务账户权限过大是常见问题。不少企业直接给域管理员权限，或者让所有节点共用同一个账户，这为攻击者提供了极大的便利。正确的做法是：每个节点的 SQL Server 服务账户使用独立的域账户，且只授予必要的权限。这些账户需要具备“作为服务登录”的本地安全策略权限、对 SQL Server 数据目录和备份目录的完全控制、以及对可用性组端点证书私钥的读取权限。如果使用 Always On 的 Kerberos 身份验证，还需要在域中为 SQL Server 服务账户注册服务主体名称，但不要授予这些账户修改自身 SPN 的权限，防止攻击者通过 SPN 劫持进行中间人攻击。

此外，SQL Server Agent 服务账户同样需要独立管理，且不应与数据库引擎服务账户混用。如果可用性组配置了自动种子设定，Agent 账户还需要对共享备份路径的读写权限，这个共享路径的访问控制列表应严格限制，仅允许参与可用性组的各节点计算机账户和 Agent 服务账户访问，禁止其他任何用户或服务读取。

监听器是客户端访问 Always On 的入口，其安全配置常被忽略。监听器名称需要在 DNS 中注册，并依赖 Kerberos 或 NTLM 进行身份验证。为确保使用更安全的 Kerberos 而非 NTLM，必须正确配置 SPN。如果 SPN 配置不当，客户端回退到 NTLM，不仅性能受影响，还可能遭受 NTLM 中继攻击。监听器的 SPN 应注册在监听器名称对应的计算机对象上，且该计算机对象必须由域管理员预先创建并禁用，防止被意外删除或接管。

另一个关键点是监听器端口。默认端口 1433 虽然方便，但也是扫描器重点探测的目标。建议将监听器配置在非标准端口上，并在防火墙策略中精确限定允许访问该端口的客户端 IP 段。同时，在 SQL Server 配置管理器中，对监听器绑定的 IP 地址启用“强制加密”选项，或在连接字符串中要求 Encrypt=yes，确保客户端到监听器的所有流量都经过 TLS 加密。

Always On 节点之间除了端点通信（默认 5022 端口），还涉及集群心跳、文件共享见证、以及可能的备份共享路径访问。这些通信链路应当部署在独立的专用 VLAN 中，与客户端访问网络和服务器管理网络完全隔离。专用心跳网络不仅提升集群稳定性，也减少了攻击者从普通网络嗅探集群通信的可能性。Windows 防火墙必须在每个节点上启用，并创建入站规则，仅允许来自其他节点 IP 的 5022 端口、135 端口（RPC）、445 端口（SMB，如使用文件共享见证）、以及集群服务所需的高端口范围。规则应精确到 IP 地址段而非整个子网，因为子网内可能存在其他非集群服务器。

对于跨数据中心的 Always On 部署，节点间通信通常经过广域网链路，此时必须部署 IPsec 或通过 VPN 隧道加密整个通信通道。仅依赖端点加密是不够的，因为集群服务和 SMB 流量可能仍然明文传输。IPsec 策略应使用 IKEv2 和 AES-256 加密，并在两端设备上配置预共享密钥或证书认证。

Always On 允许将备份任务卸载到辅助副本，这虽然减轻了主副本的压力，但也引入了新的安全风险：辅助副本上的备份文件同样包含完整数据，且辅助副本可能允许只读访问。必须确保辅助副本的备份路径权限与主副本保持一致，且备份文件在存储层面就进行加密。SQL Server 的透明数据加密在此场景下尤为重要，因为备份文件离开数据库引擎后，其安全性完全依赖文件系统和存储管理员。启用 TDE 后，即使备份文件泄露，没有证书和密钥也无法还原。

对于配置了只读路由的辅助副本，应创建专用的只读登录账户，并严格限制其权限。这些账户不应具有查看服务器状态、执行 DMV 查询等高权限操作，仅授予目标数据库的 db_datareader 角色。同时，在可用性组属性中，可以设置“可读辅助副本”的访问级别为“仅读意向”，这样只有连接字符串中指定 ApplicationIntent=ReadOnly 的连接才会被路由到辅助副本，普通读写连接不会意外分流。

Windows Server 故障转移集群的仲裁配置是 Always On 的底层支撑，其安全性直接影响整个高可用架构的稳定性。如果使用文件共享见证，该共享必须位于非集群节点的独立服务器上，且共享权限仅授予集群名称对象和集群各节点的计算机账户。共享所在的文件夹应启用访问审计，记录所有访问尝试。更安全的选择是使用云见证或磁盘见证，其中云见证通过 HTTPS 与 Azure Blob 存储通信，需要保护存储账户的访问密钥，定期轮换密钥，并使用存储账户的防火墙限制仅允许集群节点出口 IP 访问。

集群本身的操作也需加固。默认情况下，任何域用户都可以读取集群配置信息，这可能泄露可用性组的拓扑结构和节点信息。应通过集群权限设置，限制只有指定的安全组才能读取集群属性。此外，定期检查集群日志，关注异常的节点加入或资源组变更事件，结合 SIEM 系统进行实时告警。

安全配置不是一次性工作。Always On 环境需要持续监控证书过期时间、端点状态、以及异常登录尝试。证书过期会导致端点通信中断，进而触发故障转移甚至数据丢失。应建立证书到期前 30 天的自动告警机制，并在运维流程中纳入证书更新步骤。SQL Server 错误日志和 Windows 安全事件日志中会记录端点认证失败、登录失败等关键信息，应将这些日志接入集中日志分析平台，设置针对 5022 端口暴力破解、异常账户登录可用性组相关 DMV 的检测规则。

对于合规性要求高的行业，还需定期对 Always On 配置进行安全基线扫描。检查项包括：端点是否启用加密、是否使用证书认证、服务账户权限是否符合最小权限、TDE 是否启用、备份文件是否加密存储、防火墙规则是否精确、以及集群仲裁配置是否安全。这些检查可以编写 PowerShell 脚本自动化执行，并将结果输出为合规报告留存。

Always On 的安全配置需要从端点、账户、网络、加密、审计五个维度同步推进，任何一个维度的短板都可能成为攻击入口。关键是摒弃“内网即安全”的假设，以零信任的思路对待每个通信链路和每个服务账户。上述配置项在搭建新集群时就应该纳入标准部署清单，对于已上线的环境，可以分阶段逐步加固，优先处理端点加密和证书认证，再收紧服务账户权限，最后完善网络隔离和审计监控。这样既能控制变更风险，又能快速提升整体安全水位。