1. <progress id="vs7bj"></progress>
      1. <th id="vs7bj"></th>

        <dd id="vs7bj"><center id="vs7bj"></center></dd><dd id="vs7bj"><track id="vs7bj"></track></dd>

        <rp id="vs7bj"><ruby id="vs7bj"></ruby></rp>
        國家保密局網(wǎng)站>>保密科技

        云原生應用安全防護思考

        2023年06月07日    來(lái)源:國家保密科技測評中心【字體: 打印

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

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

        1 引言

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

        2 微服務(wù)架構下的應用安全

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

        (1)數據泄露的風(fēng)險

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

        應用漏洞:通過(guò)資產(chǎn)漏洞對應用數據進(jìn)行竊取。

        密鑰不規范管理:通過(guò)不規范的密鑰管理對應用數據進(jìn)行竊取。

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

        (2)未授權訪(fǎng)問(wèn)的風(fēng)險

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

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

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

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

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

        2.1 認證服務(wù)

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

        2.1.1 基于JWT的認證

        微服務(wù)架構下,每個(gè)服務(wù)是無(wú)狀態(tài)的,傳統的服務(wù)狀態(tài)認證方式(Session)由于服務(wù)端需要存儲客戶(hù)端的登錄狀態(tài),因此在微服務(wù)中不再適用。理想的實(shí)現方式應為無(wú)狀態(tài)登錄,流程通常如下所示:

        (1)客戶(hù)端請求某服務(wù),服務(wù)端對用戶(hù)進(jìn)行登錄認證;

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

        (3)在步驟(2)之后,客戶(hù)端每次請求都需攜帶認證的令牌;

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

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

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

        2.1.2 基于Istio的認證

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

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

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

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

        2.1.2.1對等認證

        對等認證(Peer authentication)主要用于微服務(wù)應用架構中服務(wù)到服務(wù)的認證,從而可驗證所連接的客戶(hù)端。針對此類(lèi)型的認證,Istio提供了雙向TLS解決方案,該解決方案提供以下功能:

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

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

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

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

        2.1.2.2請求級認證

        請求級認證(Request authen-tication)是Istio的一種認證類(lèi)型,主要用于對終端用戶(hù)的認證,與傳輸認證的主要區別為,請求級認證主要用于驗證用戶(hù)請求服務(wù)時(shí)攜帶的憑據,而非服務(wù)到服務(wù)的認證。

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

        Istio的JWT認證主要依賴(lài)于JSON Web密鑰組(JSON Web Key Set,JWKS)。JWKS是一組密鑰集合,其中包含用于驗證JWT的公鑰。在實(shí)際應用場(chǎng)景中,運維人員通過(guò)為服務(wù)部署JWT認證策略實(shí)現請求級認證,為方便理解,下面展示了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可以為遠程服務(wù)器地址,也可以為本地地址,其通常以域名或URL形式展現。

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

        當JWT認證策略部署完成后,外部對某服務(wù)有新的請求時(shí),請求級認證會(huì )根據策略?xún)热蒡炞C請求攜帶的令牌(Token),若與策略?xún)热萜ヅ,則返回認證失敗,反之認證成功。

        2.2 授權服務(wù)

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

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

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

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

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

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

        此外,Istio的授權模式也是基于其提供的授權策略實(shí)現的。

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

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

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

        2.3 數據安全

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

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

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

        2.4 其他防護機制

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

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

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

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

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

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

        2.4.2 Istio與WAF結合的深度防護

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

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

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

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

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

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

        3.1 無(wú)服務(wù)計算應用安全防護

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

        3.1.1 函數隔離

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

        為了更好地將函數進(jìn)行隔離,作者認為應當從以下4個(gè)方面進(jìn)行考慮。

        (1)不要過(guò)度依賴(lài)函數的調用序列,因為隨著(zhù)時(shí)間推移調用序列可能會(huì )改變。如果序列發(fā)生了變化,要進(jìn)行相應的安全審查。

        (2)每個(gè)函數都應當將任何事件輸入視為不受信任的源,并同時(shí)對輸入進(jìn)行安全校驗。

        (3)開(kāi)發(fā)標準化的通用安全庫,并強制每個(gè)函數使用。

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

        3.1.2 底層資源隔離

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

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

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

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

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

        3.2.2 使用云廠(chǎng)商的監控資源

        現今各大云廠(chǎng)商均為Serverless配備了相應的監控資源,例如Azure Monitor、AWS CloudWatch、AWS CloudTrail等,使用云這些監控資源可以識別和報告異常行為,例如未授權訪(fǎng)問(wèn)、過(guò)度執行的函數、過(guò)長(cháng)的執行時(shí)間等。

        3.2.3 使用云廠(chǎng)商的賬單告警機制

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

        (1)函數執行內存分配;

        (2)函數執行所需臨時(shí)的磁盤(pán)容量;

        (3)函數執行的進(jìn)程數和線(xiàn)程數;

        (4)函數執行時(shí)常;

        (5)函數接收載荷大;

        (6)函數并發(fā)執行數。

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

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

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

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

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

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

        3.4 其他防護機制

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

        (1)確認應用中函數間的邏輯關(guān)系;

        (2)確認應用的數據類(lèi)型及數據的敏感性;

        (3)評估Serverless數據的價(jià)值;

        (4)評估可訪(fǎng)問(wèn)數據API的安全。

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

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

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

        4 結語(yǔ)

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

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


        中文字幕乱码一区久久麻豆樱花,中文字幕亚洲乱码熟女一区二区,中文成人无码精品久久久不卡_电影