基于微服務架構的網絡安全等級保護實踐

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

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

關鍵詞：微服務架構;等級保護;令牌環;單體架構

中圖分類號：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 引言

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

2? 單體應用架構

單體應用架構，也稱巨石型架構，多用于中小型項目開發。傳統的Web應用程序將所有的功能模塊打包成為一個應用發布到Web應用服務器中，各個模塊之間往往通過開放類的公共方法并進行線程上下文切換來實現本地相互調用。

2.1 單體應用架構的優點

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

2.2 單體應用架構的缺點

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

3 微服務架構

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

3.1 微服務架構的優勢

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

3.2 微服務架構的缺點及可能出現的安全隱患

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

4 微服務環境在等保測評工作中可能出現的問題及解決方案

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

4.1 主機間信任安全

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

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

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

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

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

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

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

4.2 服務驗證及授權安全

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

區別于單體式架構中使用Session和Cookie在瀏覽器方與服務器端進行安全驗證的方式，在微服務架構下，應用程序被分成多個微服務進程，每個微服務器在原始單個應用程序中實現一個模塊的業務邏輯，每個微服務的訪問請求需要進行身份驗證和授權。微服務模塊之間安全認證的解決方案如下。

（1）啟用安全套接層

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

（2）啟用水平流量審計

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

（3）使用微服務認證框架

1） 具有API網關的客戶端令牌

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

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

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

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

4.3 微服務API開發安全

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

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

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

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

（4）采用鏈路監控組件，及時發現業務邏輯調用過程中執行慢速的接口模塊，如Spring Cloud體系中的Sleuth組件。

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

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

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

4.4 服務高可用性監測

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

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

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

5 結束語

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

參考文獻

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

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

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

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

[5] 馬力，畢馬寧，任衛紅.安全保護模型與等級保護安全要求關系的研究[J].信息網絡安全，2011（6）：1-4.

[6] 肖國煜.信息系統等級保護測評實踐[J].信息網絡安全，2011，36（7）：86-88.