在傳統上，保護運營環境意味著采取防火墻等安全措施。然而，像在2020年遭遇的SolarWinds這樣的網絡攻擊在軟件供應鏈上的威脅越來越大。研究表明，網絡攻擊者變得更加深思熟慮，并在軟件開發生命周期的早期階段進行攻擊。
對安全軟件開發生命周期的日益增長的需求引發了圍繞“安全左移”概念的討論。幾十年來，安全性一直處于軟件開發周期的末端，軟件開發基本上是線性規劃的。隨著云原生應用程序的發展，以及用戶對實時和全天候軟件服務的需求，這種在開發周期結束時安排安全性和測試的線性方法可能會產生重大的開發、運營和成本影響。
因此，需要的不僅僅是保護外圍。開發商從開發生命周期的開始，從編寫第一行代碼并在整個過程中運行開始，到應用程序在生產環境中運行，企業必須采取更廣泛的視角來關注安全性。
(資料圖片)
安全性應該被視為基礎設施元素，就像網絡和存儲一樣。然而，與網絡和存儲不同的是，安全性出現問題意味著應用程序的停機和隨之而來的損失，而破壞安全性可能導致敏感信息的丟失，這可能會造成更大的損失，并且在許多情況下是無法挽回的。
全面看待安全問題企業的安全涉及多個方面，包括企業資產、設備、工具、文檔和其他內部信息的安全。隨著企業實施數字化轉型，他們依靠軟件來提供所尋求的敏捷性、性能和可擴展性優勢。但是，怎樣才能在生產環境中安全地運行應用程序呢?
如果企業希望改善其安全狀況，則需要在流程、人員和產品上進行大量投資。僅僅在這些領域中的一個方面進行改進可能不會改善整體的安全狀況，其缺點可能導致整體的軟件安全風險，這就是為什么這些投資應該攜手并進的原因。
例如，如果安全團隊不能有效地與開發和運營團隊進行溝通和協作，那么網絡攻擊者發現安全漏洞只是時間問題。
通過Kubernetes實現業務敏捷性現代應用程序基于云原生技術和微服務架構。容器已經成為打包微服務的默認方式，因為它們提供了一致性、可遷移性和可重復性。隨著越來越多的企業轉向云原生應用程序，Kubernetes已經成為事實上的容器編排器，使得部署、發現和擴展這些微服務變得更加容易。
Kubernetes和容器在將新代碼交付到生產環境時提供了急需的業務敏捷性。然而，這使得安全環境更具挑戰性。Kubernetes使用熟悉的概念，例如authZ和authN、證書和加密。同時，它引入了新的概念，如部署、pod、入口、名稱空間、基于角色的訪問控制、服務帳戶、秘密、網絡策略、資源限制和配額，這些概念不僅對開發人員和運營團隊來說是陡峭的學習曲線，對安全團隊來說也是如此。
DevSecOps的利弊Kubernetes打破了DevOps和安全團隊之間的界限，并鼓勵了DevSecOps的概念，進一步推動了安全向左轉移的趨勢。DevSecOps可以優化DevOps實踐，將軟件開發周期縮短到幾周甚至幾天的時間，從而滿足企業和用戶的多樣化需求。
許多企業在嘗試在生產環境中保護Kubernetes環境時發現了采用DevSecOps的挑戰。DevSecOps和左移的概念要求開發人員具備更豐富的安全知識，他們還需要管理設計、開發、架構、基礎設施和測試。額外的安全職責會給已經承受壓力的DevOps團隊帶來更大的壓力，這為處理Kubernetes問題打開了一個新的窗口。
采用DevSecOps和左移實踐的現實方法在大多數情況下，要求開發人員也成為遇到上述挑戰的安全專家是不切實際的期望。企業的最佳選擇是采用默認安全的工具和技術，并將安全專家作為平臺團隊的一部分，他們可以了解安全結構并構建護欄，并將安全最佳實踐應用于該平臺。
另外，企業可以開始關注軟件物料清單(SBOM)。就像材料的詳細菜單一樣，軟件物料清單(SBOM)列出了代碼庫中的開源和第三方組件，幫助團隊更好地理解開發周期中單個項目和特定代碼之間的關系。
SBOM還包含組件許可信息，這可以幫助企業理解許可和法規信息，從而更容易自動化遵從性檢查。詳細的軟件文檔還提高了開發人員和安全團隊的代碼審查效率，減少了開發人員的負擔。
循序漸進提高安全性提高安全性并不一定是孤注一擲。隨著企業團隊獲得了運行安全生產環境的信心，這通常是一個緩慢提高企業安全狀況的過程。這個過程可以從保護來自集集群外部的訪問和網絡流量(南北流量)開始，然后保護來自集群內部的訪問和網絡流量(東西向流量)，最后應用安全性最佳實踐。
然后，安全團隊可以專注于實現安全合規性、構建零信任架構和改進供應鏈安全性。每個階段都需要培訓，包括學習如何部署和管理Kubernetes。成功在很大程度上取決于團隊實現這些能力的速度有多快。將流程分解并以這種方式進行將使企業能夠朝著實現更好的應用程序安全性穩步前進。
標簽：
