[[427938]]

【51CTO.com快譯】很多企業如今正在采用云原生設計模式，以使其業務運營實現現代化，并加快上市時間。云原生架構結合了微服務、容器、自動化持續集成(CI)/持續交付(CD)管道、容器編排、統一可觀察性和云計算基礎設施等技術。然而，現代云計算服務面臨著數據泄露、應用程序漏洞、帳戶劫持、API不安全、惡意內部人員、數據丟失、拒絕服務和憑證管理不足等安全風險。

為了防范這些威脅，企業應該對其數據和服務采用零信任模型，并采用DevSecOps在整個軟件開發生命周期(SDLC)中集成安全實踐。企業正在使用Docker等容器技術來簡化其云原生應用程序的打包和部署工作流。Kubernetes是一種流行的容器編排系統，用于自動化容器化應用程序的部署、擴展和管理。

采用DevOps原則使企業團隊能夠快速部署和發布功能，但它也給云原生應用程序的安全性帶來了挑戰。因此，需要將安全實踐引入DevOps。

圖1 云原生安全的四個C

1.云原生安全的四個C

云原生安全的四個C分別是云計算(Cloud)、集群(Clusters)、容器(Container)和代碼(Code)。如圖1所示，每一層都受益于外部安全層，代碼層是構建在云計算、集群和容器層之上的。以下簡要介紹每一層保護架構的作用：

• 云計算——它是所有安全層的基礎，每家云計算提供商(如AWS、Microsoft Azure、谷歌云、IBM Cloud)都為正在運行的工作負載提供云計算基礎設施的安全性。
• 集群——這一層的主要安全問題是RBAC授權、機密管理、pod安全策略和網絡策略，Kubernetes是標準操作工具。
• 容器——這一層推薦的安全態勢是容器漏洞掃描、鏡像簽名和禁止特權用戶。
• 代碼——企業對這一層擁有最大的控制權，并且可以實施安全建議，例如執行靜態代碼分析、采用DevSecOps實踐，以及使安全成為持續集成(CI)/持續交付(CD)管道的一部分。

2.云原生安全挑戰

由于發生新冠疫情，很多企業采用遠程工作模式，因此保護數據和系統的需求變得比以往任何時候都更加重要。“零信任”安全模型可以改善企業的總體安全狀況，特別是如果他們計劃讓其員工開展遠程工作或采用混合工作空間環境。其基本原則是避免盲目信任安全參數(企業網絡)內的所有內容，并始終對嘗試訪問網絡的每個用戶、應用程序和設備進行身份驗證和授權——無論是企業內部還是外部。

構建零信任架構的關鍵技術和原則是：

• 多因素身份驗證。
• 身份和訪問管理。
• 設備清單的可見性。
• 防火墻管理。
• 數據分類和加密。
• 最低權限訪問。
• 持續網絡流量監控。

3.云原生應用安全

容器可以輕松打包和部署應用程序的運行時依賴項，并幫助解決開發和生產環境之間的配置管理問題。然而，與傳統的威脅檢測和漏洞掃描安全機制相比，容器的運行是暫時的，通常使用壽命較短，這使得容器的安全性具有挑戰性。

(1)容器安全

開箱即用的容器提供了一定程度的隔離和安全性，但同時，它們也帶來了一系列安全問題，例如內核漏洞、拒絕服務攻擊、中毒圖像、容器泄漏和機密泄露。減少容器攻擊面至關重要，因為一個容器中的問題可能會影響同一主機上運行的其他實例。應用最小權限原則并限制用戶對容器的訪問是很好的做法。需要一個秘密管理解決方案來安全地存儲憑證，并允許容器在操作期間訪問敏感數據。

此外，容器鏡像是不可變的，因此容器鏡像中的任何漏洞都會在鏡像的生命周期內持續存在。因此需要確保定期掃描映像以查找漏洞，作為持續集成(CI)/持續交付(CD)管道的一部分，需要使用最新補丁進行更新，并從受信任的注冊表中提取。在容器化環境中運行云原生應用程序時，企業需要完全了解集群配置，并進行適當的監控。

(2)安全責任共擔模型

在公共云中，安全是云計算服務提供商與其客戶之間的共同責任。其責任的區分可以被視為“云平臺”的安全與“云”中的安全。云計算提供商保護運行服務的整體基礎設施，并處理物理和網絡層的操作問題。另一方面，客戶負責他們的業務邏輯的安全，包括應用程序代碼和數據層保護。

圖2說明了微軟公司的責任共擔模型，包括客戶和微軟公司之間針對在內部部署設施和云平臺中運行的工作負載的責任范圍。

圖2微軟公司的責任共擔模型

4.自動化云原生安全

DevOps方法側重于提高開發和運營流程之間的協作和透明度。然而，在追求快速上市的過程中，安全實踐不能被忽視并進一步推向下游。這就是DevSecOps發揮重要作用的地方，它在開發周期的早期結合了運營和安全措施。

(1)左移安全策略

在開發過程中轉移安全性至關重要，因為企業不希望安全性成為事后的想法。與其相反，企業應該將安全放在首位來設計和構建系統。在生產中識別和修復安全漏洞既昂貴又耗時，因此將安全性左移的目標是在開發過程中實施安全實踐并執行安全測試——而不僅僅是在生產之前部署。企業的DevOps管道應該允許以更高的質量和速度部署軟件，同時遵守安全最佳實踐。

大多數漏洞是在應用程序級別引入的，如果企業的應用程序包含漏洞，網絡攻擊者可能會破壞其系統。靜態應用程序安全測試(SAST)和SAST工具使企業能夠掃描整個代碼庫并執行與安全相關的規則，以檢測SQL注入、跨站點腳本、拒絕服務和代碼注入問題等漏洞。此外，作為持續集成工作流的一部分，可以對每次代碼提交執行靜態代碼分析，并實施自動化漏洞檢測和合規性報告。

(2)將安全性集成到持續集成(CI)/持續交付(CD)管道中

如圖3所示，將安全控制集成到企業的自動化管道中是成功交付高質量軟件的關鍵。DevOps管道具有將更改部署到其環境中所需的權限，因此必須在其周圍設置嚴格的安全護欄。開發人員可以為他們的持續集成(CI)/持續交付(CD)管道利用多種開源和商業安全工具。其目標是及早發現安全問題，并且更容易實施諸如遵循安全編碼實踐、同行評審過程和執行靜態代碼分析等低摩擦的措施。

如果企業使用的是開源軟件或第三方數據庫，應該擁有用于漏洞管理和威脅檢測的工具。在企業的管道中實施輕量級滲透測試有助于增強安全狀況——例如，像OWASP ZAP這樣的動態應用程序安全測試(DAST)工具在將代碼部署到生產之前充當安全門。除了掃描企業的容器之外，還可以考慮在部署到云平臺之前掃描其基礎設施代碼。

圖3在DevOps管道中構建安全性

結論

隨著在DevOps中構建安全性的文化轉變，企業的開發團隊有額外的責任來自動化應用程序安全測試，并將其集成到發布管道中。就安全原則和最佳實踐對開發團隊進行培訓有助于彌合知識差距。此外，與IT安全團隊密切合作的開發團隊可以幫助緩解軟件開發生命周期(SDLC)早期的安全漏洞，并在應用程序開發和安全場景中實現左移概念。

開放式Web應用程序安全項目(OWASP)是一個促進應用程序安全機制的非營利性全球社區。因此建議在云原生領域工作的開發人員熟悉OWASP十大應用程序安全漏洞、黑客如何利用它們以及消除這些風險的方法。大多數漏洞(如代碼注入、敏感數據暴露、身份驗證中斷、安全錯誤配置、跨站點腳本編寫和日志/監控不足)都可以通過安全編碼實踐和嚴格的代碼審查清單來解決。

原文標題：Securing Cloud-Native Applications，作者：Samir Behara

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】