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

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

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

中圖分類號：TP309? ? ? ? ? 文獻標識碼：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)用程序都在其自己的進程中運行，并通常以HTTP/HTTPS/TCP RPC模式進行主機間或主機內(nèi)通信。微服務(wù)架構(gòu)早期在一些大型電商系統(tǒng)中應(yīng)用較為廣泛，隨著架構(gòu)的優(yōu)勢逐漸被大眾所認可，微服務(wù)架構(gòu)也在很多中小型系統(tǒng)中應(yīng)用，但隨之而來的安全問題逐年增多。本文將微服務(wù)與單體應(yīng)用進行對比和分析，對微服務(wù)框架的優(yōu)缺點及相關(guān)的安全問題及在網(wǎng)絡(luò)等級保護評測的過程中需要關(guān)注的技術(shù)點進行歸納與總結(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ù)器中，各個模塊之間往往通過開放類的公共方法并進行線程上下文切換來實現(xiàn)本地相互調(diào)用。

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

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

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

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

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

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

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)，一臺機器做了所有功能，不能充分發(fā)揮服務(wù)器的性能。第二，每個微服務(wù)模塊獨立存在，擁有各自的實現(xiàn)模式。開發(fā)者可以根據(jù)需求選擇合適的開發(fā)技術(shù)，各模塊之間采用通用的API協(xié)議進行數(shù)據(jù)返回，任何一個微服務(wù)模塊的功能修改都不影響其他微服務(wù)模塊功能的使用。第三，對于微服務(wù)架構(gòu)中任何一個節(jié)點都可以進行主備切換，便于運維。

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

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

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

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

4.1 主機間信任安全

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

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

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

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

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

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

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

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

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

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

（1）啟用安全套接層

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

（2）啟用水平流量審計

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

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

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)認證方式如圖1所示。

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

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

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

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

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

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

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

（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（遠程命令執(zhí)行）漏洞，例如Struts2框架漏洞、反序列化漏洞等。

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

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

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

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

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

5 結(jié)束語

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

參考文獻

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

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

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

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

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

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