李大同 陳昱希 張展飛 張文杰 廖南嬌

引言

現(xiàn)如今，隨著計算機技術(shù)的迅速發(fā)展，各類應(yīng)用系統(tǒng)已廣泛在企業(yè)的日常工作中使用，為企業(yè)辦公自動化提供了很大的幫助，但同時也帶來了諸多問題。隨著信息管理系統(tǒng)數(shù)量的增加，不同的管理系統(tǒng)的登錄模式、數(shù)據(jù)結(jié)構(gòu)、體系架構(gòu)和功能模塊之間也有了很大的差異。由于上述的差異化，各個系統(tǒng)之間使用的登錄方式有可能不同，但是使用多點登錄的方式可能會導(dǎo)致各種各樣的信息安全問題。為了解決這樣的信息安全等問題，降低不同用戶在運維過程中的復(fù)雜程度，打破不同信息系統(tǒng)之間的隔閡，建立企業(yè)的信息化應(yīng)用平臺，以此來提高開發(fā)效率，降低運維難度。

經(jīng)過市場調(diào)研，許多企業(yè)對公共服務(wù)需要共享其賬號密碼是有比較大的需求的；首先是企業(yè)宣傳運營管理部有很多媒體賬號需要安全有序管理，比如公眾號，官微賬號，企業(yè)應(yīng)用市場賬號等；其次是企業(yè)HR也有很多招聘網(wǎng)站的賬號密碼需要管理；最后是企業(yè)各種內(nèi)部管理工具，SaaS服務(wù)賬號等。所以賬號密碼作為公司的重要虛擬資產(chǎn)，需要一個行之有效的管理方法，安全、精細管理。眾所周知，當(dāng)前所有企業(yè)基本都在進行企業(yè)管理信息化建設(shè)，那么針對其建設(shè)過程中面臨的應(yīng)用系統(tǒng)集成、用戶身份管理等問題，本系統(tǒng)的開發(fā)可以實現(xiàn)信息系統(tǒng)統(tǒng)一、高效、安全的用戶身份管理，以便于新應(yīng)用系統(tǒng)的集成[1]。

一、系統(tǒng)架構(gòu)

（一）技術(shù)架構(gòu)

系統(tǒng)采用微服務(wù)部署，通過使用Docker容器來承載不同的業(yè)務(wù)，并且在網(wǎng)絡(luò)層與系統(tǒng)層都部署了負載均衡的設(shè)備及應(yīng)用，確保系統(tǒng)高可用的同時，當(dāng)發(fā)生非法入侵時方便數(shù)字取證，且在后續(xù)的硬件或操作系統(tǒng)升級時，方便系統(tǒng)的遷移。具體如架構(gòu)如圖1所示。

圖1 系統(tǒng)總體架構(gòu)

（二）數(shù)據(jù)加密

需要考慮三種數(shù)據(jù)狀態(tài)：

(1)傳輸中的數(shù)據(jù)；

(2)使用中的數(shù)據(jù)，即在服務(wù)器或客戶端的內(nèi)存或文件系統(tǒng)中的數(shù)據(jù)；

(3)靜態(tài)數(shù)據(jù)，即電源關(guān)閉時在文件系統(tǒng)中的數(shù)據(jù)。

對于使用中的數(shù)據(jù)，只有密碼會被加密。例如，用戶名、評論或與共享密碼的人員列表未使用OpenPGP加密，并以明文形式存儲在客戶端和服務(wù)器端。顯然，密碼在某些時候可以通過解密形式獲得（越晚越好），但它們永遠不會以明文形式存儲在客戶端或服務(wù)器端的文件系統(tǒng)中。

對于傳輸中的數(shù)據(jù)，例如在傳輸層級別，所有通信都使用SSL加密。該級別的安全強度不受本項目的密碼管理平臺解決方案本身的控制，而是由其他因素的組合控制，例如頒發(fā)證書的組織的安全級別和托管提供商選擇的操作系統(tǒng)配置。

對于靜態(tài)數(shù)據(jù)，在大多數(shù)客戶端和服務(wù)器中，也可以在文件系統(tǒng)級別加密數(shù)據(jù)庫，這將添加另一個有用的加密層。

二、底層架構(gòu)及原理

（一）密碼中的身份驗證

本項目的密碼管理平臺不是經(jīng)典的基于表單的身份驗證，而是基于設(shè)置期間設(shè)置的OpenPGP密鑰執(zhí)行以及基于質(zhì)詢的身份驗證。本章節(jié)的目的是幫助解釋此身份驗證過程如何工作以促進審查和討論以及未來與其他產(chǎn)品的集成。授權(quán)技術(shù)多為基于訪問控制模型和授權(quán)協(xié)議進行設(shè)計[1]。本項目的目標(biāo)是提高整體解決方案的安全性和可用性，例如，重用本項目的密碼管理平臺的現(xiàn)有OpenPGP設(shè)施以避免讓用戶記住另一個密碼而不是他們的密碼。

1.基于表單的身份驗證

雖然現(xiàn)在一些Web應(yīng)用程序遵從其他服務(wù)（例如騰訊SSO及短信驗證碼）來處理身份驗證，但大多數(shù)仍然默認支持基于表單的身份驗證。在注冊期間，密碼被發(fā)送（最好通過HTTPS）到服務(wù)器。然后使用crypt（或等效）對該密碼進行加鹽和散列處理，并存儲以供服務(wù)器進一步使用。只有此應(yīng)用程序?qū)嵗赖柠}用于防止密碼的哈希值泄露（例如通過SQL注入）的暴力破解[3]。

在以與設(shè)置類似的方式發(fā)送登錄期間，服務(wù)器對其進行哈希處理并將其與存儲的版本進行比較。如果它們與服務(wù)器存儲一個會話令牌，該令牌作為cookie（或URL參數(shù)）發(fā)送回并在客戶端設(shè)置。此cookie由客戶端在會話期間為每個請求生成（直到cookie過期、用戶注銷或服務(wù)器終止會話）。

2.基于表單的方法的問題

主要問題是可用性。將這種方法用于本項目的密碼管理平臺意味著用戶需要在其私鑰密碼之上記住另一個密碼。這抵消了擁有密碼管理器的好處。

本項目還將密碼存儲在身份驗證插件中，但這會使要求復(fù)雜化，因為它會引入本項目的密碼管理平臺用戶賬戶密碼創(chuàng)建、更新和恢復(fù)的需要。

另一個大問題是用戶無法使用電子郵件驗證重置密碼，以防電子郵件客戶端的密碼存儲在本項目的密碼管理平臺中。

其他問題不是本項目的密碼管理平臺特有的，但仍然值得嘗試使用另一種方法來解決：比如網(wǎng)絡(luò)釣魚，密碼質(zhì)量等。

3.基于GPGAuth的身份驗證

這個過程將遵循GPGAuth協(xié)議。該過程通過用戶和服務(wù)之間加密和簽名令牌的雙向交換來工作。認證過程如圖2所示：

圖2 基于GPGAuth身份驗證

4.驗證步驟

（1）客戶端生成隨機數(shù)據(jù)的加密令牌（使用服務(wù)器公鑰加密），并將未加密版本存儲在本地。

（2）該加密令牌與用戶密鑰指紋一起發(fā)送到服務(wù)器。

（3）服務(wù)器根據(jù)用戶密鑰指紋檢查用戶是否存在以及是否處于活動狀態(tài)。如果是這種情況，服務(wù)器將解密nonce并檢查其格式是否有效。

（4）服務(wù)器發(fā)回解密后的隨機數(shù)。

（5）客戶端檢查隨機數(shù)是否與先前記錄的隨機數(shù)匹配。如果不匹配，客戶端會警告用戶無法驗證服務(wù)器身份。

5.登錄步驟

（1）用戶發(fā)送他們的密鑰指紋。

（2）服務(wù)器檢查指紋和關(guān)聯(lián)的用戶是否有效。然后它生成隨機數(shù)據(jù)的加密令牌，并將未加密版本存儲在本地。

（3）服務(wù)器將未加密的簽名用戶令牌和加密的服務(wù)器令牌發(fā)送給用戶。

（4）用戶輸入他們的私鑰密碼，客戶端解密隨機數(shù)并檢查令牌格式。

（5）客戶端將解密后的隨機數(shù)與用戶密鑰指紋一起發(fā)回。

（6）服務(wù)器比較從客戶端發(fā)送的未加密的簽名令牌以確保它匹配。如果服務(wù)器滿意，則與基于普通表單的登錄一樣完成身份驗證：啟動會話。

6.注釋和備注

根據(jù)協(xié)議定義，服務(wù)器密鑰驗證步驟是可選的，但建議所有的客戶端默認執(zhí)行它。

在未來可能會嘗試減少HTTP請求的數(shù)量：例如，目前不能在驗證步驟中請求nonce1。因此，對于驗證步驟，總共需要3個POST。整個協(xié)議可能會簡化為單個GET/POST往返，例如基于表單的身份驗證。

還有一個可選的“步驟0”，用戶在其中執(zhí)行GET/auth/verify請求。這可以用來獲取服務(wù)器公鑰和服務(wù)器驗證的URL，或者查看服務(wù)器發(fā)布的公鑰。

7.GPGAuth優(yōu)點

除了不必記住額外密碼的可用性優(yōu)勢之外，本項目還提供以下額外優(yōu)勢：

網(wǎng)絡(luò)釣魚：由于客戶端不輸入密碼，因此降低了這種風(fēng)險，例如，僅獲取密鑰密碼將不允許攻擊者登錄。由于客戶端可以根據(jù)服務(wù)器密鑰（手動添加到密鑰環(huán)）驗證服務(wù)器身份，因此攻擊者僅偽造表單和域是不夠的。

密碼質(zhì)量：身份驗證令牌的強度比經(jīng)典密碼強，因為每次也使用不同的“密碼”，并且與私鑰主密碼的復(fù)雜性無關(guān)。

8.殘留風(fēng)險和缺點

目前的解決方案仍然存在風(fēng)險：

服務(wù)器：客戶端公鑰有效性的完整性和驗證。服務(wù)器可能會被誘騙存儲錯誤的客戶端公鑰。為防止這種情況，服務(wù)器必須通過OpenPGP信任網(wǎng)絡(luò)自動檢查有效性和/或通過檢查公鑰服務(wù)器和/或必須由管理員進行手動檢查。

由于加密/簽名操作比基于“正?！北韱蔚牡卿浿械拿艽a哈希操作成本更高，因此這些端點可能會被用來創(chuàng)建拒絕服務(wù)。為了降低這種風(fēng)險，系統(tǒng)限制了嘗試，例如隨著時間的推移限制嘗試的次數(shù)。

有關(guān)用戶群的信息泄露。攻擊者可以通過請求加密的隨機數(shù)并收到錯誤來查明用戶是否在服務(wù)器上擁有賬戶。在標(biāo)頭中泄露信息以提高可用性并提供更好的錯誤消息：例如，告訴用戶其賬戶已被刪除。

服務(wù)器公鑰的完整性和驗證?？蛻舳丝赡軙徽T騙存儲無效的服務(wù)器密鑰。為防止這種情況，客戶端必須在設(shè)置期間檢查有效性（如前例）。同樣，在設(shè)置期間，客戶端還必須檢查域/密鑰映射，以防有人使用虛假但非常相似的域URL創(chuàng)建真實密鑰。目前已實施，但肯定可以改進，因為最終用戶仍然可能犯錯誤并且無法正確檢查。

客戶端/服務(wù)器可能被誘騙解密并返回/簽署錯誤數(shù)據(jù)，例如攻擊者先前捕獲的電子郵件。為了緩解這種情況，加密格式消息是固定的（例如UUID）并由服務(wù)器簽名。如果SSL可以破解，身份驗證cookie就可以被竊取。這并非特定于此身份驗證方法，因為表單身份驗證也容易受到此類攻擊。此外是沒有替換和撤銷密鑰的工具。

（二）角色和權(quán)限

1、系統(tǒng)角色

本項目的密碼管理平臺提出了兩個系統(tǒng)角色管理員和用戶。該系統(tǒng)是授權(quán)機制的第一線，直接對每個用戶的操作執(zhí)行檢查。

簡而言之，管理員管理實例。實際上，這意味著他們可以管理組織范圍內(nèi)的設(shè)置，例如電子郵件通知的內(nèi)容或啟用了哪個多因素身份驗證提供程序。另一個職責(zé)是創(chuàng)建或刪除用戶、管理組和組管理員、執(zhí)行與用戶目錄的同步等。

2、組級角色

每個群必須至少有一個群管理員負責(zé)添加和刪除群成員。管理員可以指定自己為組管理員或指定普通用戶，具體關(guān)系如圖3所示。

圖3 角色關(guān)系

由于本項目的密碼管理平臺中加密的性質(zhì)，只有有權(quán)訪問給定組的秘密的人才能將成員添加到該組（因為他們需要能夠為新成員解密和加密密碼）。

3、資源級角色

本項目的密碼管理平臺在資源層面提供三種權(quán)限：

（1）所有者：可以管理共享設(shè)置、刪除、更新、讀取。

（2）更新：可以更新記錄和刪除。

（3）讀?。褐荒茏x取和使用密碼元數(shù)據(jù)和秘密。

4、文件夾級別角色

在系統(tǒng)底層，文件夾權(quán)限將重用于資源可用權(quán)限系統(tǒng)相同的權(quán)限系統(tǒng)。這將允許用戶將一組權(quán)限關(guān)聯(lián)到一個或多個文件夾。與資源一樣，文件夾必須具有在文件夾權(quán)限中定義的所有者權(quán)限。還有兩種其他權(quán)限類型可用：更新和讀取。

一旦項目位于文件夾中，可以對項目執(zhí)行的操作不取決于文件夾權(quán)限，而是項目本身，就像在常規(guī)文件系統(tǒng)上一樣。對于要移動文件夾內(nèi)的項目的用戶，他們通常必須至少具有對該項目和目標(biāo)文件夾的更新權(quán)限。

三、應(yīng)用工作原理

（一）系統(tǒng)接口

密碼服務(wù)器組件API 以 REST 方式在 HTTPS 上工作，因此它與語言框架無關(guān)?？梢允褂眠m合的工具集將密碼管理服務(wù)集成到現(xiàn)有的工作流程中[2]。要開始使用密碼管理 REST API（以下簡稱“API”），至少需要：

（1）一個正在運行的密碼服務(wù)器實例。

（2）如果您想訪問受保護的數(shù)據(jù)，請使用密碼用戶帳戶。

（3）對公鑰加密的工作原理有一些基本的了解。

（4）用于構(gòu)建的OpenPGP 兼容庫。

API 通過 HTTPS 提供。本文中引用的所有 URL 都省略了密碼安裝域的基本 URL，例如：https://.

（二）響應(yīng)包結(jié)構(gòu)

API 在具有“header”和“body”屬性的信封中返回數(shù)據(jù)。“header”包含響應(yīng)元數(shù)據(jù)，如響應(yīng)代碼、server_time、錯誤消息等。“body”包含實際有效負載。

（三）錯誤響應(yīng)

不成功的操作將導(dǎo)致錯誤響應(yīng)。錯誤響應(yīng)將遵循與上面相同的方案，同時存在“header”和“body”屬性，只是這次標(biāo)題中的狀態(tài)將設(shè)置為 error而不是success。響應(yīng)正文將包含錯誤詳細信息。

如上所示，對于驗證錯誤，響應(yīng)正文包含兩個鍵，“name”和“secrets”，因為它們未通過某些驗證規(guī)則。此外，它們還有自己的 json 對象，其中包含一個表示失敗的驗證規(guī)則的鍵（“_required”）和一個包含實際錯誤消息的值（“A name is required”）。

（四）訪問密碼服務(wù)器公鑰

在身份驗證的“驗證”步驟中需要密碼管理服務(wù)器公鑰。此步驟允許客戶端驗證服務(wù)器身份，例如防止域被占用等不太可能的情況。密碼管理服務(wù)器在/auth/verify.json 廣播其公鑰：

結(jié)語

構(gòu)建具備高可靠性的統(tǒng)一身份認證體系，對于復(fù)雜商用環(huán)境特別是金融業(yè)業(yè)務(wù)系統(tǒng)大集中的場景下意義重大。隨著軟件開發(fā)技術(shù)的不斷發(fā)展，目前各大企業(yè)均構(gòu)建了面向不同業(yè)務(wù)領(lǐng)域的系統(tǒng)，企業(yè)中多項目的團隊尤其是初期階段會嘗試很多系統(tǒng)，人員流動也比較大，要有效地管理好賬號密碼，在新員工入職時可以迅速發(fā)放，員工離職時可以快速收回，并且在密碼使用過程中盡可能保障安全，線上服務(wù)器密碼管理也是比較重要的一環(huán)。目前，該系統(tǒng)已經(jīng)在本市的某企業(yè)部署應(yīng)用，并且取得了良好的應(yīng)用效果，大幅提升了運維人員的運維效率，實現(xiàn)了對企業(yè)數(shù)字資產(chǎn)的統(tǒng)一控制。