云原生架構下的微服務安全研究

【摘 要】 本文主要針對云原生架構下的微服務安全現狀進行了研究，提出了基于微服務的安全風險評估模型，給出了云原生架構下的微服務安全解決方案。

【關鍵詞】 云計算 微服務 網絡安全

1 引言

在為企業提供邊緣計算、節點安全、自動化以及智慧數據服務方面，基于云計算構建的網絡架構模型存在諸多優點，如能夠實現規模經濟效應，有效整合、配置資源，具有高可用性等。云計算集成了各種計算技術，為終端用戶提供微服務（Micro Services）。然而，在云計算與微服務發展的同時，也存在著一些安全隱患。

2 云原生架構下的微服務安全現狀及面臨的問題

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

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

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

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

2.1 云原生架構下的微服務容器安全

首先，容器的存在為微服務提供了一個完美的環境。使用容器包裝或集裝箱化分布式微服務的優勢明顯。例如，容器消除了對底層基礎設施服務的依賴，從而減少了對接不同平臺的復雜性。因此，微服務架構可以利用Docker容器來測試和跨可用的計算機網絡與其他計算設備在單獨的容器中部署單個服務。此外，容器可以提供標準化建設和持續整合與交付服務。簡而言之，容器的存在、發展與微服務聯系緊密，它們結合在一起，形成一個生態系統。當Docker容器出現安全問題時，可能會引起連鎖反應。

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

2.2 云原生架構下的微服務數據安全

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

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

2.3 云原生架構下的微服務權限安全

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

2.4 云原生架構下的微服務網絡安全

在網絡安全領域，傳統的典型威脅主要包括地址解析協議（ARP）欺騙、中間人攻擊（MITM）、DoS攻擊等。ARP欺騙涉及構建偽造目標物理地址的ARP回復，通過發送偽造的ARP回復，主機無法與目標主機正確通信。

2.5 云原生架構下的其他微服務安全風險

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

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

除SDN安全問題外，大量微服務帶來的網絡復雜性大大增加了監控整個應用程序安全的難度；單一微服務的中止也可能會導致整個應用程序的崩潰。

3 云原生架構下的微服務安全風險評估模型

3.1 STRIDE威脅模型

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

3.2 Prasad Saripalli風險評估模型

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

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

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

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

4 云原生架構下的微服務安全架構及安全防御措施

4.1 云原生架構下的微服務安全架構

基于上述風險評估架構，本文提出了相應的基于云原生架構的微服務安全整體框架。圖4為國內學者總結的云原生架構下的微服務安全架構。在此基礎上，可以追加后臺日志系統與本文中提到的風險評估告警體系。

   

4.2 基于云原生架構的微服務安全防御措施

（1）物理措施

微服務安全防御機制首先需要對物理設備進行有效管理，包括服務器、路由器、防火墻、交換機等網絡關鍵設備的定期檢查、更新，并且需要安裝不間斷電源（UPS）。

（2）數據加密

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

首先，需要確保管理系統能夠驗證與操作有關的參與者（或服務）相關的數據源，并且能夠使參與者（或服務）對其在數據中的行為負責。另外，數據源的復現是應急響應的關鍵流程，因此數據的熱備份至關重要。

其次，創建用于數據流認證的公私鑰加密系統。并且基于密碼學對源數據進行加密處理（如RSA或DES算法），結合密鑰對保證云端數據傳輸的可靠性與完整性。另外，備份數據的加密存儲能夠有效預防數據的篡改與外泄。

（3）訪問控制

針對微服務方面的權限訪問保障，請求訪問資源只能被分配最低限度的必要權利。將權限授予超出必要的范圍可能導致用戶以不正當的方式獲取或更改信息。因此，權限訪問控制可以限制攻擊者破壞系統。

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

  

   

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

（4）網絡隔離與容器隔離

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

5 結語

盡管云原生架構下的微服務體系有許多優點，但仍存在許多實際和潛在的安全問題。微服務是一種相對較新的軟件體系結構，因此其研究在工業和學術領域都仍然有限。本文從容器、數據、權限和網絡4個方面描述了用于服務通信的微服務的安全問題和當前解決方案。未來，可以考慮實施一個集成解決方案來保護基于云原生的微服務體系，使其在安全級別、應用程序性能和用戶體驗之間實現恰當平衡。

（原載于《保密科學技術》雜志2022年7月刊）