云原生架構(gòu)下的微服務(wù)安全研究

【摘 要】 本文主要針對云原生架構(gòu)下的微服務(wù)安全現(xiàn)狀進(jìn)行了研究，提出了基于微服務(wù)的安全風(fēng)險評估模型，給出了云原生架構(gòu)下的微服務(wù)安全解決方案。

【關(guān)鍵詞】 云計算 微服務(wù) 網(wǎng)絡(luò)安全

1 引言

在為企業(yè)提供邊緣計算、節(jié)點安全、自動化以及智慧數(shù)據(jù)服務(wù)方面，基于云計算構(gòu)建的網(wǎng)絡(luò)架構(gòu)模型存在諸多優(yōu)點，如能夠?qū)崿F(xiàn)規(guī)模經(jīng)濟(jì)效應(yīng)，有效整合、配置資源，具有高可用性等。云計算集成了各種計算技術(shù)，為終端用戶提供微服務(wù)（Micro Services）。然而，在云計算與微服務(wù)發(fā)展的同時，也存在著一些安全隱患。

2 云原生架構(gòu)下的微服務(wù)安全現(xiàn)狀及面臨的問題

為了理解與云計算相關(guān)的安全問題，首先要理解云計算的概念。美國國家標(biāo)準(zhǔn)技術(shù)研究院（NIST）將云計算視為服務(wù)提供的三重模型，其中包括基本特征、服務(wù)模型和部署模型。NIST對云計算的定義如圖1所示。

云計算的特征和模型提供了改進(jìn)、優(yōu)化的解決方案，并能為客戶降低成本。然而各種技術(shù)的實現(xiàn)（如虛擬化和多租戶）也產(chǎn)生了云計算所特有的安全風(fēng)險和漏洞，如容器基礎(chǔ)設(shè)施安全、容器編排平臺安全、微服務(wù)安全、服務(wù)網(wǎng)格安全、無服務(wù)器計算安全等。本文介紹了云原生架構(gòu)下的微服務(wù)安全問題，具體細(xì)分為微服務(wù)應(yīng)用程序編程接口（API）安全、微服務(wù)應(yīng)用安全。其中，微服務(wù)API安全主要包括云原生API網(wǎng)關(guān)、API脆弱性評估；微服務(wù)應(yīng)用安全主要包括認(rèn)證授權(quán)、API安全、通信安全、憑證管理、日志審計、監(jiān)控追蹤等。

云原生架構(gòu)下的微服務(wù)是一個通過消息進(jìn)行交互的內(nèi)聚、獨立的過程。例如，一個用于計算的微服務(wù)框架，它能夠提供可通過消息請求的算術(shù)運算，但不能提供其他如繪圖和可視化等功能。從技術(shù)角度來看，微服務(wù)是概念上部署的獨立組件隔離并配備專用內(nèi)存持久性工具（如數(shù)據(jù)庫）。微服務(wù)架構(gòu)是一種分布式應(yīng)用程序，它的所有模塊都是微服務(wù)。由于微服務(wù)體系結(jié)構(gòu)的所有組件都是微服務(wù)，因此個體活動源自其組件通過消息的組合和協(xié)調(diào)。圖2是一個微服務(wù)架構(gòu)的示例圖，假設(shè)存在2種微服務(wù)：計算器和顯示器。第一個是上文提到的計算器微服務(wù)，第二個是渲染和顯示圖像。為了實現(xiàn)研究目標(biāo)，我們可以引入一種新的微服務(wù)，稱為繪圖儀，它協(xié)調(diào)計算器進(jìn)行計算圖形的形狀，調(diào)用Displayer渲染計算的形狀。

微服務(wù)的概念源于工業(yè)實踐，它將大型單片應(yīng)用程序劃分為更小的協(xié)同服務(wù)，從而實現(xiàn)更大規(guī)模的可維護(hù)、可擴展和可測試，以適應(yīng)云環(huán)境。使用微服務(wù)架構(gòu)開發(fā)和部署云應(yīng)用程序越來越流行。盡管微服務(wù)架構(gòu)的開發(fā)和部署在云生產(chǎn)環(huán)境中有一些優(yōu)勢，但安全性仍是企業(yè)和客戶優(yōu)先考慮的，因此我們首先要確定微服務(wù)面臨的主要安全問題。如圖3所示，云計算開發(fā)人員應(yīng)注意微服務(wù)常見安全問題。

2.1 云原生架構(gòu)下的微服務(wù)容器安全

首先，容器的存在為微服務(wù)提供了一個完美的環(huán)境。使用容器包裝或集裝箱化分布式微服務(wù)的優(yōu)勢明顯。例如，容器消除了對底層基礎(chǔ)設(shè)施服務(wù)的依賴，從而減少了對接不同平臺的復(fù)雜性。因此，微服務(wù)架構(gòu)可以利用Docker容器來測試和跨可用的計算機網(wǎng)絡(luò)與其他計算設(shè)備在單獨的容器中部署單個服務(wù)。此外，容器可以提供標(biāo)準(zhǔn)化建設(shè)和持續(xù)整合與交付服務(wù)。簡而言之，容器的存在、發(fā)展與微服務(wù)聯(lián)系緊密，它們結(jié)合在一起，形成一個生態(tài)系統(tǒng)。當(dāng)Docker容器出現(xiàn)安全問題時，可能會引起連鎖反應(yīng)。

云原生架構(gòu)下的微服務(wù)容器主要有2類攻擊者：直接攻擊者和間接攻擊者。直接攻擊者瞄準(zhǔn)內(nèi)部的核心服務(wù)容器，銷毀或修改網(wǎng)絡(luò)和系統(tǒng)文件。例如，攻擊者可以從面向互聯(lián)網(wǎng)的容器服務(wù)中獲得相關(guān)容器中的根權(quán)限。進(jìn)而從被攻擊的容器對運行在同一主機操作系統(tǒng)上的其他容器發(fā)起攻擊，并獲得對關(guān)鍵主機操作系統(tǒng)的訪問權(quán)限系統(tǒng)文件。間接攻擊者與直接攻擊者具有相同的能力，但他們的目標(biāo)是容器生態(tài)系統(tǒng)，如代碼和圖像存儲庫，到達(dá)軟件環(huán)境。容器攻擊面包含整個部署工具鏈。部署工具鏈包括映像概念、映像分發(fā)過程、自動構(gòu)建、映像簽名、主機配置和第三方組件。圖像分發(fā)中的漏洞源于容器中心（如Docker hub）和容器生態(tài)系統(tǒng)中的其他注冊表。此外，容器圖像分布的設(shè)置增加了幾個外部步驟，從而增加了全局攻擊面。例如，一旦容器中的黑客程序啟動有效的逃逸攻擊可以獲得主機的根權(quán)限，這將影響其他容器或整個系統(tǒng)的可靠性。

2.2 云原生架構(gòu)下的微服務(wù)數(shù)據(jù)安全

微服務(wù)由于其精細(xì)的粒度，需要更復(fù)雜的通信。因此，消息數(shù)據(jù)不僅可能被攔截，也可能被競爭對手利用而推斷出具體業(yè)務(wù)運營明細(xì)情況。因為微服務(wù)通常部署在云環(huán)境中，除了消息傳輸之外，微服務(wù)還存在隱私安全問題，云消費者也擔(dān)心他們存儲的信息可能被泄露或不當(dāng)使用。微服務(wù)部署在許多分布式容器中，因此，客戶可能會對其私人信息的安全性產(chǎn)生懷疑。如何防止傳輸?shù)南�息泄露仍然是一個嚴(yán)峻的問題。

為了確保數(shù)據(jù)的保密性、完整性和可用性，微服務(wù)提供商必須提供最低限度的數(shù)據(jù)安全保障，包括通過加密保護(hù)共享存儲環(huán)境中的所有數(shù)據(jù)，嚴(yán)格訪問控制以防止未經(jīng)授權(quán)訪問數(shù)據(jù)，并定時備份數(shù)據(jù)等。

2.3 云原生架構(gòu)下的微服務(wù)權(quán)限安全

微服務(wù)體系結(jié)構(gòu)應(yīng)該驗證每個服務(wù)的真實性，因為如果單個服務(wù)由攻擊者控制，該服務(wù)可能會惡意影響其他服務(wù)。此外，當(dāng)服務(wù)接收到消息時，它需要確定消息的真實性和有效性。

2.4 云原生架構(gòu)下的微服務(wù)網(wǎng)絡(luò)安全

在網(wǎng)絡(luò)安全領(lǐng)域，傳統(tǒng)的典型威脅主要包括地址解析協(xié)議（ARP）欺騙、中間人攻擊（MITM）、DoS攻擊等。ARP欺騙涉及構(gòu)建偽造目標(biāo)物理地址的ARP回復(fù)，通過發(fā)送偽造的ARP回復(fù)，主機無法與目標(biāo)主機正確通信。

2.5 云原生架構(gòu)下的其他微服務(wù)安全風(fēng)險

一般來說，保護(hù)單一服務(wù)比保護(hù)微服務(wù)相對容易。單一服務(wù)有明確的邊界且通信是內(nèi)部的。然而，在基于微服務(wù)的光纖陀螺系統(tǒng)中，任何功能的實現(xiàn)都可能需要通過部署的光纖陀螺網(wǎng)絡(luò)在多個微服務(wù)之間進(jìn)行通信。因此，這將暴露更多的數(shù)據(jù)和信息或系統(tǒng)端點，從而擴大了攻擊面。沒有網(wǎng)絡(luò)保護(hù)，就無法實現(xiàn)安全的服務(wù)通信。

底層基礎(chǔ)設(shè)施也起著至關(guān)重要的作用。新興網(wǎng)絡(luò)架構(gòu)軟件定義網(wǎng)絡(luò)（SDN）等范例為云管理提供了靈活性和高效率等優(yōu)勢特性。然而，SDN還引入了以前不存在的、在傳統(tǒng)網(wǎng)絡(luò)中更難利用的新威脅，可能使網(wǎng)絡(luò)更容易被滲透。SDN的主要威脅是網(wǎng)絡(luò)應(yīng)用程序的身份驗證和授權(quán)�？刂破髂�塊必須進(jìn)行一系列測試和驗證，以確保其可靠并適合在生產(chǎn)環(huán)境中使用。然而，這對于保證第三方應(yīng)用程序的可靠性和可信性來說是困難的�？刂破髂�塊是集中式的，因此，如果惡意應(yīng)用程序接管控制器，結(jié)果可能會導(dǎo)致不同類型的攻擊，嚴(yán)重影響整個微服務(wù)架構(gòu)。因此，信任沖突是一種主要威脅，存在于控制器之間及應(yīng)用程序之中。SDN網(wǎng)絡(luò)的設(shè)計策略明確允許網(wǎng)絡(luò)應(yīng)用程序在網(wǎng)絡(luò)中更改應(yīng)用，但沒有行使驗證技術(shù)或語義，以評估這些應(yīng)用程序的可信度。惡意應(yīng)用程序可以濫用這些權(quán)限并危害網(wǎng)絡(luò)運營。

除SDN安全問題外，大量微服務(wù)帶來的網(wǎng)絡(luò)復(fù)雜性大大增加了監(jiān)控整個應(yīng)用程序安全的難度；單一微服務(wù)的中止也可能會導(dǎo)致整個應(yīng)用程序的崩潰。

3 云原生架構(gòu)下的微服務(wù)安全風(fēng)險評估模型

3.1 STRIDE威脅模型

微軟公司的STRIDE是一種流行的威脅建模方法，如表1所示。類似的安全威脅建模模型還有DREAD框架。識別和分類威脅事件有助于評估其影響和應(yīng)對措施。

3.2 Prasad Saripalli風(fēng)險評估模型

雖然STRIDE是一個經(jīng)過測試的較好的傳統(tǒng)軟件框架系統(tǒng)，但微服務(wù)安全風(fēng)險評估模型Prasad Saripalli明確包括特定于云的安全性目標(biāo)，更適合于云安全風(fēng)險評估。美國《聯(lián)邦信息安全管理法案》（Federal Information Security Management Act，F(xiàn)ISMA）為信息系統(tǒng)定義了3個安全目標(biāo)：保密性（Confidentiality），完整性（Integrity）和可用性（Availability）。Prasad Saripalli在基于云平臺的信息安全系統(tǒng)基礎(chǔ)之上，又增加了3個安全目標(biāo)：多方信任（Multiparty Trust）、相互審計（Mutual Auditability）和可用性（Usability）。為每個威脅事件建立適當(dāng)?shù)陌踩�目�?biāo)需要先確定其潛在影響。Prasad Saripalli表示安全類別的通用格式信息類型為：

Ie=[(C,0),(I,6),(A,8),(M,1),(A,1),(U,8)]

潛在影響的可接受值分為4個等級：較低、中等、高或不適用。風(fēng)險是以上安全威脅事件及其后果的嚴(yán)重性影響因素的概率或頻率的組合。微服務(wù)安全風(fēng)險類別根據(jù)等式進(jìn)行評估。給定應(yīng)用程序的總體平臺安全風(fēng)險（RS）將是累積的平均值，映射到安全目標(biāo)類別的n個威脅的加權(quán)總和：

具體的計算過程如表2所示。

4 云原生架構(gòu)下的微服務(wù)安全架構(gòu)及安全防御措施

4.1 云原生架構(gòu)下的微服務(wù)安全架構(gòu)

基于上述風(fēng)險評估架構(gòu)，本文提出了相應(yīng)的基于云原生架構(gòu)的微服務(wù)安全整體框架。圖4為國內(nèi)學(xué)者總結(jié)的云原生架構(gòu)下的微服務(wù)安全架構(gòu)。在此基礎(chǔ)上，可以追加后臺日志系統(tǒng)與本文中提到的風(fēng)險評估告警體系。

   

4.2 基于云原生架構(gòu)的微服務(wù)安全防御措施

（1）物理措施

微服務(wù)安全防御機制首先需要對物理設(shè)備進(jìn)行有效管理，包括服務(wù)器、路由器、防火墻、交換機等網(wǎng)絡(luò)關(guān)鍵設(shè)備的定期檢查、更新，并且需要安裝不間斷電源（UPS）。

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

在數(shù)據(jù)安全中，數(shù)據(jù)源的保護(hù)也非常重要。數(shù)據(jù)源的保護(hù)主要是針對操作員惡意篡改或者泄露主要數(shù)據(jù)。因此需要確定數(shù)據(jù)源是否可驗證并且具有與其自身相關(guān)聯(lián)的信譽度，以及如何防止篡改或者泄露。

首先，需要確保管理系統(tǒng)能夠驗證與操作有關(guān)的參與者（或服務(wù)）相關(guān)的數(shù)據(jù)源，并且能夠使參與者（或服務(wù)）對其在數(shù)據(jù)中的行為負(fù)責(zé)。另外，數(shù)據(jù)源的復(fù)現(xiàn)是應(yīng)急響應(yīng)的關(guān)鍵流程，因此數(shù)據(jù)的熱備份至關(guān)重要。

其次，創(chuàng)建用于數(shù)據(jù)流認(rèn)證的公私鑰加密系統(tǒng)。并且基于密碼學(xué)對源數(shù)據(jù)進(jìn)行加密處理（如RSA或DES算法），結(jié)合密鑰對保證云端數(shù)據(jù)傳輸?shù)目煽啃耘c完整性。另外，備份數(shù)據(jù)的加密存儲能夠有效預(yù)防數(shù)據(jù)的篡改與外泄。

（3）訪問控制

針對微服務(wù)方面的權(quán)限訪問保障，請求訪問資源只能被分配最低限度的必要權(quán)利。將權(quán)限授予超出必要的范圍可能導(dǎo)致用戶以不正當(dāng)?shù)姆绞将@取或更改信息。因此，權(quán)限訪問控制可以限制攻擊者破壞系統(tǒng)。

輕型目錄訪問協(xié)議（LDAP）是SaaS應(yīng)用程序中使用的一種非常流行的授權(quán)協(xié)議，如圖5所示。LDAP服務(wù)存儲相對靜態(tài)的授權(quán)信息，適用于一次記錄、多次讀取的場景。為了提供一種基于TCP/IP的輕量級網(wǎng)絡(luò)，降低管理維護(hù)成本，LDAP簡化了目錄訪問協(xié)議（DAP）并且可以輕松添加、修改、查詢和刪除用戶目錄信息。

  

   

OAuth77也是一種流行的授權(quán)協(xié)議，以確保REST API能夠進(jìn)行正常的授權(quán)訪問。通過OAuth，授權(quán)服務(wù)器向受信任的客戶端應(yīng)用程序發(fā)出訪問令牌，然后客戶端應(yīng)用程序可以代表最終用戶訪問API。此外，OpenID Connect是OAuth之上的一個身份驗證層，它還允許服務(wù)讀取基本用戶信息。

（4）網(wǎng)絡(luò)隔離與容器隔離

網(wǎng)絡(luò)隔離通常是通過隔離卡與安全隔離網(wǎng)閘實現(xiàn)的。而云端的容器隔離可以通過Linux系統(tǒng)中的SELinux（Security Enhanced Linux）策略模塊實現(xiàn)。SELinux是Linux中廣泛使用的安全模塊，其對安全策略模塊的支持效果十分顯著。對保護(hù)容器安全的SELinux策略模塊允許為不同容器的鏡像指定SELinux域，從而提高容器的安全性。除此以外，Gao等人提出了一種基于功率的命名空間方法，用于檢測多租戶容器云服務(wù)上的信息泄露。信息泄露主要是由于Linux系統(tǒng)中的系統(tǒng)資源隔離機制沒有完全實現(xiàn)，基于功率的命名空間方法能夠記錄和監(jiān)視每個容器的功率使用情況。對于每個容器的功率使用統(tǒng)計信息，所提出的方法可以動態(tài)限制已超過其容量的容器計算能力定義的功率閾值，進(jìn)而實現(xiàn)有效的資源隔離。

5 結(jié)語

盡管云原生架構(gòu)下的微服務(wù)體系有許多優(yōu)點，但仍存在許多實際和潛在的安全問題。微服務(wù)是一種相對較新的軟件體系結(jié)構(gòu)，因此其研究在工業(yè)和學(xué)術(shù)領(lǐng)域都仍然有限。本文從容器、數(shù)據(jù)、權(quán)限和網(wǎng)絡(luò)4個方面描述了用于服務(wù)通信的微服務(wù)的安全問題和當(dāng)前解決方案。未來，可以考慮實施一個集成解決方案來保護(hù)基于云原生的微服務(wù)體系，使其在安全級別、應(yīng)用程序性能和用戶體驗之間實現(xiàn)恰當(dāng)平衡。

（原載于《保密科學(xué)技術(shù)》雜志2022年7月刊）