如何縮小安全漏洞爆炸半徑,實現(xiàn)服務(wù)間零信任安全?
近日國內(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í)行任意代碼。
服務(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)的驗證等。
-
零信任的基礎(chǔ) - 工作負(fù)載身份;如何為云原生工作負(fù)載提供統(tǒng)一的身份;ASM 產(chǎn)品為服務(wù)網(wǎng)格下的每一個工作負(fù)載提供了簡單易用的身份定義,并根據(jù)特定場景提供定制機制用于擴(kuò)展身份構(gòu)建體系, 同時兼容社區(qū) SPIFFE 標(biāo)準(zhǔn);
-
零信任的載體 - 安全證書,ASM 產(chǎn)品提供了如何簽發(fā)證書以及管理證書的生命周期、輪轉(zhuǎn)等機制,通過 X509 TLS 證書建立身份,每個代理都使用該證書。并提供證書和私鑰輪換;
-
零信任的引擎 - 策略執(zhí)行,基于策略的信任引擎是構(gòu)建零信任的關(guān)鍵核心,ASM 產(chǎn)品除了支持 Istio RBAC 授權(quán)策略之外,還提供了基于 OPA 提供更加細(xì)粒度的授權(quán)策略;
-
零信任的洞察 - 可視化與分析,ASM 產(chǎn)品提供了可觀測機制用于監(jiān)視策略執(zhí)行的日志和指標(biāo),來判斷每一個策略的執(zhí)行情況等;
01
為什么要使用服務(wù)網(wǎng)格
實現(xiàn)零信任?
Cloud Native
- 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中的
零信任體系
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ù)之間實施雙向 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ī)則相互通信。
1
工作負(fù)載身份
數(shù)據(jù)面中的 Kubernetes 集群下的工作負(fù)載及其身份定義:
基于 WorkloadEntry 定義虛擬機工作負(fù)載及其身份定義:
認(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 示例。
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。
再次,使用 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
apiVersion: security.istio.io/v1beta1kind: PeerAuthenticationmetadata: name: details-strict namespace: defaultspec: mtls: mode: PERMISSIVE selector: matchLabels: app: details
3 請求身份驗證
其中,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"}]}
接著, 嘗試使用 productpage pod 使用純 HTTP 訪問 details 服務(wù)時,可以看到返回結(jié)果為 200。
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ī)則所需滿足的其他條件;
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)。
具體可以參考《在ASM中實現(xiàn)動態(tài)更新OPA策略》(具體請見文末相關(guān)鏈接 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)化能力。
結(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)用性能。
在 KubeCon 2021 大會上阿里云服務(wù)網(wǎng)格 ASM 負(fù)責(zé)人王夕寧和英特爾軟件和先進(jìn)技術(shù)部云計算團(tuán)隊的胡偉將會給大家?guī)硪淮螌n}的技術(shù)分享,屆時我們將會介紹更多的技術(shù)細(xì)節(jié)和實踐的情況。(技術(shù)分享鏈接見文末 7)
總結(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ù)收集和審計;
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)。
- 某互聯(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)限。