白金雪 金旺 馬濤 王汝成 商興男

摘? ?要：近年來，微服務(wù)架構(gòu)成為最流行的應(yīng)用軟件實(shí)現(xiàn)模式之一，它支持將應(yīng)用的每個模塊進(jìn)行單獨(dú)部署，將業(yè)務(wù)功能進(jìn)行解耦。文章將微服務(wù)架構(gòu)與傳統(tǒng)的單體架構(gòu)應(yīng)用進(jìn)行對比，并在安全方面對微服務(wù)架構(gòu)在設(shè)計、編碼、部署等環(huán)節(jié)進(jìn)行詳細(xì)闡述，從信息安全等級保護(hù)角度，提出了提高接口安全性、服務(wù)節(jié)點(diǎn)內(nèi)部以及服務(wù)節(jié)點(diǎn)之間安全性的措施。

關(guān)鍵詞：微服務(wù)架構(gòu);等級保護(hù);令牌環(huán);單體架構(gòu)

中圖分類號：TP309? ? ? ? ? 文獻(xiàn)標(biāo)識碼：B

Abstract： The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. This paper presents advantages of microservices over the monolith services from a security perspective. In the most important section of the article， introduces the security aspect in a microservices architecture during development processes including architecture design， coding and deployment process， summarizes how to improve the interface security， system security， avoiding unsafe node communications under the information security classified protection framework.

Key words： microservice architecture; classified protection; token ring; monolithic

1 引言

微服務(wù)架構(gòu)是一種將單體應(yīng)用程序作為一套小型服務(wù)開發(fā)的方法，每種應(yīng)用程序都在其自己的進(jìn)程中運(yùn)行，并通常以HTTP/HTTPS/TCP RPC模式進(jìn)行主機(jī)間或主機(jī)內(nèi)通信。微服務(wù)架構(gòu)早期在一些大型電商系統(tǒng)中應(yīng)用較為廣泛，隨著架構(gòu)的優(yōu)勢逐漸被大眾所認(rèn)可，微服務(wù)架構(gòu)也在很多中小型系統(tǒng)中應(yīng)用，但隨之而來的安全問題逐年增多。本文將微服務(wù)與單體應(yīng)用進(jìn)行對比和分析，對微服務(wù)框架的優(yōu)缺點(diǎn)及相關(guān)的安全問題及在網(wǎng)絡(luò)等級保護(hù)評測的過程中需要關(guān)注的技術(shù)點(diǎn)進(jìn)行歸納與總結(jié)。

2? 單體應(yīng)用架構(gòu)

單體應(yīng)用架構(gòu)，也稱巨石型架構(gòu)，多用于中小型項目開發(fā)。傳統(tǒng)的Web應(yīng)用程序?qū)⑺械墓δ苣K打包成為一個應(yīng)用發(fā)布到Web應(yīng)用服務(wù)器中，各個模塊之間往往通過開放類的公共方法并進(jìn)行線程上下文切換來實(shí)現(xiàn)本地相互調(diào)用。

2.1 單體應(yīng)用架構(gòu)的優(yōu)點(diǎn)

單體應(yīng)用架構(gòu)比較適合于小項目，其具備幾個優(yōu)點(diǎn)：第一，開發(fā)過程及框架簡單，業(yè)務(wù)邏輯清晰，模塊間調(diào)用采用方法調(diào)用模式，不用考慮調(diào)用失敗等異常處理的情況;第二，單體架構(gòu)應(yīng)用部署簡單，應(yīng)用可以被整體部署在一個Web容器中，各個模塊功能都是完全的，不需要考慮模塊間依賴的問題，若系統(tǒng)需要進(jìn)行橫向擴(kuò)展，只需要增加機(jī)器，進(jìn)行整包部署即可;第三，單體架構(gòu)應(yīng)用中所有功能模塊之間通訊都在本地執(zhí)行，沒有分布式調(diào)用的性能及網(wǎng)絡(luò)開銷。

2.2 單體應(yīng)用架構(gòu)的缺點(diǎn)

雖然單體應(yīng)用架構(gòu)結(jié)構(gòu)簡單，適合于大多數(shù)應(yīng)用場景，但是單體應(yīng)用架構(gòu)存在幾點(diǎn)不足：第一，所有的功能在一個項目上面進(jìn)行維護(hù)，系統(tǒng)依賴資源包多且復(fù)雜;第二，模塊耦合度過高，一個小問題導(dǎo)致整個應(yīng)用癱瘓;第三，應(yīng)用構(gòu)建時間長，任何小修改必須重新構(gòu)建整個項目;第四，單體應(yīng)用的擴(kuò)展性不高，無法滿足高并發(fā)情況下的業(yè)務(wù)需求;即便是需要擴(kuò)展也要整個應(yīng)用復(fù)制到不同服務(wù)器上面，并配置負(fù)載均衡;另外，每個業(yè)務(wù)模塊對于硬件資源的利用并不相同，在單體應(yīng)用中，在業(yè)務(wù)橫向擴(kuò)展時，整個應(yīng)用被整體打包部署，無法根據(jù)不同的硬件資源消耗進(jìn)行單獨(dú)的調(diào)配。

3 微服務(wù)架構(gòu)

區(qū)別于單體應(yīng)用架構(gòu)，微服務(wù)架構(gòu)應(yīng)用中的每個模塊運(yùn)行在不同的進(jìn)程中，模塊之間的調(diào)用采用RPC或HTTP方式進(jìn)行調(diào)用，依靠XML/JSON進(jìn)行傳值，這些服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，可以通過全自動部署機(jī)制進(jìn)行獨(dú)立部署。微服務(wù)架構(gòu)區(qū)別于以往的單體式應(yīng)用，它將各個業(yè)務(wù)模塊進(jìn)行獨(dú)立部署，進(jìn)行解耦。微服務(wù)應(yīng)用中的各個模塊可以部署在一臺物理機(jī)的不同容器中，也可以部署在不同機(jī)器上。除了調(diào)用方式不同外，大多數(shù)微服務(wù)架構(gòu)，如Spring Cloud、Dubbo還提供服務(wù)注冊發(fā)現(xiàn)中心，通過此方式實(shí)現(xiàn)負(fù)載均衡、動態(tài)擴(kuò)容、自動熔斷等功能。

3.1 微服務(wù)架構(gòu)的優(yōu)勢

隨著大數(shù)據(jù)時代的到來，越來越多的互聯(lián)網(wǎng)公司使用微服務(wù)技術(shù)并取得了不錯的效果，也有一些技術(shù)創(chuàng)業(yè)公司，幫助一些大型傳統(tǒng)企業(yè)，利用微服務(wù)架構(gòu)理念解決現(xiàn)有系統(tǒng)架構(gòu)的問題。微服務(wù)架構(gòu)具有幾項特性。第一，微服務(wù)架構(gòu)具有低耦合性。將各個功能模塊部署在不同的服務(wù)器/容器中，最大程度地分配利用系統(tǒng)資源，區(qū)別于單體結(jié)構(gòu)，一臺機(jī)器做了所有功能，不能充分發(fā)揮服務(wù)器的性能。第二，每個微服務(wù)模塊獨(dú)立存在，擁有各自的實(shí)現(xiàn)模式。開發(fā)者可以根據(jù)需求選擇合適的開發(fā)技術(shù)，各模塊之間采用通用的API協(xié)議進(jìn)行數(shù)據(jù)返回，任何一個微服務(wù)模塊的功能修改都不影響其他微服務(wù)模塊功能的使用。第三，對于微服務(wù)架構(gòu)中任何一個節(jié)點(diǎn)都可以進(jìn)行主備切換，便于運(yùn)維。

3.2 微服務(wù)架構(gòu)的缺點(diǎn)及可能出現(xiàn)的安全隱患

微服務(wù)的目的是分布式、去中心化的，通過對應(yīng)用進(jìn)行有效的拆分，實(shí)現(xiàn)敏捷開發(fā)和部署。但為了實(shí)現(xiàn)這個目的，架構(gòu)由此帶來了一定的復(fù)雜性。開發(fā)者需要將應(yīng)用邏輯在模塊間進(jìn)行進(jìn)程間通訊，從而實(shí)現(xiàn)特定的業(yè)務(wù)邏輯。進(jìn)程間通訊或主機(jī)間通訊過程中請求超時或者服務(wù)不可用等問題經(jīng)常出現(xiàn)，相對于單體式應(yīng)用中通過語言層級的方法或者進(jìn)程調(diào)用，微服務(wù)應(yīng)用架構(gòu)在業(yè)務(wù)邏輯實(shí)現(xiàn)及數(shù)據(jù)流轉(zhuǎn)、異常處理方面顯得非常復(fù)雜。表1描述了單體架構(gòu)與微服務(wù)架構(gòu)之間的區(qū)別。

4 微服務(wù)環(huán)境在等保測評工作中可能出現(xiàn)的問題及解決方案

從安全角度講，微服務(wù)架構(gòu)是一個開放的架構(gòu)，系統(tǒng)攻擊面增加、開放的端口更多導(dǎo)致系統(tǒng)的安全性降低。另外，由于對服務(wù)接口的公開，使得安全保護(hù)策略變得更復(fù)雜。在信息安全等級保護(hù)工作進(jìn)行過程中，需要對服務(wù)部署的主機(jī)環(huán)境、網(wǎng)絡(luò)環(huán)境、主機(jī)間安全、微服務(wù)部署環(huán)境、接口安全進(jìn)行安全檢測。

4.1 主機(jī)間信任安全

微服務(wù)部署模式多種多樣，其中最為廣泛的是容器技術(shù)，如當(dāng)今比較流行的Docker。在安全檢測過程中需要對容器層面的安全進(jìn)行關(guān)注，保證各容器之間得到有效的隔離，容器與主機(jī)操作系統(tǒng)之間采取怎樣的保護(hù)措施將是要考慮的問題。和傳統(tǒng)的主機(jī)信任機(jī)制一樣，身份及訪問管理在減小數(shù)據(jù)泄露風(fēng)險上的作用。對容器環(huán)境的安全加固注意事項包括幾個方面。

（1）小心使用鏡像倉庫，對于從遠(yuǎn)端下載的鏡像要檢查其各項安全配置，一定要非常熟悉鏡像的項目發(fā)布者，避免內(nèi)置安全漏洞，時刻注意Docker服務(wù)的官方發(fā)布版本，進(jìn)行安全升級。

（2）對Docker宿主機(jī)按照等保級別要求進(jìn)行安全加固，務(wù)必保證Docker宿主機(jī)的安全，主機(jī)加固方法可以參考相關(guān)級別的安全Checklist及相關(guān)主機(jī)安全規(guī)范。

（3）限制同一主機(jī)內(nèi)部不同容器之間的網(wǎng)絡(luò)流量，每個容器都有可能訪問同一主機(jī)內(nèi)部的不同容器資源，可能會導(dǎo)致意外泄露信息。

（4）用Root或超級權(quán)限啟動Docker容器，會將默認(rèn)的Docker守護(hù)程序更改為綁定到TCP端口或任何其他Unix套接字，那么任何有權(quán)訪問該端口或套接字的人都可以完全訪問Docker守護(hù)程序。建議創(chuàng)建Docker用戶組用戶，用Docker組用戶啟動，降低系統(tǒng)風(fēng)險。如果使用Root身份運(yùn)行的容器，需要映射為Docker主機(jī)特定用戶。

（5）容器默認(rèn)使用主機(jī)的所有內(nèi)存，可以使用內(nèi)存限制機(jī)制來防止一個容器消耗所有主機(jī)資源的拒絕服務(wù)攻擊。

（6）編排工具及平臺的安全性監(jiān)測。越來越多的使用容器進(jìn)行部署的開發(fā)者使用編排工具進(jìn)行自動化部署及運(yùn)維，編排工具及平臺的安全防護(hù)措施也是需要特別注意。

4.2 服務(wù)驗證及授權(quán)安全

微服務(wù)架構(gòu)為軟件應(yīng)用帶來許多好處，包括小型開發(fā)團(tuán)隊，更短的開發(fā)周期，語言選擇的靈活性和增強(qiáng)的服務(wù)可擴(kuò)展性，同時也存在一些問題，其中的一個挑戰(zhàn)就是如何在微服務(wù)架構(gòu)中實(shí)現(xiàn)靈活、安全和有效的身份驗證和授權(quán)方案。

區(qū)別于單體式架構(gòu)中使用Session和Cookie在瀏覽器方與服務(wù)器端進(jìn)行安全驗證的方式，在微服務(wù)架構(gòu)下，應(yīng)用程序被分成多個微服務(wù)進(jìn)程，每個微服務(wù)器在原始單個應(yīng)用程序中實(shí)現(xiàn)一個模塊的業(yè)務(wù)邏輯，每個微服務(wù)的訪問請求需要進(jìn)行身份驗證和授權(quán)。微服務(wù)模塊之間安全認(rèn)證的解決方案如下。

（1）啟用安全套接層

使用超文本傳輸協(xié)議HTTP，以明文的形式傳輸數(shù)據(jù)，將會把數(shù)據(jù)暴露給黑客，因此為保證各模塊間數(shù)據(jù)的安全性，建議采用SSL加密傳輸。

（2）啟用水平流量審計

除了來自用戶和第三方的垂直流量之外，微服務(wù)之間還存在大量的水平流量，這些流量可能位于同一局域網(wǎng)中，也可能位于不同的數(shù)據(jù)中心內(nèi)，第三方存在這些微服務(wù)之間的流量，通過啟用流量審計及SSL對微服務(wù)之間的數(shù)據(jù)傳輸進(jìn)行加密。

（3）使用微服務(wù)認(rèn)證框架

1） 具有API網(wǎng)關(guān)的客戶端令牌

API網(wǎng)關(guān)是外部請求的唯一入口，所有請求都通過API網(wǎng)關(guān)，可以有效地隱藏微服務(wù)，分離各種API和內(nèi)部組件，以減少暴露的被攻擊面。API網(wǎng)關(guān)認(rèn)證方式如圖1所示。

2） 使用JWT（Json Web Token）等第三方安全服務(wù)框架進(jìn)行微服務(wù)認(rèn)證。

3） 令牌由用戶自己持有，并且通常以Cookie的形式存儲在瀏覽器中。令牌保存用戶的身份信息，并且每次將請求發(fā)送到服務(wù)器時，服務(wù)器因此可以確定訪問者的身份并確定其是否可以訪問所請求的資源。

4） 使用OAuth2.0規(guī)范，對于用戶授權(quán)訪問的管控方面推薦使用Spring的OAuth2規(guī)范進(jìn)行用戶授權(quán)訪問管控。

4.3 微服務(wù)API開發(fā)安全

潛在的黑客、惡意軟件或任何匿名的局外人都可能輕易地嘗試一系列攻擊，如XSS、SSRF或SQL注入。為保障微服務(wù)API的安全，可以通過幾個方面來防范。

（1）使用HTTPS安全協(xié)議，或使用非對稱加密算法的安全簽名。

（2）確保API請求使用時間參數(shù)，防止重復(fù)請求以及惡意偽造請求攻擊。

（3）存儲敏感數(shù)據(jù)應(yīng)該使用加密算法，不要采用明文或者純文本形式存儲，選用比較成熟穩(wěn)定的加密算法，不要使用處于測試階段的加密算法，他們可能存在未知漏洞。

（4）采用鏈路監(jiān)控組件，及時發(fā)現(xiàn)業(yè)務(wù)邏輯調(diào)用過程中執(zhí)行慢速的接口模塊，如Spring Cloud體系中的Sleuth組件。

（5）分離各種API和內(nèi)部組件，以減少暴露的被攻擊面。

（6）優(yōu)化微服務(wù)API參數(shù)，避免緩慢HTTP拒絕服務(wù)攻擊，XSS跨站腳本注入等安全漏洞。關(guān)注每年更新的OWASP Top 10，審查自身有無類似安全漏洞，特別注意RCE（遠(yuǎn)程命令執(zhí)行）漏洞，例如Struts2框架漏洞、反序列化漏洞等。

（7）注意API接口的返回值中是否有多余字段，可能涉及敏感信息，應(yīng)遵循最小化原則只返回必須的字段。這些信息可能會在某些情況下暴露在應(yīng)用程序的日志中，或是被其他服務(wù)無意中訪問到，從而帶來安全隱患。

4.4 服務(wù)高可用性監(jiān)測

微服務(wù)的分布式處理固然有相應(yīng)的好處，但是考慮到單點(diǎn)處理、集中管理、負(fù)載均衡、備份、容災(zāi)、熱備等方式的同時，也帶來了新的問題點(diǎn)。單點(diǎn)處理故障，分布式處理的高可用性如何處理;還有其高可用性安全如何去保證，因此在微服務(wù)處理便捷的同時，也會出現(xiàn)新應(yīng)用、新技術(shù)面臨的新的安全風(fēng)險點(diǎn)。

（1）從網(wǎng)絡(luò)層面分析雙機(jī)熱備，解決了單點(diǎn)故障造成的風(fēng)險，而雙機(jī)設(shè)備之間的通訊采用生成樹的方式和加密技術(shù)的方法，來實(shí)現(xiàn)網(wǎng)絡(luò)中雙機(jī)熱備的高可用性的安全。

（2）從應(yīng)用層面分析得出服務(wù)器雙機(jī)熱備、異地雙活、容災(zāi)、負(fù)載均衡、集群等方式，消除了磁盤的單點(diǎn)故障、軟件的單點(diǎn)故障、系統(tǒng)運(yùn)行時的單點(diǎn)故障。主服務(wù)器故障時，備份服務(wù)器能夠自動接管主服務(wù)器的工作，并及時切換過去，以實(shí)現(xiàn)對用戶的不間斷服務(wù)，既而這之間采用一些加密技術(shù)來解決這些方式帶來的高可用性安全。

5 結(jié)束語

本文內(nèi)容提出了在信息系統(tǒng)安全等級保護(hù)測評過程中對微服務(wù)架構(gòu)進(jìn)行測評的注意事項。為規(guī)范微服務(wù)架構(gòu)安全應(yīng)用標(biāo)準(zhǔn)，在等保測評工作中，除對所測評系統(tǒng)進(jìn)行最基本的系統(tǒng)級別測評外，建議在建設(shè)初期從架構(gòu)安全方面進(jìn)行全方面規(guī)劃。通過對微服務(wù)的部署環(huán)境安全、接口認(rèn)證安全、API安全及審計、高可用性監(jiān)測安全方面制定有效的安全架構(gòu)方案，并在開發(fā)過程中，對開發(fā)人員進(jìn)行程序級別的安全培訓(xùn)，在系統(tǒng)實(shí)施過程中增強(qiáng)運(yùn)維人員關(guān)于系統(tǒng)安全方面的安全意識，從而提高微服務(wù)應(yīng)用整體的可用性及安全性。

參考文獻(xiàn)

[1] GB/T 22239-2008，信息系統(tǒng)安全等級保護(hù)基本要求[S].

[2] 潘孝陽，黃曉芳.微服務(wù)框架的安全管控機(jī)制的設(shè)計[J].西南科技大學(xué)學(xué)報，2018， 33（4）：74-78.

[3] 常艷，王冠.網(wǎng)絡(luò)安全滲透測試研究[J].信息網(wǎng)絡(luò)安全，2012（11）：3-4.

[4] 白璐.信息系統(tǒng)安全等級保護(hù)物理安全測評方法研究[J].信息網(wǎng)絡(luò)安全， 2011（12）：89-92.

[5] 馬力，畢馬寧，任衛(wèi)紅.安全保護(hù)模型與等級保護(hù)安全要求關(guān)系的研究[J].信息網(wǎng)絡(luò)安全，2011（6）：1-4.

[6] 肖國煜.信息系統(tǒng)等級保護(hù)測評實(shí)踐[J].信息網(wǎng)絡(luò)安全，2011，36（7）：86-88.