使用 TLS 隧道在多租戶環境中保護對 SQL Server 的遠端訪問
此處回答了一個類似的問題，並且對打開 SSH 隧道的選項進行了輕微改動，但一致認為 VPN 隧道將是最簡單的解決方案，如果客戶端是“內部”使用者，這是正確的。這個問題對外部客戶來說更具體一些。VPN解決方案的一些問題是：
- 其他試圖通過 VPN 連接執行的流量
- 客戶可能會“看到”彼此的網路（可以通過關閉防火牆上的大多數埠來解決）
- Windows 更新經常中斷 VPN 連接
所有這些問題都可以解決，但事實證明這是一個笨拙的解決方案。
最明顯的選擇是將所有數據庫訪問封裝到 API 呼叫中或使用3rd-party ODBC 驅動程序。我正在尋找一種使用 TLS 隧道（不推薦使用 SSL）的解決方案，其方式與建立 Azure 數據庫連接的方式相同。
我之前
netsh在 Windows 中使用過該命令來更改本地服務的埠。可以以類似的方式添加 TLS 隧道嗎？
Encrypt=True在客戶端，通過添加到連接字元串已經有了本機支持。這是 SSMS 客戶端選項的螢幕截圖：所以我的主要問題是：
啟用到 SQL Server 的 TLS 隧道（非標準）埠的步驟是什麼
- 在 SQL Server 服務上（如果有）
- 在執行 SQL 伺服器的機器上（我們可以使用類似工具的
netsh工具還是需要安裝某種代理？）- 在防火牆上
我們是否需要購買任何“特殊”類型的證書（我們不想使用自簽名來防止中間人攻擊）或者與正常網站使用的相同類型的證書也可以工作？
為了順利將其推廣到成千上萬的客戶，我們還應該記住什麼？
以同樣的方式建立 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-a-像 VM、Linux 的 Windows 子系統、單獨的類 unix 機器），如果您出於其他原因不需要它們。
可以添加 SSH 隧道嗎
您連結到的 ODBC 驅動程序特別提到了對基於 SSH 的隧道的支持，所以是的。您必須查看他們的文件以了解如何執行此操作。
要更手動地使用 SSH 隧道而不是 3rd 方驅動程序，您只需要在同一網路上執行的 SSH 伺服器，配置為允許隧道，並且通過防火牆打開 SSH 埠，就像允許直接 SQL Server 連接一樣外。然後，您將需要管理該 SSH 服務上的帳戶/密碼/密鑰。通過隧道訪問 SQL 實例就像
ssh user@111.111.111.111 -L1433:222.222.222.222:1433111.111.111.111 是相關的公共地址（或它的 DNS 名稱）和 222.222.222.222 是 SQL 伺服器的內部地址一樣簡單。然後客戶端連接到localhost(127.0.0.1)。如果他們有一個在埠 1433 上偵聽的本地實例，那麼他們需要將隧道規範更改為其他內容，例如-L12345:222.222.222.222:1433，他們將連接到locathost:12345.我不會進一步詳細介紹，因為我們與您的問題標題“使用 TLS 隧道”無關，因為 SSH 不是基於 TLS 的。
多租戶環境
您可能需要充實您的問題以包含您的意思，因為該片語可以指代多種事物中的一種或多種（多個客戶端使用相同的數據庫，在相同的實例上使用不同的數據庫，在相同的實例上使用不同的實例伺服器/網路，…）。
通過代理的 TLS 隧道 （關於更新的問題）
確實存在用於普通服務的簡單 TLS 代理，我過去聽說過一些但我不是專家，因為我從來沒有需要使用它們（使用 SSH 或 VPN 代替非 Web 流量和 HTTP 特定工具對於 HTTPS）。使用這種解決方案，您需要在客戶端電腦上安裝一半的代理，以及在伺服器端的防火牆內的伺服器一半（通過埠映射到它）。客戶端接受普通連接，與伺服器端建立加密連結，通過該連結傳輸代理，伺服器端與伺服器建立真實（普通）連接。
https://github.com/square/ghostunnel是第一個快速搜尋“TLS 代理”的範例。毫無疑問，您會通過更深入的搜尋找到其他人。
但是，客戶端安裝的需要可能使這種解決方案對您的客戶來說是不可行的。
內置加密支持
在本地進行的快速測試表明加密選項“正常工作”。如果您尚未在伺服器上安裝“正確”證書，則客戶端連接將需要使用“信任伺服器證書”選項，但這會使您容易受到中間人攻擊。
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 來說足夠安全，而且我還沒有聽說過你所期望的不存在的 hoo-hah，除非你的客戶使用不支持的軟體，否則這可能是可行的方法加密的 TDS 連接。
確保為每個 SQL Server 實例啟用“強制加密”選項，否則您的客戶端可能會忘記並保持其傳輸打開。