深入瞭解 Kerberos 驗證通訊協定
Kerberos 驗證通訊協定是一種網路驗證通訊協定，可在不受信任的網路（如網際網路）中，於兩個或多個受信任主機之間驗證服務請求，且無需傳送密碼。Kerberos 被譽為現代網路安全通訊協定的基礎，採用對稱式金鑰加密技術，並仰賴受信任的第三方進行協調。
自 1983 年問世以來，Kerberos 已廣泛應用於各種環境，特別是在對驗證/身分驗證有嚴格要求的場合。Kerberos 已整合於多種作業系統中，並成為許多網路安全與單一登入解決方案的標準組件。
Kerberos 的起源
Kerberos 驗證/身分驗證通訊協定於 1983 年誕生，源自麻省理工學院（MIT）、Digital Equipment Corporation 和 IBM 共同推動的 Project Athena 計畫，用意在打造一個橫跨校園的分散式運算環境，供教學使用。
「Kerberos」這個名稱取自希臘神話中的三頭犬 Cerberus，牠負責守護冥界 Hades 的大門。
這三頭犬象徵著該通訊協定的結構：分為三個相互依存的元件——用戶端、伺服器，以及金鑰發佈中心（KDC）。
Kerberos 驗證/身分驗證的運作方式：架構與流程解析
Kerberos 驗證/身分驗證架構
Kerberos 架構採用對稱式加密（密鑰加密技術）與受信任的第三方——金鑰發佈中心（KDC），來實現用戶端與伺服器應用程式的驗證/身分驗證，並確認使用者身分。KDC 透過驗證伺服器發放票證給用戶端，並藉由票證授權伺服器提供票證授權服務。這些票證會以工作階段金鑰加密，作為用戶端身分的憑證。
KDC 包含三大核心元件：
- 驗證伺服器（AS , Authentication Server）：負責處理使用者存取服務時的初步驗證/身分驗證，並發放票證
- 票證授權伺服器（TGS , Ticket-Granting Server）：接受已驗證的用戶端，並協助使用者連接至所需的服務伺服器（SS , Service Server）
- Kerberos 資料庫：儲存所有已驗證使用者的識別資訊
請注意，KDC 發放的所有票證均有時效限制。
Kerberos 驗證/身分驗證流程
Kerberos 驗證/身分驗證流程涵蓋用戶端、伺服器與 KDC 之間的一系列互動。每次會話都會產生一組加密票證（即工作階段金鑰），並儲存在申請服務的使用者裝置上。服務端將此票證作為驗證依據，而非傳統密碼。
Kerberos 驗證/身分驗證流程分為四大步驟，確保使用者密碼從不經過網路傳輸，有效防範潛在攔截風險。
1. Kerberos 初始驗證/身分驗證服務請求
使用者啟動登入，向 KDC 的驗證伺服器（AS）提出 Kerberos 驗證/身分驗證服務請求。此請求包含使用者主體名稱（UPN，亦即使用者識別碼），但不包含密碼，並載明票證有效期限及到期資訊。請求內容以使用者密碼雜湊加密，AS 隨後產生票證授權票（TGT）。
2. Kerberos 票證授權票（TGT）發放
當 AS 收到服務請求後，KDC 會利用使用者密碼雜湊進行解密。若解密成功且時間戳記未過期，AS 便產生工作階段金鑰與 TGT，發送給用戶端以加密後續請求。
TGT 內含用戶端 ID、網路位址及有效期限。使用者系統會用密碼解密工作階段金鑰；TGT 則以 TGS 專屬密鑰加密。
3. Kerberos 服務票證請求
接著用戶端向 TGS 發出請求，內容包含先前取得的加密 TGT，以及以工作階段金鑰加密的服務請求。服務端會以其密鑰解密票證並驗證其有效性。若服務端成功解密並驗證服務票證，即確認用戶端身分並授予存取權。
4. Kerberos 服務存取
驗證成功後，用戶端向伺服器出示服務票證。伺服器若能正確解密服務票證，即授予用戶端存取權限。
Kerberos 驗證/身分驗證的優勢
Kerberos 驗證/身分驗證在網路安全與管理上具有多項優勢，包括：
跨平台互通性
Kerberos 作為開放標準協定，具備高度互通性，支援多種系統與平台（如 Windows、Unix 及 Linux），可靈活整合各類 IT 環境。
雙向驗證/身分驗證
Kerberos 提供用戶端與伺服器雙向驗證/身分驗證，雙方皆須確認彼此身分，有效降低中間人（MitM）攻擊風險，防止攻擊者冒充伺服器或用戶端竊取訊息內容。由於雙方均需驗證/身分驗證，可徹底防堵中間人攻擊。
高擴展性
隨著基礎結構規模調整，Kerberos 可因應大量用戶與服務的驗證/身分驗證需求，支援大型網路環境的彈性擴展。
單一登入（SSO）功能
Kerberos 支援單一登入，使用者只需驗證/身分驗證一次，即可存取多項服務，無需重複登入。此舉不僅提升用戶體驗，也藉由減少多重密碼管理，降低密碼疲勞與弱密碼風險，強化整體安全防護。
強大加密保護
Kerberos 採用對稱式加密，全面保障用戶端與伺服器間的資料傳輸安全，包括驗證/身分驗證過程。加密所用金鑰從不經由網路傳送，進一步降低攔截風險，防止竊聽或資料竄改。
Kerberos 驗證/身分驗證的限制
雖然採用 Kerberos 驗證/身分驗證機制具有諸多優點，但在部署與運作過程中仍存在若干限制，這些挑戰源自於協定設計、作業需求及環境因素。
複雜度與管理負擔
Kerberos 協定本身結構複雜，導致部署和管理成為重大難題。建置與維護 Kerberos 系統需要深入瞭解協定原理、謹慎的設定，以及持續的管理工作，這對規模較小的組織（企業）而言，尤其是一大挑戰，因為這需要專業知識與資源。
管理人員必須妥善管理金鑰、正確設定服務，並確保金鑰發佈中心（KDC）的持續維護。若管理疏忽，容易產生錯誤與漏洞，進而削弱安全性。此外，每一個網路服務都需配置專屬的 Kerberos 金鑰。
跨網域驗證/身分驗證的複雜性
Kerberos 最初設計僅適用於單一網域，因此跨網域或不同管理領域（realm）間的驗證/身分驗證設定與管理相當繁瑣。必須手動建立及維護不同領域間的連線，並在 KDC 之間共享金鑰。
相容性與互通性限制
並非所有協定都支援 Kerberos 驗證/身分驗證，這使其在異質化網路環境中（服務及協定多元）應用受限。將 Kerberos 整合至各類系統與應用程式（特別是原生不支援 Kerberos 的情境）時，往往需要額外投入與客製化解決方案。
Kerberos 憑證限制
Kerberos 憑證（ticket）具有有效期限。當應用程式或連線持續時間超過憑證有效期時，可能導致服務中斷。若需在不中斷使用者連線的情況下續發憑證，管理上更具挑戰性。
密碼型攻擊風險
Kerberos 僅需連線至 KDC，即可進行暴力破解或字典攻擊。攻擊者可反覆發送驗證/身分驗證請求，利用常見密碼字串，嘗試取得票證授權憑證（TGT），進而偽冒合法使用者。
擴充性問題
雖然 Kerberos 設計上具備擴充性，但過度依賴集中式 KDC，當驗證/身分驗證請求量激增時，容易形成瓶頸。為支援業務成長，必須審慎規劃並隨時擴充基礎結構。
單點故障風險
KDC 為 Kerberos 驗證/身分驗證架構的核心，若 KDC 發生故障或遭入侵（如硬體故障、網路異常或網路攻擊），將導致所有依賴 Kerberos 的服務無法驗證/身分驗證，造成業務中斷。
時間同步敏感性
Kerberos 透過時間戳記防止重放攻擊（即攻擊者重送合法資料以冒充合法身分）。為防止此類攻擊，系統內所有實體必須維持精確的時間同步。若同步失敗，將導致驗證/身分驗證失敗。預設情況下，若用戶端與伺服器的本地時間相差超過五分鐘，即無法完成驗證/身分驗證。
然而，在大型分散式網路環境中，維持時間同步極具挑戰，特別是在時鐘精度與穩定性不一的情境下。
Kerberos 驗證/身分驗證常見問題與排解指引
透過深入瞭解 Kerberos 常見問題的成因及對策，能有效預防風險，讓組織（企業）充分享受 Kerberos 驗證/身分驗證帶來的安全效益。
網域控制站
Kerberos 依賴高可用性的金鑰發佈中心（KDC），通常部署於 Active Directory 的網域控制站。若網域控制站無法連線或設定錯誤，將導致驗證/身分驗證失敗。建議排解步驟如下：
- 檢查網域控制站的覆寫狀態
- 驗證網域控制站的 DNS 服務記錄
- 確認防火牆與路由器設定允許 Kerberos 流量
第三方系統整合性
應用程式需正確設定服務主體名稱（SPN）及金鑰檔（keytab）。若 SPN 不唯一或 keytab 過期，將導致整合失敗。建議排解步驟如下：
- 驗證 SPN 設定
- 若服務回報「解密完整性檢查失敗」，重新產生 keytab
- 確認服務本身支援 Kerberos
舊型系統
部分舊型系統可能不支援 Kerberos，或預設使用 NTLM，造成相容性問題並帶來安全漏洞。建議排解步驟如下：
- 在群組原則中強制優先使用 Kerberos
- 若無法支援 Kerberos，應隔離舊型系統，並採用虛擬私人網路（VPN）、防火牆及多因子驗證（MFA）等補償性控管措施
Kerberos 驗證/身分驗證錯誤
這類錯誤通常源於用戶端、伺服器或 KDC 之間時間同步誤差超過五分鐘。其他常見原因包括 DNS 設定錯誤導致 KDC/服務無法解析，或 SPN 設定錯誤或重複。建議解決步驟如下：
- 同步用戶端、伺服器及 KDC 的系統時間
- 驗證網域登入狀態
- 清除現有憑證後重新驗證/身分驗證
Kerberos 是否可能遭到入侵？
如同所有資安機制，Kerberos 驗證/身分驗證並非完全無法被攻擊。下列為 Kerberos 驗證/身分驗證可能遭到入侵的方式：
金鑰發佈中心（KDC）遭入侵
KDC 為 Kerberos 驗證/身分驗證流程的核心，一旦 KDC 遭到入侵，攻擊者便可為任意使用者簽發有效憑證（ticket），取得網域內所有服務的無限制存取權限，進而橫向擴散至整個網路。
黃金票攻擊（Golden Ticket Attack）
攻擊者若取得 KDC 所屬網域（realm）的祕密金鑰，即可自行產生票證授權憑證（TGT），並以任意身分存取所有服務。這類憑證可設定長時間有效，且與合法憑證難以區分，偵測上極具挑戰。
白銀票攻擊（Silver Ticket Attack）
此攻擊規模較小，攻擊者取得特定服務的祕密金鑰後，可產生有效的服務憑證（service ticket），進而冒用任意使用者身分，繞過一般驗證/身分驗證檢查。由於白銀票攻擊不經過 KDC，且與黃金票相同，難以被偵測。
票證轉移攻擊（Pass-the-Ticket Attack）
攻擊者竊取有效的 TGT，直接冒充合法使用者，取得未經授權的存取權限。Kerberos 驗證/身分驗證以憑證為基礎，無需互動式密碼交換，因此只要取得有效憑證，攻擊者即可橫行無阻。若票證有效期限過長或可續發，風險尤高。
內部威脅
具備合法存取 Kerberos 驗證/身分驗證基礎結構（如 KDC）權限的內部人員（如員工、承包商或任何可存取內部網路者），可能繞過外部防禦，取得敏感服務的存取權限。
中間人（MitM）攻擊
Kerberos 設計上透過雙向驗證/身分驗證防範中間人攻擊，但若設定不當或網路存在漏洞，攻擊者仍有機會攔截用戶端與 KDC 或服務伺服器之間的通訊。
密碼猜測攻擊
Kerberos 驗證/身分驗證常見弱點之一為使用者密碼強度不足，因為初始驗證/身分驗證依賴使用者密碼產生的祕密金鑰。若密碼過於簡單，攻擊者可透過暴力破解或字典攻擊進行猜測。一旦密碼被破解，攻擊者即可向 KDC 申請 TGT，冒充使用者，取得未經授權的存取權限。
重放攻擊
重放攻擊利用 Kerberos 的時間戳記機制。儘管大多數憑證有效期短暫，攻擊者若取得有效憑證，仍可在允許的時限內重複發送請求，取得未經授權的存取權限。
Kerberos 驗證/身分驗證設定最佳實務
遵循這些設定最佳實務，可確保 Kerberos 驗證/身分驗證的安全性與可靠性：
- 正確設定正向與反向 DNS 查詢，確保用戶端能隨時找到正確的網域控制站及服務。
- 限制服務委派範圍。
- 部署多台 KDC（金鑰發佈中心），避免單點故障。
- 為每個服務指派唯一的服務主體名稱（SPN）。
- 所有用戶端、伺服器與 KDC 必須維持系統時間誤差在五分鐘以內。
- 縮短票證（TGT 與服務票證）有效期限，降低風險。
- 詳實記錄跨網域或跨領域的設定。
- 定期測試票證與 SPN 的有效性。
- 定期輪替並更新服務金鑰，確保與 KDC 保持同步。
- 持續監控 Kerberos 事件，偵測異常行為（例如 pass-the-ticket 攻擊）。
- 僅使用強式、以 AES 為基礎的加密演算法。
Kerberos 與其他驗證/身分驗證通訊協定的比較與差異
除了 Kerberos 之外，常見的驗證/身分驗證通訊協定還包括 NTLM、LDAP、OAuth、SAML及 OpenID Connect。以下簡要說明各種驗證/身分驗證通訊協定：
- NTLM：舊版 Windows 挑戰回應通訊協定，採用密碼雜湊。
- 限制：易受 pass-the-hash 及 relay 攻擊，現今環境下安全性不足。
- LDAP：用於儲存與擷取身分資訊的目錄存取通訊協定。
- 限制：除非搭配 LDAPS，否則安全性薄弱，且不具備內建SSO功能。
- OAuth：授權框架，發行權杖以讓應用程式取得有限的使用者資源存取權。
- 限制：設計用途為授權而非驗證/身分驗證，若權杖遭竊會帶來風險。
- SAML：以 XML 為基礎的通訊協定，在身分提供者與服務提供者間交換驗證/身分驗證與授權資料。
- 限制：依賴冗長的 XML，較現代 JSON 通訊協定複雜且效能較低。
- OpenID Connect：建構於 OAuth 2.0 之上的 JSON 身分層，為網頁、行動及 API 應用程式提供驗證/身分驗證與授權。
- 限制：高度仰賴正確的 OAuth 2.0 實作，設定錯誤風險較高。
評估 Kerberos 驗證通訊協定
Kerberos 仍廣泛應用於現代網路環境中，為不安全的網路提供安全的驗證/身分驗證機制。
然而，雖然使用普遍，Kerberos 並非沒有其限制。為維持 Kerberos 驗證/身分驗證的安全性，必須謹慎規劃與管理，包括確保跨網路系統間的時間同步，以及嚴密保護金鑰發放中心（KDC），以防止可能造成重大損害的資安事件。
儘管如此，組織（企業）可透過適當的資源與專業知識，降低上述風險，進而善用 Kerberos 驗證/身分驗證，作為分散式網路環境中用戶與服務驗證的基礎架構。
免責聲明：本文件所載資訊僅供參考，並非任何形式的法律建議。SailPoint 無法提供法律意見，建議您就相關法律問題諮詢專業律師。
