在適用於 PostgreSQL 的 Azure 資料庫 中使用 TLS 和 SSL 的安全連線 - 彈性伺服器

適用範圍：適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器

適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器會強制使用傳輸層安全性將用戶端應用程式連線到 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器。 TLS 是業界標準通訊協定，可確保為資料庫伺服器與用戶端應用程式之間的網路連線加密。 TLS 是安全通訊端層 (SSL) 更新後的通訊協定。

什麼是 TLS？

TLS 是由 Netscape 的 SSL 通訊協定所組成，並已定期加以取代。 SSL 或 TLS/SSL 一詞有時仍可互換使用。 TLS 是由兩層所組成：TLS 記錄顯示和 TLS 交握顯示。 記錄顯示提供關聯安全性。 交握顯示可讓伺服器和客戶相互確認，並在交易任何資訊之前協調加密評估和密碼編譯密鑰。

上圖顯示典型的 TLS 1.2 交握序列，其中包含下列步驟：

1. 用戶端一開始會傳送名為 ClientHello 的訊息，表示願意透過 TLS 1.2 與用戶端支援的一組加密套件進行通訊。
2. 伺服器會透過TLS 1.2 使用特定加密套件來接收訊息、解答 ServerHello，並同意透過TLS 1.2 與客戶端通訊。
3. 伺服器也會傳送其金鑰共用。 此金鑰共用的詳細資料會根據選取的加密套件而變更。 若要讓客戶端和伺服器同意密碼編譯密鑰，他們需要接收彼此的部分，或共用。
4. 伺服器會傳送憑證（由證書頒發機構單位 [CA] 簽署）和 和 ServerHello部分的ClientHello簽章。 它也包含金鑰共用。 如此一來，用戶端就會知道它們是真實的。
5. 用戶端成功接收數據併產生自己的金鑰共用之後，它會將其與伺服器金鑰共用混合，以產生會話的加密密鑰。
6. 用戶端會傳送伺服器其金鑰共用、啟用加密，以及傳送 Finished 訊息。 此訊息是到目前為止所發生狀況的文字記錄哈希。 伺服器會執行相同的動作。 它會混合金鑰共用以取得金鑰，並傳送自己的 Finished 訊息。
7. 現在，應用程式數據可以在連線上加密。

憑證鏈結

憑證鏈結是包含 TLS/SSL 憑證和 CA 憑證的已排序憑證清單。 它們可讓接收者確認寄件人和所有 CA 都值得信任。 鏈結或路徑會以 TLS/SSL 憑證開頭。 鏈結中的每個憑證都會由鏈結中下一個憑證所識別的實體簽署。

鏈結會以根 CA 憑證終止。 此憑證一律由 CA 本身簽署。 鏈結中所有憑證的簽署必須驗證至根 CA 憑證。

鏈結中位於 TLS/SSL 憑證與根 CA 憑證之間的任何憑證，稱為中繼憑證。

TLS 版本

全球數個政府實體會維護 TLS 關於網路安全性的指導方針。 在 美國 中，這些組織包括衛生和人類服務部和國家標準與技術研究所。 TLS 提供的安全性層級受到 TLS 通訊協定版本和所支援的加密套件影響最大。

加密套件是一組演算法，包括加密、金鑰交換演算法和哈希演算法。 它們會一起使用來建立安全的 TLS 連線。 大部分的 TLS 用戶端和伺服器都支援多個替代方案。 當他們建立安全連線時，他們必須交涉以選取一般 TLS 版本和加密套件。

適用於 PostgreSQL 的 Azure 資料庫支援 TLS 版本 1.2 和更新版本。 在 RFC 8996中，網際網路工程任務推動小組 (IETF) 明確指出不得使用 TLS 1.0 和 TLS 1.1。 這兩個通訊協定已在 2019 年底被取代。

所有使用舊版 TLS 通訊協定的連入連線 (例如 TLS 1.0 和 TLS 1.1) 預設遭到拒絕。

IETF 於 2018 年 8 月在 RFC 8446 中發行 TLS 1.3 規格，而 TLS 1.3 現在是使用中最常見的建議 TLS 版本。 TLS 1.3 比 TLS 1.2 更快速且安全。

注意

SSL 和 TLS 憑證會認證您的連線是否受到最先進的加密通訊協定保護。 在網路上加密連線可以防止您的資料在傳輸時遭他人未經授權存取。 強烈建議您使用最新版本的 TLS 來加密連線至 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器。

雖然我們不建議這麼做，但如有需要，您可以停用 TLS\SSL 來連線到 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器。 您可以將伺服器參數更新 require_secure_transport 為 OFF。 您也可以藉由設定和 ssl_max_protocol_version 伺服器參數來設定 ssl_min_protocol_version TLS 版本。

憑證驗證是使用 SSL 用戶端憑證進行驗證 來執行。 在此案例中，PostgreSQL 伺服器會比較針對所要求資料庫用戶呈現之用戶端憑證的一般名稱 （CN） 屬性。

目前，適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器不支援：

• SSL 憑證式驗證。
• 自定義 SSL\TLS 憑證。

注意

Microsoft針對各種 Azure 服務進行根 CA 變更，包括 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器。 如需詳細資訊，請參閱 Azure TLS 憑證變更和在用戶端上設定 SSL 一節。

若要判斷目前的 TLS\SSL 連線狀態，您可以載入 sslinfo 擴充功能，然後呼叫 ssl_is_used() 函式來判斷是否正在使用 SSL。 如果連線使用 SSL，函式會傳 t 回 。 否則會傳回 f。 您也可以使用下列查詢，收集 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器 SSL 使用方式的所有資訊：進程、用戶端和應用程式：

SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
   FROM pg_stat_ssl
   JOIN pg_stat_activity
   ON pg_stat_ssl.pid = pg_stat_activity.pid
   ORDER BY ssl;

若要進行測試，您也可以直接使用 openssl 命令：

openssl s_client -starttls postgres -showcerts -connect <your-postgresql-server-name>:5432

此命令會列印低階通訊協議資訊，例如 TLS 版本和加密。 您必須使用 選項 -starttls postgres。 否則，此命令會報告未使用 SSL。 使用此命令至少需要 OpenSSL 1.1.1 版本。

若要強制執行最新、最安全的 TLS 版本，以便從用戶端連線到 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器，設定ssl_min_protocol_version為 1.3。 該設定需要連線到您 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器的用戶端才能使用此版本的通訊協定，才能安全地通訊。 較舊的用戶端可能無法與伺服器通訊，因為它們不支援此版本。

在客戶端上設定 SSL

根據預設，PostgreSQL 不會執行伺服器憑證的任何驗證。 基於這個理由，可以詐騙伺服器身分識別（例如，修改 DNS 記錄或接管伺服器 IP 位址），而不需要用戶端知道。 所有 SSL 選項都會以加密和金鑰交換的形式帶來額外負荷，因此效能和安全性之間會進行取捨。

若要防止詐騙，必須使用用戶端上的SSL憑證驗證。

有許多連線參數使用於設定 SSL 的用戶端。 其中一些重要事項如下：

• ssl：使用 SSL 進行連線。 此屬性不需要與其相關的值。 其存在僅指定 SSL 連線。 為了與未來的版本相容，建議使用 值 true 。 在此模式中，當您建立 SSL 連線時，客戶端驅動程式會驗證伺服器的身分識別，以防止攔截式攻擊。 它會檢查伺服器證書是否由受信任的授權單位簽署，而且您要連線的主機與憑證中的主機名相同。

• sslmode：如果您需要加密，而且如果無法加密連線，請設定 sslmode=require。 此設定可確保伺服器已設定為接受此主機/IP 位址的SSL連線，而且伺服器可辨識客戶端憑證。 如果伺服器不接受 SSL 連線或無法辨識客戶端憑證，連線就會失敗。 下表列出此設定的值：

  SSL 模式	說明
  disable	未使用加密。
  allow	如果伺服器設定需要或強制執行加密，則會使用加密。
  prefer	如果伺服器設定允許加密，則會使用加密。
  require	使用加密。 它可確保伺服器已設定為接受此主機 IP 位址的 SSL 連線，而且伺服器可辨識客戶端憑證。
  verify-ca	使用加密。 針對客戶端上儲存的憑證，確認伺服器證書簽章。
  verify-full	使用加密。 針對客戶端上儲存的憑證，確認伺服器證書簽章和主機名。

  使用的預設 sslmode 模式在 libpq 型用戶端 （例如 psql） 和 JDBC 之間不同。 以 libpq 為基礎的客戶端預設為 prefer。 JDBC 客戶端預設為 verify-full。

• sslcert、 sslkey和 sslrootcert：這些參數可以覆寫用戶端憑證的預設位置、PKCS-8 用戶端密鑰和跟證書。 它們分別預設為 /defaultdir/postgresql.crt、 /defaultdir/postgresql.pk8和 /defaultdir/root.crt，其中 defaultdir 位於 ${user.home}/.postgresql/ nix 系統和 %appdata%/postgresql/ Windows 上。

CA 是負責頒發證書的機構。 受信任的證書頒發機構單位是有權驗證某人是否為他們所稱的實體。 若要讓此模型運作，所有參與者都必須同意一組受信任的CA。 所有操作系統和大部分的網頁瀏覽器都內建一組受信任的 CA。

使用 verify-ca 和 verify-full sslmode 組態設定也稱為 憑證釘選。 在此情況下，PostgreSQL 伺服器上的根 CA 憑證必須符合憑證簽章，甚至是用戶端上憑證的主機名。

當 CA 在 PostgreSQL 伺服器憑證上變更或過期時，您可能需要定期更新用戶端儲存的憑證。 若要判斷您是否要釘選 CA，請參閱 憑證釘選和 Azure 服務。

如需用戶端上 SSL\TLS 組態的詳細資訊，請參閱 postgreSQL 文件。

針對使用 verify-ca 和 verify-full sslmode 組態設定的用戶端（也就是憑證釘選），必須將三個根 CA 憑證部署到用戶端證書存儲：

• DigiCert Global Root G2 和 Microsoft RSA Root CA 2017 根 CA 憑證，因為服務正從 Digicert 移轉至 Microsoft CA。
• Digicert Global Root CA，以取得舊版相容性。

在憑證釘選案例中下載根 CA 憑證和更新應用程式用戶端

若要在憑證釘選案例中更新用戶端應用程式，您可以下載憑證：

• Microsoft RSA 根 CA 2017
• DigiCert Global Root G2
• Digicert 全域根 CA

若要將憑證匯入用戶端證書存儲，您可能必須從上述 URI 下載憑證檔案之後，將憑證 .crt 檔案轉換成 .pem 格式。 您可以使用 OpenSSL 公用程式來執行這些檔案轉換：

openssl x509 -inform DER -in certificate.crt -out certificate.pem -outform PEM

更新用戶端應用程式證書存儲與新的根 CA 憑證的相關信息記載於 更新應用程式用戶端的用戶端 TLS 憑證中。

重要

某些 Postgres 用戶端連結庫在使用 設定時 sslmode=verify-full ，可能會遇到與中繼憑證交叉簽署的根 CA 憑證聯機失敗。 結果是替代信任路徑。 在此情況下，建議您明確指定 sslrootcert 參數。 或者，將 PGSSLROOTCERT 環境變數設定為本機路徑，其中Microsoft將 RSA 根 CA 2017 根 CA 憑證從 的預設值 %APPDATA%\postgresql\root.crt設定為 。

使用憑證釘選案例讀取複本

透過根 CA 移轉至 Microsoft RSA 根 CA 2017，新建立的複本可以位於較新的根 CA 憑證上，而不是先前建立的主伺服器。 針對使用 verify-ca 和 verify-full sslmode 組態設定的用戶端（也就是憑證釘選），中斷聯機必須接受三個根 CA 憑證：

• Microsoft RSA 根 CA 2017
• DigiCert Global Root G2
• Digicert 全域根 CA

目前，適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器不支持憑證式驗證。

在憑證釘選案例中使用 psql 連線來測試客戶端憑證

您可以使用用戶端的 psql 命令列，在憑證釘選案例中測試伺服器連線能力：

$ psql "host=hostname.postgres.database.azure.com port=5432 user=myuser dbname=mydatabase sslmode=verify-full sslcert=client.crt sslkey=client.key sslrootcert=ca.crt"

如需 SSL 和憑證參數的詳細資訊，請參閱 psql 檔。

測試 TLS/SSL 連線能力

嘗試從用戶端應用程式存取已啟用 SSL 的伺服器之前，請確定您可以透過 psql 存取它。 如果您建立了 SSL 連線，您應該會看到類似下列範例的輸出：

psql (14.5) SSL 連線 (通訊協定：TLSv1.2，加密：ECDHE-RSA-AES256-GCM-SHA384，位元：256，壓縮：關閉) 輸入「說明」以取得協助。

您也可以載入 sslinfo 擴充功能 ，然後呼叫 函 ssl_is_used() 式來判斷是否使用 SSL。 如果連線使用 SSL，函式會傳 t 回 。 否則會傳回 f。

加密套件

密碼套件 是一組加密演算法。 TLS/SSL 通訊協定使用加密套件中的演算法來建立金鑰和加密資訊。

加密套件會顯示為看似隨機資訊的長字串，但該字串的每個區段都包含重要資訊。 一般而言，此數據字串包含數個主要元件：

• 通訊協定 (也就是 TLS 1.2 或 TLS 1.3)
• 金鑰交換或合約演算法
• 數位簽章 (驗證) 演算法
• 大量加密演算法
• 訊息驗證碼演算法 (MAC)

不同版本的 TLS/SSL 支援不同的加密套件。 TLS 1.2 加密套件無法與 TLS 1.3 連線交涉，反之亦然。

目前，適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器支援許多加密套件，其中包含屬於 HIGH：！aNULL 類別的 TLS 1.2 通訊協定版本。

針對 TLS/SSL 連線錯誤進行疑難解答

1. 針對 TLS/SSL 通訊協定版本相容性進行疑難解答的第一個步驟，是識別您或使用者嘗試從用戶端存取 TLS 加密下 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器時所看到的錯誤訊息。 視應用程式和平臺而定，錯誤訊息可能會不同。 在許多情況下，它們會指向基礎問題。

2. 若要確定 TLS/SSL 通訊協定版本相容性，請檢查資料庫伺服器和應用程式用戶端的 TLS/SSL 元件，以確定它們支援相容的版本和加密套件。

3. 分析資料庫伺服器與用戶端 TLS/SSL 版本與加密套件之間的任何差異或差距。 嘗試藉由啟用或停用特定選項、升級或降級軟體，或變更憑證或密鑰來解決問題。 例如，您可能需要根據安全性和相容性需求，在伺服器或用戶端上啟用或停用特定的 TLS/SSL 版本。 例如，您可能需要停用 TLS 1.0 和 TLS 1.1，這被視為不安全和已被取代，並啟用 TLS 1.2 和 TLS 1.3，這些 TLS 較安全且新式。

4. Microsoft RSA 根 CA 2017 發行 的最新憑證在 Digicert Global Root G2 CA 所簽署的鏈結中具有中繼。 某些 sslmode=verify-full Postgres 用戶端連結庫在使用 或 sslmode=verify-ca 設定時，可能會遇到使用中繼憑證交叉簽署的根 CA 憑證聯機失敗。 結果是替代信任路徑。

   若要解決這些問題，請將這三個必要憑證新增至用戶端證書存儲，或明確指定 sslrootcert 參數。 或者，將 PGSSLROOTCERT 環境變數設定為本機路徑，其中Microsoft將 RSA 根 CA 2017 根 CA 憑證置於 預設值 %APPDATA%\postgresql\root.crt。

相關內容

• 了解如何在 [Azure 入口網站]或 [Azure CLI] 中使用 [私人存取 (VNet 整合)] 選項以建立適用於 PostgreSQL 的 Azure 資料庫彈性伺服器。
• 瞭解如何使用 Azure 入口網站 或 Azure CLI 中的 [公用存取][允許的 IP 位址] 選項來建立 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器。