執(zhí)行摘要

目的

云原生的開發(fā)和部署模式已經(jīng)成為業(yè)界趨勢，技術(shù)、產(chǎn)品、標準和解決方案的生態(tài)系統(tǒng)也在同步的擴張之中，決策者面臨著跟進復(fù)雜設(shè)計的挑戰(zhàn)。CISO 要在這個動蕩的戰(zhàn)場中實踐業(yè)務(wù)價值，這個角色顯得尤為重要。云原生模式鼓勵消費模式的變化，和采用需要集成安全實踐的現(xiàn)代工作流程（如敏捷方法和 DevOps）。

問題分析

面對快速開發(fā)和部署的迫切需要，基于邊界的傳統(tǒng)安全保障顯得力不從心。傳統(tǒng)安全方法偏重于對邊界進行保護，而更復(fù)雜的云原生應(yīng)用則傾向于識別動態(tài)工作負載中的屬性和元數(shù)據(jù)來進行保護，這樣才能為應(yīng)用的模式轉(zhuǎn)換保駕護航。這種方式能對工作負載進行識別和保護，以此適應(yīng)云原生應(yīng)用的規(guī)模擴展以及快速變化的需要。模式的轉(zhuǎn)變要求使用面向安全的架構(gòu)設(shè)計（例如零信任），并且在應(yīng)用安全生命周期中采用更多的自動化方法。作為云原生環(huán)境的典型特征，容器化也需要最新的最佳實踐。安全措施的變更會觸及組織內(nèi)的多個利益方，并且會對開發(fā)和運維人員的生產(chǎn)力造成影響，因此其權(quán)衡過程會持續(xù)存在。云原生應(yīng)用并沒有跳出開發(fā)、發(fā)布、部署和運維的圈子，但是新的模式需要新的安全機制，從而保障（新方式下）能夠保障這些環(huán)節(jié)目標的達成。云原生應(yīng)用的生命周期可以建模為開發(fā)、發(fā)布、部署和運行時這樣幾個不同的階段。和傳統(tǒng)安全方法相比，云原生安全有機會在不同的階段注入各自的安全保障，而不是用獨立的安全措施來干預(yù)應(yīng)用的生命周期。需要指出的是，需要針對這些概念的使用和整合、相關(guān)工具和流程的教育和培訓(xùn)，云原生的落地和應(yīng)用可能難以為繼，甚至被打回原形。

生命周期

開發(fā)

對云原生應(yīng)用來說，建議在應(yīng)用生命周期的早期就引入安全保障。盡早地使用安全測試來識別合規(guī)和配置的相關(guān)問題，從而為持續(xù)改進提供快速、可操作的反饋流程。這種方式能夠使用同樣的工作流程來處理安全問題和 Pipeline 中的其它常規(guī)問題（例如 Bug 修復(fù)或者 CI 失敗）。這種模型中使用的現(xiàn)代的安全方法符合設(shè)計模式（例如 12 要素）要求，并且能保障交付過程的完整性。云原生的概念和 IaC（基礎(chǔ)設(shè)施即代碼）的實踐密不可分，以此確保能夠在早期進行安全檢查后，按照預(yù)期執(zhí)行。這樣的過程能夠識別錯誤配置，并可以盡早在 IaC ?和編排清單中實施最佳實踐，從而降低長期成本并提高安全價值。

發(fā)布

軟件供應(yīng)鏈安全在快速的軟件迭代過程中尤其重要。云原生應(yīng)用的完整性保障不僅針對工作負載自身，還需保證其創(chuàng)建和運維過程的完整性。對于開源軟件和第三方應(yīng)用的強依賴加劇了這方面的要求。Pipeline 生產(chǎn)的制品（例如容器鏡像）需要持續(xù)地進行自動掃描和更新，從而避免遭受漏洞、惡意軟件、危險代碼以及其它不當(dāng)行為的侵害。完成這些檢查之后，應(yīng)該對制品進行簽名來保障其完整性和不可否認性。

部署

在開發(fā)和發(fā)布過程中集成的安全性能夠?qū)蜻x工作負載的屬性進行實時的持續(xù)的驗證（例如制品簽名的驗證、容器鏡像和運行時的安全策略等）。隨安全的工作負載同時部署的可觀察性支持，提供了對日志和指標的支持，進一步完善了安全保障的覆蓋面積。

運行時

云原生運行環(huán)境應(yīng)提供策略和資源限制功能。對工作負載進行運行時資源限制（例如 Linux 的 cgroup 隔離）就是一個在云原生環(huán)境中進行限制和可觀察性的原語的例子。可以把云原生運行時環(huán)境分解為具備不同安全問題的關(guān)聯(lián)的組件層（例如硬件、主機、容器鏡像運行時和編排）。

在云原生環(huán)境中，普遍采用了微服務(wù)架構(gòu)。應(yīng)用通常會由獨立且目標單一的微服務(wù)組成，這些微服務(wù)需要通過服務(wù)層進行通信，容器編排層完成了這一任務(wù)。這種相互糾纏的組件架構(gòu)下，安全方面的最佳實踐包括只有被許可的進程才能在容器的命名空間內(nèi)運行、預(yù)防和告知未經(jīng)授權(quán)的資源訪問、以及能夠感知惡意行為的網(wǎng)絡(luò)監(jiān)控。服務(wù)網(wǎng)格是另一個常見的抽象，它在避免對工作負載進行變更的情況下，為被編排的服務(wù)提供了加固和補充的功能（例如 API 流量日志、傳輸加密、認證、授權(quán)以及可觀察性等）。

建議

相對傳統(tǒng)安全模型，云原生安全同樣要對盡職性、完整性、信任關(guān)系以及威脅防范提供支持，在此基礎(chǔ)之上還加入了臨時性、分布式和不可變設(shè)施的現(xiàn)代概念。在這種快速變化的環(huán)境中，要在迭代中實現(xiàn)與開發(fā) Pipeline 自動同步的安全保障才能防止迭代失敗。組織必須對這些核心安全概念進行學(xué)習(xí)分析和應(yīng)用，避免在應(yīng)用加固和環(huán)境管理方面的落后；需要對相關(guān)的第三方執(zhí)行同樣的標準；并對其云功能和安全支持方面的員工進行持續(xù)的教育和培訓(xùn)。因為復(fù)雜性的增加和組件的復(fù)雜關(guān)系，必須通過在整個生命周期和運行環(huán)境中整合安全保障能力來制止未授權(quán)訪問。強烈建議組織根據(jù)攻擊框架[^2]來確認安全堆棧的覆蓋面。另外組織還可以采用安全左移[^3]的方式，擴大 DevOps 的能力，在 Pipeline 執(zhí)行之前、之中和之后進行持續(xù)、適用的檢查，對進入生命周期的任何新東西進行校驗。

結(jié)論

如果一個組織以戰(zhàn)略的高度重視云原生安全的落地工作，能夠在大規(guī)模情況下提供高可用、可信、韌性和冗余的應(yīng)用能力，保證客戶和開發(fā)者能夠以他們期望的效率，安全地訪問所需資源。安全是一個跨學(xué)科領(lǐng)域，并不能獨立于開發(fā)之外，也不僅僅局限在技術(shù)范疇。開發(fā)、運維和安全人員都必須緊密交流和協(xié)作，推動該領(lǐng)域的持續(xù)進步。與任何技術(shù)創(chuàng)新一樣，真正使社區(qū)和云原生安全成為可能的是人。

簡介

本文嘗試讓組織及其技術(shù)領(lǐng)導(dǎo)者能夠清晰地理解云原生，從而能夠?qū)⑵浼{入原有生命周期，并確定其應(yīng)用方式。云原生安全是一個覆蓋多個專業(yè)技術(shù)和實踐領(lǐng)域的多目標、多約束的問題空間。在初期運維過程中有很多工作都和安全領(lǐng)域重疊，例如身份管理和存儲方案。然而云原生安全的覆蓋面遠不止于此，它還是一個關(guān)系到人本身的問題空間，其中包含了個人、團隊以及組織。它是一種機制和流程，人類和系統(tǒng)借此進行交互，對云原生應(yīng)用和技術(shù)造成深遠影響。

目標讀者

我們的目標讀者是希望交付安全云原生技術(shù)生態(tài)的企業(yè)、政府機構(gòu)以及非營利組織的首席安全觀(CSO)、首席信息安全觀 (CISO) 或者 首席技術(shù)官 (CTO) 。其它的組織利益相關(guān)方，包括負責(zé)設(shè)計實現(xiàn)安全云原生產(chǎn)品和服務(wù)的項目經(jīng)理、產(chǎn)品經(jīng)理和架構(gòu)師。當(dāng)然其他對云原生安全有興趣的人也都可以參考本文。

云原生的目標

包括容器和微服務(wù)架構(gòu)在內(nèi)的新技術(shù)的采用和創(chuàng)新帶來了新的挑戰(zhàn)。現(xiàn)代組織中，安全需求的優(yōu)先級已經(jīng)大幅提升。圍繞云原生技術(shù)的加速創(chuàng)新，威脅范圍也在擴大。安全領(lǐng)導(dǎo)者要負責(zé)保護人力[^4]和非人力的資產(chǎn)，要在滿足嚴格合規(guī)性要求的同時，采取措施來預(yù)防、檢測和對應(yīng)安全問題。一個老生常談的埋怨就是，安全措施降低了 DevOps 團隊的速度和敏捷性。因此安全領(lǐng)導(dǎo)層必須（和 DevOps 團隊）進行更緊密的合作并增進雙方的理解，讓 DevOps 團隊也能同樣共享網(wǎng)絡(luò)風(fēng)險方面的所有權(quán)。

企業(yè)需要采用的安全云原生模式和架構(gòu)必須進行分享，確保業(yè)界能夠用更高優(yōu)先級來實施安全實踐，并將其集成到現(xiàn)代應(yīng)用生命周期之中。強調(diào)安全架構(gòu)和安全行業(yè)領(lǐng)導(dǎo)者的協(xié)同作用，并在漏洞管理、零信任、云安全和 DevSecOps 等方面調(diào)整組織的架構(gòu)目標，這是當(dāng)務(wù)之急。

本文中的概念是具備普遍性的，并不偏向于特定的組件或者服務(wù)。

但是這里并不會對安全和云原生方面的基本概念進行掃盲，也不會推薦特定的技術(shù)和工具，當(dāng)然，敘述過程中可能會使用一些相關(guān)工具被列舉在相關(guān)專題中，或者進行示例。

除了本文中的建議之外，與數(shù)據(jù)和隱私保護（例如 GDPR、PCI DSS）的相關(guān)內(nèi)容需要額外的監(jiān)管相關(guān)的方面進行考慮。建議讀者另行尋找相關(guān)咨詢資源對這方面的技術(shù)控制和合規(guī)風(fēng)險提供支持。

假設(shè)

CNCF 在 CNCF 技術(shù)監(jiān)督委員會（TOC）的 GitHub 倉庫中提供了云原生的定義。本文不會改變這一定義或?qū)ζ溥M行擴展。

云原生的落地和現(xiàn)代軟件開發(fā)方法論都在持續(xù)演進之中。構(gòu)成云原生技術(shù)棧的技術(shù)也會隨著時間的推移不斷變化。云原生 Landscape 中會持續(xù)支持這個不斷變化的技術(shù)棧。

本文中出現(xiàn)的工作負載這個詞，代表已經(jīng)或者將要開發(fā)、運維、發(fā)布以及部署到基于云的運行時環(huán)境的任何產(chǎn)品、項目、應(yīng)用或者系統(tǒng)。

云原生的層次

圖 1

云原生技術(shù)棧由基礎(chǔ)、環(huán)境和生命周期構(gòu)成。云原生技術(shù)棧可能用不同的模型（例如 IaaS、PaaS、CaaS 或者 FaaS）進行部署。每一種模型都提供了各自的抽象，以此來簡化云原生環(huán)境的管理和運維。這些模型中有一些是已經(jīng)廣為人知并被廣泛采用，我們會聚焦在云原生特有的模型上。

CaaS（容器即服務(wù)）模型讓用戶通過基于容器的虛擬化平臺及其 API 或者 Web 管理界面對容器、應(yīng)用和集群進行編排和其它管理工作。CaaS 幫助用戶構(gòu)建容器化應(yīng)用，其中內(nèi)置以代碼方式表達的安全策略，這些應(yīng)用能運行在私有云、自建數(shù)據(jù)中心和公有云上。CaaS 有助于簡化容器的構(gòu)建過程。有了微服務(wù)的編排和部署，CaaS 幫助企業(yè)更快地發(fā)布軟件，并且具備在混合云、多云環(huán)境下的移植性，同時還降低了基礎(chǔ)設(shè)施和運維成本。CaaS 模型之所以能節(jié)約成本，是因為它能夠幫助企業(yè)簡化容器管理，并給企業(yè)僅為實際的 CaaS 需求買單的選擇。CaaS 以容器為基礎(chǔ)資源，而 IaaS 環(huán)境中的基礎(chǔ)資源則是虛擬機和裸金屬。

FaaS（功能即服務(wù)）是另一種云原生部署模型，它是一種云原生服務(wù)的形態(tài)，讓企業(yè)用戶能夠根據(jù)事件來觸發(fā)代碼的執(zhí)行，避免了構(gòu)建運行微服務(wù)的復(fù)雜的基礎(chǔ)設(shè)施管理工作。在云上運行應(yīng)用通常提供虛擬環(huán)境，管理操作系統(tǒng)和 Web 組件等。有了 FaaS 之后，物理硬件、主機操作系統(tǒng)以及 Web 服務(wù)器軟件管理都由云服務(wù)提供商自動支持。這樣一來，用戶就能專注于單獨的微服務(wù)功能代碼，并且只需要向云服務(wù)商用彈性的方式支付資源的實際使用費用。

生命周期

云原生語境下的生命周期指的是在云環(huán)境下，幫助實現(xiàn)有韌性、可管理、可觀測的工作負載的技術(shù)和實踐。如圖一所示，生命周期由四個持續(xù)階段構(gòu)成：開發(fā)、發(fā)布、部署和運行時。每個階段都是前一個階段的擴展和放大，同時要放行安全工作負載的運行，并提供相應(yīng)支持。

生命周期過程

對于安全實現(xiàn)來說，供應(yīng)鏈的管理和合適的安全基線是非常重要的。

供應(yīng)鏈

組織有責(zé)任確保它們開發(fā)的工作負載的供應(yīng)鏈能夠接受可操作的安全分析。供應(yīng)鏈安全可以分為兩個部分：為創(chuàng)建工作負載供應(yīng)支撐環(huán)境的服務(wù)和工具（開發(fā)工具）的安全，以及組成工作負載的組件（例如庫、依賴和鏡像）的安全。供應(yīng)鏈必須以能夠接受檢查的方式來構(gòu)建，軟件供應(yīng)鏈輸出的制品也應(yīng)該能夠使用簽署的方式確認來源。為保障依賴項的正常運行并阻止可能的破壞行為，對第三方包的真實性和完整性進行校驗非常必要。

云原生應(yīng)用的一個顯著特征就是軟件復(fù)用，這些軟件可能以軟件包或容器鏡像的方式，通過開源倉庫進行構(gòu)建和分發(fā)。正因如此，對于開發(fā)、運維和安全人員來說，確保應(yīng)用中的制品和依賴不包含已知的惡意軟件和缺陷是個必要工作。容器鏡像可能包含的惡意軟件，很明顯會威脅到運行時環(huán)境[^5]。在持續(xù)集成過程中和容器倉庫中進行周期性掃描和按需掃描能夠有效防范這些問題。

使用這些手段實現(xiàn)可檢測的、安全的軟件發(fā)布和運維操作。在工作負載的產(chǎn)生過程中進行威脅檢測讓組織能夠快速向開發(fā)團隊進行反饋，并阻止不安全的或有漏洞的更新被發(fā)布和部署。對現(xiàn)存軟件進行周期性的掃描，能夠發(fā)現(xiàn)新公布的問題，從而避免其造成危害。

安全基準

安全基準（例如 NIST Application Security Container Guide、 Center for Internet Security (CIS), NIST Security Strategies for microservices 以及 OpenSCAP）為開發(fā)團隊和組織提供了創(chuàng)建“缺省即安全”的工作負載的指引。采納并實現(xiàn)這些安全標準，讓團隊能夠基于加固的基線進行測試。然而這些基準無法深入數(shù)據(jù)流，也無法干涉平臺的用法。因此這些內(nèi)容應(yīng)該作為一個指南，而非檢查表。

接下來的幾節(jié)將詳細分析在整個應(yīng)用程序生命周期中集成安全的意義、工具、機制和最佳實踐。

開發(fā)

圖 2

云原生應(yīng)用的安全需要體現(xiàn)在應(yīng)用的整個生命周期之中。開發(fā)環(huán)境是這個周期的第一個環(huán)節(jié)，這個環(huán)節(jié)輸出的是制品，例如 IaaS、應(yīng)用和容器清單等，這些制品會被用于云原生應(yīng)用的部署和配置。經(jīng)驗表明，這些制品會是多種攻擊的來源。接下來的內(nèi)容會介紹這個階段里需要介紹多種工具、流程和檢查過程，以此減少運行時應(yīng)用程序的攻擊面。

開發(fā)過程中的安全檢查

在應(yīng)用開發(fā)過程中的安全加固是一個重要環(huán)節(jié)。安全需求也是需求的一部分，應(yīng)該盡早在軟件開發(fā)過程中進行引入。安全需求通常是圍繞業(yè)務(wù)的風(fēng)險和合規(guī)性進行的。這些需求如果不在早期進行處理，而是在生命周期的后續(xù)才開始進行的話，就會拖慢 DevOps 過程，提高總體成本。DevOps 團隊還需要使用專門工具在這些應(yīng)用的部署之前對危險配置和漏洞進行檢測。這些工具應(yīng)該無縫集成到 DevOps 團隊現(xiàn)有的熟悉的工作鏈之中，在不阻礙敏捷性的同時，提高安全性。例如可以在開發(fā) IDE 中或者創(chuàng)建 PR 的時候?qū)?IaaS 模板以及應(yīng)用清單文件進行掃描，并生成豐富的上下文相關(guān)的安全信息，開發(fā)團隊就能夠盡早、迅速、輕松地采取行動。加入這些步驟后能夠避免已知漏洞和高危配置。云原生組件應(yīng)該是 API 驅(qū)動的，被編排的業(yè)務(wù)應(yīng)用能夠和復(fù)雜的調(diào)試工具進行交付。

團隊應(yīng)該部署獨立的開發(fā)、測試和生產(chǎn)環(huán)境，從而為應(yīng)用開發(fā)者提供隔離的設(shè)施，對基礎(chǔ)鏡像、容器、應(yīng)用、虛擬機鏡像以及進行開發(fā)、測試和部署。有些組織可能已經(jīng)在嘗試金絲雀部署和藍綠部署。以及其他部署模型在現(xiàn)場進行動態(tài)和交互測試，以此進一步提高效率。

測試方案的開發(fā)

開發(fā)、運維和安全人員應(yīng)該為關(guān)鍵業(yè)務(wù)、有高危特征、變化頻繁或具有歷史問題的代碼和基礎(chǔ)設(shè)施建立測試方案。威脅建模可以識別高風(fēng)險和高影響的代碼熱點，提高開發(fā)測試的投資回報率（ROI）。測試對象可以包括部署、操作系統(tǒng)、基礎(chǔ)設(shè)施和數(shù)據(jù)庫加固、應(yīng)用測試（靜態(tài)和動態(tài)源碼測試、容器配置）、集成或系統(tǒng)測試（應(yīng)用程序和基礎(chǔ)設(shè)施組件及其交互的驗收）和冒煙測試（針對實時系統(tǒng)的部署后檢查）。測試作者應(yīng)該能夠全面地訪問開發(fā)和測試環(huán)境，從而能夠快速地開發(fā)測試方案，同時減少持續(xù)集成（CI）反饋循環(huán)次數(shù)。作者應(yīng)該能在本地和共享測試環(huán)境中運行系統(tǒng)測試套件。

代碼評審

對工作負載或基礎(chǔ)設(shè)施的細微變更可能引發(fā)意料之外的安全問題。為減少風(fēng)險，建議合并 PR 之前應(yīng)用四眼原則進行評審。

發(fā)布

圖 3

這個階段會使用鏡像定義和規(guī)范來構(gòu)建后續(xù)步驟的制品，例如容器鏡像、虛擬機鏡像等。在現(xiàn)代 CI/CD 語境下，發(fā)布階段中包含了系統(tǒng)性的應(yīng)用測試，以此識別軟件中的 Bug 和故障。然而對開源軟件和包的復(fù)用，有可能會把安全威脅引入到制品之中。為了防止這種情況，需要對制品進行掃描，并驗證其完整性，防止發(fā)生篡改。后續(xù)內(nèi)容會為開發(fā)和運維人員介紹識別和保護容器鏡像、CI/CD 流水線的工具、技術(shù)以及基礎(chǔ)設(shè)施。還可以對制品進行加密來滿足額外的保密需求。

如果遭遇泄密等問題導(dǎo)致制品不可信，應(yīng)對密鑰進行更換并重新簽署。

構(gòu)建流水線

不同安全級別和敏感性的項目，應(yīng)對 CI 服務(wù)器應(yīng)進行分別的隔離和保護。需要提權(quán)的基礎(chǔ)設(shè)施構(gòu)建應(yīng)在專用的持續(xù)構(gòu)建服務(wù)上運行。編排器應(yīng)該為流水線創(chuàng)建和執(zhí)行構(gòu)建策略。

供應(yīng)鏈工具可以對流水線的元數(shù)據(jù)進行搜集和簽名。后續(xù)步驟能夠?qū)灻M行檢查，并借此確信前面的步驟已經(jīng)完成。

讀者要確保 CI/CD 設(shè)施的安全。例如及時進行安全更新，并通過硬件安全模塊或者憑據(jù)管理器對密鑰進行保護，防止泄露。

鏡像掃描

鏡像掃描是應(yīng)用鏡像生命周期中的重要步驟。在把鏡像部署到生產(chǎn)環(huán)境之前對其進行掃描是非常必要的。具備了這一能力之后，開發(fā)、運維和安全人員就能夠獲知已知問題的詳細信息例如嚴重性、CVSS 評級以及對應(yīng)的補救和修復(fù)措施。將容器漏洞掃描和流水線的合規(guī)規(guī)則結(jié)合在一起，能夠確保僅有打過合適補丁的應(yīng)用能夠部署到生產(chǎn)環(huán)境，從而降低攻擊風(fēng)險。容器掃描還能幫助識別開源軟件包和基礎(chǔ)鏡像中可能存在的惡意軟件。鏡像掃描僅是對現(xiàn)狀的識別而非預(yù)防措施。組織需要謹慎選擇掃描工具、在合理的環(huán)節(jié)中進行調(diào)用，在合乎規(guī)則的情況下，提供可操作的輸出信息。

鏡像加固

容器鏡像是構(gòu)建管道的第一次輸出。因此必須對其進行安全加固，加固過程不僅需要考慮降低威脅，還要為整體環(huán)境下的應(yīng)用運行提供可配置的能力。

需要在安全保障目標中評估以下幾個問題：

• 執(zhí)行環(huán)境應(yīng)該限制到特定用戶么？

• 資源訪問應(yīng)該受限么？

• 需要在內(nèi)核級對進程執(zhí)行做限制么？

容易應(yīng)用清單掃描

應(yīng)用清單描述了部署容器化應(yīng)用所需的配置。正如在安全基準部分介紹的那樣，NIST 800-190 之類的材料中推薦了容器化應(yīng)用的最佳安全實踐和配置。可以在 CI/CD 中對清單進行必要的掃描。

容器化應(yīng)用清單的加固

和容器鏡像類似，容器應(yīng)用清單的加密也可以在構(gòu)建和運行時進行。

需要在安全保障目標中評估以下幾個問題：

• 滿足環(huán)境運行目標的最小化限制是什么樣的？

測試

云原生應(yīng)用應(yīng)該適用于傳統(tǒng)應(yīng)用相同的測試套件和質(zhì)量標準——例如代碼清潔、測試金字塔，為開發(fā)人員提供測試所需完整的基礎(chǔ)設(shè)施，通過靜態(tài)安全掃描（SAST）、依賴分析和掃描、動態(tài)應(yīng)用安全測試（DAST）（例如 Mocking）等，為安全和合規(guī)提供實時的保障能力。

確定了安全問題之后（例如錯誤的防火墻或路由規(guī)則），進行根本原因分析之后，如果認為它有可能重復(fù)發(fā)生的話，開發(fā)人員就應(yīng)該編寫一個自動化測試，防止問題卷土重來。在測試失敗時，團隊應(yīng)該收到反饋，改正 bug，試圖在下一次合并中通過測試。（有效的測試）能夠防范對同一段代碼的變更造成的問題復(fù)現(xiàn)。

基礎(chǔ)設(shè)施的單元測試是預(yù)防性措施，測試目標是基礎(chǔ)設(shè)施即代碼（IaC）配置中涉及的實體和輸入項。針對現(xiàn)存基礎(chǔ)設(shè)施的安全測試是一種檢測性控制，并包含了保障、歷史回歸和意外配置檢測（例如防火墻規(guī)則全面開放、過度授權(quán)的身份與訪問管理（IAM）策略、未認證的端點）等內(nèi)容。

基礎(chǔ)設(shè)施和工作負載的加固應(yīng)得到全面測試套件的支持，隨著系統(tǒng)的成熟，基礎(chǔ)設(shè)施和工作負載也能得到逐步加固。在構(gòu)建過程中應(yīng)該有對加固項目的測試，這些檢查也應(yīng)該在部署時執(zhí)行，以評估整個生命周期中可能發(fā)生的變化或回歸。

靜態(tài)分析和安全測試

IaC 和應(yīng)用清單、軟件代碼以及 IaC 的靜態(tài)分析過程可能包括對錯誤配置的識別和漏洞掃描。IaC 代碼應(yīng)該和應(yīng)用工作負載使用同樣的流水線策略控制。

IaC 日益流行，越來越多組織使用這種方式來進行云和容器基礎(chǔ)設(shè)施的部署，所以要警惕其配置問題可能暴露的攻擊面。

在進行應(yīng)用和基礎(chǔ)設(shè)施的部署之前，應(yīng)該對這些模板進行掃描，發(fā)現(xiàn)其中的不安全配置和其它安全問題。需要著重考慮的幾個方面：

• 應(yīng)用清單中包含的漏洞鏡像。

• 一些不當(dāng)配置（例如允許特權(quán)逃逸）。

• 安全上下文和系統(tǒng)調(diào)用可能對系統(tǒng)產(chǎn)生威脅。

• 資源限制。

動態(tài)分析

對已部署的基礎(chǔ)設(shè)施進行動態(tài)分析，可能包含 RBAC 和 IAM 配置的檢查，對網(wǎng)絡(luò)暴露面的校驗。確認 SOC 能夠在各個環(huán)境中生效。動態(tài)分析也應(yīng)該是測試的一環(huán)，應(yīng)該在非生產(chǎn)環(huán)境中運行。

安全測試

對應(yīng)用程序進行自動的安全測試是安全團隊的工作焦點之一。測試套件需要進行持續(xù)更新，和組織入侵模型一致，能夠?qū)ο到y(tǒng)進行持續(xù)的可復(fù)用的安全測試。自動化的安全測試避免了人工的檢查點控制，降低了時間消耗，提高了安全性和發(fā)布效率；自動化安全測試還能夠顯式的執(zhí)行安全威脅來按需展示控制能力，從而提高系統(tǒng)安全性，并保持合規(guī)性。

制品和鏡像

倉庫

開源組件經(jīng)常是從公共源中拉取的，組織應(yīng)在管線中為各個階段創(chuàng)建倉庫。只有認證的開發(fā)者能夠訪問共有倉庫，拉取基礎(chǔ)鏡像，基礎(chǔ)鏡像被保存到內(nèi)部倉庫，被組織中的團隊大量使用。不同的團隊或小組應(yīng)該使用獨立的私有倉庫來保存各自的開發(fā)中的制品，最后一個 Staging 或預(yù)生產(chǎn)倉庫用于保存用在生產(chǎn)環(huán)境里的鏡像。這種措施能更嚴格地控制開源組件的出處和安全性，同時可以對 CI/CD 鏈的各個階段進行不同類型的測試。

不管是什么倉庫，都必須通過專門的認證和權(quán)限模型實施訪問控制。對所有的連接都應(yīng)使用雙向 TLS。

簽名、信任和完整性

在構(gòu)建時對鏡像內(nèi)容進行簽名，在使用前對簽名進行校驗，能夠保證鏡像數(shù)據(jù)在構(gòu)建和部署之間不會被篡改，這樣就保證了制品的完整性和可信性。確認過程首先要表明一個制品是經(jīng)過審批的，還要驗證制品是否具有有效的簽名。在最簡單的情況下，每個制品都可以由一個簽名者簽名，表明制品通過了測試和驗證過程。然而多數(shù)情況下的軟件供應(yīng)鏈是比較復(fù)雜的，一個制品的構(gòu)建依賴于多個驗證步驟，因此需要有一組實體的認證。這方面的例子有：

• 容器鏡像簽名：對容器鏡像清單進行簽名的過程。

• 配置簽名：對配置文件進行簽名：GitOps 方式中很常見，能夠?qū)ε渲眠M行檢查和驗證。

• 包簽名：對一個制品包進行簽名。

對于通用軟件工件，如庫或 OCI 制品，簽名表示它們的來源是經(jīng)組織批準使用的。制品的簽名和驗證非常重要。強烈建議倉庫使用雙向認證，對倉庫中鏡像的變更或者提交代碼都需要進行認證。

加密

對容器鏡像進行加密，可以保證其數(shù)據(jù)的機密性，從構(gòu)建階段到運行階段，數(shù)據(jù)都是保密的。即使發(fā)布過程受損，鏡像內(nèi)容仍然是保密的。這種機制可以用于保護交易密文或者其它機密材料。

鏡像加密的還有一個使用場景就是對容器鏡像進行授權(quán)。當(dāng)鏡像加密與密鑰管理和/或授權(quán)和憑證分發(fā)相結(jié)合時，可以要求容器映像只能在特定平臺上運行。容器鏡像授權(quán)對于合規(guī)性使用案例非常有用，例如地理圍欄或出口控制和數(shù)字版權(quán)媒體管理。

部署

圖 4

The “Deploy” phase is responsible for incorporating a sequence of ‘pre-flight’ checks in order to ensure that the applications that are going to be deployed in the runtime environment conform and comply with organization wide security and compliance policies.

部署前置檢查

部署之前應(yīng)該對現(xiàn)狀進行調(diào)研，檢查以下狀態(tài)：

• 鏡像簽名和完整性。

• 鏡像的運行時策略（避免惡意軟件和嚴重缺陷）

• 容器運行時策略（例如避免權(quán)限過高）

• 主機漏洞和合規(guī)控制。

• 工作負載、應(yīng)用和網(wǎng)絡(luò)安全策略。

可觀察性和指標

把可觀察性和指標引入云原生架構(gòu)，能夠提高安全方面的觀察力，有助于解決和緩解異常情況；這個領(lǐng)域的工具能夠收集信息并進行可視化展示。如果加入行為和啟發(fā)式分析能力，團隊能夠檢測到可疑事件、不明調(diào)用等異常行為并進行上報。AI、機器學(xué)習(xí)以及統(tǒng)計模型都是促進行為分析和啟發(fā)式分析的手段。

應(yīng)對和調(diào)查

應(yīng)用應(yīng)該提供日志，對認證、鑒權(quán)、行為和故障進行記錄。開發(fā)人員應(yīng)該在計劃和設(shè)計階段就開始這些工作。這些要素構(gòu)成的證據(jù)鏈條，對于進行調(diào)查和根本原因跟蹤時會非常有幫助。

對事故的應(yīng)對和處理都需要進行取證，根據(jù)證據(jù)確定事件的根本原因，并為解決措施的實施提供反饋。容器環(huán)境的短暫性要求更靈活的工具集來對證據(jù)進行捕獲和分析。將取證功能集成到事件響應(yīng)計劃和程序中，將提供獲取和處理證據(jù)的方法，縮短確定根本原因的時間，并最大限度地減少損害風(fēng)險。

運行時環(huán)境

圖 5

運行時階段包括三個關(guān)鍵領(lǐng)域：計算、訪問和存儲。雖說運行時環(huán)境是依賴開發(fā)、發(fā)布和部署階段的成功完成，但運行時的安全性同樣取決于前幾個階段的安全實踐的有效性。以下各段將詳細介紹這些關(guān)鍵組件的安全要求和影響。

計算

云原生計算的復(fù)雜性很高，并且還在持續(xù)演進之中。如果核心組件沒有動用計算能力，組織就無法確保工作負載的安全。

Cloud native compute is a highly complex and continually evolving construct. Without core components to make compute utilization occur, organizations cannot ensure workloads are secure.

例如在共享主機上，用軟件虛擬化環(huán)境運行的容器化多租戶應(yīng)用，這里使用面向容器的操作系統(tǒng)是非常有益的，這種操作系統(tǒng)是只讀的，無關(guān)服務(wù)會被禁用。這樣就很好地減小了攻擊面；它還提供了隔離和資源限制，開發(fā)人員能夠在共享主機內(nèi)核上運行隔離的應(yīng)用程序。為了增加防御縱深，注意不要讓不同的數(shù)據(jù)敏感工作負載運行在同一個操作系統(tǒng)內(nèi)核上。

安全應(yīng)該貫穿容器平臺和服務(wù)的所有層級，可以使用可信平臺模塊（TPM）或虛擬TPM（vTPM）硬件作為信任鏈的根基。基于硬件的信任鏈可以擴展到操作系統(tǒng)內(nèi)核及其組件，以實現(xiàn)可信啟動、系統(tǒng)鏡像、容器運行時和容器鏡像等的加密驗證。

操作系統(tǒng)提供了 crypto 庫之類的系統(tǒng)組件，用于遠程連接、進程啟動、管理等的內(nèi)核函數(shù)。操作系統(tǒng)是容器的基礎(chǔ)，因此操作系統(tǒng)漏洞會影響到這些主機上運行的所有容器和應(yīng)用。同時配置不當(dāng)?shù)娜萜饕矔绊懙街鳈C內(nèi)核的安全，從而影響到該主機上運行的所有容器中的服務(wù)。

編排

任何編排系統(tǒng)都會有很多組件，這些組件被分成控制、數(shù)據(jù)之類的不同平面。有時會需要有上層建筑，負責(zé)在幾個不同的的相互獨立的控制平面上維持狀態(tài)。

編排系統(tǒng)都會面對威脅，這些威脅可能影響部署的整體安全性和運行時的持續(xù)安全性。惡意訪問編排 API、未經(jīng)授權(quán)訪問和更改鍵值存儲、編排器儀表板控制集群、攔截控制平面流量、API 濫用、攔截應(yīng)用流量等都是潛在的威脅領(lǐng)域。使用最佳實踐和加固配置來防止暴露在這些威脅中是很重要的[^7]。另外，對初始配置的任何更改都需要在運行時進行監(jiān)控和檢測，以確保集群的持續(xù)安全。其他的安全最佳實踐，如最小化對控制平面的管理訪問、職責(zé)分離和最小特權(quán)原則等，都應(yīng)該得到執(zhí)行。

安全策略

編排器的安全特性和各種配置選項必須認真對待，要對容器運行時所生成的容器的特權(quán)需要嚴加管控。使用高層次的策略和治理構(gòu)造可以強制執(zhí)行這些安全限制。

資源申請和限制

通過 cgroups 在不同的對象層級使用不同的資源請求和限制，有助于防止工作負載有意（如 Fork 炸彈攻擊或挖礦）或無意（如在內(nèi)存中讀取大文件而未進行輸入驗證、水平自動縮放導(dǎo)致計算資源耗盡）的耗盡節(jié)點和集群資源。

審計日志分析

審計日志分析是識別和關(guān)聯(lián)系統(tǒng)入侵、濫用或配置不當(dāng)?shù)淖畛墒旆椒ㄖ弧３掷m(xù)的地、自動化的對審計日志進行分析和關(guān)聯(lián)，對于安全團隊來說至關(guān)重要。和傳統(tǒng)應(yīng)用對比，云原生架構(gòu)能夠為工作負載生成更精細的審計配置，更方便進行過濾。對日志的過濾能力， 能夠避免下游處理機制的過載。與傳統(tǒng)的日志分析一樣，將日志中的數(shù)據(jù)關(guān)聯(lián)/上下文轉(zhuǎn)化為 “信息”，生成可操作的審計事件是重中之重，以此為基礎(chǔ)來觸發(fā)決策和進行事件響應(yīng)。

違反組織政策的行為，會根據(jù)預(yù)先配置的一套規(guī)則進行過濾和識別。

為了能夠?qū)κ褂眉旱膶嶓w的行為進行審計，啟用 API 審計并對特定 API 或者動詞進行過濾是很重要的。這些API 組或動詞是安全團隊、集群管理員或其他研究領(lǐng)域的團隊的工作重心之一。攻擊者可能會通過禁用日志或刪除其活動日志來掩蓋蹤跡，為了制止這種行為，應(yīng)盡快將日志轉(zhuǎn)發(fā)到通過集群級憑證無法訪問的位置。處理警報的系統(tǒng)應(yīng)定期對假陽性報告進行調(diào)整，以避免警報泛濫、疲勞，并防止假陰性情況的出現(xiàn)。

控制平面認證和根證書

管理員應(yīng)該配置所有的編排器控制平面組件，要求其使用雙向認證，并且用周期性輪轉(zhuǎn)的證書來進行認證，以此加固現(xiàn)有的控制平面。證書簽發(fā)使用的 CA 可以是編排器自己的 CA，也可以是外部的。管理員應(yīng)小心保護 CA 私鑰。

Secret 加密

在容器編排或者部署環(huán)境中，可以在外部管理器或者編排器內(nèi)部對 Secret 進行管理，介紹幾個不同的保護方法：

• 使用外部密鑰管理系統(tǒng)（KMS）加密

• KMS 是一種保護 Secret 的安全方式，這種方式中，密鑰在外部 KMS 中加密，KMS 會加密保存 DEK（Data Encryption Key），用 DEK 加密后的數(shù)據(jù)保存在 ETCD 中。這種方式有一個選項是把 DEK 緩存在內(nèi)存中，減少對外部 KMS 可用性的依賴，并更快的在創(chuàng)建 Pod 的時候進行解密。

• 完全用編排器管理加密

• 這種方式也會對 Secret 進行加密，但是密鑰也同樣由編排器管理。

• 不加密

• 例如某些編排器會用 Base64 對 Secret 進行編碼，然后直接存儲在鍵值庫中。

使用外部秘密管理器可以限制使用未加密的 Secret 的風(fēng)險，并降低密鑰管理工作的復(fù)雜性。多數(shù)情況下，這些工具會以 controller 或者 operator 的形式運行，從而在運行時透明地進行注入或者證書翻轉(zhuǎn)。

容器

運行時

容器運行時的監(jiān)控和保護，需要從進程、文件和網(wǎng)絡(luò)的角度入手。容器中只能使用被許可的 Capability 和系統(tǒng)調(diào)用（如 seccomp）。對于關(guān)鍵掛載點和文件的更改需要被監(jiān)控和阻止。對二進制文件、證書和遠程訪問配置的更改需要被制止，還應(yīng)保證容器僅執(zhí)行允許范圍內(nèi)的網(wǎng)絡(luò)訪問。此外，還應(yīng)檢測并拒絕指向惡意域的網(wǎng)絡(luò)流量。

微服務(wù)以及杜絕隱式信任

微服務(wù)方式部署的容器化應(yīng)用，其邊界就是微服務(wù)本身。因此定義策略限制特定微服務(wù)之間的通信是有必要的。0 信任微服務(wù)架構(gòu)能夠在微服務(wù)受到威脅時，禁止橫向移動，減少威脅半徑。運維人員應(yīng)該確保使用網(wǎng)絡(luò)策略之類的能力來對容器間通信進行限制，僅允許被授權(quán)的東西向訪問流量。NIST SP 800-204 中做了一些微服務(wù)安全策略的工作，可以作為實現(xiàn)安全微服務(wù)架構(gòu)的指南。

鏡像信任和內(nèi)容保護

組織可以使用策略引擎僅允許運行保障被授權(quán)和簽名的鏡像，從而實現(xiàn)可信的可控的工作負載。另外加密容器允許對容器中的敏感代碼、方法或者數(shù)據(jù)進行保護。

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

服務(wù)網(wǎng)格在服務(wù)之間進行連接，并在連接中加入了流量控制、服務(wù)發(fā)現(xiàn)、負載均衡、韌性、可觀測性、安全性等額外能力。服務(wù)網(wǎng)格中的微服務(wù)無需在應(yīng)用層次實現(xiàn)這些能力，開發(fā)者可以聚焦在業(yè)務(wù)邏輯的實現(xiàn)上。為了有效地確保云原生服務(wù)之間的通信安全，企業(yè)應(yīng)該使用服務(wù)網(wǎng)格的動態(tài)數(shù)據(jù)加密來消除 Pod 之間和工作負載之間的隱式信任。用服務(wù)網(wǎng)格還能夠解決身份問題，（云原生環(huán)境下）3 層、4 層、IP 地址的認證都已經(jīng)無法有效反應(yīng)工作負載的身份。服務(wù)網(wǎng)格不但提供了網(wǎng)絡(luò)側(cè)的隔離和安全，還在網(wǎng)絡(luò)層提供了重試、超時以及斷路器等服務(wù)治理能力。服務(wù)網(wǎng)格在工作負載級別上提供的授權(quán)能夠增強訪問控制方面的安全性。

服務(wù)網(wǎng)格能夠減小云原生環(huán)境中的被攻擊面積，并提供零信任應(yīng)用網(wǎng)絡(luò)所需的框架基礎(chǔ)。

運行時檢測

通過對已部署工作負載的監(jiān)控，團隊能夠判斷當(dāng)前運行狀態(tài)是否符合預(yù)期。組織應(yīng)持續(xù)對環(huán)境進行安全掃描和監(jiān)控，否則環(huán)境中的工作負載可能會變成攻擊者的游樂場。使用工具對來自容器的系統(tǒng)調(diào)用和網(wǎng)絡(luò)流量進行檢測、跟蹤、匯總和報告，來檢測意外或者惡意行為。

雖然回歸測試和安全測試可以幫助防止已知的、預(yù)期的問題被部署到生產(chǎn)環(huán)境中，但是要阻止的不止這些。應(yīng)該對工作負載進行動態(tài)掃描，以檢測之前未知的惡意行為。例如在工作負載運行了 X 天之后，改寫的 Sleep 命令從 etcd 進行數(shù)據(jù)滲透，這樣的行為在大多數(shù)環(huán)境中都是預(yù)期之外，因此不包括在安全測試中。工作負載中的木馬，可能存在時間或事件方式的延遲，只有通過與基線預(yù)期進行比較才能檢測到，這通常是在徹底的活動和掃描監(jiān)控中才能發(fā)現(xiàn)的。

Functions

Serverless function 是很容易受到攻擊的，必須進行適當(dāng)?shù)谋Ｗo。限制進程只能執(zhí)行白名單中的 Function，不允許進程更改關(guān)鍵系統(tǒng)掛載點等。

Function 必須進行限制，僅允許訪問特定服務(wù)，可以使用網(wǎng)絡(luò)或者授權(quán)模型來完成這個限制。另外 Egress 網(wǎng)絡(luò)必須進行監(jiān)控，管理員通過監(jiān)控來檢測或阻止對 C&C（Command & Conrol）以及其它危險網(wǎng)域的訪問。Ingress 網(wǎng)絡(luò)的監(jiān)控則可以檢查和移除涉嫌滲透攻擊的惡意流量和命令（例如 SQL 注入）。

Serverless function 中，可供租戶使用的控制措施相對有限。例如損壞的身份驗證、不安全的依賴服務(wù)以及不安全的 API 集成都可能成為安全問題的根源。確定所有 Function 都在租戶資源中，進行數(shù)據(jù)隔離都有助于解決這些問題，然而隔離環(huán)境可能因為資源受限造成性能受損。

Bootstrapping

要對計算節(jié)點進行初始化，建立信任數(shù)據(jù)，然后才能保障工作負載和配置運行在正確的節(jié)點上。這個過程檢查計算節(jié)點的物理和邏輯定位，并為其提供認證。一般來說，云供應(yīng)商的供給過程會完成這個工作，也會依賴第三方進行信任的檢查。

存儲

云原生存儲涉及到很多技術(shù)，按照訪問方式可以分為兩類，一類是面向工作負載的存儲（例如卷）包括塊存儲、文件系統(tǒng)等；另一類是通過 API 訪問的存儲，例如對象存儲、鍵值存儲和數(shù)據(jù)庫。

存儲系統(tǒng)包含是數(shù)據(jù)訪問界面，其中定義了應(yīng)用或工作負載存儲以及消費數(shù)據(jù)的接口，這個接口可以通過訪問控制、認證、授權(quán)和加密傳輸?shù)确绞竭M行保護。

存儲系統(tǒng)還包含一個控制平面管理界面，它通常是一個受認證和 TLS 保護的 API，也可能有更細致的訪問粒度。一般來說，控制界面只能由編排器或者服務(wù)管理員通過服務(wù)賬號的方式來使用。

存儲棧

存儲解決方案都由多層功能組成的，這些功能定義了數(shù)據(jù)的存儲、檢索、保護，及其與應(yīng)用程序、編排器和/或操作系統(tǒng)的交互方式。每一層都有可能影響和沖擊存儲系統(tǒng)的安全性。一個常見的例子是將文件或塊持久化到對象存儲的文件系統(tǒng)。包括提供對外訪問能力的頂層之內(nèi)的每一層，都是需要一視同仁進行保護的。

編排

大多數(shù)編排系統(tǒng)都會實現(xiàn)各種抽象和虛擬化層，其中可能包括文件系統(tǒng)（如綁定掛載）、卷管理器以及基于協(xié)調(diào)器策略的用戶或組級別的權(quán)限應(yīng)用。與容器化和微服務(wù)架構(gòu)的許多組件一樣，對卷和存儲的保護始終依賴于其他能力。如果用戶能夠在編排器或容器運行時內(nèi)將他們的權(quán)限升級到 root，他們就會在環(huán)境中造成破壞。零信任、最小權(quán)限和訪問控制的實現(xiàn)和執(zhí)行是成功保護云原生架構(gòu)中存儲安全的關(guān)鍵。

系統(tǒng)拓撲和數(shù)據(jù)保護

要保護數(shù)據(jù)訪問路徑，和保障分布式拓撲中跨節(jié)點通信安全性，關(guān)鍵在于理解系統(tǒng)的存儲拓撲。

常見的拓撲結(jié)構(gòu)包括：

• 所有計算節(jié)點訪問中央存儲服務(wù)的集中式模型

• 將功能分布在多個節(jié)點上的分布式模型

• 以及將應(yīng)用和存儲工作負載結(jié)合在同一節(jié)點上的超融合模型。

要根據(jù)系統(tǒng)的拓撲模型來選擇特定的、分層的安全機制，來保護存儲中的數(shù)據(jù)和在存儲位置之間傳輸?shù)臄?shù)據(jù)。

存儲系統(tǒng)的關(guān)鍵功能就是為系統(tǒng)或服務(wù)中的持久化數(shù)據(jù)提供保護。這種保護首先通過向授權(quán)用戶提供數(shù)據(jù)來實現(xiàn)，并應(yīng)作為系統(tǒng)中的一個透明層存在。保護措施還可以包括奇偶校驗或鏡像、擦除碼或復(fù)制等技術(shù)。接下來是針對完整性的保護，存儲系統(tǒng)會在塊、對象或文件中增加哈希和校驗，主要是為了檢測和恢復(fù)被破壞的數(shù)據(jù)，但也可以增加一層保護，防止數(shù)據(jù)被篡改。

緩存

緩存層，通常是完全獨立的系統(tǒng)，是為了提高存儲系統(tǒng)的性能，特別是文件系統(tǒng)、對象和數(shù)據(jù)庫的性能而實施的。緩存層是數(shù)據(jù)層的前哨，因此同樣需要應(yīng)用適當(dāng)?shù)脑L問控制和安全策略，

數(shù)據(jù)服務(wù)

存儲系統(tǒng)通常會實現(xiàn)一些數(shù)據(jù)服務(wù)，一次提供額外的功能對核心存儲功能進行補充，這些功能可以在堆棧的不同層實施，例如復(fù)制和快照（數(shù)據(jù)的時間點副本）。這些服務(wù)通常用于將數(shù)據(jù)副本移動到遠程位置，必須確保相同的訪問控制和安全策略也適用于遠程位置的數(shù)據(jù)。

物理和非易失性存儲

因為云原生功能可以在內(nèi)部進行部署，云原生存儲安全并不局限于虛擬的云原生架構(gòu)。重要的是存儲系統(tǒng)最終會將數(shù)據(jù)持久化在某種形式的物理存儲層上，這種存儲層一般是非易失性的。現(xiàn)代物理存儲（如SSD）通常支持安全功能，例如根據(jù) OPAL 標準進行自我加密，以及快速/安全擦除功能。當(dāng)包含數(shù)據(jù)的設(shè)備需要離開安全的物理位置時（例如出現(xiàn)故障后要返回給廠商），安全擦除是很重要的。

存儲加密

存儲系統(tǒng)可以提供數(shù)據(jù)加密，從而對數(shù)據(jù)進行保密。傳輸中或存儲中的數(shù)據(jù)都可以實施加密，當(dāng)使用存儲系統(tǒng)時，應(yīng)確保加密功能的實現(xiàn)是獨立于應(yīng)用的。

加密是有計算開銷的，因此會對性能產(chǎn)生影響，但許多系統(tǒng)上都有加速選項可以減少這一開銷。在選擇數(shù)據(jù)的加密種類時，要考慮數(shù)據(jù)路徑、大小和訪問頻率，以及安全算法的法規(guī)要求或額外的安全保護措施需求。此外，團隊在考慮架構(gòu)的加密要求時，也同樣應(yīng)該緩存的加密問題。

傳輸中的數(shù)據(jù)（網(wǎng)絡(luò)中的數(shù)據(jù)）和靜止中的數(shù)據(jù)（磁盤上的數(shù)據(jù)）都是加密保護的目標。存儲客戶端或存儲服務(wù)器中都可以進行加密，加密的粒度將因系統(tǒng)而異（例如每卷、每組或全局密鑰）。在許多系統(tǒng)中，傳輸中的數(shù)據(jù)是用 TLS 保護的（TLS 的額外好處是通過證書提供一個認證層[^8]。舊的協(xié)議（如 iSCSI）可能更難保證傳輸中的安全（盡管可以使用更復(fù)雜的解決方案，如 IPsec 或加密的VPN[^9]）。靜止狀態(tài)下的數(shù)據(jù)一般使用標準的對稱加密算法（如 AES）進行保護，并可采用特定的加密模式（如針對塊設(shè)備的 XTS）進行部署。

加密功能通常依賴于和密鑰管理系統(tǒng)的集成。

持久卷保護

要確保只有授權(quán)的容器和工作負載才能訪問卷，就需要對持久卷的訪問進行保護。首要措施就是為命名空間定義信任邊界，以隔離對卷的訪問。使用安全策略阻止容器組訪問工作節(jié)點加載的卷，并確保只有合適的工作節(jié)點能夠訪問卷。尤其需要注意的是，特權(quán)容器能夠加載不同命名空間中的加載卷，所以需要其它措施來進行保護。

指定卷的 UID 或 GID 仍然允許同一命名空間的容器訪問，不會提供數(shù)據(jù)保護。NFSv3 會假設(shè)客戶端已經(jīng)進行了認證和授權(quán)，而不進行驗證。在實施保護時，必須考慮認證和授權(quán)的發(fā)生點，以及是否存在該操作的驗證。

制品倉庫

制品庫應(yīng)該對 OCI 制品進行簽署和核實。同樣需要注意的是，緩存和發(fā)布工具也應(yīng)該有這種能力，確保緩存層有能力檢測篡改或者對數(shù)據(jù)集投毒的企圖。

CNCF 存儲白皮書提供了更多的云原生存儲的概念、術(shù)語、使用模式等技術(shù)資料。

訪問

認證和訪問管理

一個面向云原生架構(gòu)的全面的認證和訪問管理（IAM）方案至少要提供服務(wù)認證能力。維護或者運營自建云、混合云的組織，需要進行用戶和設(shè)備的身份管理。如果是多云環(huán)境中的應(yīng)用和工作負載，身份聯(lián)合是實現(xiàn)成功的關(guān)鍵因素。

應(yīng)用程序和工作負載應(yīng)該顯示地使用雙向認證的方式進行授權(quán)。由于云計算的短暫性，密鑰輪換和壽命需要頻繁而短暫，以維持敏態(tài)和控制的需求，在憑證發(fā)生泄露時，其泄露半徑也能得到有效控制。

為了讓客戶端和服務(wù)器通過加密技術(shù)雙向驗證身份，所有的工作負載都必須利用相互/雙向傳輸認證。

認證和授權(quán)必須在環(huán)境內(nèi)部和整個環(huán)境中獨立確定（決定點）和執(zhí)行（執(zhí)行點）。理想情況下，應(yīng)實時確認所有工作負載的安全操作，在可能的情況下驗證更新的訪問控制和文件權(quán)限，因為緩存可能允許未經(jīng)授權(quán)的訪問（例如訪問被撤銷未在緩存中進行驗證）。工作負載的授權(quán)是根據(jù)屬性和角色/權(quán)限分配給它們的。強烈建議組織同時使用基于屬性的訪問控制（ABAC）和基于角色的訪問控制（RBAC），以便在所有環(huán)境中和整個工作負載生命周期中提供精細的授權(quán)執(zhí)行。這樣的態(tài)勢可以實現(xiàn)深度防御，所有的工作負載都能夠接受、消費和轉(zhuǎn)發(fā)終端用戶的身份進行上下文或動態(tài)授權(quán)。這可以通過使用身份文件和令牌來實現(xiàn)。如果不執(zhí)行這一點，就會限制組織真正對系統(tǒng)對系統(tǒng)和服務(wù)對服務(wù)的調(diào)用進行最小權(quán)限]訪問控制的能力。

需要注意的是，在微服務(wù)的背景下，應(yīng)用或服務(wù)身份也是至關(guān)重要的，應(yīng)用的身份可能會被惡意服務(wù)欺騙和冒充。使用強認證系統(tǒng)和服務(wù)網(wǎng)格可以幫助克服這些問題。

所有工作負載和集群的控制過程，不管是人還是非人。都需要進行認證，他們的行動必須根據(jù)控制策略，對每個請求的上下文、目的和輸出進行評估。為了簡化認證過程，可以和企業(yè)功能（如多因子認證）進行對接。必須通過本節(jié)提到的訪問控制機制進行授權(quán)。

憑據(jù)管理

硬件安全模塊（HSM）

讀者應(yīng)該盡可能使用 HSM 這樣的技術(shù)，用物理方式進行密鑰保護。如果無法做到，則應(yīng)該使用軟件的證書管理器。

憑據(jù)管理周期

加密密鑰數(shù)據(jù)應(yīng)該由 HSM 或者基于軟件的密鑰管理系統(tǒng)生成。

Secret 的有效期應(yīng)該盡可能短，超過期限后即宣告失效。為了達成“短壽”目標，密鑰的生成機制應(yīng)該是高可用、高易用的。如果使用了長效的 Secret，則應(yīng)建立相應(yīng)的流程和指導(dǎo)，定期進行輪換或撤銷，特別是在秘密意外泄露的情況下。所有秘密都必須通過安全的通信方式進行分發(fā)，并應(yīng)得到與其保護的訪問或數(shù)據(jù)水平相稱的保護。

在任何情況下，Secret 都應(yīng)該在工作負載運行時通過非持久性的機制進行注入，這些內(nèi)容不會在日志、審計、或者系統(tǒng)轉(zhuǎn)儲（例如環(huán)境變量）時泄露。

可用性

拒絕服務(wù)攻擊和分布式拒絕服務(wù)攻擊

云原生應(yīng)用程序中的拒絕服務(wù)攻擊是一種網(wǎng)絡(luò)攻擊。攻擊者嘗試破壞關(guān)鍵的云原生應(yīng)用組件（例如微服務(wù)）、或者云原生應(yīng)用賴以運行的編排層組件以及健康檢測系統(tǒng)，讓云原生服務(wù)無法正常提供服務(wù)。拒絕服務(wù)供給通常會通過向關(guān)鍵微服務(wù)或資源發(fā)起大量無效請求，引發(fā)系統(tǒng)過載的方式，來阻止系統(tǒng)的正常運行。

典型的分布式拒絕服務(wù)攻擊會包含大量的入站流量，對云原生應(yīng)用或者其依賴的上游設(shè)施進行沖擊，這些流量來自大量不同的源頭，需要在攻擊到達云原生應(yīng)用之前識別和轉(zhuǎn)移流量，來緩解攻擊造成的損害。

安全保障

從根本上來說，安全就是一個風(fēng)險管理的過程，其目標是檢測和解決系統(tǒng)風(fēng)險。組織根據(jù)自身風(fēng)險狀況和容忍度來對系統(tǒng)進行持續(xù)加固，以期降低、轉(zhuǎn)移或者消解風(fēng)險。安全團隊可以對組件進行評估，制定最小化、有彈性、功能正常的加固方案。例如團隊決定更新基礎(chǔ)鏡像，應(yīng)該對更新可能增加的額外端口、權(quán)限和軟件包進行審查，接受、改變或進行限制。

而合規(guī)原則是一種控制原則，用來確定或創(chuàng)建需求，并根據(jù)需求對系統(tǒng)進行評估。評估結(jié)果是二進制的（通過或失敗），但可能包含第 1 類（假陽性）或第 2 類（假陰性）錯誤，應(yīng)視作 CI/CD 管線的測試結(jié)果進行評估。因此，合規(guī)性和安全保證是相輔相成且無法互換的過程。合規(guī)系統(tǒng)不能保證安全，安全系統(tǒng)也不能保證合規(guī)。

威脅建模

對于采用云原生技術(shù)的組織來說，對風(fēng)險進行識別，并對識別結(jié)果進行控制和消解的主要機制就是對應(yīng)用、數(shù)據(jù)流、支持流程和基礎(chǔ)設(shè)施進行威脅建模。實現(xiàn)這一目標的方法與典型的威脅建模差別很小。以下指南是對 OWASP 威脅建模法的改進，建議用于云原生環(huán)境。

端到端架構(gòu)

如果對個人或組織的云原生架構(gòu)有了清晰的認識，就應(yīng)該對數(shù)據(jù)影響進行指導(dǎo)和分類。這有助于團隊根據(jù)架構(gòu)進行數(shù)據(jù)的分布和其他保護機制的建設(shè)。云原生架構(gòu)不僅僅是針對核心組件的，還應(yīng)該包含源碼、存儲等所有軟件開發(fā)周期中的其它元素。在對威脅建模時，這些相關(guān)因素都應(yīng)該考慮。

威脅識別

在考慮針對云原生能力特定的威脅時，建議采用成熟的、使用良好的模型，例如 STRIDE) 或者 OCTAVE。云原生架構(gòu)的常見威脅包括但不限于如下內(nèi)容：

• 通過社會工程方法竊取憑證，獲取管理員身份。

• 篡改 API 服務(wù)配置文件或者證書，導(dǎo)致 API Server 重啟，或破壞 TLS 認證失敗。

• 禁用或配置錯誤的審計策略，導(dǎo)致對攻擊行為缺乏證據(jù)支持。

• 如果攻擊者破壞了正在運行的工作負載，成功進行滲透之后，就有可能造成信息泄露。

• 拒絕服務(wù)攻擊能夠?qū)е聸]有資源限制的容器消耗整個節(jié)點的 CPU 和內(nèi)存，導(dǎo)致節(jié)點離線。

• 特權(quán) Pod 或者缺乏限制的安全策略，可能導(dǎo)致特權(quán)提升的后果。

云原生安全需要考慮的威脅者和已知的威脅模型是一致的：

• 內(nèi)部惡意

• 內(nèi)部無意

• 外部惡意

• 外部無意

建議各組織利用 Cloud Native Landscape 的現(xiàn)有資源，獲取有關(guān)云原生架構(gòu)威脅的其他信息。

利用管線和 IaC 可能對某些威脅產(chǎn)生消解作用，或降低其成功或發(fā)生的可能性。

與任何云原生流程一樣，迭代和反饋非常重要。在威脅建模的背景下，應(yīng)重新評估現(xiàn)有的措施、機制和指標，判斷其是否準確地反映了架構(gòu)不斷變化的運行狀態(tài)。

威脅情報

從設(shè)計和目的來看，云原生應(yīng)用是由多個動態(tài)組件組成的集合，這些組件包含第一方和第三方的代碼和工具，這意味著必須跟進網(wǎng)絡(luò)活動和云原生應(yīng)用組件應(yīng)用威脅情報。網(wǎng)絡(luò)威脅情報是關(guān)于威脅和威脅行為者的信息，有助于緩解有害事件。云原生系統(tǒng)中的威脅情報將利用在網(wǎng)絡(luò)或主機上觀察到的指標，如IP地址、域名、URL和文件哈希，這些指標可用于協(xié)助識別威脅。行為指標，如威脅行為者的戰(zhàn)術(shù)、技術(shù)和程序，也可用于識別云原生組件中的威脅行為者活動。MITRE ATT&CK 云框架包括可作為建立和驗證可觀察性的起點的云原生戰(zhàn)術(shù)和技術(shù)。

事件響應(yīng)

如果組織機已經(jīng)具備了事件響應(yīng)和分流機制，關(guān)注點應(yīng)該放在如何將既有機制應(yīng)用到云原生工作負載的問題上，云原生工作負載在節(jié)點隔離（Pod 會在不同節(jié)點上漂移）、網(wǎng)絡(luò)（IP 地址動態(tài)分配）和不可變性（對容器內(nèi)文件系統(tǒng)的更改通常會在重啟后丟失）方面和傳統(tǒng)流程的假設(shè)很不一樣。因此需要重新評估這些假設(shè)并根據(jù)需要更新應(yīng)用或者更新應(yīng)對流程。觀察工具和取證工具需要了解云原生應(yīng)用的特點（例如 Pod 和容器），以便管理或重建受損系統(tǒng)。在一些編排系統(tǒng)中，因為將工作負載視為無個性的不持久的，證據(jù)的獲取可能比較困難。另外要提到的一點是，從頭構(gòu)建事件響應(yīng)和分流機制是可行的，但是不在本文范圍之內(nèi)。

安全堆棧

環(huán)境

預(yù)檢安全工具

環(huán)境預(yù)檢安全工具應(yīng)最大限度地進行加固并確保遵守安全方面的最佳實踐，同時最大限度地減少與托管環(huán)境、網(wǎng)絡(luò)和協(xié)調(diào)層有關(guān)的權(quán)限。工具還應(yīng)該確保合規(guī)性不會在運行時被破壞。

計算和節(jié)點檢查

應(yīng)利用工具確保計算資源的加固和安全性，例如用主機漏洞掃描器和 CIS 基準掃描器進行檢查，通過后才能將資源標記為可以交付。

運行上下文

覆蓋預(yù)檢安全的工具適合作為 CI 管線的一部分，對文件、制品（例如容器）和 IaC 進行掃描。CD 管線中運行的安全工具更適合在特定上下文的特定配置中運行。

運行中的安全工具

工作負載和運行時安全

運行時安全工具可以分為四個關(guān)鍵的保護區(qū)域：

• 進程、容器或者系統(tǒng)層的安全

• 網(wǎng)絡(luò)安全

• 數(shù)據(jù)安全

• 應(yīng)用安全

每個保護區(qū)域都可以使用多種工具。策略引擎可以執(zhí)行手動編寫或者基于推薦系統(tǒng)的策略。策略一旦投入使用，這些工具將提供可預(yù)測的結(jié)果，并且可以在僅做監(jiān)視、或者強制模式下使用策略。

威脅和漏洞信息可以讓安全工具能夠攔截來自未知威脅和已識別威脅的異常行為和安全事件。這些信息通常會定期更新。這些信息不但能夠補充策略引擎的能力，還能實現(xiàn)為一個覆蓋更大領(lǐng)域的防御工具。團隊應(yīng)該關(guān)注網(wǎng)絡(luò)威脅情報中已知的 C&C 服務(wù)器、挖礦域名、惡意軟件校驗和等信息，從而有目的的更新策略工具。

盡管現(xiàn)有工具可以提供機制來管理由誤報和誤報問題產(chǎn)生的噪聲并處理已知威脅，并使用策略驅(qū)動的防護來規(guī)范操作，但基于機器學(xué)習(xí)（ML）的安全工具提供了已知和未知威脅的檢測層，超出了可預(yù)測工具可以建立的范圍。例如，對基于身份的授權(quán)日志進行基于行為的分析，以檢測內(nèi)部威脅和破壞，或者對編排器審計日志進行自適應(yīng)分析，以檢測服務(wù)帳戶的試探和盜用行為。機器學(xué)習(xí)驅(qū)動的主機系統(tǒng)調(diào)用模式分析可用于檢測容器逃逸嘗試，或主機爆破嘗試。

用于監(jiān)控和跟蹤云原生編排器的安全工具通常以特定領(lǐng)域的商業(yè)產(chǎn)品的形式提供，其中會包含跨越多個領(lǐng)域的強大功能，例如策略控制、合規(guī)檢查、基于 AI/ML 的異常檢測和良好的集成接口。

和工作負載一樣，用云原生方式實現(xiàn)的用于監(jiān)視，報告或控制環(huán)境安全性的工具會更加便于使用，管理和部署。

零信任架構(gòu)

零信任架構(gòu)通過細粒度拆分、微邊界的架構(gòu)，并通過執(zhí)行策略限制消除數(shù)據(jù)、資產(chǎn)、應(yīng)用程序和服務(wù)的隱式信任，從而減輕了網(wǎng)絡(luò)威脅橫向擴散的可能性。零信任架構(gòu)的最常見實現(xiàn)方法是依賴于加密概念的。首先要用硬件或者令牌來保護特定的密鑰信息，并且能夠用安全的方式和平臺進行通信。

零信任架構(gòu)通常由幾個部分組成：

• 每個實體都能創(chuàng)建自己的標識

• 每個實體都能獨立地認證其它實體（例如用公鑰體系）

• 實體之間的通信是加密且不可篡改的

零信任架構(gòu)以信任根來創(chuàng)建零信任的各個組成部分：給實體或者進程綁定防篡改的信任能力，構(gòu)成框架的基礎(chǔ)成員。然后需要實現(xiàn)自證、驗證、和證明實體身份的能力。例如對于容器服務(wù)的來說，如何檢查該容器是否是它聲稱的身份？這需要使用編排器進行驗證，但是要信任編排器，我們需要確保其不受干擾地運行，只有它在運行受信任的操作系統(tǒng)和 BIOS 等基礎(chǔ)設(shè)施上的時候，才能確保這一點。這實際上也是一個信任鏈條。

零信任架構(gòu)也需要實體之間的通信安全。網(wǎng)絡(luò)分段能為零信任架構(gòu)提供幫助，值得考慮，但這并不能覆蓋零信任的需求。編排器的網(wǎng)絡(luò)策略以及服務(wù)網(wǎng)格都是全面的零信任方案組件。網(wǎng)上有更多零信任相關(guān)概念的相關(guān)信息。

最小權(quán)限

最小權(quán)限原則非常重要，某種程度上說，是云原生架構(gòu)中最重要的一方面，這個技術(shù)棧的所有層面在進行認證和授權(quán)的設(shè)計實現(xiàn)過程中，都需要考慮這個原則。傳統(tǒng)的最小權(quán)限原則是在賬戶層考慮的，這個賬戶可能是人，也可能是服務(wù)。

云原生環(huán)境中，應(yīng)該在堆棧的每個層次使用最小權(quán)限原則。在評估負責(zé)每個層次的工具時，也應(yīng)該考慮到這一點。在探索各種產(chǎn)品和能力時，會發(fā)現(xiàn)很多容器缺省就是特權(quán)模式的，或者是要求 root 權(quán)限進行運維的。因此可能需要一些額外的隔離措施來運行這些特權(quán)負載。組織需要考慮對不同特權(quán)的領(lǐng)域進行隔離，在工作負載和部署中采用最小權(quán)限模式，可能包括從 cgroup 和系統(tǒng)調(diào)用，到制品管理和非 root 構(gòu)建等多個方面。

為了持續(xù)減少潛在的攻擊面積和和控制影響范圍，組織需要在其架構(gòu)的每一個層次上實施最低權(quán)限原則。這不僅適用于在其角色中執(zhí)行各種功能的個人，也適用于在特定環(huán)境中執(zhí)行的服務(wù)和工作負載。無根服務(wù)和容器對于確保如果攻擊者確實進入組織的環(huán)境，他們不能輕易地在他們獲得訪問權(quán)的容器和底層主機或其他主機上的容器之間進行穿越至關(guān)重要。

強制性訪問控制（MAC，例如如 SELinux 和 AppArmor）可以限制超出為容器或命名空間設(shè)置的權(quán)限，并在主機級別提供額外的容器隔離，以防止容器越獄或從一個容器轉(zhuǎn)向另一個容器以升級，得到超出現(xiàn)有訪問控制所允許的權(quán)限。

角色和責(zé)任

在轉(zhuǎn)向云原生架構(gòu)和部署時，組織應(yīng)該對傳統(tǒng)安全角色和責(zé)任進行調(diào)整，并創(chuàng)建云原生特有的新安全角色。隨著現(xiàn)代開發(fā)方法論的快速發(fā)展，以及 IT 活動與業(yè)務(wù)需求的更好結(jié)合，安全工作必須具有適應(yīng)性、具備應(yīng)對實際風(fēng)險相匹配的能力和透明性。期望開發(fā)人員和運維人員成為安全專家是不合理的。安全從業(yè)人員需要與開發(fā)、運維和其他項目角色合作，使安全和合規(guī)性的執(zhí)行和開發(fā)生命周期充分結(jié)合。開發(fā)人員使用的工具就能實時報告發(fā)現(xiàn)（安全）問題，并像處理構(gòu)建失敗一樣去解決問題。

在云原生環(huán)境中管理安全性時，在 DevOps 環(huán)境中經(jīng)常出現(xiàn)界限模糊的情況，這里還是應(yīng)該進行明確的職責(zé)分離（SoD）。盡管開發(fā)人員將更多地參與實施和執(zhí)行安全措施，但他們無需設(shè)置策略，也不必了解角色所不需要的區(qū)域等。應(yīng)根據(jù)組織的風(fēng)險承受能力和業(yè)務(wù)實踐，在角色之間、產(chǎn)品之間和應(yīng)用團隊之間進行職責(zé)分離。可以理解，小組織中的個人會履行許多職責(zé)以保持業(yè)務(wù)蓬勃發(fā)展時，這種分拆可能很困難。然而，隨著組織的不斷發(fā)展，個人的認知也會發(fā)生變化，實施不同角色的權(quán)限讓個人能夠發(fā)揮獨特作用，也有助于執(zhí)行 SoD。最終將重組角色重新分配給新的成員，但是不會為新角色增加范圍。

隨著產(chǎn)品和服務(wù)遷移上云，組織將需要重新評估其資產(chǎn)風(fēng)險。隨著使用中的技術(shù)及其部署堆棧的所有權(quán)和管理方面的變化，管理人員會面臨風(fēng)險態(tài)勢的急劇變化。資源提供者和團隊之間的共同責(zé)任將要求更改風(fēng)險接受、轉(zhuǎn)移和新的緩解機制的閾值。

合規(guī)

系統(tǒng)應(yīng)當(dāng)具備一定安全控制措施，能夠應(yīng)對監(jiān)管和合規(guī)性指導(dǎo)，讓云原生資源更加安全。這樣做還可能使相關(guān)監(jiān)管機構(gòu)和審計人員的工作過程變得更加方便，系統(tǒng)甚至可以通過設(shè)計和規(guī)劃，最終使用插件模式實現(xiàn)對各種監(jiān)管機構(gòu)的自動合規(guī)。雖然合規(guī)性通常需要利用安全基準來提高安全性和配置管理的執(zhí)行力，如 CIS 基準，還是建議使用機器可讀的合規(guī)性控制框架和語言。

監(jiān)管審計

金融、衛(wèi)生、政府等行業(yè)需要遵守特定的要求來進行系統(tǒng)保護。用戶信任這些系統(tǒng)和他們的交互是安全的和私密的。每個組織都應(yīng)該評估適用于自己的監(jiān)管標準（例如 PCI-DSS、HIPAA、FedRAMP、GDPR 等），然后要確定如何把具體需求落地到自己的云原生系統(tǒng)之中，以及如何在現(xiàn)實世界中實施這些標準。這種支持特定標準的證據(jù)收集機制應(yīng)該盡量通過不可抵賴性的環(huán)節(jié)來實現(xiàn)自動化。

角色和用例

重點是安全、保護、檢測和盡可能的自動響應(yīng)。它不一定是單獨的開發(fā)工具，而是透明地集成到開發(fā)流程中的安全工具，以執(zhí)行安全策略，在此過程中可以進行快速反饋和最直接的補救行動。有關(guān)云原生安全用例的具體信息，請參考 SIG-Security 的用例列表。

業(yè)界

企業(yè)

企業(yè)采用云原生模式的核心關(guān)注點是：在滿足業(yè)務(wù)目標的同時，保持當(dāng)前的流程和程序。當(dāng)整個組織引入新的標準和實踐時，將互操作性、數(shù)據(jù)丟失或泄漏以及安全風(fēng)險暴露保持在最低限度。

微型企業(yè)

小企業(yè)采用云原生模式的核心關(guān)注點在于能否專注于短期目標，能否促進創(chuàng)新以應(yīng)對激烈的競爭。資源、預(yù)算、技術(shù)深度和最佳實踐的缺乏阻礙了他們適應(yīng)云原生解決方案的能力。小企業(yè)需要可重復(fù)的模式和小規(guī)模的 IT 足跡來解決這些挑戰(zhàn)。

金融

金融行業(yè)關(guān)注的核心領(lǐng)域是未經(jīng)授權(quán)的信息披露、欺詐和資金可用性，這對成功采用云原生技術(shù)至關(guān)重要。欺詐會直接影響資金的可用性，因此金融交易的完整性是頭等大事。

醫(yī)療

醫(yī)療保健行業(yè)關(guān)注的核心領(lǐng)域是未經(jīng)授權(quán)的信息披露、記錄的及時性和可用性以及記錄的準確性，這些都是采用云原生技術(shù)成敗的決定性因素。由于醫(yī)療行業(yè)的性質(zhì)和實踐，記錄及其相關(guān)內(nèi)容的可用性是做出醫(yī)療決策的基礎(chǔ)。在沒有這些信息的情況下，就會形成新的記錄。

學(xué)術(shù)和教育

教育機構(gòu)成功采用云原生技術(shù)的核心關(guān)注領(lǐng)域可能取決于預(yù)期的最終用戶。面向未成年人的機構(gòu)可能有額外的法律要求，以保護未成年人的機密性，因此要重視訪問控制能力。除此以外，各機構(gòu)應(yīng)關(guān)注教育內(nèi)容對終端用戶的可用性。

公共領(lǐng)域

公共部門組織關(guān)注的核心領(lǐng)域是安全、數(shù)據(jù)主權(quán)、合規(guī)性和供應(yīng)商鎖定，這些領(lǐng)域?qū)τ诔晒Φ脑圃陵P(guān)重要。這些障礙來自于機構(gòu)為保護公共利益而制定的法規(guī)。在公共部門，保持公共和政府實體之間的和諧和信任是必須保障的。此外，部署和功能的及時性也可能是一個強有力的考慮因素。采用云原生，加上現(xiàn)代方法論，可以提高組織效率，這對公共部門的許多領(lǐng)域會產(chǎn)生極大促進。

云原生安全的演變

容器技術(shù)是一個不斷發(fā)展的領(lǐng)域，得到了廣泛的應(yīng)用。云原生技術(shù)的威脅狀況以及在緩解和解決這些威脅的方法也在不斷變化。除了安全容器平臺的復(fù)雜生態(tài)系統(tǒng)外，這些都需要一個全面制定、深思熟慮的安全策略，并對安全策略的執(zhí)行、響應(yīng)和操作紀律進行技術(shù)控制和自動化。

如果實施得當(dāng)，容器可以提供巨大的安全優(yōu)勢。它們提供了更大的透明度、模塊化、減少攻擊面、更容易的應(yīng)用組件更新以及應(yīng)用組件運行的一致環(huán)境。這種一致性使得并行安全能夠在開發(fā)、測試和生產(chǎn)運行環(huán)境中茁壯成長。它們還可以減少企業(yè)范圍內(nèi)安全事件的影響，當(dāng)實現(xiàn)應(yīng)用程序之間建立的適當(dāng)隔離時（基本上可以在可能擁有扁平網(wǎng)絡(luò)的企業(yè)中實現(xiàn)微觀分段），作為分層防御-深度安全策略的一部分。

在當(dāng)前安全方面的所有挑戰(zhàn)、所需安全工具的數(shù)量以及市場上技能和人才的短缺，確保容器平臺的安全是一個巨大的挑戰(zhàn)。我們預(yù)計，隨著云提供商提供的容器服務(wù)產(chǎn)品越來越成熟，在互不兼容的規(guī)范上集成了更多的云原生安全與智能工具，我們將看到更多的遷移到云端。這些產(chǎn)品作為共同責(zé)任模式的一部分，最終會降低企業(yè)的開銷。

因此容器的采用、以及云原生的采用，將繼續(xù)推動企業(yè)的數(shù)字化轉(zhuǎn)型進程。企業(yè)已經(jīng)開始嘗試 Serverless 架構(gòu)和設(shè)計來提供一些服務(wù)，但考慮到在編排 Function 構(gòu)建業(yè)務(wù)功能時，可視性降低的挑戰(zhàn)，以及現(xiàn)有的大量尚未知曉的安全挑戰(zhàn)，使用 Serverless 構(gòu)建整個業(yè)務(wù)功能仍在發(fā)展階段。簡而言之，隨著服務(wù)提供商的安全控制以類似于現(xiàn)有容器生態(tài)系統(tǒng)的方式減少消費者的開銷，Serverless 在云原生架構(gòu)中的應(yīng)用預(yù)計將隨著時間的推移而增加。

然而，威脅狀況總體上保持不變，頂級弱點始終被同一組攻擊者利用。我們看到的最顯著的變化是攻擊者針對云原生組織和應(yīng)用采取的攻擊方式和機制。任何針對容器編排者和部署的攻擊都在增加，這一點從通過滲透或木馬鏡像進行的挖礦行為可以看出。與任何開始達到市場飽和的創(chuàng)新技術(shù)一樣，攻擊者會利用任何可用機會。

隨著這些攻擊變得更普遍、更復(fù)雜、更擴大，云原生安全必須不斷發(fā)展，企業(yè)和 DevOps 團隊需要更加重視。我們看到安全策略即代碼的案例越來越多，但在安全策略的執(zhí)行、檢測和響應(yīng)方面，還有很大的演進和增加自動化的空間。很明顯，即時和自動化的安全智能和響應(yīng)將是挫敗攻擊，甚至從攻擊中自我修復(fù)的關(guān)鍵。甚至可能在§[^9]發(fā)生時進行調(diào)整和整合。

容器取證工具和技術(shù)將需要不斷發(fā)展，以跟上云原生的發(fā)展方向。這一點尤為重要，因為在基礎(chǔ)設(shè)施即服務(wù)和其他即服務(wù)模式的背景下，事件的數(shù)量和復(fù)雜性都在增加。

結(jié)論

在過去的十五年里，社區(qū)見證了云服務(wù)和技術(shù)的快速應(yīng)用，最近更是大力推動云原生模式的發(fā)展。如同安全行業(yè)的任何新商品一樣，創(chuàng)新者們都在不斷摸索和推進技術(shù)的早期應(yīng)用和測試。

處于技術(shù)鴻溝邊緣或早期多數(shù)的組織，應(yīng)認真分析和應(yīng)用核心安全概念，以緩解加固和環(huán)境控制的滯后現(xiàn)狀。

雖然對于我們今天看到的和未來即將出現(xiàn)的大多數(shù)創(chuàng)新來說，可能還不存在針對安全的指導(dǎo)和控制，但在設(shè)計、開發(fā)和部署新功能時，可以持續(xù)應(yīng)用云原生架構(gòu)中的核心安全概念。

這些核心安全概念是：

• 防止未經(jīng)授權(quán)的訪問（個人和非個人實體）通過持續(xù)地從已知的良好狀態(tài)重新建立基礎(chǔ)，減少資產(chǎn)對未經(jīng)授權(quán)實體的暴露。

• 不變性以保持內(nèi)容和代碼的完整性。

• 服務(wù)、工具和內(nèi)容的可用性——分布提供彈性和冗余。

• 審計和問責(zé)——提供了一個機制來確保合規(guī)，并跟蹤授權(quán)的變化。

參考

NIST 800-204 Security Strategies for Microservices-based Application Systems

NIST 800-190 Application Container Security Guide

https://www.cisecurity.org/benchmark/Kubernetes/

Threat Modeling: 12 Available Methods

https://owasp.org/www-community/Application_Threat_Modeling

NIST Application Security Container Guide, Center for Internet Security (CIS), NIST Security Strategies for microservices and OpenSCAP benchmarks exist for Docker, Kubernetes, and several managed Kubernetes distributions.

MITRE ATT&CK Matrix For Kubernetes

致謝

This white paper is a community effort driven by the members of the CNCF Security-SIG. Thank you to everyone for their outstanding contributions. Special thanks to Emily Fox and Jeyappragash JJ.

Contributors:

• Aradhna Chetal - TIAA

• Brandon Lum - IBM

• Chase Pettet - Mirantis ([email protected])

• Emily Fox - US National Security Agency (NSA)

• Gadi Naor - Alcide

• Harmeet Singh - IBM

• Jeff Lombardo - Independent

• Jeyappragash JJ - Tetrate IO

• Pushkar Joglekar - Visa

• Rowan Baker - ControlPlane

• Andrew Martin - ControlPlane

• Trishank Karthik Kuppusamy - Datadog

• Vinay Venkataraghavan -Prisma Cloud (Palo Alto Networks)

• Wayne Haber - GitLab

• Mark Bower

• Alex Chircop - StorageOS

Reviewers:

• @justincappos

• @lumjjb

• @whaber

• @craigbox

• @anvega

• @magnologan

• Alok Raj - XenonStack ([email protected])

• @nyrahul

• @ranio1

• @lizrice

• @justincormack

[1^]: Another model to consider is Cloud, Clusters, Containers, and Code: https://kubernetes.io/docs/concepts/security/overview/

[2^]: Example - MITRE ATT&CK Framework for Kubernetes

[3^]: Shifting security left often leaves organizations to lapse operational security monitoring. It is important that security exists in all parts of the lifecycle and organizations continually evaluate other aspects of their business and technology processes where they may reach beyond modern security paradigms to embrace security as a culture and habit.

[4^]: Human capital is a vital asset necessary to the success of any organization, the corresponding intellectual property and relational capital brought as a result is equally in need of protection.

[5^] https://blog.aquasec.com/malicious-container-image-docker-container-host ?

[6^]: According to Applied Software Measurement, Capers Jones, 1996 and adjusting for inflation - 85% of defects are introduced during coding with a cost of $41 to fix compared to a post release fix cost of $26,542.

[7^]: cisecurity.org maintains a listing of benchmarks for hardening

[8^] It is critical to note that while authentication is available for use, mutual authentication is the preferred mechanism to not only verify the client but also the server (outsider versus insider).

[9^]: Utilization of a VPN does not guarantee encryption.

[10^]: The concept of regression proofing is best explained as a facet of antifragile behaviors within technology environments. Instead of remaining resilient and robust against adverse conditions and attacks, technology can proactively adapt and thrive when subjected to them.