云原生應(yīng)用安全防護(hù)思考

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

【關(guān)鍵詞】 云原生應(yīng)用 API安全 無服務(wù)器運算安全微服務(wù)應(yīng)用安全

1 引言

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

2 微服務(wù)架構(gòu)下的應(yīng)用安全

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

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

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

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

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

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

（2）未授權(quán)訪問的風(fēng)險

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

（3）被拒絕服務(wù)的風(fēng)險

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

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

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

2.1 認(rèn)證服務(wù)

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

2.1.1 基于JWT的認(rèn)證

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

（1）客戶端請求某服務(wù)，服務(wù)端對用戶進(jìn)行登錄認(rèn)證；

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

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

（4）服務(wù)端對令牌進(jìn)行解密，判斷是否有效，若有效，則認(rèn)證通過，否則返回失敗信息。

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

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

2.1.2 基于Istio的認(rèn)證

Istio的安全架構(gòu)，如圖3所示。

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

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

下文介紹Istio的2種主要認(rèn)證類型。

2.1.2.1對等認(rèn)證

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

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

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

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

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

2.1.2.2請求級認(rèn)證

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

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

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

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可以為遠(yuǎn)程服務(wù)器地址，也可以為本地地址，其通常以域名或URL形式展現(xiàn)。

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

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

2.2 授權(quán)服務(wù)

授權(quán)服務(wù)是針對未授權(quán)訪問風(fēng)險最直接的防護(hù)手段，微服務(wù)應(yīng)用架構(gòu)下，由于服務(wù)的權(quán)限映射相對復(fù)雜，因而會導(dǎo)致授權(quán)服務(wù)變得更難。授權(quán)服務(wù)可以通過基于角色的授權(quán)以及基于Istio的授權(quán)實現(xiàn)。

2.2.1 基于角色的授權(quán)服務(wù)

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

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

2.2.2 基于Istio的授權(quán)服務(wù)

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

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

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

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

以下是一個簡單的Istio授權(quán)策略：

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命名空間下，且滿足標(biāo)簽為app: httpbin和version: v1的目標(biāo)Pod, 并設(shè)置授權(quán)規(guī)則為當(dāng)訪問源為“cluster.local/ns/default/sa/sleep”的服務(wù)，且請求頭中包含v1或v2的version字段時，才允許訪問。默認(rèn)情況下，任何與策略不匹配的請求都將被拒絕。

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

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

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

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

2.4 其他防護(hù)機(jī)制

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

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

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

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

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

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

2.4.2 Istio與WAF結(jié)合的深度防護(hù)

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

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

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

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

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

3 無服務(wù)計算安全防護(hù)

3.1 無服務(wù)計算應(yīng)用安全防護(hù)

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

3.1.1 函數(shù)隔離

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

為了更好地將函數(shù)進(jìn)行隔離，作者認(rèn)為應(yīng)當(dāng)從以下4個方面進(jìn)行考慮。

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

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

（3）開發(fā)標(biāo)準(zhǔn)化的通用安全庫，并強(qiáng)制每個函數(shù)使用。

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

3.1.2 底層資源隔離

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

3.2 無服務(wù)計算平臺安全防護(hù)

針對無服務(wù)計算平臺安全防護(hù)，可以考慮通過以下幾種方式進(jìn)行相應(yīng)緩解。

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

為了盡量避免用戶在使用云廠商提供的Serverless平臺時因不安全的錯誤配置造成數(shù)據(jù)泄露的風(fēng)險，主流云廠商均提供了相應(yīng)的存儲最佳實踐供各位開發(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配備了相應(yīng)的監(jiān)控資源，例如Azure Monitor、AWS CloudWatch、AWS CloudTrail等，使用云這些監(jiān)控資源可以識別和報告異常行為，例如未授權(quán)訪問、過度執(zhí)行的函數(shù)、過長的執(zhí)行時間等。

3.2.3 使用云廠商的賬單告警機(jī)制

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

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

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

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

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

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

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

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

3.3 無計算服務(wù)被濫用的防護(hù)措施

針對Serverless被濫用的風(fēng)險，我們可以采取以下方式進(jìn)行防護(hù)。

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

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

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

3.4 其他防護(hù)機(jī)制

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

（1）確認(rèn)應(yīng)用中函數(shù)間的邏輯關(guān)系；

（2）確認(rèn)應(yīng)用的數(shù)據(jù)類型及數(shù)據(jù)的敏感性；

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

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

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

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

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

4 結(jié)語

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

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