一、概述

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

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

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

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

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

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

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

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

網(wǎng)格管理模式下組織的生存離不開效率，效率是敏捷性最重要的指標。組織級敏捷轉(zhuǎn)型的終級目標是把敏捷應(yīng)用到整個組織中，給業(yè)務(wù)帶來創(chuàng)新與收益。組織采用敏捷建?？梢蕴嵘憫?yīng)能力，微服務(wù)架構(gòu)是敏捷建模（AM）的應(yīng)用體現(xiàn)。

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

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

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

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

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

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

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

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

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

2）安全控制措施疊加

安全疊加概念：是指運用裁剪標準及指南的方法裁剪控制基線后得出的一個全套特定控制措施、控制措施強化和補充指南集，幫助組織實現(xiàn)安全管控

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

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

認證服務(wù)

由于攻擊者在進行未授權(quán)訪問前首先需要通過系統(tǒng)的認證，因而確保認證服務(wù)的有效性非常重要，尤其在微服務(wù)應(yīng)用架構(gòu)下，服務(wù)的不斷增多將會導致其認證過程變得更為復雜。

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

授權(quán)服務(wù)是針對未授權(quán)訪問風險最直接的防護手段，微服務(wù)應(yīng)用架構(gòu)下，由于服務(wù)的權(quán)限映射相對復雜，因而會導致授權(quán)服務(wù)變得更難。

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

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

其它防護

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

1.認證服務(wù)

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

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

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

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

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

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

（2）基于Istio的認證

Istio的安全架構(gòu)

Istio的認證和授權(quán)兩部分，Istio的安全機制涉及諸多組件，控制平面由核心組件Istiod提供，其中包含密鑰及證書頒發(fā)機構(gòu)（CA）、認證授權(quán)策略、網(wǎng)絡(luò)配置等；數(shù)據(jù)平面則由Envoy代理、邊緣代理（Ingress和Egress）組件構(gòu)成。借助控制平面Istiod內(nèi)置的CA模塊，Istio可實現(xiàn)為服務(wù)網(wǎng)格中的服務(wù)提供認證機制，該認證機制工作流程包含提供服務(wù)簽名證書，并將證書分發(fā)至數(shù)據(jù)平面各個服務(wù)的Envoy代理中，當數(shù)據(jù)平面服務(wù)間建立通信時，服務(wù)旁的Envoy代理會攔截請求并采用簽名證書和另一端服務(wù)的Envoy代理進行雙向TLS認證從而建立安全傳輸通道，保障了數(shù)據(jù)安全。

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

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

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

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

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

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

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

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

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

4.其他防護機制

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

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

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

（2）Istio和WAF結(jié)合的深度防護

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

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

四、總結(jié)

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