摘 要:提出一種新網格安全框架UserCA。它支持跨域的訪問;利用在線簽署代理證書的透明使用,免去了網格用戶在使用網格前需手工提供代理證書的麻煩;減少了私鑰在網上傳輸的次數,增強了系統的安全性;一次提供后還可以多次使用,增強了網格的實用性。
關鍵詞:網格安全; 在線簽署; 代理證書; MyProxy
中圖分類號:TP309文獻標志碼:A
文章編號:1001—3695(2007)03—0115—03
0 引言
網格(Grid)技術是近幾年來國際上興起的一種重要的信息技術[1]。它的目標是將地理上廣泛分布、系統異構的各種計算資源全面整合在一起, 實現網絡虛擬環境上的高性能資源共享和協同工作。與傳統網絡環境相比,網格計算環境極其復雜,具有動態、異構分布等特征,其安全系統需提供單點登錄、代理授權等基本功能[2]。由于網格系統與傳統的網絡環境在各個方面存在差異,解決網絡安全問題的方法已經不能完全用來解決網格的安全問題。網格采用GSI作為認證網格用戶和資源的手段[3]。網格入口(Portal)是所有用戶訪問網格資源的統一入口[4],它的使用為用戶省去了開發和部署特定客戶端的煩惱;所有用戶都使用統一的入口提交網格任務。在通常情況下,出于安全考慮不使用原始證書,而使用代理證書提交任務[5]。網格入口在提交用戶任務時需提供一個代理證書,代理證書由用戶證書的私鑰簽發,代表原用戶主體身份,擁有原主體全部或部分權限。其生命期很短,一旦被攻破可以使系統損失降到最低。
用戶在提交作業時,網格入口需要驗證提交用戶的身份,這種方式帶來了一個問題,即如何向網格入口提交自己的代理證書。本文提出一種兼顧安全性和實用性的代理證書簽署方案,代理證書簽署端通過Java Web Start的方式部署在網頁上[6],用戶只需點擊就可以自動下載到本地運行。這個提交代理證書的方案方便靈活,與現行的網格體系結構和安全基礎設施相兼容。
1 相關工作
將代理證書上傳至網格入口,目前主要有兩種方式:①在網格入口上部署一個上傳頁面,用戶在本地上傳生成的代理證書,由網格入口將該代理證書存放在固定的位置。在Globus[7]系統中,用戶一般通過其函數庫grid—proxy—init產生一個代理證書,在網格入口處進行上傳。但這種方式一個明顯的缺點是網格用戶需要有一個運行命令grid—proxy—init的環境,一般來說需要安裝Globus這套軟件才可以使用該命令。由于安裝Globus步驟煩瑣,并且使用這個命令對用戶要求高,這種方式實用性較差。②用戶通過Java Web Start或Applet的方式從網頁上直接啟動上傳代理證書的程序。這種方式被GridSphere[8]項目所采用,其代理證書的上傳要求指定My ̄Proxy[9]服務器的IP地址以及用戶的用戶名、密碼、私鑰的密碼等信息。這種實現解決了本地安裝Globus環境的問題,但是出現了另外兩個問題:①用戶需要知道MyProxy 服務器的IP地址或域名。②提取的證書可能不滿足運行任務要求的時間。由于用戶很難知道上次保存證書的生命期是否還能滿足本次應用的需求,這種方案也存在弊端。
2 體系結構
為了解決以上問題,提出了一種新網格安全框架UserCA。它提供跨域訪問,并且在線透明簽署用戶的代理證書,用戶只需在提交網格任務前進行配置(包括本地證書私鑰的密碼以及運行模式)并啟動服務端就可以提交網格計算任務。UserCA安全框架如圖1所示。其主要模塊有代理證書消費者、代理證書提供者、代理證書簽署端、身份映射信息服務器、訪問控制、身份映射策略、CA認證策略、CA認證中心等。各個模塊功能描述如下:
(1)CA認證中心。作為一個全局的證書審核簽發中心,所有的原始證書均由該認證中心簽發,包括個人證書和主機證書。用戶要成為合法的網格用戶,必須由CA中心簽署其個人證書;如果用戶需要部署網格服務并使其受限訪問,則必須由CA中心簽署一個合法的主機證書。
(2)信息服務器。它對外提供信息查詢,如某項服務是否存在、某個用戶能否有權訪問某類服務、特定服務所在節點信息等。
(3)映射策略。它決定外域的用戶訪問本域時將被映射為何種身份。
(4)代理證書消費者。網格中通過使用代理證書進行資源安全訪問。當某模塊訪問網格服務時,該模塊扮演的角色就是代理證書消費者。一般在實際的系統中表現為資源調度器(Resource Broker)。
(5)代理證書提供者。代理證書消費者在訪問服務前,必須向被訪問服務出示自己的身份,即代理證書。代理證書消費者通過代理證書提供者請求獲得所需的代理證書,代理證書提供者通過與代理證書簽署端進行交互獲得代理證書并返回給代理證書消費者。
(6)代理證書簽署端。它部署于用戶的客戶端,可以單獨配置運行。代理證書提供者在訪問代理證書服務器時,如果沒有符合條件的代理證書,就將會向代理證書簽署端發出符合PKCS#10[3]格式的證書簽署請求;代理證書簽署端將簽署的代理證書返回給代理證書請求者。代理證書簽署端存在自動和手工兩種工作模式。在自動模式下代理證書簽署端會自動完成簽署功能,不需要用戶參與;在手動簽署模式下,每一個簽署請求都需用戶進行確認,避免了誤簽的可能,這種模式的效果更加安全。
(7)訪問控制。網格用戶在訪問具體的本地服務時,先映射為一個具體的本地用戶(根據Grid—Map—file[3]文件給定的映射關系)后再訪問本地服務。
(8)身份映射。外域用戶在訪問本域時,他的身份將被映射為本域用戶。
(9)代理證書存放池。代理證書提供者獲得的代理證書雖然生命期很短,但是仍然有被攻擊者利用的可能,因此有必要將代理證書存放在一個可靠的位置供下次使用。
3 代理證書的獲取流程
代理證書的獲取主要是由代理證書提供者、代理證書存放池、代理證書簽署端的交互完成的。當前系統的實現是將代理證書直接放在代理證書存放池中。但如前所述,如果代理證書過期或者不滿足應用的需求可能只是返回出錯;出錯后用戶需要再次手工生成代理證書并上傳,這種方式的效率不高。本文通過增加代理證書簽署端,可以在線透明地簽署代理證書,用戶無須知道細節,就像永遠都有一個有效且安全的代理證書一樣。從獲取代理證書的流程可以看出,代理證書簽署端并不是必須運行的,因為如果代理證書提供者能夠在代理證書存放池中找到合適的代理證書,那么它就不會與代理證書簽署端通信。這種方式的好處在于網格用戶可以通過預先訪問網格,將代理證書存入代理證書存放池,當在任何其他位置直接訪問網格時,不需要再次啟動代理證書在線簽署者。
下面給出流程描述:
(1)用戶登錄。首先用戶將從ChinaGrid CA處獲得的證書轉換為.pfx(或.p12)[11]格式。本文采用Flexi ̄Core ̄Provider[12]提供的編程庫實現一個轉換證書的接口。用戶獲得PFX格式的證書后導入瀏覽器,瀏覽器可以為IE或Netscape等;需要支持SSL/TLS[13],一般都支持PFX個人證書。瀏覽器通過采用SSL/TLS方式訪問網格入口并提交任務。
(2)提交任務。在網格入口處,用戶身份將被驗證,他的身份也將被記錄,以便傳給代理證書消費者(實際表現為作業管理器);代理證書消費者通過網格用戶身份確定需要提取哪個網格用戶的代理證書。
(3)代理證書的獲取。代理證書消費者直接利用獲得的用戶身份信息,包括用戶名、密碼、IP地址等信息初始化一個代理證書提供者,并且調用代理證書提供者的接口獲得代理證書。
(4)查看代理證書服務器。代理證書提供者本身并不能提供代理證書,它將首先到代理證書服務器中查看符合服務要求的代理證書是否存在。如果存在,將直接返回代理證書給代理證書消費者。
(5)簽署代理證書。如果在代理證書服務器中沒有符合要求的代理證書,則代理證書提供者將求助于代理證書簽署者。在代理證書提供者向代理證書簽署者證明自己的身份后,代理證書簽署者將處理代理證書提供者的請求。根據本地策略,代理證書簽署者簽署代理證書,并將簽好的代理證書發送給代理證書提供者。
(6)存儲代理證書。代理證書提供者獲得剛簽署好的代理證書后,存放于代理證書服務器,以便下次直接從代理證書服務器獲取。
(7)訪問服務。代理證書消費者在獲得代理證書后,利用代理證書去訪問服務。在訪問服務的過程中,同樣可以通過獲得的代理證書透明地使用GSI。
由于程序認證時并不是直接使用代理證書(Proxy Certificate)的,而是使用代理證書的封裝形式——信任狀(Credential)。在圖2中,代理證書消費者(資源調度器)在訪問服務時需要代理證書,系統隱式的實現是獲取用戶的缺省信任狀,資源調度器以該用戶的身份運行。該用戶信任狀由臨時目錄(在UNIX下為/tmp/,在Windows下為S│{tempdir})下的代理證書(x509up_uS│{UID})生成。UID為用戶系統中的ID,在Windows下為用戶名。本文的實現就是顯式地設置了安全環境中的信任狀。信任狀的獲取由代理證書提供者ProxyProvi ̄der給出。ProxyProvider的構造很簡單,只需要用到用戶本地的IP以及代理證書存放池的IP,存取代理證書存放池用戶名、密碼,可以生成代理證書提供者ProxyProvider,通過調用ProxyProvi ̄der的getProxy方法可以啟動獲取代理證書的簽署程序,步驟如前所述。
4 身份映射
域A的用戶A—User1訪問域B時,由于A—User1是在域A中注冊的,在域B沒有關于域A的身份信息,因此A—User1的身份需轉換為域B的身份。圖3給出了身份映射服務組件部署圖。其中,信息服務器前面已有描述;域管理器是部署身份映射的載體;GateKeeper[14]部署在作業管理器的前端,任何作業調度請求將首先經過GateKeeper驗證,驗證通過后才能進行作業調度。由圖3可知,跨域訪問共有三種形式:①跨域查詢,用戶的任務提交到外域時,將調用信息服務器查詢外域的信息;②跨域作業調度,用戶通過信息服務器查找到相應的服務地址后,將作業調度到服務所在域的作業管理器;③直接提交作業到服務提供者(這種情況出現在程序中直接指定了將要調用的服務的物理地址情況下)。
另外值得考慮的是用戶跨域訪問時,需要使用自身所在注冊域的原始身份。在身份映射時,始終采用原始身份進行映射,而不是采用映射后的用戶身份進行映射;否則會出現映射不一致的情況。例如,域A的A—User1用戶在域B被映射為B—User1,在域C被映射為C—User1;而域B的用戶B—User1在域C被映射為C—User2。如果跨域訪問(用戶A—User1通過域B訪問域C)時采用被映射后的用戶身份進行訪問,會出現與直接訪問域C結果不一致的情形,如表1所示。
因此在跨域訪問時采用原始身份可以保證在跨多個域后結果都不會出現映射不一致的情形。例如圖3中的用戶進行跨域作業調度時,GateKeeper將調用身份映射服務將用戶的原始身份轉換為本地用戶,再將作業提交給服務。
5 結束語
通過引入UserCA的安全體系結構,并重點介紹了UserCA中的兩個主要功能,即代理證書的在線簽署機制和跨域用戶身份的映射機制,為用戶展現了一個更加實用的網格安全框架。除了解決用戶跨域身份映射需求外,該設計還具有如下好處:
(1)方便、透明的用戶使用接口。
UserCA 系統的實現采用了Java Web Start的方式,用戶只需要點擊網頁就可以將UserCA 的服務端下載到本地運行。用戶在訪問網格時,只需安裝和配置UserCA 的服務端,不需要在本地手工產生代理證書,使用戶可以透明地訪問網格,不需要考慮自身代理證書是否已經提交,極大地方便了網格用戶。
(2)安全性的提高。
程序本身的安全性由Java Web Start來保證。如果訪問網絡和本地資源都由證書簽署來保證,并且由用戶本身決定是否授權,則在與網格入口的交互過程中采用SSL/TLS的加密認證體系。由于代理證書的申請(Certificate Request)是通過代理證書消費者生成的,由PKCS#10協議可知,私鑰是臨時產生的,證書與私鑰組成的信任狀如果不需要放在代理證書存放池中,則可以存放在本地,不需要在網上傳播;即使需要存放于代理證書存放池中,也由SSL/TLS協議來保證私鑰不被泄漏。與本地產生代理證書并通過網頁上載的方式相比,其減少了私鑰被攻破的可能性,使安全性得到了提高。
本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文。