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

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

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

1 引言

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

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

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

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

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

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

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

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

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

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

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

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

針對(duì)以上提到的風(fēng)險(xiǎn)，相應(yīng)的防護(hù)也應(yīng)從以上3個(gè)方面去考慮，作者通過(guò)調(diào)研和實(shí)踐發(fā)現(xiàn)使用傳統(tǒng)的防護(hù)方法是可行的，但當(dāng)服務(wù)隨業(yè)務(wù)的增多而逐漸增多時(shí)，傳統(tǒng)的防護(hù)方法由于需要開(kāi)發(fā)人員進(jìn)行大量配置而變得非常復(fù)雜。例如，用戶(hù)的應(yīng)用部署在K8s上，該應(yīng)用包含上百個(gè)服務(wù)，做訪問(wèn)控制時(shí)可以依托K8s的基于角色的權(quán)限訪問(wèn)控制（Role-Based Access Control，RBAC）機(jī)制對(duì)目的服務(wù)進(jìn)行授權(quán)，進(jìn)而就需要依賴(lài)K8s的API以完成配置。每次配置都會(huì)耗費(fèi)一定時(shí)間，因此需要大量服務(wù)授權(quán)時(shí)，開(kāi)發(fā)者往往感到力不從心，為解決諸如以上服務(wù)治理帶來(lái)的難題，可以使用微服務(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)訪問(wèn)前首先需要通過(guò)系統(tǒng)的認(rèn)證，因而確保認(rèn)證服務(wù)的有效性非常重要，尤其在微服務(wù)應(yīng)用架構(gòu)下，服務(wù)的不斷增多將會(huì)導(dǎo)致其認(rèn)證過(guò)程變得更為復(fù)雜。微服務(wù)架構(gòu)下，服務(wù)可以采用JSON Web令牌（JSON Web Token，JWT）或基于Istio的認(rèn)證方式，下面作者將分別進(jìn)行說(shuō)明。

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1.2.1對(duì)等認(rèn)證

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

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

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

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

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

2.1.2.2請(qǐng)求級(jí)認(rèn)證

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

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

Istio的JWT認(rèn)證主要依賴(lài)于JSON Web密鑰組（JSON Web Key Set，JWKS）。JWKS是一組密鑰集合，其中包含用于驗(yàn)證JWT的公鑰。在實(shí)際應(yīng)用場(chǎng)景中，運(yùn)維人員通過(guò)為服務(wù)部署JWT認(rèn)證策略實(shí)現(xiàn)請(qǐng)求級(jí)認(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獲取的地址，用于驗(yàn)證JWT的簽名，jwksUri可以為遠(yuǎn)程服務(wù)器地址，也可以為本地地址，其通常以域名或URL形式展現(xiàn)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通過(guò)以上介紹，我們可以看出采用微服務(wù)治理框架的防護(hù)方式可在一定程度上有效規(guī)避云原生應(yīng)用的新風(fēng)險(xiǎn)，但其防護(hù)點(diǎn)主要針對(duì)微服務(wù)架構(gòu)下應(yīng)用的東西向流量，針對(duì)南北向的流量防護(hù)稍顯脆弱。由于微服務(wù)架構(gòu)下的應(yīng)用防護(hù)應(yīng)當(dāng)是全流量防護(hù)，因而針對(duì)南北向所存在的問(wèn)題，我們可以考慮將微服務(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ù)

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

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

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

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

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

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

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

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

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

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

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

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

3.1.1 函數(shù)隔離

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

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

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

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

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

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

3.1.2 底層資源隔離

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

3.2 無(wú)服務(wù)計(jì)算平臺(tái)安全防護(hù)

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

3.2.1 使用云廠商提供的存儲(chǔ)最佳實(shí)踐

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

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

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

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

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

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

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

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

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

通過(guò)上述選項(xiàng)的合理配置可以在一定程度上緩解DoW攻擊。

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

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

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

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

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

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

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

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

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

（3）評(píng)估Serverless數(shù)據(jù)的價(jià)值；

（4）評(píng)估可訪問(wèn)數(shù)據(jù)API的安全。

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

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

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

4 結(jié)語(yǔ)

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

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