☰

使用 TLS 隧道在多租户环境中安全地远程访问 SQL Server

tag-icon • tag-icon ssl sql-server database-connection
使用 TLS 隧道在多租户环境中安全地远程访问 SQL Server

回答过类似问题这里，并且轻描淡写地提到了打开 SSH 隧道的选项，但大家一致认为 VPN 隧道是最简单的解决方案，如果客户是“内部”用户，情况确实如此。这个问题对于外部客户来说更具体一些。VPN 解决方案的一些问题是：

  • 尝试通过 VPN 连接运行的其他流量
  • 客户可能会“看到”彼此的网络（可以通过关闭防火墙上的大多数端口来解决）
  • Windows 更新经常会破坏 VPN 连接

所有这些问题都可以解决，但事实证明这是一个笨拙的解决方案。

最明显的选择是将所有数据库访问包装到 API 调用中，或者使用第三方 ODBC 驱动程序。我正在寻找一种使用 TLS 隧道（SSL 已被弃用）的解决方案，其方式与建立 Azure 数据库连接的方式相同。

我之前曾使用netshWindows 中的命令更改本地服务的端口。是否可以以类似的方式添加 TLS 隧道？

在客户端，通过添加Encrypt=True连接字符串，已经提供了本机支持。这是 SSMS 客户端选项的屏幕截图： 在此处输入图片描述

所以我的主要问题是：

  • 启用 SQL Server 的 TLS 隧道（非标准）端口的步骤是什么
    • 在 SQL 服务器服务上（如果有）
    • 在运行 SQL 服务器的机器上（我们可以使用类似的工具吗netsh，或者我们需要安装某种代理？）
    • 在防火墙上
  • 我们是否需要购买任何“特殊”类型的证书（我们不想使用自签名证书以防止中间人攻击）或者与常规网站使用的相同类型的证书也可以使用？
  • 为了顺利地将其推广到数千名客户，我们还应该注意什么？

答案1

与建立 Azure 数据库连接的方式相同

本质上，Azure（假设您指的是 Azure SQL，而不是安装在 Azure VM 或其他选项中的 SQL Server）向全世界开放了虚拟 SQL 服务器的接口地址，您可以使用门户的安全/防火墙部分（或相关的 API 调用）中的设置来控制访问。

要使用本地 SQL 服务器模拟此操作，请在边缘防火墙上设置端口转发规则，以允许连接到 SQL 实例的 TCP 端口（默认实例为 1433，除非您更改了它），并使用规则仅允许来自特定源地址的连接（以模拟 Azure 中可设置的规则）。如果您有多个实例，则需要将它们放在固定端口上，否则每次重新启动实例时都需要检查/重新配置端口转发规则。如果您有多个公共 IP 地址，您可以根据需要将每个实例放在标准端口 1433 上，方法是将每个实例放在不同的地址上，或者模拟内部看到的相同端口号。

不过，通常不建议直接向客户端开放 SQL Server，最好使用 VPN 或隧道连接。即使直接连接到 SQL Server 足够安全，零日 SQL 身份验证漏洞或泄露的 SQL 密码也不会立即让您面临危险，因为攻击者需要在先前级别进行身份验证，然后才能对您发起任何攻击。

SSH 已被弃用

你这是什么意思？被贵公司的政策排除在外了吗？SSH 本身并没有被弃用，事实上，它正在获得更广泛的支持，因为 MS 将在未来的 Windows Server 版本中包含 OpenSSH 的本机端口，因此如果您不需要其他选项（Cygwin、Linux 或其他类 unix VM、适用于 Linux 的 Windows 子系统、单独的类 unix 机器），如果您出于其他原因不需要它们的话。

可以添加 SSH 隧道吗

您链接到的 ODBC 驱动程序特别提到了对基于 SSH 的隧道的支持，所以是的。您必须查看其文档以了解如何执行此操作。

要手动使用 SSH 隧道而不是第三方驱动程序，您只需要在同一个网络上运行一个 SSH 服务器，配置为允许隧道，并通过防火墙打开 SSH 端口，就像允许从外部直接连接 SQL Server 一样。然后，您将需要管理该 SSH 服务上的帐户/密码/密钥。通过隧道访问 SQL 实例很简单，其中111.111.111.111 是相关的公共地址（或其 DNS 名称），222.222.222.222 是 SQL 服务器的内部地址。然后客户端连接到（）。如果他们有一个在端口 1433 上监听的本地实例，那么他们需要将隧道规范更改为其他内容，例如，然后他们将连接到。ssh [email protected] -L1433:222.222.222.222:1433localhost127.0.0.1-L12345:222.222.222.222:1433locathost:12345

我不会进一步详述，因为我们与您的问题标题“使用 TLS 隧道”无关，因为 SSH 不是基于 TLS 的。

多租户环境

您可能需要充实您的问题以包含您的意思，因为该短语可能指几件事中的一件或多件（多个客户端使用相同的数据库，在相同的实例上使用不同的数据库，在同一服务器/网络上使用不同的实例，...）。

通过代理建立 TLS 隧道 （关于更新后的问题）

确实存在用于普通服务的简单 TLS 代理，我以前听说过一些，但我并不是专家，因为我从未需要使用它们（对于非 Web 流量，使用 SSH 或 VPN，对于 HTTPS，使用 HTTP 特定工具）。使用这种解决方案，您需要在客户端计算机上安装一半代理，并在服务器端的防火墙内安装一半服务器（通过端口映射）。客户端接受普通连接，与其服务器端建立加密链接，通过该链接代理传输，服务器端与服务器建立真正的（普通）连接。

https://github.com/square/ghostunnel是快速搜索“TLS 代理”后得到的第一个示例。毫无疑问，通过更深入的搜索，您还会找到其他示例。

但是，需要客户端安装可能会使这种解决方案对您的客户来说不适用。

内置加密支持

本地快速测试表明加密选项“有效”。如果您没有在服务器上安装“正确”的证书，则客户端的连接将需要使用“信任服务器证书”选项，但这会使您容易受到 MitM 攻击。

https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/enable-encrypted-connections-to-the-database-engine建议将其设置为使用真实验证的证书并不困难（“服务器身份验证”要求由通常为 HTTPS 颁发的证书涵盖）。如今，单个名称的 SSL 证书很便宜，事实上，另一个快速搜索表明使用 LE 的免费证书并不困难：https://sqlsunday.com/2017/11/22/encrypting-tds-with-letsencrypt/

由于 MS 似乎认为此功能对于 Azure SQL 来说足够安全，我并没有听到你所期望的喧嚣不是除非您的客户端使用的软件不支持加密 TDS 连接，否则这可能是可行的方法。

确保为每个 SQL Server 实例启用“强制加密”选项，否则您的客户端可能会忘记并保持其传输开放。

相关内容