零信任網絡的微服務基本要素概述
本文譯自 Tetrate 博客 Zero Trust Network for Microservices[1]，作者 Varun Talwar，譯者宋淨超。
編者按
本博客將向您介紹零信任網絡及其基本要素，這是 CISO（首席信息安全官）必須考慮的，以使網絡強大，在當今的數字轉型中沒有安全漏洞，並減少潛在的財務損失。
當今所有主要組織都在經歷大規模的數字化轉型，採用雲、移動、微服務和容器技術來高效地提供服務，滿足關鍵業務需求，趕上市場預期。企業的平臺和 DevOps 團隊必須對分佈式和多雲的應用程序和服務進行建模，以便隨時隨地進行訪問，從而實現敏捷性。這在組織內部產生了兩個重要的趨勢：
1. 隨着越來越多的組織採用多雲，他們將其應用程序部署到公有云（谷歌、亞馬遜、Azure 等），這意味着數據離開了他們所認爲的安全的內部數據中心。2. 企業使用微服務和分佈式架構來實現大規模和敏捷。
然而，應用程序開發人員現在需要解決一系列新的可靠性和安全性問題，因爲越來越多的依賴性是通過網絡調用消耗的。當集中式系統在使用時，網絡和端點安全在十年前很容易實現和管理。安全團隊可以利用防火牆充分保障周邊的安全。隨着多雲中的分散數據和微服務導致的分佈式工作負載的新趨勢，IT 安全組織需要評估他們的安全態勢，並重新思考他們的網絡架構。當然，安全不是一個人或一個部門的工作，它是一個組織中的 IT 安全、DevOps 和 Ops 團隊的共同責任。
什麼是零信任網絡？
零信任是一個指導原則，它強調 IT 組織在構建網絡架構時不信任任何個人、應用程序或設備。在這裏，“零 "信任意味着" 不隱含 " 信任。企業 IT 部門不能假設外部和內部實體是值得信任的，或者對任何實體的安全風險進行一次性評估就足夠了（實體可以是應用、人或流量）。
零信任通常與網絡安全相關，因爲只有在有數據交換的情況下，信任纔會出現。零信任網絡是一種通過認證和監控每個網絡訪問來識別任何外部實體的可信度的方法。
點擊下載零信任架構白皮書 [2]
爲什麼我們比以往任何時候都更需要零信任網絡？
我們想強調零信任網絡比以往任何時候都更重要的最常見原因。
雲中的數據泄露現在很普遍
數據泄露事件在逐年上升，損害了公司的聲譽。我仍然記憶猶新，一個分水嶺事件是 2020 年的 Solarwinds 攻擊事件。Solarwinds Orion 是一個基於 SaaS 的網絡監控工具，它被入侵了，木馬使用惡意軟件攻擊來掌握整個網絡基礎設施。雖然沒有任何企業的敏感數據或文件被竊取等附帶損害，但入侵是跨領域和跨地域的。即使是先進的公司，對雲的網絡釣魚攻擊和惡意軟件攻擊通常也很難發現，而且在未來可能會上升。根據 Verizon 最近的研究結果 [3]，雲計算漏洞已經超過了內部數據漏洞 ——2021 年 73% 的網絡安全事件涉及外部雲資產。而 CISO 的一個標準建議是儘快應用零信任網絡的原則以避免安全漏洞。
分佈式工作負載也不安全，由於運行時矢量攻擊
雖然企業採用 Kubernetes 技術的速度比以往任何時候都快，但它們並不是 100% 安全的。Kubernetes 和容器化應用經常出現漏洞和黑客攻擊的情況。根據 2021 年 RedHat 的報告 [4]，90% 的受訪者在過去一年中經歷了涉及其容器和 Kubernetes 環境的安全事件。
分佈式系統失敗的常見原因之一是 Kubernetes 集羣在運行時（或實時）的矢量攻擊，並帶來了一系列新的安全挑戰。如果黑客攻破一個 Kubernetes 容器，他們將試圖攻破整個集羣，這是一種複雜的矢量攻擊。美國國家安全局（NSA）指出，黑客針對 Kubernetes 來竊取數據和計算能力 [5]。
根本原因往往是隱性信任，假設集羣間的資源是可信的，集羣內不安全的網絡通信是安全的。
安全配置不是開發人員的核心能力
儘管 Kubernetes 給基礎設施和應用交付領域帶來了敏捷性和規模，但要確保安全是個挑戰。有人可能會說，Kubernetes 中有一些固有的安全功能，如使用 ClusterRoleBinding 的 RBAC，Kubernetes 服務的 TLS 等，應該足夠了。然而，Kubernetes 需要大量的配置來使工作負載免受外部和內部威脅。例如，在 pod 之間強制執行 TLS，在某些時候需要維護數百個 TLS 證書。
而那些已經專注於開發業務功能的開發人員可能不會優先考慮安全問題。紅帽公司最近發佈的一份關於 Kubernetes 安全狀況 [6] 的報告顯示，大型企業面臨的安全事件大多與錯誤配置、重大漏洞有關，並遭遇到運行時安全事件。
應用程序的交付在 CI/CD 的幫助下獲得了快速發展，而安全問題卻沒有
通過 CI/CD 流程、交付協調工具、GitOps 風格的部署，DevOps 團隊加快了軟件交付速度。許多組織可以每天將應用程序部署到生產中（如果需要，往往在幾個小時內）。這種創新速度適合於組織的蓬勃發展和成長，但如果不注重強大的安全性和合規性，就會帶來漏洞。
我們所接觸的大多數組織都在他們的 DevOps 流程中逐步發展並開始採用 DevSecOps，將安全檢查整合到他們的 SDLC 過程中。作爲一種實踐，他們的 DevOps 團隊、合規經理、安全經理、網絡管理員在部署前合作討論安全要求和構建威脅模型。
實施零信任網絡的關鍵因素
不同的安全組織、分析師和作者提出了許多框架。例如，Forrester 建議零信任擴展（ZTX 模型），並主張保護不同的數據管道以保護數據本身。Gartner 有一個概念，叫做持續適應性風險和信任評估（CARTA），它主要側重於分析與身份和設備相關的風險態勢。
我們相信，沒有任何一個放之四海而皆準的框架能適用於所有的場景和所有的組織。我們爲使用微服務範式開發和部署應用程序的企業提供一個零信任框架，以確保網絡和應用程序的安全。
Tetrate 與美國國家標準與技術研究所（NIST）[7] 合作，爲聯邦機構開發標準，以便爲其微服務實施零信任架構。
你可以在 NIST 和 Tetrate 共同編寫的 NIST 特別出版物中閱讀在微服務中實現零信任的詳細指南：《微服務的安全策略 [8]》、《 使用服務網格構建安全的微服務 [9]》、《 使用服務網格的基於屬性的微服務訪問控制 [10]》、《 使用服務網格實現微服務的 DevSecOps[11]》和《 零信任架構 [12]》。
對於 CISO 和 CTO 來說，基於上述研究文件，我們主張採用持續安全框架，以實現其微服務和服務網格的零信任，避免數據泄露。在這個框架下，有 4 個關鍵因素需要考慮。
微服務的零信任網絡框架
1. 安全網絡
DevSecOps 團隊的首要任務是確保網絡和數據的完整性。到你的應用程序的流量可以來自任何地方：包括企業自有網絡內部和外部。任何設備或請求都不應該被信任，不管它們是否屬於企業網絡。所有的通信都應該以加密、認證和授權的方式進行，以保護數據的機密性，防止惡意行爲者從網絡中竊取數據。
2. 保障資源
資源可以是小型應用（服務或工作負載），可以向網絡內的其他應用發送流量。一個網絡可能由多個服務組成，每個服務將通過網絡使用 API 調用與其他服務對話，以執行某些業務功能和邏輯。在授予訪問權以發送處理請求之前，必須根據已建立的資源身份，對每個服務的信任進行評估。認證和授權檢查服務身份必須發生在一個會話中，而且服務不應該默認繼承對所有資源的訪問。
3. 確保用戶安全
對一個應用程序的威脅可能是由內部或外部用戶造成的。這就是爲什麼在授予訪問權之前要通過適當的認證來評估每個請求者的可信度。就像保護資源一樣，對用戶的訪問應該以完成任務所需的最小權限來授予，而且應該是基於會話的。當然，各種用戶會根據他們的角色獲得訪問權限。DevOps 團隊和安全部門應該謹慎地分配權限，定義角色，並對用戶進行治理，以避免安全和合規性威脅。
4. 最大限度地提高可見性
爲了實施零信任網絡，IT 安全組織必須不斷實時評估其 IT 環境的安全態勢，特別是微服務。爲了對任何安全事件做出反應，安全團隊必須配備適當的信息和可見性，以加快診斷和分流。應該有一個適當的機制，從企業網絡的資源中追蹤和隔離損壞的或脆弱的資源或用戶或設備。
Tetrate Service Bridge（TSB）如何幫助開箱即用？
Tetrate Service Bridge(TSB)[13] 通過一個與雲無關的集中式平臺爲所有從邊緣到工作負載的應用和 API 實現安全、敏捷和可觀察性。它爲平臺所有者提供所有環境的內置安全和集中的可見性和治理，同時授權開發人員爲其應用程序做出本地決定。
TSB 通過爲您的應用程序和雲平臺提供 FIPS 認證的構建，Istio 和 Envoy 的生命週期管理，以及其他增強功能以提高可用性，將 Istio 和 Envoy 增強爲企業級服務網格。
Tetrate Service Bridge（TSB）位於應用邊緣，負責控制所有計算集羣的請求級流量、多雲、Kubernetes 和傳統計算集羣之間的流量轉換，並提供南北 API 網關功能。TSB 還提供了一個帶有 NGAC[14] 框架的全局管理平面，以定義安全策略和配置，獲取遙測數據，並在整個網絡拓撲結構中處理 Istio 和 Envoy 的生命週期。有了 TSB，安全團隊可以將安全從應用代碼棧中剝離出來，放在屬於他們的透明網絡層中 —— 避免開發人員爲安全而耗費精力修改代碼。
DevOps 團隊仍然可以繼續執行他們的計劃，根據業務需求更快地將應用程序部署到多雲中，而安全方面可以對微服務的安全策略進行集中控制。讓我們看看 TSB 組件如何幫助實現安全。
微服務的零信任網絡的 Tetrate 實現
TSB 提供保護您的資源、網絡、用戶和最大限度地提高可見性。
1. 安全命名，用於服務間的授權，以確保資源安全
由於 Tetrate Service Bridge（TSB）建立在 Istio 上，默認情況下它提供安全命名，以確保工作負載（VM 和 Pod）屬於同一個微服務。TSB 爲每個工作負載（VM 或 Pod）創建服務身份，並將信息存儲在安全名稱信息中。服務器身份在證書中進行編碼，但服務名稱是通過發現服務或 DNS 檢索的。安全命名信息將服務器身份映射到服務名稱。從（例如）服務 A 到服務名稱 B 的身份映射意味着 "A 被授權與服務 B 對話”。
2. 基於 mTLS 的服務認證，確保網絡安全
TSB 提供 Istio 點對點認證資源，以驗證客戶端與安全工作負載的連接。它使你能夠通過 Envoy 代理在你的服務網格中實現 mTLS 認證，這是一個與每個服務一起工作的小應用程序（也被稱爲 sidecar 代理）。客戶端 Envoy 代理與服務端 Envoy 代理進行握手，只有當相互的 TLS 連接建立後，流量才從客戶端轉移到服務器端。
基於 mTLS 的認證被稱爲點對點（P2P）認證，不需要改變任何服務代碼。基於 mTLS 的 p2p 認證爲每個服務提供了一個強大的識別，以實現跨集羣和多雲的互操作性。安全管理人員現在可以在 TSB 管理平面中定義基於 mTLS 的認證策略，對網絡中的服務間的通信進行加密。有了安全的網絡，就沒有中間人攻擊的機會。
TSB 提供了一個證書管理系統，自動生成、分發和輪換私鑰和證書，以解密請求中的數據。
3. 基於 JWT 的認證，以確保來自內部和外部用戶的應用安全
對於終端用戶的認證，以驗證附加在請求上的憑證，TSB 提供現有的 Istio 資源（也稱爲請求認證）。安全管理人員現在可以利用 Istio 資源，通過驗證 JSON 網絡令牌（JWT）來驗證憑證。該令牌將有令牌的位置、發行者的詳細信息和公共 JSON 網絡密鑰集。安全經理可以根據他們的組織標準指定認證策略和規則，TSB 將根據令牌與策略的匹配程度拒絕或接受用戶請求。
由於 TSB 全局管理使用 Istio，它提供了靈活性，可以與您選擇的認證供應商連接，如 OpenID Connect 供應商，例如，KeyCloak、OAuth 2.0、Google Auth、Firebase Auth 等。
4. 對安全資源和用戶進行訪問控制的授權策略
TSB 授權策略允許安全經理創建跨服務網格、命名空間和工作負載的訪問控制。比如說，一個真實的用戶已經進入了一個系統，但是應該限制他在該系統下采取任何行動。
安全經理現在可以使用單一資源定義工作負載之間和最終用戶之間授權的細化規則（如允許、拒絕或自定義請求）；易於使用和維護。最重要的是，TSB 中的 Istio 授權策略支持通信框架，如 gRPC、HTTP、HTTPS 和 HTTP/2、TCP。
5. 可觀察性和實時可見性
Tetrate Service Bridge（TSB）允許安全管理人員主動監控和測量微服務的完整性和安全態勢。TSB 控制平面產生運行時遙測數據，幫助安全人員、網絡管理員和 SRE 不斷跟蹤服務的行爲。除了生成指標，TSB 還提供運行時的可觀察性，如每個服務的流量和服務依賴關係。TSB 管理平面提供對信息的可見性，如誰被授權使用什麼服務，什麼被加密等。
安全團隊現在可以看到每個服務是如何與其他服務互動的，在發生惡意攻擊的情況下，他們可以迅速隔離被破解的應用程序，以免損害其聲譽，然後準備發佈補丁。此外，TSB 爲選定的時間段生成審計日誌，提供每個訪問信息的方式、內容、時間和地點的完整視圖。審計日誌幫助審計人員和安全經理追蹤潛在的安全漏洞或任何違反策略的行爲，並幫助迅速找到問題的根源。
總結
如果安全團隊能夠保護網絡，在每筆交易中驗證服務和用戶的身份，並獲得 360 度的可見性，以便在發生事故時做出更快的反應，他們就達到了微服務的零信任。通過零信任架構，安全團隊可以消除從網絡中竊取數據（用戶憑證、網絡訪問和橫向移動能力）的風險。另一方面，終端用戶可以獲得一致的、穩定的，更重要的是安全的體驗，無論他們在什麼地方，使用什麼終端，或者他們的應用程序是在企業內部還是在雲中。
如果你對此感興趣的話，你可以：
• 註冊參加即將舉行的關於 ZTA 和雲原生應用的 DevSecOps 的 [15] 安全會議 • 閱讀更多關於 TSB 提供的服務 [16] 如何 幫助您在微服務中實現零信任的信息 [17]• 下載我們的白皮書，瞭解 [爲什麼使用 Istio 服務網格來實現零信任安全
引用鏈接
[1] Zero Trust Network for Microservices: https://www.tetrate.io/blog/zero-trust-network-for-microservices/
[2] 點擊下載零信任架構白皮書: https://www.tetrate.io/white-paper-zero-trust-architecture/
[3] 最近的研究結果: https://www.verizon.com/business/resources/reports/dbir/2021/masters-guide/
[4] 2021 年 RedHat 的報告: https://www.redhat.com/en/resources/kubernetes-adoption-security-market-trends-2021-overview
[5] 竊取數據和計算能力: https://www.zdnet.com/article/hacker-target-kubernetes-to-steal-data-and-processing-power-now-the-nsa-has-tips-to-protect-yourself/
[6] Kubernetes 安全狀況: https://www.redhat.com/en/blog/state-kubernetes-security
[7] 美國國家標準與技術研究所（NIST）: https://www.nist.gov/news-events/events/2022/01/zta-and-devsecops-cloud-native-applications-virtual
[8] 微服務的安全策略: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf
[9] 使用服務網格構建安全的微服務: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204A.pdf
[10] 使用服務網格的基於屬性的微服務訪問控制: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204B-draft.pdf
[11] 使用服務網格實現微服務的 DevSecOps: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204C-draft.pdf
[12] 零信任架構: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
[13] Tetrate Service Bridge(TSB): https://www.tetrate.io/tetrate-service-bridge/
[14] NGAC: https://www.tetrate.io/blog/unpacking-next-generation-access-control-ngac-and-tetrate-q/
[15] ZTA 和雲原生應用的 DevSecOps 的: https://www.tetrate.io/zta-devsecops-conference-2022/
[16] TSB 提供的服務: https://www.tetrate.io/zero-trust/
[17] 幫助您在微服務中實現零信任的信息: https://www.tetrate.io/zero-trust/
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/OeRgmmh9_igz6zZx0xh47g