云原生應用安全防護思考

【摘 要】 云原生場景下服務架構的變化，也會引發相關的安全機制出現變化。本文從微服務架構下的應用安全、無服務器計算安全提出了云原生安全防護見解及思考，以提升業界對云原生應用防護的認識。

【關鍵詞】 云原生應用 API安全 無服務器運算安全微服務應用安全

1 引言

2022年4月，云安全聯盟大中華區（CSA GCR）發布了《云原生安全技術規范》，針對云原生環境下面臨的風險提出了體系化的安全能力要求。如圖1所示，云原生應用安全不僅包括容器基礎設施和容器編排平臺安全，還包括上層的云原生應用安全。云原生場景下服務被拆分成眾多微服務，有些通過服務網格形成了點對點（Ad-hoc）的連接模式，相關的安全機制也出現一些變化，而無服務計算（Serveless）作為云原生場景下的一種創新的計算模式，對應的安全機制與傳統應用、微服務應用也有所不同，因此對應的防護方式相對傳統應用需要做思路上的轉變。

2 微服務架構下的應用安全

應用的微服務化帶來的新風險主要包含數據泄露、未授權訪問、被拒絕服務3種。

（1）數據泄露的風險

云原生環境中，雖然造成應用數據泄露風險的原因有很多，但都離不開以下幾個因素。

應用漏洞：通過資產漏洞對應用數據進行竊取。

密鑰不規范管理：通過不規范的密鑰管理對應用數據進行竊取。

應用間通信未經加密：通過應用間通信未經加密的缺陷對傳輸中數據進行竊取，進而升級到對應用數據的竊取。

（2）未授權訪問的風險

在云原生環境中，應用未授權訪問的風險多是由于應用自身漏洞或訪問權限錯誤配置而導致。

（3）被拒絕服務的風險

被拒絕服務是應用程序面臨的常見風險。造成拒絕服務的主要原因包括兩方面：一方面是由于應用自身漏洞所致，如ReDoS漏洞、Nginx拒絕服務漏洞等；另一方面是由于訪問需求與資源能力不匹配所致，例如某電商平臺的購買API由于處理請求能力有限，因而無法面對突如其來的大量購買請求，導致平臺資源（CPU、內存、網絡）的耗盡甚至崩潰，這種場景往往不帶有惡意企圖。而帶有惡意企圖的則主要以ACK、SYNC泛洪攻擊及挑戰黑洞（Challenge Collapsar ，CC）等攻擊為主，其最終目的也是應用資源的耗盡。

針對以上提到的風險，相應的防護也應從以上3個方面去考慮，作者通過調研和實踐發現使用傳統的防護方法是可行的，但當服務隨業務的增多而逐漸增多時，傳統的防護方法由于需要開發人員進行大量配置而變得非常復雜。例如，用戶的應用部署在K8s上，該應用包含上百個服務，做訪問控制時可以依托K8s的基于角色的權限訪問控制（Role-Based Access Control，RBAC）機制對目的服務進行授權，進而就需要依賴K8s的API以完成配置。每次配置都會耗費一定時間，因此需要大量服務授權時，開發者往往感到力不從心，為解決諸如以上服務治理帶來的難題，可以使用微服務治理框架進行相應防護。

綜上所述，面向微服務架構下的應用安全，可以采用傳統的防護方式或微服務治理框架進行防護，具體的防護措施包含認證服務、授權服務、數據安全防護等。

2.1 認證服務

由于攻擊者在進行未授權訪問前首先需要通過系統的認證，因而確保認證服務的有效性非常重要，尤其在微服務應用架構下，服務的不斷增多將會導致其認證過程變得更為復雜。微服務架構下，服務可以采用JSON Web令牌（JSON Web Token，JWT）或基于Istio的認證方式，下面作者將分別進行說明。

2.1.1 基于JWT的認證

微服務架構下，每個服務是無狀態的，傳統的服務狀態認證方式（Session）由于服務端需要存儲客戶端的登錄狀態，因此在微服務中不再適用。理想的實現方式應為無狀態登錄，流程通常如下所示：

（1）客戶端請求某服務，服務端對用戶進行登錄認證；

（2）認證通過，服務端將用戶登錄信息進行加密并形成令牌，最后返回至客戶端，作為登錄憑證；

（3）在步驟（2）之后，客戶端每次請求都需攜帶認證的令牌;

（4）服務端對令牌進行解密，判斷是否有效，若有效，則認證通過，否則返回失敗信息。

為了滿足無狀態登錄，我們可通過JWT實現。JWT是JSON輕量級認證和授權規范，也就是上述流程中提到的令牌，主要用于分布式場景，其使用流程如圖2所示。

從圖2我們可以看出，JWT交互流程與上述提到的理想流程基本相似，需要注意的是，JWT令牌中會包含用戶敏感信息，為防止被繞過的可能，JWT令牌采用了簽名機制。此外，傳輸時需要使用加密協議。

2.1.2 基于Istio的認證

Istio的安全架構，如圖3所示。

Istio包括認證和授權兩部分，安全機制涉及諸多組件，控制平面由核心組件Istiod提供，其中包含密鑰及證書頒發機構（CA）、認證授權策略、網絡配置等；數據平面則由透明代理（Envoy）、邊緣代理（Ingress和Egress）組件構成。

借助控制平面Istiod內置的CA模塊，Istio可實現為服務網格中的服務提供認證機制，該認證機制工作流程包含提供服務簽名證書，并將證書分發至數據平面各個服務的Envoy代理中。當數據平面服務間建立通信時，服務旁的Envoy代理會攔截請求并采用簽名證書和另一端服務的Envoy代理進行雙向（Mutual Transport Layer Security，TLS）認證，從而建立安全傳輸通道，保障數據安全。

下文介紹Istio的2種主要認證類型。

2.1.2.1對等認證

對等認證（Peer authentication）主要用于微服務應用架構中服務到服務的認證，從而可驗證所連接的客戶端。針對此類型的認證，Istio提供了雙向TLS解決方案，該解決方案提供以下功能：

（1）確保服務到服務之間的通信安全；

（2）提供密鑰管理系統，從而自動進行密鑰及證書的生成、分發和輪換；

（3）為每個服務提供一個代表其角色的身份，從而可實現跨集群的互操作性。

具體我們可以通過使用傳輸認證策略為Istio中的服務指定認證要求，例如，命名空間級別TLS認證策略可以指定某命名空間下所有Pod（K8s的最小單位，里面包含一組容器）間的訪問均使用TLS加密，Pod級別TLS認證策略可以指定某具體Pod被訪問時需要進行TLS加密等。

2.1.2.2請求級認證

請求級認證（Request authen-tication）是Istio的一種認證類型，主要用于對終端用戶的認證，與傳輸認證的主要區別為，請求級認證主要用于驗證用戶請求服務時攜帶的憑據，而非服務到服務的認證。

請求級認證主要通過JWT機制實現，實現原理與前面“基于JWT的認證”小節中提到的內容類似，區別為Istio在其基礎上進行了一層封裝，使用戶可以以yaml的方式進行策略配置，用戶體驗更為友好。

Istio的JWT認證主要依賴于JSON Web密鑰組（JSON Web Key Set，JWKS）。JWKS是一組密鑰集合，其中包含用于驗證JWT的公鑰。在實際應用場景中，運維人員通過為服務部署JWT認證策略實現請求級認證，為方便理解，下面展示了JWT認證策略的核心部分配置：

issuer:https://example.com

jwksUri:https://example.com/.well-known/jwks.json

triggerRules:

-excludedPaths:

-exact:

/status/version

includedPaths:

- prefix: /status/

其中：

issuer：代表發布JWT的發行者。

jwksUri：代表JWKS獲取的地址，用于驗證JWT的簽名，jwksUri可以為遠程服務器地址，也可以為本地地址，其通常以域名或URL形式展現。

triggerRules（重要）：為使用JWT驗證請求的規則觸發列表，如果滿足匹配規則就進行JWT驗證。此參數使得服務間的認證變得彈性化，用戶可以按需配置下發規則。上述策略中triggerRules的含義為對于任何帶有“/status/”前綴的請求路徑，除了/status/version，都需要JWT認證。

當JWT認證策略部署完成后，外部對某服務有新的請求時，請求級認證會根據策略內容驗證請求攜帶的令牌（Token），若與策略內容匹配，則返回認證失敗，反之認證成功。

2.2 授權服務

授權服務是針對未授權訪問風險最直接的防護手段，微服務應用架構下，由于服務的權限映射相對復雜，因而會導致授權服務變得更難。授權服務可以通過基于角色的授權以及基于Istio的授權實現。

2.2.1 基于角色的授權服務

RBAC通過角色關聯用戶，角色關聯權限的方式間接賦予用戶權限。在微服務環境中作為訪問控制被廣泛使用，RBAC可以增加微服務的擴展性。例如，微服務場景中，每個服務作為一個實體，若要分配服務相同的權限，使用RBAC時只需設定一種角色，并賦予相應權限，再將此角色與指定的服務實體進行綁定即可。若要分配服務不同的權限，只需為不同的服務實體分配不同的角色，而無須對服務具體的權限進行修改。這種方式不僅可以大幅提升權限調整的效率，還降低了漏調權限的概率。

如果用戶選擇在K8s中部署微服務應用，則可以直接使用K8s原生的RBAC策略。

2.2.2 基于Istio的授權服務

Istio還提供授權機制，其主要用于對服務進行授權。在Istio 1.4版本之前，授權機制依賴于K8s的RBAC策略，相比K8s的原生RBAC策略，Istio對其進行了進一步的封裝，可讓用戶直接通過Istio的聲明式API對具體的服務進行授權。不過為了更好的用戶體驗，Istio在其1.6版本中引入了授權自定義策略（AuthorizationPolicy Custom Resource Definition，CRD），相比1.4版本，CRD帶來了更多的優勢：一方面，該CRD將RBAC的配置變得更為簡化，從而大幅改善了用戶體驗；另一方面，該CRD支持更多的用例，例如對Ingress/Egress的支持，且不會增加復雜性。

此外，Istio的授權模式也是基于其提供的授權策略實現的。

如圖4所示，Istio授權流程可以歸納總結為以下內容：

管理員（Administrator）使用yaml文件指定Istio授權策略并將其部署至Istiod核心組件中，Istiod通過K8s的API服務端組件（API Server）監測授權策略變更，若有更改，則獲取新的策略，Istiod將授權策略下發至服務的邊車（Sidecar）代理，每個Sidecar代理均包含一個授權引擎，在引擎運行時對請求進行授權。

以下是一個簡單的Istio授權策略：

apiVersion: security.istio.io/v1beta1

kind: AuthorizationPolicy

metadata:

name: httpbin

namespace: foo

spec:

selector:

matchLabels:

app: httpbin

version: v1

rules:

- from:

- source:

principals: ["cluster.local/ns/default/sa/sleep"]

to:

- operation:

methods: ["GET"]

when:

- key: request.headers[version]

values: ["v1", "v2"]

可以看出，以上策略適用于foo命名空間下，且滿足標簽為app: httpbin和version: v1的目標Pod, 并設置授權規則為當訪問源為“cluster.local/ns/default/sa/sleep”的服務，且請求頭中包含v1或v2的version字段時，才允許訪問。默認情況下，任何與策略不匹配的請求都將被拒絕。

2.3 數據安全

在微服務應用架構下，服務間通信不僅使用HTTP協議，還會使用gRPC協議等，數據安全防護尤為必要。可以通過安全編碼、使用密鑰管理系統和安全協議的方式防止數據泄露，在微服務應用架構中，可以考慮使用K8s原生的安全機制或微服務治理框架的安全機制進行防護。

針對K8s原生的安全機制，例如密鑰機制（Secret），我們可以使用其進行密鑰存儲，從而規避了敏感信息硬編碼帶來的數據泄露風險。

針對微服務治理框架的安全機制，如Istio支持服務間的TLS雙向加密、密鑰管理及服務間的授權，可以有效規避由中間人攻擊或未授權訪問攻擊帶來的數據泄露風險。

2.4 其他防護機制

通過以上介紹，我們可以看出采用微服務治理框架的防護方式可在一定程度上有效規避云原生應用的新風險，但其防護點主要針對微服務架構下應用的東西向流量，針對南北向的流量防護稍顯脆弱。由于微服務架構下的應用防護應當是全流量防護，因而針對南北向所存在的問題，我們可以考慮將微服務治理框架與API網關和WAF防火墻相結合，從而提升南北向的防護能力。

本節將以微服務治理框架Istio為例，介紹Istio和API網關協同的全面防護以及Istio與WAF結合的深度防護。

2.4.1 Istio和API網關協同的全面防護

針對應用的南北流量而言，Istio采取的解決方案為使用邊緣代理Ingress與Egress分別接管用戶或外界服務到服務網格內部的入/出站流量，Ingress與Egress實則為Istio部署的兩個Pod，Pod內部為一個透明代理（Envoy），借助Envoy代理的安全過濾（Filter）機制，在一定程度上可對惡意Web攻擊進行相應防護。但現有的Envoy安全Filter種類相對較少，面對復雜變化場景下的Web攻擊仍然無法應對，可行的解決方案為在服務網格之外部署一層云原生API網關，具體如圖5所示。

安全功能上，云原生API網關可提供全方位的安全防護，例如訪問控制、認證授權、證書管理、機器流量檢測（Bot）、數據丟失防護、黑白名單限制等，在這些有效防護基礎之上，應用的南北向得到了控制。

此外，該解決方案的好處還在于應用內部的東西流量不需通過外部網關層，這樣可以從邊緣到端點進行一站式防護。

2.4.2 Istio與WAF結合的深度防護

WAF作為抵御常見Web攻擊的主流安全產品，可以有效對Web流量進行深度防護，并且隨著云原生化概念的普及，國內外安全廠商的容器化WAF產品也在迅速落地，未來容器化WAF與Istio的結合將會在很大程度上提升微服務安全。

根據近期市場調研，已有幾家公司有了各自的容器化WAF解決方案。以其中一款方案為例，其設計如圖6所示，該方案主要運用了Envoy的過濾器機制（Filter），通過外部授權HTTP過濾器（External Authorization HTTP Filter）可以將流經業務容器的東西/南北向流量引流至WAF容器，從而阻斷惡意請求，保護微服務的安全。

此方案的優勢是對業務入侵較小，實現較為容易，且容器化WAF規模不會隨用戶業務更改而更改。但同時也有一些弊端，比如需要單獨部署容器化WAF、Envoy引流模塊的性能問題、引流方式對WAF處理的延遲等。

另一種解決方案是K8s WAF方案。該方案基于Istio實現，其中WAF被拆分為代理程序（Agent）和后端服務兩部分，Agent程序作為Sidecar容器置于Pod的Envoy容器和業務容器間，該Sidecar的主要作用為啟動一個反向代理，以便將外部請求流量代理至Pod外部的WAF后端服務中，如圖7所示。該套方案的好處是無須關心外部請求如何路由至Pod，與Istio結合的理念更接近云原生化，實現了以單個服務為粒度的防護。但同時存在不足，例如，流量到達業務容器前經歷了兩跳，這在大規模并發場景下可能影響效率。

此外，由于Istio的數據平面為微服務應用安全防護提供了引擎，而數據平面默認采取Envoy作為Sidecar，因此Envoy自身的擴展性成為了安全廠商較為關心的問題。近些年Envoy也在不斷提升著其適配性，例如Envoy提供Lua過濾器和Wasm過濾器，以便安全廠商將WAF的能力融入Envoy，從而對微服務應用進行防護。

3 無服務計算安全防護

3.1 無服務計算應用安全防護

針對Serverless應用安全訪問控制，除了使用基于角色的訪問控制，針對Serverless云計算模式帶來的變化，還需要進行更深層次的防護，作者認為函數隔離及底層資源隔離是較為合適的防護方法。

3.1.1 函數隔離

函數間進行隔離可有效降低安全風險。一個函數即服務（Function as a Service，FaaS）應用通常由許多函數以既定的序列和邏輯組成，每個函數可以獨立進行擴展、部署，但同時可能被攻破，如果安全團隊沒有對函數進行有效隔離，那么攻擊者也可同時訪問應用中的其他函數。再如隨著應用設計的不斷變化，這些函數更改了執行序列，從而使攻擊者有機可乘并發起業務邏輯攻擊，這些是FaaS產生的碎片化問題。正確的做法應當是將每個函數作為邊界，使得安全控制粒度細化至函數級別，這對于創建能夠長期保持安全的FaaS應用是非常必要的。

為了更好地將函數進行隔離，作者認為應當從以下4個方面進行考慮。

（1）不要過度依賴函數的調用序列，因為隨著時間推移調用序列可能會改變。如果序列發生了變化，要進行相應的安全審查。

（2）每個函數都應當將任何事件輸入視為不受信任的源，并同時對輸入進行安全校驗。

（3）開發標準化的通用安全庫，并強制每個函數使用。

（4）使用FaaS平臺提供的函數隔離機制，例如AWS Lambda采用亞馬遜彈性計算云（Elastic Compute Cloud，EC2）模型和安全容器Firecracker模型機制進行隔離。

3.1.2 底層資源隔離

僅僅對函數層面進行訪問控制是不夠的，例如攻擊者仍可以利用函數運行時環境的脆弱性以獲取服務端的運行權限，從而進行濫用，為了預防上述場景的發生，我們應當從底層進行資源隔離，例如可通過開源安全容器Kata Container從上至下進行防護，再如可通過K8s的網絡策略（Network Policy）實現由左至右的網絡層面隔離。

3.2 無服務計算平臺安全防護

針對無服務計算平臺安全防護，可以考慮通過以下幾種方式進行相應緩解。

3.2.1 使用云廠商提供的存儲最佳實踐

為了盡量避免用戶在使用云廠商提供的Serverless平臺時因不安全的錯誤配置造成數據泄露的風險，主流云廠商均提供了相應的存儲最佳實踐供各位開發者參考，例如How to secure AWS S3 Resources、Azure Storage Security Guide、Best Practices for Google Cloud Storage等。

3.2.2 使用云廠商的監控資源

現今各大云廠商均為Serverless配備了相應的監控資源，例如Azure Monitor、AWS CloudWatch、AWS CloudTrail等，使用云這些監控資源可以識別和報告異常行為，例如未授權訪問、過度執行的函數、過長的執行時間等。

3.2.3 使用云廠商的賬單告警機制

針對拒絕錢包服務（A denial-of-wallet，DoW）攻擊，公有云廠商提供了賬單告警機制進行緩解，如AWS開發者可通過在Lambda控制臺為函數調用頻度和單次調用費用設定閾值進行告警；或提供資源限額的配置，主流的云廠商已提供了以下資源選項供開發者配置：

（1）函數執行內存分配；

（2）函數執行所需臨時的磁盤容量；

（3）函數執行的進程數和線程數；

（4）函數執行時常；

（5）函數接收載荷大小；

（6）函數并發執行數。

通過上述選項的合理配置可以在一定程度上緩解DoW攻擊。

3.3 無計算服務被濫用的防護措施

針對Serverless被濫用的風險，我們可以采取以下方式進行防護。

（1）通過入侵檢測系統（Intrusion Detection Systems，IDS）等安全設備監測木馬在本機的出口流量，諸如“/pixel”“/utm.gif”“ga.js”等URL的流量應進行重點監測。

（2）確認自己的資產中是否有云廠商提供的Serverless函數業務，如果沒有可以通過瀏覽器禁用相關云廠商的子域名。

（3）采取斷網措施，從根源上直接禁止所有網絡訪問。

3.4 其他防護機制

由于云廠商通常缺乏一套自動化機制對現有Serverless應用中包含的函數、數據及可用API進行分類、追蹤、評估等操作，因此開發者在不斷完善應用的同時，可能疏于對應用數據及API的管理，從而導致攻擊者利用敏感數據、不安全的API發起攻擊。為了避免這種情況，開發者需要在應用的設計階段對資產業務進行詳細梳理。其中包括但不限于以下4個部分：

（1）確認應用中函數間的邏輯關系；

（2）確認應用的數據類型及數據的敏感性；

（3）評估Serverless數據的價值；

（4）評估可訪問數據API的安全。

有了一個較為全面的應用全景圖，便可在一定程度上降低應用被攻擊的風險。

由于Serverless應用通常遵循微服務的設計模式，因此一套完整的工作流應由許多函數組成，而開發者可能部署了非常多的Serverless應用，在這些應用中，必定存在一些長時間不被調用的實例，為了避免被攻擊者利用，應當定期對Serverless應用進行檢測，清理非必要的實例，從而降低安全隱患。

開發者首先應當限制函數策略，給予其適當的訪問權限，刪除過于寬松的權限，這樣即便攻擊者拿到了訪問憑證也無法對所有資源進行訪問。

4 結語

由于應用架構的變化是帶來新風險的主要原因，鑒于此，本文作者針對具體的風險提出了防護方法。其中，使用微服務治理框架Istio可以在一定程度上緩解應用架構帶來的風險，此外，也介紹了Istio與API網關和WAF結合的業界方案，從而實現微服務應用的全流量防護。此外，作者較為系統地從Serverless應用及平臺兩方面對前述提到的Serverless風險進行了相應防護介紹。可以看出，與傳統安全防護不同的是Serverless模式帶來的是新型云原生下的應用安全場景。因而，我們需要適應云計算模式的不斷變化，并不斷總結新場景下的防護方法，才能最終將安全落實到底。

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