云原生應用安全防護思考

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

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

1 引言

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

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

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

（1）數(shù)據(jù)泄露的風險

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

應用漏洞：通過資產(chǎn)漏洞對應用數(shù)據(jù)進行竊取。

密鑰不規(guī)范管理：通過不規(guī)范的密鑰管理對應用數(shù)據(jù)進行竊取。

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

（2）未授權訪問的風險

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

（3）被拒絕服務的風險

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

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

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

2.1 認證服務

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

2.1.1 基于JWT的認證

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

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

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

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

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

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

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

2.1.2 基于Istio的認證

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

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

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

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

2.1.2.1對等認證

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

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

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

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

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

2.1.2.2請求級認證

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

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

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

issuer:https://example.com

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

triggerRules:

-excludedPaths:

-exact:

/status/version

includedPaths:

- prefix: /status/

其中：

issuer：代表發(fā)布JWT的發(fā)行者。

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

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

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

2.2 授權服務

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

2.2.1 基于角色的授權服務

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

如果用戶選擇在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帶來了更多的優(yōu)勢：一方面，該CRD將RBAC的配置變得更為簡化，從而大幅改善了用戶體驗；另一方面，該CRD支持更多的用例，例如對Ingress/Egress的支持，且不會增加復雜性。

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

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

管理員（Administrator）使用yaml文件指定Istio授權策略并將其部署至Istiod核心組件中，Istiod通過K8s的API服務端組件（API Server）監(jiān)測授權策略變更，若有更改，則獲取新的策略，Istiod將授權策略下發(fā)至服務的邊車（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, 并設置授權規(guī)則為當訪問源為“cluster.local/ns/default/sa/sleep”的服務，且請求頭中包含v1或v2的version字段時，才允許訪問。默認情況下，任何與策略不匹配的請求都將被拒絕。

2.3 數(shù)據(jù)安全

在微服務應用架構下，服務間通信不僅使用HTTP協(xié)議，還會使用gRPC協(xié)議等，數(shù)據(jù)安全防護尤為必要�？梢酝ㄟ^安全編碼、使用密鑰管理系統(tǒng)和安全協(xié)議的方式防止數(shù)據(jù)泄露，在微服務應用架構中，可以考慮使用K8s原生的安全機制或微服務治理框架的安全機制進行防護。

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

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

2.4 其他防護機制

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

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

2.4.1 Istio和API網(wǎng)關協(xié)同的全面防護

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

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

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

2.4.2 Istio與WAF結合的深度防護

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

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

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

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

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

3 無服務計算安全防護

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

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

3.1.1 函數(shù)隔離

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

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

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

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

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

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

3.1.2 底層資源隔離

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

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

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

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

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

3.2.2 使用云廠商的監(jiān)控資源

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

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

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

（1）函數(shù)執(zhí)行內(nèi)存分配；

（2）函數(shù)執(zhí)行所需臨時的磁盤容量；

（3）函數(shù)執(zhí)行的進程數(shù)和線程數(shù)；

（4）函數(shù)執(zhí)行時常；

（5）函數(shù)接收載荷大��；

（6）函數(shù)并發(fā)執(zhí)行數(shù)。

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

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

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

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

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

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

3.4 其他防護機制

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

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

（2）確認應用的數(shù)據(jù)類型及數(shù)據(jù)的敏感性；

（3）評估Serverless數(shù)據(jù)的價值；

（4）評估可訪問數(shù)據(jù)API的安全。

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

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

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

4 結語

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

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