Excel 连接合作伙伴的 SQL Server：无需域信任

一个 Excel 工作簿要打开另一家组织的 SQL Server 上的表，需要三样东西，而人们常把它们当成一件事来讨论：服务器接受的身份、客户端验证的传输，以及双方都允许的网络路径。域信任是满足第一项的一种方式，也是最宽泛的一种。TLS 满足第二项，却对第一项只字不提。路径满足第三项，其本身不提供任何保护。

把这三者分开，电子表格就变成一个小而可审阅的请求，而不是一段行政关系。

这个问题藏着的三个决定

身份是指数据库认为你是谁：来自受信任域的 Windows 账户、带自己密码的 SQL 登录，或基于证书的身份。传输是指会话是否加密、客户端是否检查服务器的证书链。路径是指数据包如何到达侦听器，可能是 VPN、专用链路，或带防火墙规则的公网端点。三者各在一处，也各自可能单独失效。

林信任能宽泛地满足第一项，而它是组织之间的关系，不是单个工作簿的设置。它也不加密任何东西，这让那些以为信任就是安全控制的人感到意外。

没有林信任时的身份

在目标环境中专门预置的账户可以在没有任何信任的情况下满足更窄的需求，前提是客户端流程能用上它。策略允许时，SQL 身份验证是另一种常见答案：该登录自带凭据生命周期，不加入域，也不产生 Windows 集成身份验证。基于证书或令牌的身份是较新平台上的第三种选择。无论选哪种，只授予工作簿真正需要的数据库权限。

优先使用专用账户，而不是某人的个人登录。表格里的共享凭据是迟早要发生的支持问题，而具名账户让项目结束时可以撤销。

加密是要的，可证书还信吗

使用 ODBC Driver 18 时，Encrypt=Yes;TrustServerCertificate=No 要求的是证书确实被检查的加密会话。连接字符串必须写明证书覆盖的服务器名，客户端也必须信任其证书链。Driver 18 还与早期版本不同，默认就加密，因此旧连接字符串现在可能在未声明的情况下协商 TLS。显式设置让既定策略在每台机器上都可见，当多人维护同一个工作簿时这一点很重要。

TrustServerCertificate=Yes 会加密但跳过验证，对于名称不匹配或不受信任的证书链，这并不是等价的修复。它去掉了本可以告诉你客户端连到了错误端点的信号，所以要改的是证书或名称。

服务器端强制是另一项控制。如果加密必须适用于每个客户端，就配置并核实服务器的强制加密设置，因为一条配合的连接字符串什么也强制不了。

网络路径不是保护

通过 VPN 到达的专用侦听器能减少暴露面，而要让这一点成立，VPN 必须携带正确的目标与返回路由。隧道能用，并不能免除身份验证或证书验证的需要，TLS 也不限制哪些远程系统可以尝试连接。这是三个彼此独立的观察：TLS 握手、VPN 登录和一次被授权的查询。只有第三项能证明工作簿读到了它被允许读的数据。

所以，不要用把数据库暴露到公网来回答信任问题这条捷径。窄答案通常是：专用账户、经过验证的加密，以及一条获批的路径，顺序也是如此。

用常规的 Excel 流程核实：被接受的身份、实际生效的权限，以及协商出的加密，每一项都通过服务器自身的会话视图来检查。