巨量資料時代面臨的考驗(下)：Kerberos原理與程序

2013 / 04 / 12

施宏良

在巨量資料技術工具Hadoop 1.0正式版中，針對資料存取與運算安全性增加了Kerberos驗證、HDFS的HTTP存取與Append功能，使Hadoop具備了企業應用所需要的重要功能。在這篇文章已介紹Hadoop平台的安全架構，以下將針對Kerberos深入介紹。

Kerberos工作原理介紹：使用者認證與金鑰管理

Kerberos的基本構成元素包含了憑證發放中心KDC，使用者端與伺服器端，如圖1右上方虛線方塊所示。其中使用者端又包含了伺服器本身，認證服務與真實使用者。其中憑證發放中心提供了身份鑑別伺服器AS（Authentication Server）與通行證簽發中心TGS（Ticket Granting Server）。認證服務系統中是採用DES加密演算法且每一個使用者?會有一把個別的認證金鑰（Authentication Key），該證金鑰將會儲存在身份鑑別伺服器中。

圖1 Kerberos系統架構
圖1：Kerberos系統架構與認證運作程序。(資料來源：本文作者整理)

另外在Hadoop安全性設置中常出現關於Kerberos認證的術語還包含：

● 安全個體（Principal）：即被認證的個體本身。它可以是實體的伺服器名稱，系統服務認證個體，或是系統使用者（可由實體系統或目錄服務提供）。其組成包含了三個部分，即名稱（Name）、實例（Instance）與領域（Realm ）而格式則採ASN.1標準（Abstract Syntax Notation）來準確定義。
● 通行證（Ticket）：用戶端用來向伺服器證明自己的身份，其內容包含有使用者標識、通行證簽發中心 ID、通訊金鑰、時間戳記及有效期限等。
● 領域（Realm），即一完整的Kerberos運作環境。其管理領域包含有身份鑑別伺服器，用戶端，應用伺服器端，與共享金鑰等。

Kerberos協議與運作程序

在 Kerberos認證系統中，當用戶端要和伺服器通訊時，用戶端會先向身份鑑別伺服器請求一張與通?證簽發中心 TGS （Ticket Granting Server）溝通所需要的通行證，即TGT（Ticket Granting Ticket），如圖1用戶端與KDC中的黑色線。並用認證協議開始前用戶端與憑證發放中心之間的密鑰將TGT加密回覆給用戶端。此時只有真正的用戶端才能利用它與憑證發放中心之間的密鑰將加密後的TGT解密，從而獲得TGT。此過程避免了用戶端直接向憑證發放中心發送密碼，以求通過驗證的不安全方式。

如圖1所示，用戶端將之前獲得TGT和要請求的服務訊息發送給憑證發放中心，憑證發放中心中的TGS將為用戶端與服務端之間生成一通訊金鑰（Session Key）用於服務端對用戶端的身份鑑別。然後憑證發放中心將這個通訊金鑰和用戶端ID，用戶端網路位址（IP）、簽證中心ID、有效期限、時間戳記等一起包裝成一個Ticket（這些訊息最終用於服務端對用戶端的身份鑑別）發送給服務端，不過Kerberos協議並沒有直接將通行證發送給服務端，而是通過用戶端轉發給服務端。

此時憑證發放中心將剛才產生的通行證轉發給用戶端。由於這個通行證是要給服務端的，不能讓用戶端看到，所以憑證發放中心用協議開始前憑證發放中心與服務端之間的密鑰將通行證加密後再發送給用戶端。同時為了讓用戶端和認證服務之間共享那個密鑰，憑證發放中心在第一步為它們建立的通訊金鑰，發放中心與用戶端之間的密鑰將通訊金鑰加密，隨加密的通行證一起返回給用戶端。

為了完成通行證的傳遞，用戶端將剛才收到的通行證轉發到服務端。由於用戶端不知道憑證發放中心與服務端之間的密鑰，所以它無法竄改通行證中的訊息。同時用戶端將收到的通訊金鑰解密出來，然後將自己的用戶名稱、用戶端網路位址包裝成Authenticator，再用通訊金鑰加密發送給服務端，其使用期限短，用以減少遭受他人重送（Replay Attack）攻擊的機會。

服務端收到Ticket後利用它與憑證發放中心之間的密鑰將通行證中的訊息解密出來，從而獲得通訊金鑰和用戶名稱、用戶端網路位址、服務名稱、有效期限。然後再用通訊金鑰將Authenticator解密從而獲得用戶端名稱、與用戶端網路位址，將其與之前通行證中解密出來的用戶名稱、與用戶端網路位址做比對，從而驗證用戶端的身份。最後，如果服務端沒有返回結果，則將其發送回用戶端。

巨量資料處理與安全性

伴隨著巨量資料時代來臨，雲端運算、行動應用以及社群網絡崛起，資料產生速度相較以往來說更快速也越加複雜，如何及時從中分析出珍貴資訊來優化商業決策，讓巨量資料分析技術越益成熟連動了應用程序的需求增長。當企業在嘗試與尋求新一代巨量運算技術與分析平台的同時，資料安全問題也同樣的挑戰著傳統IT維運的思維（資料安全性上除了可能涉及到用戶訊息，甚至是相關隱私的資料分析問題等）。

前文介紹了現有Hadoop運算平台的安全性架構與Kerberos的工作原理、使用者認證、金鑰管理、認證協議與其運作程序。然而根據Cloudera的統計(註1)，在Hadoop Troubleshooting中，超過了35%的問題都起因於系統組態或Hadoop相關的服務設定所造成，另外40%則由系統硬體與維運所引起。因此建議企業可選擇已整合監控、部署、安全性認證與高可用性等企業必要功能於後端叢集系統中，並有網頁化管理介面的解決方案，此外應考量可將LDAP 和Kerberos整合於解決方案中，企業可直接與內部目錄服務整合（如Windows AD或既有LDAP服務），並透過內建的認證服務來操作資料分析與前端來管理系統服務，以加速企業Hadoop分析平台與資料分析等相關應用程式的建置。

註1：Hadoop Troubleshooting, Kate, Cloudera