国产精品chinese,色综合天天综合精品网国产在线,成午夜免费视频在线观看,清纯女学生被强行糟蹋小说

    <td id="ojr13"><tr id="ojr13"><label id="ojr13"></label></tr></td>
        • <source id="ojr13"></source>
            <td id="ojr13"><ins id="ojr13"><label id="ojr13"></label></ins></td>

            Article / 文章中心

            如何縮小安全漏洞爆炸半徑,實現(xiàn)服務(wù)間零信任安全?

            發(fā)布時間:2021-12-13 點擊數(shù):638


            近日國內(nèi)外多家安全機構(gòu)監(jiān)測到 Apache Log4j 存在任意代碼執(zhí)行漏洞(漏洞編號:CVE-2021-44228),未取得身份認(rèn)證的用戶,可以從遠(yuǎn)程發(fā)送數(shù)據(jù)請求輸入數(shù)據(jù)日志,輕松觸發(fā)漏洞,最終在目標(biāo)上執(zhí)行任意代碼。


            眾所周知,Log4j 在多個微服務(wù)應(yīng)用框架中被廣泛使用,這些分布眾多的微服務(wù)也會增加安全的挑戰(zhàn),每個微服務(wù)都是一個被攻擊的目標(biāo)。Kubernetes 為托管和編排用戶的微服務(wù)提供了一個出色的平臺。但是,默認(rèn)情況下,微服務(wù)之間的所有交互都不安全。它們通過純文本 HTTP 進(jìn)行通信,但這不足以滿足安全要求。只依賴網(wǎng)絡(luò)邊界來保證安全是不夠的,因為一旦內(nèi)部的某個服務(wù)被攻陷,邊界安全手段就如馬奇諾防線,攻擊者能夠以該機器為跳板來攻擊內(nèi)網(wǎng)。所以,內(nèi)部的調(diào)用也必須安全,這就是零信任的用武之地。


            零信任是 Forrester 分析師 John Kindervag 提出的, 是指無論在網(wǎng)絡(luò)邊界內(nèi)部還是外部,都沒有任何隱含的信任可言。換句話說,任何地方都需要顯式認(rèn)證, 并使用最小權(quán)限原則來限制對資源的訪問。
            服務(wù)網(wǎng)格技術(shù)的一個重要的價值主張就是它如何有效地保護(hù)應(yīng)用的生產(chǎn)環(huán)境,同時又不降低開發(fā)人員的生產(chǎn)力。通過服務(wù)網(wǎng)格技術(shù),為微服務(wù)架構(gòu)采用零信任網(wǎng)絡(luò)安全方法提供必要的基礎(chǔ),以此實現(xiàn)所有訪問都經(jīng)過強身份驗證、基于上下文授權(quán)、記錄監(jiān)控等安全目標(biāo)。使用這些網(wǎng)格功能,您可以為屬于網(wǎng)格的所有應(yīng)用程序提供安全控制能力,例如所有流量都已加密、到應(yīng)用程序的所有流量都通過策略執(zhí)行點(PEP)的驗證等。


            由美國國家安全局(NSA)于 2021 年 8 月發(fā)布的《Kubernetes Hardening Guidance》(具體請見文末相關(guān)鏈接 1)也提到了管理員應(yīng)該考慮使用服務(wù)網(wǎng)格來加強 Kubernetes 集群的安全性。


            阿里云服務(wù)網(wǎng)格 ASM(具體請見文末相關(guān)鏈接 2)成為重要的云原生零信任體系落地載體之一,將身份驗證和授權(quán)從應(yīng)用程序代碼卸載到服務(wù)網(wǎng)格,開箱即用、動態(tài)可配、更新策略更加容易且立即生效。在使用 Kubernetes Network Policy 實現(xiàn)三層網(wǎng)絡(luò)安全控制之上,服務(wù)網(wǎng)格 ASM 提供了包括對等身份和請求身份認(rèn)證能力、Istio 授權(quán)策略以及更為精細(xì)化管理的基于 OPA(Open Policy Agent) 的策略控制能力。阿里云服務(wù)網(wǎng)格 ASM 提供的這些零信任安全能力, 幫助用戶實現(xiàn)上述這些安全目標(biāo)。


            構(gòu)建基于服務(wù)網(wǎng)格的零信任安全能力體系包括了以下幾個方面:
            1. 零信任的基礎(chǔ) - 工作負(fù)載身份;如何為云原生工作負(fù)載提供統(tǒng)一的身份;ASM 產(chǎn)品為服務(wù)網(wǎng)格下的每一個工作負(fù)載提供了簡單易用的身份定義,并根據(jù)特定場景提供定制機制用于擴(kuò)展身份構(gòu)建體系, 同時兼容社區(qū) SPIFFE 標(biāo)準(zhǔn);


            2. 零信任的載體 - 安全證書,ASM 產(chǎn)品提供了如何簽發(fā)證書以及管理證書的生命周期、輪轉(zhuǎn)等機制,通過 X509 TLS 證書建立身份,每個代理都使用該證書。并提供證書和私鑰輪換;


            3. 零信任的引擎 - 策略執(zhí)行,基于策略的信任引擎是構(gòu)建零信任的關(guān)鍵核心,ASM 產(chǎn)品除了支持 Istio RBAC 授權(quán)策略之外,還提供了基于 OPA 提供更加細(xì)粒度的授權(quán)策略;


            4. 零信任的洞察 - 可視化與分析,ASM 產(chǎn)品提供了可觀測機制用于監(jiān)視策略執(zhí)行的日志和指標(biāo),來判斷每一個策略的執(zhí)行情況等;


            01

            為什么要使用服務(wù)網(wǎng)格

            實現(xiàn)零信任?

            Cloud Native


            與直接在應(yīng)用程序代碼中構(gòu)建這些安全機制的傳統(tǒng)方法相比,服務(wù)網(wǎng)格體系結(jié)構(gòu)具有以下多種安全性好處:
            • Sidecar 代理的生命周期與應(yīng)用程序保持獨立,因此可以更輕松地管理這些 Sidecar 代理。

            • 允許動態(tài)配置,更新策略變得更加容易,更新立即生效,而無需重新部署應(yīng)用程序。

            • 服務(wù)網(wǎng)格的集中控制架構(gòu)使企業(yè)的安全團(tuán)隊可以構(gòu)建、管理和部署適用于整個企業(yè)的安全策略,從而默認(rèn)情況下就能確保應(yīng)用開發(fā)人員構(gòu)建的業(yè)務(wù)應(yīng)用的安全。他們無需額外的工作即可立即使用這些安全策略。

            • 服務(wù)網(wǎng)格提供了對附加到請求的終端用戶憑據(jù)進(jìn)行身份驗證的能力如 JWT。

            • 此外, 使用服務(wù)網(wǎng)格體系結(jié)構(gòu),可以將身份驗證和授權(quán)系統(tǒng)作為服務(wù)部署在網(wǎng)格中。這樣一來,如同網(wǎng)格中的其他服務(wù)一樣,這些安全系統(tǒng)從網(wǎng)格中本身也可以得到安全保證,包括傳輸中的加密、身份識別、策略執(zhí)行點、終端用戶憑據(jù)的身份驗證和授權(quán)等。


            借助阿里云服務(wù)網(wǎng)格 ASM,可以使用單個控制平面來實施強大的身份和訪問管理,透明的 TLS 和加密,身份驗證和授權(quán)以及審核日志記錄。阿里云服務(wù)網(wǎng)格 ASM 開箱即用地提供了這些功能,并且安裝和管理它的簡單性使開發(fā)人員,系統(tǒng)管理員和安全團(tuán)隊可以適當(dāng)?shù)乇Wo(hù)其微服務(wù)應(yīng)用程序。


            02

            阿里云服務(wù)網(wǎng)格 ASM中的

            零信任體系

            Cloud Native


            服務(wù)網(wǎng)格能夠減小云原生環(huán)境中的被攻擊面積,并提供零信任應(yīng)用網(wǎng)絡(luò)所需的基礎(chǔ)框架。通過 ASM 管理服務(wù)到服務(wù)的安全性,可以確保服務(wù)網(wǎng)格的端到端加密、服務(wù)級別身份認(rèn)證和細(xì)粒度授權(quán)策略。


            在服務(wù)網(wǎng)格體系下, 可以支持:
            • 在服務(wù)之間實施雙向 TLS 認(rèn)證或者面向 server 側(cè)的 TLS 認(rèn)證,支持證書的自動輪轉(zhuǎn)等生命周期管理。網(wǎng)格內(nèi)的通信都經(jīng)過身份驗證和加密處理。

            • 啟用基于身份的細(xì)粒度授權(quán),以及基于其他維度參數(shù)的授權(quán)?;诮巧L問控制 (RBAC) 的基礎(chǔ),支持 “最低權(quán)限” 的立場,也就是只有經(jīng)過授權(quán)的服務(wù)才能根據(jù) ALLOW/DENY 規(guī)則相互通信。


              阿里云服務(wù)網(wǎng)格 ASM


            當(dāng)前, 阿里云服務(wù)網(wǎng)格 ASM 提供了如下的零信任安全基本能力:
            1
            工作負(fù)載身份


            當(dāng)應(yīng)用程序在服務(wù)網(wǎng)格環(huán)境中運行時,服務(wù)網(wǎng)格會為每個服務(wù)提供一個唯一標(biāo)識。連接到服務(wù)網(wǎng)格中運行的其他微服務(wù)時,將會使用該標(biāo)識。服務(wù)標(biāo)識可用于服務(wù)的雙向驗證,以此進(jìn)行驗證是否允許服務(wù)間的訪問,同時該服務(wù)標(biāo)識也可用于授權(quán)策略中。


            當(dāng)使用服務(wù)網(wǎng)格 ASM 管理運行在 Kubernetes 上的工作負(fù)載或者基于 WorkloadEntry 定義虛擬機工作負(fù)載時,ASM 會為每個工作負(fù)載提供服務(wù)身份;該身份基于工作負(fù)載的服務(wù)帳戶令牌實現(xiàn)。


            ASM 中的服務(wù)身份符合 SPIFFE 標(biāo)準(zhǔn),并具有以下格式:spiffe:///ns//sa/


            在服務(wù)網(wǎng)格 ASM 控制臺上,打開對應(yīng)的 ASM 實例,在左側(cè)導(dǎo)航欄中可以看到如下零信任安全下的工作負(fù)載身份。


            數(shù)據(jù)面中的 Kubernetes 集群下的工作負(fù)載及其身份定義:

             Kubernetes 集群

            基于 WorkloadEntry 定義虛擬機工作負(fù)載及其身份定義:

             Kubernetes 集群


            2 對等身份認(rèn)證


            認(rèn)證指的是身份:這個服務(wù)是誰?這個最終用戶是誰?我可以相信他們就是他們所說的那樣嗎?
            ASM產(chǎn)品提供了兩種身份驗證:
            • 對等身份驗證 - 當(dāng)兩個微服務(wù)相互交互時,啟用還是禁用雙向TLS進(jìn)行對等身份驗證。


            • 請求身份驗證 - 允許最終用戶和系統(tǒng)使用請求身份認(rèn)證與微服務(wù)進(jìn)行交互。通常使用JSON Web令牌(JWT)執(zhí)行該操作。


            按照入門指引(具體請見文末相關(guān)鏈接 3)安裝部署 bookinfo 示例。


            首先,當(dāng)嘗試從同一命名空間(例如本示例中為 default)中的 productpage pod 使用純 HTTP 訪問 details 服務(wù)時,默認(rèn)情況下請求應(yīng)該以 status 200 成功返回。這是因為在默認(rèn)情況下,TLS 和純文本流量都可以被接受。
            kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n'

            接著,在命名空間 default 下定義對等身份認(rèn)證。

            在服務(wù)網(wǎng)格 ASM 控制臺上,打開對應(yīng)的 ASM 實例,在左側(cè)導(dǎo)航欄中可以看到如下零信任安全下的對等身份認(rèn)證。在右側(cè)頁面中,點擊 “新建雙向 mTLS 模式” 按鈕,為工作負(fù)載 details 定義 mTLS 模式為 STRICT。

            雙向 mTLS 模式




            再次,使用 productpage pod 使用純 HTTP 訪問 details 服務(wù)時:

            kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n'000command terminated with exit code 56


            退出碼 56 表示接收網(wǎng)絡(luò)數(shù)據(jù)失敗。這是符合預(yù)期的,工作負(fù)載 details 定義了 mTLS 模式為 STRICT,這樣在每個請求中都需要 TLS 證書認(rèn)證。


            為了允許正常訪問,可以通過上述定義的對等身份認(rèn)證從 STRICT 修改為 PERMISSIVE。對應(yīng)的 YAML 定義如下:
            	
            						
            apiVersion: security.istio.io/v1beta1kind: PeerAuthenticationmetadata: name: details-strict namespace: defaultspec: mtls: mode: PERMISSIVE selector: matchLabels: app: details

            3 請求身份驗證


            首先,我們將創(chuàng)建一個請求身份認(rèn)證策略來對 details 服務(wù)的入站請求強制執(zhí)行 JWT 身份驗證。在服務(wù)網(wǎng)格 ASM 控制臺上,打開對應(yīng)的 ASM 實例,在左側(cè)導(dǎo)航欄中可以看到如下零信任安全下的請求身份認(rèn)證。在右側(cè)頁面中,點擊 “新建” 按鈕,為工作負(fù)載 details 定義 jwt 規(guī)則。


            其中,issuer 值設(shè)置為"testing@secure.istio.io",jwks 的值取自 Istio 安裝文件中的 security/tools/jwt/samples/jwks.json,對應(yīng)如下


            { "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}

            ASM 控制臺



            接著, 嘗試使用 productpage pod 使用純 HTTP 訪問 details 服務(wù)時,可以看到返回結(jié)果為 200。


            其中設(shè)置變量 TOKEN 值為:
            	
            				
            export TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer $TOKEN" -s -w '%{http_code}\n' 200

            如果傳遞的是無效令牌,我們應(yīng)該看到 “401: Unauthorized” 響應(yīng):
            	
            				
            kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer badtoken" -s -w '%{http_code}\n' 401

            但是,如果我們根本不傳遞令牌,RequestAuthentication 則不會調(diào)用該策略。不使用 JWT Token 的請求, 同樣也返回了 200。
            	
            				
            kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n' 200

            因此,除了此身份驗證策略之外,我們還需要一個授權(quán)策略,該策略要求對所有請求進(jìn)行 JWT。下一部分會講述如何在 ASM 產(chǎn)品中定義授權(quán)策略。
            4 授權(quán)策略


            ASM 產(chǎn)品提供了授權(quán)策略,可以使用授權(quán)策略 AuthorizationPolicy 資源來激活微服務(wù)之間的授權(quán)機制,并使用以下內(nèi)容建立適當(dāng)?shù)牧髁渴跈?quán)策略機制:
            • 工作負(fù)載標(biāo)簽選擇 selector 字段指定策略目標(biāo);

            • action 字段指定是 ALLOW 還是 DENY 請求。如果您未指定操作,則操作默認(rèn)設(shè)置為 ALLOW。為清晰起見,我們建議您始終指定操作。(授權(quán)政策還支持 AUDIT 和 CUSTOM 操作);

            • rules 指定何時觸發(fā)操作:
              • rules 中的 from 字段指定請求的來源;
              • rules 中的 to 字段指定請求的操作;
              • when 字段指定為了應(yīng)用規(guī)則所需滿足的其他條件;



            AuthorizationPolicy 資源




            對應(yīng)的 YAML 定義如下:
            	
            						
            apiVersion: security.istio.io/v1beta1kind: AuthorizationPolicymetadata: name: require-jwt namespace: defaultspec: action: ALLOW rules: - from: - source: requestPrincipals: - testing@secure.istio.io/testing@secure.istio.io selector: matchLabels: app: details

            再次不使用 JWT Token 發(fā)送請求,您現(xiàn)在應(yīng)該看到 403 - Forbidden。這就是 AuthorizationPolicy 生效了,所有前端請求都必須有一個 JWT Token。


             kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'403

            5 OPA 策略


            作為由 CNCF(具體請見文末相關(guān)鏈接 4)托管的一個孵化項目,開放策略代理(OPA)(具體請見文末相關(guān)鏈接 5)是一個策略引擎,可用于為您的應(yīng)用程序?qū)崿F(xiàn)細(xì)粒度的訪問控制。OPA 作為通用策略引擎,可以與微服務(wù)一起部署為獨立服務(wù)。為了保護(hù)應(yīng)用程序,必須先授權(quán)對微服務(wù)的每個請求,然后才能對其進(jìn)行處理。為了檢查授權(quán),微服務(wù)對 OPA 進(jìn)行 API 調(diào)用,以確定請求是否被授權(quán)。


            服務(wù)網(wǎng)格 ASM




            服務(wù)網(wǎng)格 ASM 集成了開放策略代理(OPA)插件,通過 OPA 定義訪問控制策略,可以使您的應(yīng)用實現(xiàn)細(xì)粒度的訪問控制,并支持動態(tài)更新 OPA 策略。

            具體可以參考《在ASM中實現(xiàn)動態(tài)更新OPA策略》(具體請見文末相關(guān)鏈接 6)


            6 零信任性能提升


            英特爾® 在全新的第三代英特爾® 至強® 可擴(kuò)展處理器(ICELAKE)中引入眾多我們稱為 Crypto Acceleration 加解密加速技術(shù)和架構(gòu)創(chuàng)新,大大提升了一些關(guān)鍵加解密算法的性能。第三代英特爾至強處理器和 Multi-Buffer 技術(shù)所使用的 AVX512 指令集,在阿里云第七代 ECS 服務(wù)器中提供了若干不同的實例類型?;谶@些指令集, 加上融合了 MultiBuffer 技術(shù)的 Envoy 上游社區(qū)能力,阿里云服務(wù)網(wǎng)格 ASM 產(chǎn)品提供了基于 MB 技術(shù)的 TLS 加解密性能優(yōu)化能力。

            阿里云服務(wù)網(wǎng)格 ASM



            結(jié)合英特爾的開源軟件庫,例如 IPP 加密庫、IPsec 多緩沖區(qū)加密庫 (intel-ipsec-mb)、英特爾® QuickAssist 技術(shù)(英特爾® QAT)和 OpenSSL 引擎。這些解決方案顯著改善了加密操作,例如 TLS 連接握手性能。這些新組件可以并行處理多個 TLS 私鑰操作。借助 OpenSSL 和 BoringSSL 中都可用的異步私鑰處理機制,應(yīng)用程序軟件可以提交握手私鑰請求,而無需等待一個請求返回,然后才能提交另一個。反過來,一旦準(zhǔn)備好,就會為每個請求調(diào)用一個回調(diào)。在下面,多緩沖區(qū)加密處理可以將 8 個這樣異步提交的私鑰操作,并使用 AVX512 SIMD(單指令多數(shù)據(jù))指令并行處理,大大提高了整體應(yīng)用性能。


            在阿里云 ASM 控制臺中一鍵可以啟用性能優(yōu)化開關(guān),當(dāng)前這個功能已經(jīng)在產(chǎn)品最新版本中對外開放。
            在 KubeCon 2021 大會上阿里云服務(wù)網(wǎng)格 ASM 負(fù)責(zé)人王夕寧和英特爾軟件和先進(jìn)技術(shù)部云計算團(tuán)隊的胡偉將會給大家?guī)硪淮螌n}的技術(shù)分享,屆時我們將會介紹更多的技術(shù)細(xì)節(jié)和實踐的情況。技術(shù)分享鏈接見文末 7)


            03

            總結(jié)及參考案例

            Cloud Native


            綜上所示,服務(wù)網(wǎng)格 ASM 提供了以下用于增強安全性的組件:
            • 提供具有完整證書生命周期管理的托管證書基礎(chǔ)設(shè)施,解決了證書頒發(fā)和 CA 輪換的復(fù)雜性;

            • 托管的控制面 API,用于向 Envoy 代理分發(fā)身份驗證策略,授權(quán)策略和安全命名信息;

            • Sidecar 代理通過提供策略執(zhí)行點 PEP 來幫助確保網(wǎng)格的安全;

            • Envoy 代理擴(kuò)展允許遙測數(shù)據(jù)收集和審計;


            每一個工作負(fù)載通過 X509 TLS 證書建立身份,每個 Sidecar 代理都使用該證書。服務(wù)網(wǎng)格 ASM 提供并定期輪換證書和私鑰。如果某個特定的私鑰被盜用,服務(wù)網(wǎng)格很快就會用新的私鑰替換它,從而大大減少了攻擊面。
            1 參考案例


            1. 使用授權(quán)策略在入口網(wǎng)關(guān)上實施基于 IP 的訪問控制(具體請見文末相關(guān)鏈接 8)、或者基于自定義外部授權(quán)的訪問控制等,如下圖所示云產(chǎn)品云原生應(yīng)用交付平臺 ADP(具體請見文末相關(guān)鏈接 9)基于阿里云服務(wù)網(wǎng)格ASM的網(wǎng)關(guān)授權(quán)策略實現(xiàn)。

              阿里云服務(wù)網(wǎng)格 ASM授權(quán)


            1. 某互聯(lián)金融客戶在解決跨集群多語言應(yīng)用的訪問權(quán)限控制方面,使用阿里云服務(wù)網(wǎng)格 ASM 提供的授權(quán)策略隔離外聯(lián)區(qū)域和應(yīng)用區(qū)域。同時可以結(jié)合出口網(wǎng)關(guān)來審計出網(wǎng)格的流量,配合上授權(quán)策略,還可以控制應(yīng)用對第三方服務(wù)的訪問權(quán)限。