零信任安全運作於一個簡單的前提：絕不基於網路位置而假定信任，並將每一次請求都視為源自開放網路來進行驗證。數十年來，資料庫安全極度依賴邊界防禦，例如防火牆、VPN，以及「企業網路內部一切皆安全」這一假設。零信任則徹底摒棄了這種假設。無論請求是來自辦公室裡的筆記型電腦，還是遠端工作的承包商，每一個連線、每一次查詢以及每一個使用者工作階段都必須經過驗證、授權與加密。本文將為你剖析這種轉變對 DBA 的實際意義，以及像 SSH 通道、SSL/TLS 連線和基於角色的存取管理等日常工具，如何融入零信任方法中。
為什麼僅靠邊界安全已不足夠
DBA 早已深知，資料庫往往是最後一道防線，而非第一道。一個遭到入侵的應用程式伺服器、一組外洩的憑證或一個配置錯誤的雲端執行個體，都能輕易繞過網路層級的防護，將攻擊者直接送達資料庫。零信任重塑了 DBA 的工作職責；與其依賴網路團隊將入侵者阻擋在外，資料庫存取本身就成為一個控制點。這意味著無論網路路徑為何都必須對連線進行加密、為每個帳號授予最少的權限，並在得到證實之前，將每個工作階段（不論是內部還是外部）皆視為未經審核的狀態。
將零信任原則套用於資料庫存取
資料庫層零信任方法的核心在於以下三個實踐：
- 加密每一個連線。 不論流量是跨越網際網路還是保留在內部網段中，都應實施端對端加密，使憑證與查詢結果無法在傳輸過程中被攔截。
- 強制執行最小權限原則。 每個帳號（不論是個人帳號還是服務帳號）都應僅擁有其功能所需的權限，絕不多給。
- 持續進行驗證。 身分驗證不該是一次性的檢查點。強大的憑證處理、工作階段控制以及稽核軌跡，與初始登入同樣重要。
這些實踐不僅僅是抽象的理想，它們可以直接對應到 DBA 每天用於連線與管理資料庫的工具上。
Navicat 如何融入零信任工作流程
Navicat 的連線層直接支援了上述的幾項原則。在加密傳輸中資料方面，它提供了在連線對話方塊中內建的 SSL/TLS 配置，以及 SSH 通道功能。SSH 通道能將整個資料庫工作階段封裝在加密的 SSH 連線中，而非僅依賴資料庫引擎本身的 TLS 設定——當伺服器未配置 TLS 或因防火牆考量未對外開放直接的資料庫通訊埠時，這是一項極其優異的選擇。通道功能同時支援密碼與公鑰/私鑰驗證，為 DBA 提供了比單純靜態密碼更強大的安全保障。
在存取管理方面，Navicat On-Prem Server 透過三層角色系統在專案層級的協作，管理員可以分配存取權限來決定每位成員在專案中可以執行的操作，這與 DBA 透過 Navicat 為 MySQL、PostgreSQL 與 MariaDB 等平台內建的「使用者」與「權限管理員」工具所配置的引擎級精細權限控制相輔相成。
總結
零信任並非單一的產品功能，而是一種思維模式的轉變，即驗證每一個連線並最大限度地減少每個權限。對於 DBA 而言，這種轉變可以透過日常工作流程中已有的工具來實現：使用加密通道取代隱式網路信任，並使用特定角色範圍的存取權限取代廣泛且永久的常設權限。將這些習慣融入日常資料庫管理中，是一種切實可行的循序漸進的方法，可以將零信任原則從架構圖轉換為日常實踐。
