原文出自：CNCF（云原生基金會）Blog

原文作者：Giri Radhakrishnan

在機器學習 (ML) 和人工智能 (AI) 技術的幫助下，數(shù)據(jù)分析領域微服務架構的采用率大幅上升。容器在機器學習 (ML) 開發(fā)人員中流行的一些原因，是得益于容器易于移植、可擴展性強以及可以使用服務（特別是網(wǎng)絡服務）快速訪問數(shù)據(jù)。隨著云原生應用程序的興起，尤其是在大數(shù)據(jù)分析領域，使得這些應用程序成為了網(wǎng)絡犯罪的主要目標。

防止威脅參與者破壞網(wǎng)絡并訪問關鍵數(shù)據(jù)或應用程序，這對于個人開發(fā)者或者一個團隊來說都是一項艱巨的任務。DevOps 和安全工程師、SRE 和平臺架構師都需要共同努力來促進這一過程。這些團隊通常面臨兩方面的挑戰(zhàn)：

1. 由于微服務的基本架構模型是分布式的，因此必須存在東西向流量。在大多數(shù)使用多云或混合模型的常見部署中，沒有真正的網(wǎng)絡邊界。

2. 一個或多個微服務將訪問第三方云服務、API 和應用程序等外部服務，從而為南北流量產(chǎn)生多個入口/出口點。

接下來，本文將會介紹IT架構不得不了解的有關云原生工作負載零信任的知識，以及云原生零信任與傳統(tǒng)的零信任網(wǎng)絡有何不同。

什么是零信任？

使用各種方法來保護傳統(tǒng)工作負載，包括為每個區(qū)域使用具有不同防火墻規(guī)則的安全區(qū)域、通過訪問列表過濾流量以及使用虛擬專用網(wǎng)絡 (VPN) 進行遠程訪問……所有這些方法都在一個共同的假設下運行，那就是——內部網(wǎng)絡是可信的；而外網(wǎng)不是。對于外網(wǎng)而言，這種安全思考方式顯然是存在問題的，并且會導致許多外部和內部威脅，例如數(shù)據(jù)泄露，以及橫向威脅，例如惡意軟件和勒索軟件等。

最終，我們將會意識到需要一種不同的方法，這便產(chǎn)生了零信任網(wǎng)絡的概念——沒有任何東西是可信的，而且一切都必須得到驗證（持續(xù)驗證，從未信任）。大約十年前，行業(yè)分析師和安防公司共同認為，零信任是抵御不良行為攻擊的最佳方法。支持的形式是美國聯(lián)邦政府提交行政命令，要求各機構在 2024 財年末之前滿足某些符合零信任成熟度模型的網(wǎng)絡安全標準。

公開資料解釋：零信任是一種安全模型，它對嘗試訪問網(wǎng)絡及其資產(chǎn)的任何用戶、服務或設備進行嚴格驗證。

基于 CISA（網(wǎng)絡安全和基礎設施安全機構）成熟度模型的零信任的核心支柱是：

· 身份 - 持續(xù)驗證（密碼、多因素身份驗證）

· 設備 - 合規(guī)執(zhí)法

· 網(wǎng)絡/環(huán)境—— 宏觀或 微觀分段

· 應用程序工作負載—— 基于訪問的控制

· 數(shù)據(jù) – 最小權限，加密

云原生工作負載的零信任

在云原生環(huán)境中，保護和監(jiān)控單個 pod 或節(jié)點是一項挑戰(zhàn)。當虛擬機 (VM) 取代舊式服務器時，配置防火墻仍然相當容易，因為這些虛擬機本質上大多是靜態(tài)的。但是微服務的細粒度組件（例如 pod）是動態(tài)的并且是短暫的——有時只有幾分鐘的生命周期——并且對于單體應用程序具有的相同類型的工作具有更大的占用空間（增加的攻擊面）。假設您已經(jīng)通過在每個節(jié)點或 pod 周圍放置防火墻來解決保護這些小型工作負載的問題。威脅可能仍潛伏在您的網(wǎng)絡中，源自內部。

云工作負載的零信任強制對任何進出工作負載的訪問都將進行嚴格驗證。

當您考慮為云原生工作負載設計安全策略有多么困難時，唯一合乎邏輯的解決方案就是遵循云原生應用程序的構建方式。使用 IP 地址創(chuàng)建區(qū)域和策略的外圍防火墻構建零信任網(wǎng)絡永遠不會奏效，因為當 pod 重新啟動時地址會不斷變化。Kubernetes 和其他基于容器的解決方案本質上是聲明性的（即任何配置更改都由代碼處理），并且策略基于標簽或 DNS，而不是 IP 地址。使用相同的原則，安全專業(yè)人員可以使用云原生程序針對他們的安全用例實施策略。

應該從哪里開始設計構建零信任模型？

要了解從哪里開始以及如何為基于 Kubernetes 或容器的設計構建零信任模型，企業(yè)需要確定網(wǎng)絡的保護面（對企業(yè)最有價值的東西）并了解其攻擊面。零信任背后的理念是保護關鍵業(yè)務資產(chǎn)，包括客戶數(shù)據(jù)。

為了了解企業(yè)的攻擊面，企業(yè)需要查看企業(yè)的應用程序以及相關的通信和訪問。對于云原生應用程序，每個微服務不僅需要與集群內的其他微服務通信，而且在某些情況下還需要與外部服務（例如，SaaS 服務、API 或駐留在私有數(shù)據(jù)中心的應用程序）進行通信。

當談到 Kubernetes 集群內的網(wǎng)絡連接時，默認情況下所有 pod 都可以相互通信。一個好的安全原則是識別每個工作負載的功能，這就是 DevOps 最佳實踐派上用場的地方。現(xiàn)在我們已經(jīng)根據(jù)身份（微服務的功能，例如 storefront-compliance）確定了要提供授權和訪問的組件，下一步是創(chuàng)建最小權限訪問的策略。這將確保只有某些工作負載可以與某些其他工作負載通信，并根據(jù)端口、服務帳戶等驗證一組相關條件。（持續(xù)驗證，從未信任）

我們通過這個過程所取得的成果便是，能夠在發(fā)生安全漏洞時有效地減少攻擊面。我們對從工作負載發(fā)送到工作負載的流量的控制越多，當需要隔離受感染的工作負載時，我們對惡意軟件的橫向移動的控制就越多。

-------------------

有關云原生更多技術干貨，請獲取《2022云原生技術應用情況調研報告》，點擊下方鏈接免費下載>>

https://www.cloudtogo.cn/whitepaper/203.html?B=lingxinren