DB2 UDB 安全性：基於 GSS-API 的 SPKM/LIPKEY 安全外掛實作指南

DB2 UDB V8.2 引入可自訂安全外掛架構，支援基於通用安全服務應用程式介面（GSS-API）的外掛驗證。隨著 NFSv4 (RFC 3530) 強制要求 SPKM (RFC 2025) 與 LIPKEY (RFC 2847) 機制，DB2 UDB 將支援這些基於公開金鑰技術的新型 GSS-API 機制，實現除 Kerberos 之外的非對稱金鑰驗證選項。

DB2 UDB 安全外掛架構回顧

• 群組擷取外掛： 取得用戶群組成員資訊
• 用戶端驗證外掛： 管理客戶端驗證
• 伺服器端驗證外掛： 管理伺服器端驗證

兩種驗證機制：用戶 ID/密碼 與 GSS-API（RFC 2743/2744）。預設使用 OS 層面的用戶 ID/密碼外掛。透過 DB2 提供的 API 可開發/採購自訂外掛實現客製化驗證行為。

GSS-API 與 SPKM/LIPKEY 機制

GSS-API 以通用形式提供安全服務，抽象化驗證、訊息來源驗證與完整性，使應用程式碼可在不同安全機制間移植。目前主流僅支援 Kerberos（對稱金鑰），但 NFSv4 強制要求 SPKM/LIPKEY，將推動廠商擴展支援。

SPKM（簡單公開金鑰機制，RFC 2025）

• 基於公開金鑰基礎設施（PKI）而非對稱金鑰
• 提供單向/雙向驗證、金鑰建立、資料完整性/機密性，無需安全時間戳
• 使用演算法識別碼指定雙方演算法，支援真正非對稱演算法的數位簽章（gss_sign/gss_seal → gss_getMIC/gss_wrap）
• 資料格式設計與 Kerberos 相似，易於在既有 Kerberos 環境部署

LIPKEY（低基礎設施公開金鑰機制，RFC 2847）

• 對應典型 TLS 部署：客戶端無公開金鑰憑證，透過伺服器憑證建立安全通道
• 流程：取得伺服器憑證 → 驗證 CA 簽署 → 產生隨機對稱會話金鑰 → 用伺服器公鑰加密 → 傳送給伺服器 → 建立安全通道 → 客戶端以用戶 ID/密碼驗證身分
• 適用於發起端（客戶端）無憑證但需用戶 ID/密碼驗證的場景

DB2 UDB 整合 SPKM/LIPKEY GSS-API 外掛

IBM 提供的 Kerberos 範例外掛即基於 GSS-API。若擁有支援 SPKM/LIPKEY 的 GSS-API 庫，即可開發對應外掛。

基於 SPKM 的驗證需求

• 伺服器端：X.509 憑證 + PKI 環境 + 支援 SPKM 的伺服器端 GSS-API 外掛
• 客戶端：X.509 憑證 + PKI 環境 + 支援 SPKM 的客戶端 GSS-API 外掛

基於 LIPKEY 的驗證需求

• 伺服器端：X.509 憑證 + PKI 環境 + 支援 LIPKEY 的伺服器端 GSS-API 外掛 + 用戶 ID/密碼資料庫存取權
• 客戶端：支援 LIPKEY 的客戶端 GSS-API 外掛（無需 X.509 憑證，但可能需 PKI 驗證伺服器憑證）

關鍵實作差異（相對 Kerberos 外掛）

1. 取得支援 SPKM/LIPKEY 的 GSS-API 產品並建置 PKI 環境
2. db2secServerAuthPluginInit()：向 gss_acquire_cred() 傳遞正確機制 OID（非 GSS_C_NO_OID_SET），確保服務主體名稱與 X.509 憑證主體名稱（CN）匹配
3. db2secGenerateInitialCred()：同樣傳遞正確機制 OID；LIPKEY 場景下此處提示用戶輸入 ID/密碼
4. db2secProcessServerPrincipalName()：使用 gss_import_name() 轉換服務主體名稱，需與伺服器憑證主體名稱一致
5. 封裝 gss_init_sec_context() 確保傳遞正確機制 OID 啟動安全上下文（預設為 Kerberos）
6. 其餘 DB2 UDB API 函數實作參考 Kerberos 範例外掛（IBMkrb5.c）

結語

隨 SPKM/LIPKEY 納入 GSS-API 支援矩陣，DB2 UDB 管理員/開發者應考慮實作支援這些機制的新型外掛。這將使 DB2 UDB 能在極少代碼變更下，靈活切換公開金鑰技術與傳統對稱金鑰驗證，提升安全架構彈性。