題幹與適用場景
團隊計畫從 PostgreSQL 18 升級到 PostgreSQL 19。現有叢集使用 RADIUS 和部分 MD5 密碼驗證，客戶端包括應用程式、維運腳本和 BI 工具。請說明如何盤點依賴、選擇替代驗證、驗證客戶端並設定停止條件。
PostgreSQL 官方的 19 Beta 說明這是預發布功能預覽，不建議直接用於生產。19 的遷移說明移除了 RADIUS，並會在成功的 MD5 驗證後發出警告；RADIUS 僅支援 UDP，官方說明其安全性無法修復。題目考察驗證遷移的證據鏈，不要求假設所有環境都受影響。
面試官考察點
面試官會關注你是否區分驗證協定移除、密碼儲存格式和客戶端能力，能否建立完整依賴清單、最小權限替代方案、可觀測灰度與明確回滾。高品質回答還會說明 Beta 結論不能等同於最終版承諾，並避免把 MD5 警告誤說成已經禁止連線。
回答前需要釐清的問題
- 目前 PostgreSQL 版本、目標版本和計畫中的正式版時間是什麼？
- 哪些入口使用 RADIUS，哪些使用者或連線仍使用 MD5？
- 客戶端驅動、連線池、維運工具是否支援 SCRAM、憑證或外部身分代理？
- 驗證伺服器、網路路徑、稽核要求、故障轉移和緊急帳號如何管理？
- 遷移期間允許的中斷時間、回滾窗口和安全負責人是誰？
30 秒回答框架
「我先把 Beta 當作隔離驗證對象，盤點所有 pg_hba.conf 規則、使用者密碼格式、客戶端和 RADIUS 依賴，再在 PostgreSQL 19 測試叢集驗證 SCRAM、憑證或受控身分代理。先讓同一身分同時具備新舊路徑，在不寫入生產的環境回放連線、故障轉移和稽核場景；逐步切換低風險租戶，觀察驗證失敗、延遲和稽核缺口。任何無法登入、權限擴大、稽核缺失或回滾失敗都停止，並保留舊叢集和舊驗證路徑。」
分步驟深入解答
1. 先建立依賴清單
匯出並評審 pg_hba.conf、角色屬性、密碼儲存方式、連線來源、客戶端版本、連線池和自動化腳本。把 RADIUS、MD5、SCRAM、憑證和外部代理分別標記，記錄每條規則的使用者、網段、資料庫、優先級和負責人。不要只搜尋應用程式儲存庫，因為臨時腳本和 BI 工具也可能持有連線憑據。
2. 區分移除與警告
PostgreSQL 19 的遷移說明移除了 RADIUS；成功的 MD5 驗證會觸發客戶端警告，且可透過 md5_password_warnings 控制。警告表示仍需遷移，不等同於目前連線已被拒絕。RADIUS 依賴必須在升級前替換，MD5 依賴則要安排密碼和規則遷移，避免把兩種風險混為一談。
3. 選擇替代驗證並限制權限
優先評估 SCRAM-SHA-256、客戶端憑證或既有企業身分代理，具體選擇取決於客戶端支援、金鑰生命週期、網路邊界和稽核要求。為遷移建立短期、最小權限帳號，禁止共用超級使用者；新舊帳號分離，設定到期時間和負責人。驗證方案要能覆蓋故障轉移、唯讀副本、維運 break-glass 帳號和離線復原。
4. 在隔離環境驗證連線矩陣
用去識別資料和獨立憑據複製生產拓撲，逐項驗證應用程式、連線池、遷移工具、備份復原、監控和故障轉移。為每種客戶端固定驅動版本，記錄驗證方式、TLS、連線耗時、失敗原因和稽核事件。可以先讓同一角色存在新舊登入路徑，但禁止讓測試憑據存取生產。
psql "host=pg19-test dbname=app user=app_scram sslmode=verify-full" -c 'select 1'
psql "host=pg19-test dbname=app user=app_cert sslmode=verify-full" -c 'select 1'5. 設計灰度、閘門與回滾
先切換低風險租戶或非關鍵作業，再擴大範圍。設定驗證失敗率、連線延遲、密碼重設成功率、稽核事件完整率和故障轉移成功率的閾值；任何權限擴大、無法登入、稽核缺口或復原失敗立即停止。保留 PostgreSQL 18 的可啟動副本、舊規則版本、密碼輪換記錄和回滾腳本，並驗證舊客戶端仍能在回滾窗口內恢復。
6. 記錄 Beta 的不確定性
Beta 版本的行為和介面仍可能變化。把測試結論寫成「在某客戶端、某驗證設定和某測試資料上的結果」，記錄版本、設定雜湊和已知問題；等待正式版再做最終批准。不要因為測試叢集成功就聲稱所有客戶端都相容。
高品質示範回答
我會先凍結 PostgreSQL 18 的驗證基線，匯出 pg_hba.conf、角色、客戶端和 RADIUS 依賴，按入口和負責人建立矩陣。由於 PostgreSQL 19 移除 RADIUS，我會在隔離叢集為受影響身分驗證 SCRAM、憑證或企業身分代理，並單獨處理仍使用 MD5 的使用者；MD5 成功驗證警告說明要遷移，不表示已全面拒絕。接著回放應用程式、連線池、腳本、備份復原和故障轉移，觀察失敗率、延遲、稽核和權限邊界。低風險灰度通過所有閘門後才擴大；出現權限擴大、稽核缺失、無法登入或回滾失敗就停止並恢復舊路徑。Beta 證據只作為正式版評估輸入。
常見錯誤
- 把 RADIUS 移除和 MD5 警告當成同一件事 → 一個是支援移除，一個是遷移訊號 → 分別盤點和設定計畫。
- 只改
pg_hba.conf不測客戶端 → 驅動和連線池可能不支援新方式 → 建立完整連線矩陣並逐項回放。 - 直接在生產輪換全部密碼 → 故障面和回滾難以控制 → 先做隔離驗證、短期最小權限帳號和分批切換。
- 忽略 break-glass 帳號 → 故障時可能無法復原 → 準備受控緊急帳號、雙人核准和稽核。
- 把 Beta 測試通過寫成最終相容承諾 → 預發布行為仍可能變化 → 記錄版本與邊界，正式版重新核准。
追問及應對
什麼時候必須停止升級？
出現無法登入、權限擴大、稽核缺口、關鍵客戶端不相容、故障轉移失敗或回滾無法在窗口內完成時停止。
為什麼不能只把 RADIUS 替換成任意密碼驗證？
驗證強度、金鑰生命週期、網路邊界和稽核要求可能不同；替代方案必須符合組織安全策略並覆蓋客戶端與故障場景。
MD5 警告是否代表馬上斷開所有 MD5 使用者？
不是。警告用於暴露仍在使用的路徑；應先識別客戶端、輪換密碼並驗證 SCRAM、憑證或代理路徑，再按窗口分批切換。
如何證明沒有遺漏隱藏客戶端？
結合連線日誌、稽核、角色使用記錄、網路來源、儲存庫搜尋和維運訪談，按時間窗口核對矩陣；遷移前後持續監控未知來源和驗證失敗。
Beta 驗證通過後何時可以生產？
等正式版發布，重新驗證版本和客戶端矩陣，完成回滾與稽核演練，並由安全、資料庫和業務負責人共同核准後再灰度。