潘孝陽 黃曉芳

(西南科技大學(xué)計算機(jī)科學(xué)與技術(shù)學(xué)院 四川綿陽 621010)

近年來，隨著軟件的不斷發(fā)展，軟件市場對軟件的開發(fā)技術(shù)有著越來越高的訴求，不斷提升的用戶量和業(yè)務(wù)依賴復(fù)雜度都對軟件開發(fā)技術(shù)提出許多挑戰(zhàn)。因此，軟件開發(fā)技術(shù)以高性能、易擴(kuò)展為核心設(shè)計理念，從單一架構(gòu)到分布式架構(gòu)的逐步轉(zhuǎn)型。微服務(wù)的特性正符合了我們所期望的目標(biāo)，所以被大多數(shù)的開發(fā)者所看好，也說明了微服務(wù)框架是軟件開發(fā)的必然選擇。

普遍認(rèn)為2014年Fowler與Lewis首次提出了微服務(wù)的概念[1]，但當(dāng)時并沒給出精準(zhǔn)的定義，只是將微服務(wù)描述為：微服務(wù)就是將單個應(yīng)用程序拆分成多個小的服務(wù)的集群，每個微服務(wù)都圍繞具體業(yè)務(wù)進(jìn)行實現(xiàn)，相互之間通過輕量級通信機(jī)制，有著極少的統(tǒng)一管理。每個微服務(wù)可以獨立部署，使用不同的編程語言，使用不同的數(shù)據(jù)存儲技術(shù)[1-2]。反觀SOA框架，它對某些技術(shù)棧的依賴性較高，從而使得切換時間長，花費成本高，讓決策者望而生畏。由此也可以看出，雖然同樣是以服務(wù)模塊化為目標(biāo)，微服務(wù)架構(gòu)與SOA架構(gòu)有著很大的差別。

微服務(wù)框架在很大程度上優(yōu)化了現(xiàn)有的軟件開發(fā)流程，主要表現(xiàn)在：細(xì)化的服務(wù)模塊相互獨立，使得各部分邏輯更為清晰簡潔；某一部分的改動可以單獨發(fā)布，對整體的影響也相對較??；服務(wù)間相互技術(shù)隔離，也使得開發(fā)工具的選擇更加靈活；各模塊獨自成為一個項目，可以對不同的業(yè)務(wù)部分進(jìn)行需求性能調(diào)優(yōu)。但是，微服務(wù)并不是一個完美的解決方案：分散的服務(wù)模塊需要更龐大的運維團(tuán)隊，提升了服務(wù)監(jiān)控和日志審計難度；分布式的數(shù)據(jù)同步和跨平臺檢索等技術(shù)問題同樣也帶入了微服務(wù)框架中；進(jìn)程中的接口調(diào)用變成了服務(wù)間的接口調(diào)用，提高了調(diào)用的改動成本和性能成本；多個服務(wù)相互依賴，使得測試更加困難；微服務(wù)模塊之間無條件相互信任，為攻擊者提供了很多可乘之機(jī)。所以，本文將在分析微服務(wù)框架的安全性問題后，提出一些針對性的解決方案。

1 微服務(wù)框架脆弱性分析

微服務(wù)的分布式架構(gòu)解決了一些目前SaaS業(yè)務(wù)的復(fù)雜性問題，但同時也引入以下安全隱患：

(1)分布式的框架設(shè)計暴露了更大的可攻擊面[3]。在整體架構(gòu)中，接口與接口之間的調(diào)用是進(jìn)程中的調(diào)用，難以被外部介入，但在分布式的微服務(wù)框架中，各個模塊被細(xì)化成為了單獨的項目，相互間接口的調(diào)用和數(shù)據(jù)的傳遞都必須通過輕量級的通信機(jī)制實現(xiàn)，因此，微服務(wù)之間的通信內(nèi)容就直接暴露了出來，特別是在現(xiàn)在比較常用的第三方云環(huán)境中部署時，不同節(jié)點上的微服務(wù)之間的通信也就直接通過網(wǎng)絡(luò)進(jìn)行傳輸了，攻擊者便可以通過針對網(wǎng)絡(luò)通信的攻擊手段對系統(tǒng)數(shù)據(jù)進(jìn)行篡改。

(2)各個微服務(wù)相互信任，整個應(yīng)用更容易受個別已被攻陷的服務(wù)的影響[4]。各個微服務(wù)之間相互協(xié)作以完成一個復(fù)雜的業(yè)務(wù)邏輯，服務(wù)與服務(wù)之間相互信任對其他模塊的數(shù)據(jù)和請求沒有做較為完善的數(shù)據(jù)校驗，在這種情況下，一旦某個微服務(wù)被攻擊者攻陷，攻擊者便可以利用這種信任關(guān)系對整個系統(tǒng)進(jìn)行數(shù)據(jù)獲取或者篡改。

2 微服務(wù)框架的安全管控解決方案設(shè)計

微服務(wù)的設(shè)計核心之一是業(yè)務(wù)去中心化，但對于微服務(wù)模塊集群的管理工作則需要采用中心化的管理手段，強(qiáng)化微服務(wù)框架中的安全策略。因此，筆者案設(shè)計權(quán)限中心微服務(wù)，在認(rèn)證每個微服務(wù)的同時對系統(tǒng)內(nèi)部框架訪問進(jìn)行權(quán)限控制，保障安全的訪問。

當(dāng)單個的系統(tǒng)被拆分成為了多個服務(wù)模塊后，服務(wù)與服務(wù)之間的權(quán)限控制和信任關(guān)系便成為了安全控制的關(guān)鍵點。對微服務(wù)集群提供身份認(rèn)證機(jī)制可以提高微服務(wù)的可信度，而以最小化權(quán)限思想來考慮微服務(wù)的訪問權(quán)限，可以在很大程度上降低微服務(wù)集群被單點突破的不良影響。因此，本文考慮使用挑戰(zhàn)應(yīng)答的模式對微服務(wù)進(jìn)行認(rèn)證，同時在微服務(wù)框架中應(yīng)用權(quán)限控制模型來控制微服務(wù)的可訪問范圍，進(jìn)而降低微服務(wù)會受到系統(tǒng)中的其他被攻陷微服務(wù)的影響的可能性。

2.1 挑戰(zhàn)應(yīng)答式心跳機(jī)制

通常微服務(wù)框架中需要一個注冊發(fā)現(xiàn)機(jī)制，一般分為客戶端的注冊發(fā)現(xiàn)和服務(wù)端的注冊發(fā)現(xiàn)，以實現(xiàn)對分散的微服務(wù)的統(tǒng)一識別。在服務(wù)端的注冊發(fā)現(xiàn)機(jī)制中，注冊服務(wù)器利用客戶端發(fā)送的心跳包實時監(jiān)控微服務(wù)的存活狀態(tài)。權(quán)限中心微服務(wù)的設(shè)計參考了這種客戶端與服務(wù)端的聯(lián)系方式，使用不間斷的挑戰(zhàn)應(yīng)答來實現(xiàn)對微服務(wù)存活檢測的同時，完成對微服務(wù)的身份認(rèn)證。

挑戰(zhàn)應(yīng)答是一種異步令牌的動態(tài)口令技術(shù)，其中沒有需要進(jìn)行同步的要素，不受客戶端和服務(wù)器的時間差異等問題的影響[5]。在挑戰(zhàn)應(yīng)答的一般實現(xiàn)中，通常由客戶端發(fā)起挑戰(zhàn)請求，然后服務(wù)端生成挑戰(zhàn)碼，客戶端對挑戰(zhàn)碼進(jìn)行運算然后響應(yīng)給服務(wù)器，由服務(wù)器來識別客戶端的合法性。然而，客戶端服務(wù)器雙方一般使用的加密雜湊算法，其運算結(jié)果會直接放在請求消息中，所以監(jiān)聽者只需要維護(hù)一個挑戰(zhàn)碼與響應(yīng)的映射表，就可以簡單地推測出相同的挑戰(zhàn)碼所對應(yīng)的響應(yīng)，冒充正?？蛻舳诉M(jìn)行攻擊。

劉彤等[6]提到了一種添加了時間戳進(jìn)行對稱加密的雙向認(rèn)證挑戰(zhàn)應(yīng)答方法，使得某一個挑戰(zhàn)碼在不同的時間戳下會得到不同的響應(yīng)，增加了加密的混淆程度，減少了挑戰(zhàn)響應(yīng)被仿冒的可能性，并實現(xiàn)了客戶端與服務(wù)器的雙向認(rèn)證。在微服務(wù)框架中，由于挑戰(zhàn)應(yīng)答需要在客戶端和服務(wù)器之間不間斷地進(jìn)行發(fā)送，所以這種混淆程度較高的挑戰(zhàn)應(yīng)答機(jī)制比較適用。另外，文獻(xiàn)[7-8]中提到HMAC算法是一種安全度較高的加密雜湊算法，其普遍應(yīng)用于挑戰(zhàn)/應(yīng)答機(jī)制中。

在圖1中，本文擬采用HMAC算法替換劉彤等的挑戰(zhàn)應(yīng)答方案中的分組加密算法[6]，以進(jìn)一步提高認(rèn)證結(jié)果的可靠性。挑戰(zhàn)應(yīng)答協(xié)議的主要內(nèi)容除了包含客戶端與服務(wù)端的3次握手之外，還必須對客戶端和服務(wù)器雙方的密鑰共享方式進(jìn)行設(shè)計。本方案擬采用提前配置的方式來確定客戶端與服務(wù)器雙方的密鑰，即雙方的密鑰會在創(chuàng)建之初生成并添加到雙方的配置文件中，來達(dá)到密鑰共享的目的。

圖1 微服務(wù)中的挑戰(zhàn)應(yīng)答Fig.1 Challenge response in microservice

在圖1中，由于這里的挑戰(zhàn)應(yīng)答兼顧了心跳檢測的機(jī)制，所以其間隔時間不宜過長，以保證檢測的時效性，由于需要進(jìn)行較為復(fù)雜的3次交互，所以其間隔時間也不宜過短，以避免占用過多通信資源。這里將間隔時間設(shè)置為5 min，既在一定程度上保證了狀態(tài)識別和認(rèn)證識別的時效性，也不會占用過多的帶寬和計算資源。在挑戰(zhàn)應(yīng)答完成之后，由權(quán)限中心服務(wù)器為認(rèn)證成功的微服務(wù)頒發(fā)一個唯一識別的令牌，來標(biāo)識這個微服務(wù)。該令牌也會隨每次挑戰(zhàn)應(yīng)答而變化。

由于微服務(wù)框架本身有具備心跳檢測的模塊，這里將方案中提到的心跳機(jī)制與微服務(wù)框架自己的心跳檢測一起使用。當(dāng)所有微服務(wù)實例都沒有在指定的時間間隔內(nèi)發(fā)起挑戰(zhàn)請求時，則權(quán)限中心向注冊發(fā)現(xiàn)中心發(fā)送微服務(wù)已全部停止的消息，修改微服務(wù)的注冊狀態(tài)為“DOWN”。

2.2 適用于微服務(wù)間通信的基于角色的權(quán)限控制

在傳統(tǒng)的RBAC模型中，為表達(dá)用戶與訪問權(quán)限的關(guān)聯(lián)關(guān)系，抽象出了幾大模塊來對其進(jìn)行描述，主要包括用戶、角色、會話和權(quán)限，權(quán)限一般又以操作和控制對象來表達(dá)[9-13]。而在微服務(wù)框架中，每個業(yè)務(wù)微服務(wù)實例被視為用戶對象，每個業(yè)務(wù)微服務(wù)模塊可以被定義為一種角色，對于微服務(wù)的權(quán)限使用“httpMethod+服務(wù)名”的格式來表達(dá)，傳統(tǒng)的基于角色的權(quán)限控制模型在微服務(wù)環(huán)境下即為基于微服務(wù)的權(quán)限配置。在應(yīng)用于微服務(wù)的權(quán)限配置模型中，多個微服務(wù)實例注冊為相同的微服務(wù)模塊，實現(xiàn)微服務(wù)實例與微服務(wù)功能模塊的對應(yīng)關(guān)系；同時，設(shè)計權(quán)限中心微服務(wù)來維護(hù)微服務(wù)模塊與權(quán)限集的關(guān)聯(lián)關(guān)系，實現(xiàn)微服務(wù)權(quán)限的靈活可定制。傳統(tǒng)的RBAC模型和本文設(shè)計的微服務(wù)框架中的權(quán)限控制對比如圖2所示。在RBAC模型應(yīng)用到微服務(wù)框架中后，由于微服務(wù)實例所屬的微服務(wù)是唯一不變的，所以刪除了原模型中的會話模塊，在判斷微服務(wù)權(quán)限的時候不需要經(jīng)由會話來激活對應(yīng)所屬的微服務(wù)。對于微服務(wù)權(quán)限的定義也是靈活可變的，操作可以粗略地分為“讀與寫”，也可以細(xì)分為“get,post,delete,put”；控制對象可以粗略地分為“服務(wù)級別”，也可以細(xì)分為“url級別”。通過調(diào)整不同的許可粒度，可以平衡管理復(fù)雜度和權(quán)限精準(zhǔn)度之間主次關(guān)系。

圖2 傳統(tǒng)RBAC模型在微服務(wù)中的應(yīng)用Fig.2 Application of RBAC model in microservice

權(quán)限的設(shè)置需要設(shè)計者針對大致的業(yè)務(wù)邏輯提前抽象出來，然后使微服務(wù)在每次發(fā)起訪問時都必須符合預(yù)置的權(quán)限限制。假設(shè)在一個簽名系統(tǒng)中有如下4個核心微服務(wù)模塊：用戶微服務(wù)，財務(wù)微服務(wù)，簽名微服務(wù)，文件微服務(wù)。這4個微服務(wù)存在相互調(diào)用關(guān)系，根據(jù)相關(guān)的業(yè)務(wù)邏輯，他們相互之間的調(diào)用限制如表1所示。

表1 微服務(wù)調(diào)用限制表Table 1 Invoking restriction of microservice

在業(yè)務(wù)邏輯中，新用戶在注冊入系統(tǒng)時，會默認(rèn)添加一定量的余額，因此用戶微服務(wù)有對財務(wù)微服務(wù)的post(添加)請求；用戶在進(jìn)行充值操作時，會定位充值者提供的用戶信息是否正確，確保充值正常進(jìn)行；同理，簽名微服務(wù)和文件微服務(wù)會檢查簽名和文件上傳時的用戶信息，所以都對用戶微服務(wù)有g(shù)et(獲取)權(quán)限；在簽名流程中，必須檢查該用戶的余額足夠，然后進(jìn)行扣費操作，所以簽名微服務(wù)對財務(wù)微服務(wù)有g(shù)et(查詢)和put(修改)的權(quán)限，簽名微服務(wù)獲取需要簽名的文件對象，并將簽名完成的文件重新上傳到系統(tǒng)中，所以簽名微服務(wù)對文件微服務(wù)有g(shù)et(查詢)權(quán)限和post(提交)權(quán)限。鑒于權(quán)限判定增加了接口的響應(yīng)時間，所以推薦在權(quán)限判定器的邏輯中直接跳過來自api網(wǎng)關(guān)的訪問請求，所以這里所有微服務(wù)不對來自網(wǎng)關(guān)的請求進(jìn)行限制。

為處理這些權(quán)限控制，這些權(quán)限關(guān)系會預(yù)先持久化到權(quán)限中心微服務(wù)中，并在每個微服務(wù)中設(shè)計權(quán)限判定器。由于注冊發(fā)現(xiàn)中心只存儲了微服務(wù)模塊與其提供服務(wù)的IP和端口關(guān)聯(lián)，所以通過IP和端口信息只能識別出請求中的目的地的微服務(wù)模塊。為標(biāo)識出請求來源的微服務(wù)模塊，在微服務(wù)發(fā)起請求時要求使用第2.1節(jié)中提到的令牌來表明請求者身份，同時提供對令牌和部分請求消息計算的摘要值。當(dāng)一個微服務(wù)收到請求時，消息會進(jìn)入權(quán)限判定器進(jìn)行處理，首先會校驗摘要是否一致，保證消息的完整性沒有被破壞，然后提交當(dāng)前請求的“源ip+httpMethod+源令牌”到權(quán)限中心進(jìn)行權(quán)限檢查，如果權(quán)限正確則流程繼續(xù)，如果權(quán)限不正確，則阻止當(dāng)前訪問。

3 方案分析

通過前期研究，本文提出了微服務(wù)的脆弱性之一是微服務(wù)間的訪問缺乏身份認(rèn)證和安全性控制機(jī)制，這樣很容易被惡意攻擊者利用，并通過單點突破實現(xiàn)全網(wǎng)擴(kuò)散，導(dǎo)致整個微服務(wù)集群系統(tǒng)的不安全。因此，本文提出應(yīng)用于微服務(wù)框架的微服務(wù)身份認(rèn)證機(jī)制和訪問控制機(jī)制，以權(quán)限中心微服務(wù)為基礎(chǔ)建立微服務(wù)之間的信任關(guān)系。

3.1 防止重放攻擊

在本文設(shè)計的挑戰(zhàn)應(yīng)答機(jī)制中，每次通信都會加入隨機(jī)數(shù)和時間戳，并用HMAC對時間戳消息進(jìn)行了完整性保護(hù)。每個隨機(jī)數(shù)和時間戳數(shù)據(jù)對只會使用一次，使用后立刻失效，當(dāng)攻擊者截獲數(shù)據(jù)包進(jìn)行重放時，接收方會檢查時間戳和隨機(jī)數(shù)，防止攻擊者重放數(shù)據(jù)包[14]。同時，每5 min一次令牌更新，也能夠有效降低令牌被截取帶來的不良影響。

3.2 通信消息完整性保護(hù)

在本文設(shè)計的通信協(xié)議中，每次通信都會將通信消息進(jìn)行hash值的保護(hù)，使用MD5雜湊算法計算通信消息的hash值時，加入部分通信信息和令牌數(shù)據(jù)，提高了摘要的混淆程度， 防止攻擊者對通信消息的篡改，保障協(xié)議過程中消息的完整性。

3.3 微服務(wù)間的隱蔽信道及安全性分析

各個業(yè)務(wù)微服務(wù)實例需要和權(quán)限微服務(wù)進(jìn)行通信，在本系統(tǒng)架構(gòu)中，采用改進(jìn)的挑戰(zhàn)應(yīng)答機(jī)制建立身份信任關(guān)系，防止非法訪問。微服務(wù)之間的消息通信通過令牌機(jī)制證明身份的可信，并采用權(quán)限控制系統(tǒng)對微服務(wù)實例在系統(tǒng)內(nèi)的訪問進(jìn)行控制，防止攻擊者的跳板攻擊，并且，微服務(wù)的訪問請求只能通過網(wǎng)關(guān)進(jìn)行路由然后響應(yīng)結(jié)果，請求信息不能以任何形式直接發(fā)送到某個微服務(wù)的接口上，因此，保證了微服務(wù)模塊的接口不被暴露出來。除此之外，在權(quán)限判斷過程中，選擇了源ip和源令牌的組合身份鑒定，避免了令牌被盜用之后被濫用的情況，提高了令牌的可信度。

4 結(jié)束語

針對微服務(wù)中微服務(wù)間的訪問缺乏身份認(rèn)證和安全性控制機(jī)制的這一安全性問題，提出了將挑戰(zhàn)應(yīng)答和訪問控制模型應(yīng)用到微服務(wù)框架中的方案。在保證方案本身安全性的情況下，實現(xiàn)了對微服務(wù)的身份認(rèn)證和訪問控制，對通信中可能存在的重放攻擊和消息篡改進(jìn)行防護(hù)，阻止微服務(wù)集群的單點攻擊對系統(tǒng)的影響進(jìn)行擴(kuò)散，提高了微服務(wù)框架的安全性。除了本文中提到的安全性問題，其拆分之后的效率問題也是亟待解決的內(nèi)容，因此，如何平衡框架的安全性和效率，還需要進(jìn)行進(jìn)一步的研究。