共用方式為


傳輸層安全性和數位憑證

本文描述通訊協定傳輸層安全性 (TLS) 和數位憑證的詳細資料。

傳輸層安全性 (TLS)

TLS 和 SSL 通訊協定位於應用程式通訊協定層和 TCP/IP 層之間,可在其中保護應用程式資料,並將應用程式資料傳送至傳輸層。 TLS/SSL 通訊協定使用加密套件中的演算法來建立金鑰和加密資訊。 用戶端和伺服器會交涉通訊協定版本和加密套件,以用於在連線建立的初始連線 (登入前) 階段進行加密。 TLS 交握中一律偏好最受支援的 TLS 版本。 若要檢查不同 Windows 作業系統版本支援的 TLS 通訊協定版本,請參閱 TLS/SSL 中的通訊協定 (安全通道 SSP)。 SSL 和早期 TLS 版本獲報出現數個已知弱點。 建議您升級至 TLS 1.2 以進行安全通訊。

SQL Server 可使用 TLS 來加密在 SQL Server 執行個體與用戶端應用程式之間的網路傳輸資料。 TLS 使用憑證來實作加密。

啟用 TLS 加密,可提高 SQL Server 執行個體和應用程式之間跨網路傳輸資料的安全性。 不過,使用 TLS 加密 SQL Server 與用戶端應用程式之間的所有流量時,需要下列額外的處理:

  • 在連線時需要額外的網路往返作業。
  • 從應用程式傳送到 SQL Server 執行個體的封包必須利用用戶端 TLS 堆疊來加密,並使用伺服器 TLS 堆疊來解密。
  • 從 SQL Server 執行個體傳送到應用程式的封包必須利用伺服器 TLS 堆疊來加密,並使用用戶端 TLS 堆疊來解密。

重要

從 SQL Server 2016 (13.x) 開始,已停用安全通訊端層 (SSL)。 建議改用 TLS (TLS 1.2)。 如需詳細資訊,請參閱 KB3135244 - Microsoft SQL Server 的 TLS 1.2 支援。 SQL Server 2022 引進 TLS 1.3 的支援。 如需詳細資訊,請參閱 TLS 1.3 支援。 如果用戶端和伺服器電腦之間沒有相符的通訊協定,您可能會遇到 遠端主機強制關閉現有連線中所述的錯誤。

數位憑證概觀

數位憑證是作用像線上密碼的電子檔案,用來確認使用者或電腦的身分識別。 它們是用來建立用於用戶端通訊的加密通道。 憑證是由憑證授權單位 (CA) 簽發的數位聲明,用來擔保憑證持有者的身分識別,並可讓合作對象藉由使用加密來安全通訊。

數位憑證提供下列服務:

  • 加密:它們有助於保護交換的資料免於遭竊或竄改。
  • 驗證:其會驗證其持有者 (人員、網站,甚至是路由器之類的網路裝置) 確實具有所宣稱的身分。 一般而言,驗證是單向驗證,其中來源會驗證目標的身分識別,但也可以進行相互 TLS 驗證。

憑證包含公開金鑰,並且會將該公開金鑰連結至持有相對應私密金鑰的人員、電腦或服務的身分識別。 用戶端和伺服器會使用公開和私密金鑰先行加密資料,然後再傳輸資料。 針對 Windows 使用者、電腦及服務而言,當可信任的根憑證存放區中已定義一份根憑證,且該憑證包含有效的憑證路徑時,就會建立 CA 信任關係。 如果憑證尚未撤銷 (其不在 CA 的憑證撤銷清單或稱 CRL 中) 或過期,則會將其視為有效。

下表描述三種主要數位憑證類型:

類型 Description 優點 缺點
自我簽署憑證 憑證是由建立憑證的設備簽署,或使用 New-SelfSignedCertificate 建立。 成本 (免費) - 用戶端電腦和行動裝置不會自動信任憑證。 憑證必須手動新增至所有用戶端電腦和裝置上的受信任根憑證存放區,但並非所有行動裝置都允許變更受信任的根憑證存放區。

- 並非所有服務都使用自我簽署憑證。

- 難以建立憑證生命週期管理的基礎結構。 例如,無法撤銷自我簽署憑證。
內部 CA 所簽發的憑證 憑證是由組織中的公開金鑰基礎結構 (PKI) 所發行。 範例有 Active Directory 憑證服務 (AD CS)。 如需詳細資訊,請參閱 Active Directory 憑證服務概觀 - 允許組織發行自己的憑證。

- 比來自商業 CA 的憑證便宜。
- 部署和維護 PKI 的複雜度較高。

- 用戶端電腦和行動裝置不會自動信任憑證。 憑證必須手動新增至所有用戶端電腦和裝置上的受信任根憑證存放區,但並非所有行動裝置都允許變更受信任的根憑證存放區。
商業 CA 所發行的憑證 憑證是從受信任的商業 CA 購買。 因為所有用戶端、裝置和伺服器都會自動信任憑證,所以憑證部署已經過簡化。 成本。 您必須事先規劃,才能將所需的憑證數目降到最低。

如需證明憑證持有者符合其所宣稱的身分,憑證必須正確地識別其他用戶端、裝置或伺服器的憑證持有者。 下表描述執行這項作業的三個基本方法:

方法 Description 優點 缺點
憑證主體比對 憑證的 [主體] 欄位包含主機的一般名稱 (CN)。 例如,發行給 www.contoso.com 的憑證可以用於網站 https://www.contoso.com - 與所有用戶端、裝置和服務相容。

- 區隔化。 撤銷主機的憑證不會影響其他主機。
- 所需的憑證數目。 您只能針對指定的主機使用憑證。 例如,即使服務安裝在相同的伺服器上,您也無法將 www.contoso.com 的憑證用於 ftp.contoso.com

- 複雜度。 在網頁伺服器上,每個憑證都需要自己的 IP 位址繫結。
憑證主體別名 (SAN) 比對 除了 [主體] 欄位之外,憑證的 [主體別名] 欄位還包含多個主機名稱的清單。 例如:
www.contoso.com
ftp.contoso.com
ftp.eu.fabirkam.net
- 便利。 您可以將相同憑證用於多個不同網域中的多部主機。

- 大部分的用戶端、裝置和服務都支援 SAN 憑證。

- 稽核和安全性。 您確切知道哪些主機能夠使用 SAN 憑證。
- 需要更多規劃。 建立憑證時,您必須提供主機清單。

- 缺少區隔化。 您無法在不影響憑證中所有主機的情況下,選擇性地撤銷某些特定主機的憑證。
萬用字元憑證比對 憑證的 [主體] 欄位包含的一般名稱為萬用字元 (*) 加上單一網域或子域。 例如,*.contoso.com*.eu.contoso.com*.contoso.com 萬用字元憑證可用於獲得:
www.contoso.com
ftp.contoso.com
mail.contoso.com
彈性。 當您要求憑證時,您不需要提供主機清單,且您可以在未來可能需要的任意數目主機上使用該憑證。 - 您無法將萬用字元憑證與其他頂層網域 (TLD) 搭配使用。 例如,您無法將 *.contoso.com 的萬用字元憑證用於 *.contoso.net 主機。

- 您只能在萬用字元層級使用主機名稱的萬用字元憑證。 例如,您無法將 *.contoso.com 的憑證用於 www.eu.contoso.com。 或者,您無法將 *.eu.contoso.com 的憑證用於 www.uk.eu.contoso.com

- 較舊的用戶端、裝置、應用程式或服務可能不支援萬用字元憑證。

- 擴充功能驗證 (EV) 憑證無法使用萬用字元。

- 需要仔細稽核和控制。 如果萬用字元憑證遭到洩露,其會影響特定網域中的每部主機。