每當資料庫用戶端傳送查詢或接收結果集時，資料都會在網路中傳遞。在一個完全隔離且完全不對外的私有網路環境中，這或許是可接受的風險；然而，在多數現實環境中，資料流量往往會經過共用的基礎設施、雲端網路或開放的網際網路，此時未經加密的資料庫連線便會成為重大的資安漏洞。正確設定 SSL/TLS 加密就能填補了這一缺口，而它也是資料庫安全中極其重要卻常被忽視的一步。
為什麼未加密的連線是風險
在沒有加密的情況下，資料庫用戶端與伺服器之間交換的資料將以明文形式傳輸。任何位於相同網路路徑上的攻擊者——例如被入侵的路由器、設定錯誤的雲端虛擬網路，或內部人員威脅——都有可能讀取這些流量。這不僅包含查詢結果，更包括驗證憑證。攻擊者只要從未加密的資料庫連線中擷取到登入封包，無需費力即可獲得有效的使用者名稱與密碼。這種風險並非理論；網路攔截屬於成熟且常見的攻擊手法，而當攔截到的流量是資料庫連線時，其影響會更嚴重。
理解憑證鏈
傳輸層安全協定（TLS）是建立在數位憑證系統之上的。在開始加密通訊前，伺服器會向用戶端出示憑證以證明自己的身分，這等同於在說：「我就是我所聲稱的那台伺服器，這裡有一份由可信任機構頒發的加密簽署文件可以證明。」這個可信任機構就是憑證授權單位（Certificate Authority，CA），其職責是驗證其頒發的憑證的真實性。
在實際操作上，這代表若要與資料庫伺服器建立一個經過正確驗證的 TLS 連線，你需要具備以下三項要素：
- 伺服器必須擁有一份由 CA 核發的有效憑證。
- 用戶端必須擁有一份 CA 憑證副本，以便驗證伺服器的身分。
- （選用）若使用雙向 TLS（mTLS），用戶端也要提供自己的憑證給伺服器做反向驗證。這種可選的用戶端驗證常被稱為憑證型驗證，它能提供比單純密碼驗證更強而有力的保障。
需要了解的關鍵配置選項
在為資料庫連線配置 TLS 時，不同的資料庫系統和用戶端都會有一些相同的參數：
- CA 憑證檔案扮演著信任錨點的角色，它負責告知用戶端在驗證伺服器身分時，應信任哪一個憑證授權單位。
- 當需要雙向 TLS 時，會使用戶端憑證檔案和用戶端金鑰檔案，這能讓伺服器反過來驗證用戶端的身份。
- 密文（Cipher）規格控制了階段作業可接受的加密演算法；由於舊有的密文存在已知弱點，最佳做法是指定現代且強大的密文，而非直接接受預設值。
PostgreSQL 的 SSL 選項
PostgreSQL 的 SSL 模式設定為安全性提供了特別實用的嚴格度控制，讓你能明確定義連線的嚴格程度。這些選項的範疇相當廣泛，從 allow（先嘗試非 SSL 連線，必要時才使用 SSL）和 prefer（先嘗試 SSL 連線，失敗則回退至未加密模式），到較為嚴格的 require（僅使用 SSL，但不驗證憑證）、verify-ca（使用 SSL 並驗證憑證是否來自信任的 CA），以及最嚴密的 verify-full（使用 SSL，驗證 CA，並且必須驗證主機名稱）。針對正式生產環境，verify-ca 或 verify-full 才是合適的選擇，因為任何嚴謹度低於 require 的設定，都可能造成中間人攻擊的風險。
SSH 通道：另一種替代做法
SSL/TLS 是針對資料庫協定本身進行加密，而安全殼層（SSH）通道則用另一種方式：它將整個資料庫連線封裝在加密的 SSH 階段作業中。在這種架構下，資料庫用戶端會連線至本地通訊埠，接著 SSH 隧道會將該流量透過加密連線轉送到遠端伺服器，使得資料庫伺服器端接收到的是來自通道端點的本地連線。SSH 通道在特定情境下顯得格外實用，例如資料庫伺服器尚未配置 TLS，或是基於防火牆安全考量而未對外開放的資料庫通訊埠，因為它僅需 SSH 存取權限，而無需資料庫層級的 TLS 配置。此外，對於需要與位於堡壘機後方的資料庫進行互動式連線的管理員而言，這也是一種實現安全遠端存取且簡單直接的方式。
Navicat 如何支援 SSL/TLS 與 SSH 通道
Navicat 的桌面產品系列——包括 Navicat Premium 以及各個特定資料庫的用戶端——在連線設定介面中直接提供了 SSL/TLS 配置功能，使用者在建立或編輯連線時，即可透過專屬的 SSL 索引標籤進行設定。在該介面中，使用者可以啟用 SSL、提供驗證伺服器身分所需的 CA 憑證檔案，並視需求提供雙向 TLS 所需的用戶端憑證和用戶端金鑰檔案。此外，密文規範欄位允許管理員限制該連線可接受的加密套件，而非僅依賴協商後的預設值。特別針對 PostgreSQL 連線，Navicat 完整支援了前述的所有 SSL 模式選項，讓管理員能精確控制連線驗證的嚴格程度。
Navicat 產品系列也能原生支援 SSH 通道。連線對話方塊中的 SSH 索引標籤允許使用者透過中間 SSH 伺服器配置通道，並同時支援密碼驗證以及公私鑰對驗證模式。這讓連線至未直接暴露於外部網路的資料庫變得簡單且安全。
Navicat On-Prem Server 也將這種 SSL/TLS 支援進一步延伸到協作層面。伺服器與其用戶端之間的連線可以透過 SSL/TLS 進行加密，且管理員能夠針對這些階段作業配置特定的加密套件。此外，SSL/TLS 同樣能套用於 Navicat On-Prem Server 與其底層儲存庫資料庫之間的連線，這確保了協作平台的內部架構實施了端對端加密，而不僅僅是針對終端使用者的連線進行保護。
總結
為資料庫連線配置 SSL/TLS 並非難事，但必需留意細節——憑證管理、模式選擇以及密文配置等，這些環節極易出錯或可能誤用不安全的預設值。正確配置的好處在於能有效降低因網路層級攔截而導致憑證遭竊或資料外洩的風險。對於處理敏感資料，或需經由非隔離私有網路存取的資料庫而言，完善的 TLS 配置絕非選配，而是不可或缺的基礎要求。
