一、概述

企鵝今天想分享云原生應(yīng)用安全防護(hù)系列，本文筆者主要針對(duì)微服務(wù)架構(gòu)下的應(yīng)用安全、Serverless安全提出一些防護(hù)見(jiàn)解及思考。文章篇幅較長(zhǎng)，內(nèi)容上與之前筆者發(fā)表的若干文章有相互交叉對(duì)應(yīng)的部分，希望能為各位讀者帶來(lái)幫助

二、微服務(wù)架構(gòu)模式

1. 數(shù)字時(shí)代的微服務(wù)安全

這里CSA發(fā)布《微服務(wù)架構(gòu)模式》，給出了 CSA 的最佳實(shí)踐與總結(jié)，通過(guò) CSA 微服務(wù)安全參考架構(gòu)以及安全控制措施疊加的新思路，保證了微服務(wù)在架構(gòu)層面的安全性。

成功地開(kāi)發(fā)基于微服務(wù)架構(gòu)的應(yīng)用軟件，需要掌握一系列全新的架構(gòu)思想和實(shí)踐。[2]? 在這本獨(dú)特的書籍中，微服務(wù)架構(gòu)的先驅(qū)、Java 開(kāi)發(fā)者社區(qū)的意見(jiàn)領(lǐng)袖 Chris Richardson 收集、分類并解釋了 44 個(gè)架構(gòu)設(shè)計(jì)模式，這些模式用來(lái)解決諸如服務(wù)拆分、事務(wù)管理、查詢和跨服務(wù)通信等難題。

（1）數(shù)字化時(shí)代的網(wǎng)格管理

數(shù)字化轉(zhuǎn)型是全球的熱門話題，是組織應(yīng)用新興技術(shù)從根本上提高組織的業(yè)績(jī)及創(chuàng)新的新興方法。在云計(jì)算、大數(shù)據(jù)、物聯(lián)網(wǎng)(IoT)、人工智能、5G（6G），和移動(dòng)應(yīng)用等新興技術(shù)的應(yīng)用，加速了整個(gè)社會(huì)及組織形態(tài)的變化。這些新興技術(shù)已經(jīng)改變了傳統(tǒng)的工作流程，并使組織成為數(shù)字化時(shí)代網(wǎng)格模式與網(wǎng)格管理。

數(shù)字化時(shí)代網(wǎng)格模式在數(shù)字化轉(zhuǎn)型中無(wú)處不在，在每個(gè)行業(yè)都在發(fā)生。網(wǎng)格模式影響組織的所有活動(dòng)、功能和流程，也影響著組織每個(gè)部門，因?yàn)樗梢杂绊憳I(yè)務(wù)模型本身。數(shù)字化時(shí)代的網(wǎng)格管理是指在數(shù)字轉(zhuǎn)型背景下，業(yè)務(wù)、功能、流程、安全等都是相互關(guān)聯(lián)的，網(wǎng)格管理模式是數(shù)字化的核心表現(xiàn)。

網(wǎng)格管理模式下組織的生存離不開(kāi)效率，效率是敏捷性最重要的指標(biāo)。組織級(jí)敏捷轉(zhuǎn)型的終級(jí)目標(biāo)是把敏捷應(yīng)用到整個(gè)組織中，給業(yè)務(wù)帶來(lái)創(chuàng)新與收益。組織采用敏捷建模可以提升響應(yīng)能力，微服務(wù)架構(gòu)是敏捷建模（AM）的應(yīng)用體現(xiàn)。

（2）微服務(wù)安全是數(shù)字化成功的重要基石

數(shù)字化轉(zhuǎn)型成功的重要基石之一是業(yè)務(wù)與IT的關(guān)系，需要縮小兩者之間的差距，專注于相同的目標(biāo)。這也是微服務(wù)可以在數(shù)字轉(zhuǎn)型過(guò)程中發(fā)揮作用的地方。

微服務(wù)可謂當(dāng)下一大熱門詞匯，與之并駕齊驅(qū)的包括物聯(lián)網(wǎng)、容器化與區(qū)塊鏈等新興技術(shù)。微服務(wù)提供敏捷性、可靠性、可維護(hù)性、可擴(kuò)展性和可部署性，幫助組織完成數(shù)字化轉(zhuǎn)型過(guò)程。微服務(wù)架構(gòu)越來(lái)越多地用于設(shè)計(jì)和實(shí)現(xiàn)基于云部署的基礎(chǔ)設(shè)施、大型應(yīng)用程序和服務(wù)中的應(yīng)用程序系統(tǒng)。

在應(yīng)用微服務(wù)架構(gòu)時(shí)需要解決許多安全挑戰(zhàn)，這也刺激著組織思考微服務(wù)安全性在數(shù)字化轉(zhuǎn)型中的價(jià)值實(shí)現(xiàn)，即業(yè)務(wù)放到云基礎(chǔ)設(shè)施上并不等于走入數(shù)字化時(shí)代，業(yè)務(wù)放到云基礎(chǔ)設(shè)施必須保證架構(gòu)的安全性，微服務(wù)安全是數(shù)字化轉(zhuǎn)型必守之城。

2.如何設(shè)計(jì)微服務(wù)成為可信安全系統(tǒng)

（1）CSA?微服務(wù)安全參考架構(gòu)

DevSecOps模式成為DevOps最新的演進(jìn)路線，幫助組織在數(shù)字化轉(zhuǎn)型過(guò)程中實(shí)現(xiàn)云原生的安全性。通過(guò)將架構(gòu)的使用、架構(gòu)模式和安全控制措施疊加成為一個(gè)整體，在技術(shù)上實(shí)現(xiàn)了網(wǎng)格模式，確保了組織應(yīng)用的機(jī)密性、完整性和可用性（CIA）。

無(wú)論組織領(lǐng)導(dǎo)者傾向于購(gòu)買現(xiàn)成解決方案還是 “內(nèi)部構(gòu)建”，微服務(wù)和API消費(fèi)的集成都會(huì)是一種常見(jiàn)的系統(tǒng)集成預(yù)期。隨著組織繼續(xù)對(duì)流程數(shù)字化，安全團(tuán)隊(duì)必須應(yīng)對(duì)增加的攻擊矢量和更復(fù)雜的管理，同時(shí)還要與越來(lái)越復(fù)雜的攻擊者保持同步。面對(duì)這一巨大的挑戰(zhàn)，安全團(tuán)隊(duì)必須評(píng)估和更新他們的遺留安全過(guò)程、工具和技能集，以適應(yīng)新的、可適應(yīng)的組織安全方法。

為了便于指導(dǎo)安全控制措施疊加對(duì)微服務(wù)的施用，通用微服務(wù)架構(gòu)模式通過(guò)兩個(gè)分支形成了兩個(gè)不同的視角。第一個(gè)視角著眼于組織層面。組織層面包含了可協(xié)助實(shí)現(xiàn)微服務(wù)架構(gòu)治理的信息技術(shù)資產(chǎn)。組織期望減少控制措施狀態(tài)的變數(shù)。自定義編碼、生產(chǎn)狀態(tài)變通方案和一次性修改都會(huì)增加開(kāi)發(fā)成本。第二個(gè)視角著眼于軟件層面。分布式微服務(wù)應(yīng)用的分解圖，這種狀況存在于軟件層面，是最接近軟件代碼的表現(xiàn)方式。

2）安全控制措施疊加

安全疊加概念：是指運(yùn)用裁剪標(biāo)準(zhǔn)及指南的方法裁剪控制基線后得出的一個(gè)全套特定控制措施、控制措施強(qiáng)化和補(bǔ)充指南集，幫助組織實(shí)現(xiàn)安全管控

安全控制措施疊加可通過(guò)執(zhí)行相關(guān)業(yè)務(wù)和安全策略把風(fēng)險(xiǎn)降至一個(gè)可接受水平。控制挑選是在業(yè)務(wù)需要、投放市場(chǎng)時(shí)間和風(fēng)險(xiǎn)容忍度之間平衡的結(jié)果。安全疊加包裝了一種軟件模式，盡管它可能會(huì)帶來(lái)更大的安全控制覆蓋范圍，但是，適合于一種模式的，只會(huì)有一個(gè)安全疊加。在微服務(wù)架構(gòu)內(nèi)的不同位置和層級(jí)發(fā)揮作用的控制措施，會(huì)產(chǎn)生形成軟件深度防御的累加效應(yīng)。

三、微服務(wù)應(yīng)用安全

認(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ù)雜。

授權(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ù)變得更難。

數(shù)據(jù)安全防護(hù)

與《云原生應(yīng)用安全風(fēng)險(xiǎn)思考》一文中分析數(shù)據(jù)安全防護(hù)的必要性一樣，但微服務(wù)應(yīng)用架構(gòu)下，服務(wù)間通信不僅使用HTTP協(xié)議，還會(huì)使用gRPC協(xié)議等，這是我們需要注意的地方。

其它防護(hù)

除了上述防護(hù)方法之外，微服務(wù)治理框架與API網(wǎng)關(guān)/WAF可以結(jié)合以進(jìn)行深度防護(hù)，例如可以在一定程度上緩解微服務(wù)環(huán)境中被拒絕服務(wù)攻擊的風(fēng)險(xiǎn)。

1.認(rèn)證服務(wù)

微服務(wù)架構(gòu)下，服務(wù)可以采用JWT或基于Istio的認(rèn)證方式

（1） 基于JWT(JSON Web Token)的認(rèn)證

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

1. 客戶端請(qǐng)求某服務(wù)，服務(wù)端對(duì)用戶進(jìn)行登錄認(rèn)證；
2. 認(rèn)證通過(guò)，服務(wù)端將用戶登錄信息進(jìn)行加密并形成令牌，最后再返回至客戶端作為登錄憑證；
3. 在2步驟之后，客戶端每次請(qǐng)求都需攜帶認(rèn)證的令牌;
4. 服務(wù)端對(duì)令牌進(jìn)行解密，判斷是否有效，若有效則認(rèn)證通過(guò)，否則返回失敗信息；

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

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

（2）基于Istio的認(rèn)證

Istio的安全架構(gòu)

Istio的認(rèn)證和授權(quán)兩部分，Istio的安全機(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可實(shí)現(xiàn)為服務(wù)網(wǎng)格中的服務(wù)提供認(rèn)證機(jī)制，該認(rèn)證機(jī)制工作流程包含提供服務(wù)簽名證書，并將證書分發(fā)至數(shù)據(jù)平面各個(gè)服務(wù)的Envoy代理中，當(dāng)數(shù)據(jù)平面服務(wù)間建立通信時(shí)，服務(wù)旁的Envoy代理會(huì)攔截請(qǐng)求并采用簽名證書和另一端服務(wù)的Envoy代理進(jìn)行雙向TLS認(rèn)證從而建立安全傳輸通道，保障了數(shù)據(jù)安全。

2.授權(quán)服務(wù)

微服務(wù)架構(gòu)下，授權(quán)服務(wù)可以通過(guò)基于角色的授權(quán)以及基于Istio的授權(quán)實(shí)現(xiàn)

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

基于角色的授權(quán)服務(wù)為RBAC（RoleBased Access Control），通過(guò)角色關(guān)聯(lián)用戶，角色關(guān)聯(lián)權(quán)限的方式間接賦予用戶權(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)行修改，通過(guò)這種方式不僅可以大幅提升權(quán)限調(diào)整的效率，還降低了漏調(diào)權(quán)限的概率。

（2）基于Istio的授權(quán)服務(wù)

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

（3）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”]

3.數(shù)據(jù)安全

傳統(tǒng)應(yīng)用架構(gòu)中，我們可以通過(guò)安全編碼、使用密鑰管理系統(tǒng)和使用安全協(xié)議的方式防止數(shù)據(jù)泄露，在微服務(wù)應(yīng)用架構(gòu)中，我們可以考慮使用Kubernetes原生的安全機(jī)制或微服務(wù)治理框架的安全機(jī)制去進(jìn)行防護(hù)。

針對(duì)Kubernetes原生的安全機(jī)制，例如Secret機(jī)制，我們可以使用其進(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)。

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

采用微服務(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ù)能力。

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

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

（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ù)安全。

另一種解決方案是Radware提出的Kubernetes WAF方案，該方案基于Istio實(shí)現(xiàn)，其中WAF被拆分為Agent程序和后端服務(wù)兩部分，Agent程序作為Sidecar容器置于Pod的Envoy容器和業(yè)務(wù)容器間，該Sidecar的主要作用為啟動(dòng)一個(gè)反向代理，以便將外部請(qǐng)求流量代理至Pod外部的WAF后端服務(wù)中。該套方案帶來(lái)的好處是無(wú)需關(guān)心外部請(qǐng)求如何路由至Pod、與Istio結(jié)合的理念更接近云原生化、實(shí)現(xiàn)了以單個(gè)服務(wù)為粒度的防護(hù)。

四、總結(jié)

版權(quán)聲明：本文為CSDN博主「跳樓梯企鵝」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/weixin_50481708/article/details/126277058