作者 | Drishti Shastri
譯者 | 天道酬勤 責編 | 徐威龍
封圖| CSDN 下載於視覺中國
在當今時代，企業網絡和數據安全風險從未像現在這樣具有里程碑意義。儘管如此，傳統方法（包括公有云運營商使用的方法）基本上是相同的。
雲原生應用的興起及其安全威脅
在當今時代，企業網絡和數據安全風險從未像現在這樣具有里程碑意義。儘管如此，傳統方法（包括公有云運營商使用的方法）基本上是相同的。
轉向應對威脅攻擊而不是阻止威脅的反應措施。雲原生應用程序日益受到重視，用各種可能的方式質疑了傳統智慧。
從基礎架構到應用程序的開發，堆棧在傳統方法與更現代的基於雲的方法之間形成了鮮明的對比，其中大多數已對成功的模式和實踐達成了主流觀點：
DevOps文化、持續交付和微服務架構 。為什麼我們還沒有重新構想雲原生的安全性呢？我們對此大膽的新想法在哪裡呢？可以肯定地說，在交付應用程序的過程中，雲原生的安全性一直在被長期追蹤。傳統的IT安全團隊將自己視為中間人。他們必須正確地完成工作，否則將面臨代理機構所面臨的更大風險。
它們在所有過程中都對安全性有很高的要求，但是要滿足這些級別需要花費時間、測試和修訂。因為這會延遲應用程序的開發並且通常不能確保全面的保護，所以開發團隊經常會抱怨。
當組織希望提高和加快應用程序改進生命週期並調度雲原生應用程序時，安全將成為更為突出的測試。大部分雲原生應用程序都在新模型中運行，這些模型可提供非常規的生產力、適應性和成本優勢。
使用dev-ops進行開發的雲原生進一步將DevSecOps作為其安全組件。DevSecOps試圖將安全納入速度、敏捷性和連續交付流程中。但是，如果DevSecOps忽略了集成、業務流程功能和控制，並且對用戶的安全性較低，則可能很難在連續交付系統中提供安全性。
雲原生漏洞
雲原生肯定會發生漏洞。我們是人類，肯定會犯錯誤，尤其是在苛刻的期限和產品交付之後。儘管有全部的警告、標誌和注意事項，我們也會做出一些錯誤的判斷。
在發出警告的過程中，人們繼續盲目地從Stack Exchange複製和粘貼，來掩蓋在GitHub上發現的應用程序，甚至隨機地將代碼從一個毫無頭緒的文件夾中隨機拉出，並且只能懷疑地認為該作者從未遇到過或甚至沒有與之交談過的第三方。
微服務應用程序的分佈式性質意味著，即使在內部編寫所有代碼的情況下，通過消除第三方參與者的風險，不同的組件也可能由不同的團隊擁有。
團隊之間的溝通障礙會導致一系列問題，包括在測試、質量保證甚至應用程序中的漏洞解決方面缺乏協調。
一個單獨的雲原生應用程序可以包括分散在眾多基礎上的數千個剩餘任務。在本地數據中心、眾多公有云和邊緣數據中心中可能會有奇異的微服務，最後，在組織領域中，我們目前似乎還無法發展。
每個開發人員和每個開發團隊都知道並瞭解如何解決不同的問題。他們所做的就是相應地培養他們的注意力和知識。在內部代碼環境中，即使所有部門都以某種方式保護自己的更廣泛程序的一部分，微服務也必須與其他部門聯繫，並且通信在這裡是風險或脆弱性。
這些所有說法聽起來都令人生畏和令人恐懼，但云原生確實解決了一些非常複雜的現實問題，我們再也不能忽視它的存在。隨著我們不斷升級其安全性，雲原生的漏洞正在不斷髮展並一直存在。
對雲原生應用程序的主要威脅
儘管公司開始體驗雲原生應用程序的優勢，但他們對處理和維護此類系統的實際方面卻知之甚少。與在雲環境中相比，保護的後果是否與傳統系統相比有很大不同？防護措施和保障措施如何對其產生影響？
以下是基於雲的環境的一些最高安全性問題：
1.雲配置錯誤
IaaS和雲數據存儲的配置錯誤是當今一些最具破壞性的雲違規和數據洩露的主要原因。無論你要刪除結構化的雲安全設置、使用通用代碼、無限制地訪問某些資源還是其他任何原因，配置錯誤問題都會導致許多未知威脅，這些威脅僅在尷尬的遭遇後經常在報紙上看到。最新的《 2019年雲安全報告》稱，大約40％的組織認為錯誤配置雲平臺是他們對網絡安全的主要關注點。
2.商業化管理的IT
不用擔心“影子IT”或“流氓IT”。毫不誇張地說， 幾家公司將基礎架構的收購趨勢標記為，將獲得和運營雲服務的業務橋樑客戶稱為“商業化管理的IT”，以及創造力和發展的引擎。《 Harvey Nash /畢馬威CIO 2019調查》報告稱，目前有超過三分之二的公司為企業推廣或允許IT管理。這是因為這樣做的公司擊敗行業競爭對手的能力提高了52％，提供更好的員工服務的可能性提高了38％。
令人擔憂的是，如果沒有信息和網絡安全專業人員的合作，這些雲技術孤島可能成為組織的巨大安全障礙。這些公司的發展速度相當快，但調查顯示，
冗餘的安全隱患波長的可能性是後者的兩倍。3.購買多雲產品
《雲保護聯盟報告》顯示，大多數公司都依賴各種各樣供應商的雲環境來購買多雲產品。大約66％的公司具有多雲設置，其中大約36％取決於多雲和混合系統的混合。
目前，由於雲實際上是希望降低其運營處理成本的所有其他企業的首選工具，因此雲計算向其雲消費者提供一系列服務（SaaS、PaaS、IaaS）。雲在其整個上下文中提供安全、迅速響應和服務質量。但是，每次用戶無法從一個雲遷移到另一個雲時，它都會保持成本和QoS可伸縮性。為了克服這種多雲計算框架，引入了基於雲的系統之間的資源動態共享。在多雲設備中，安全性甚至是一個更為複雜的問題。
4.混合架構
根據著名的《雲安全聯盟報告》，大約55％的組織擁有複雜的、混合操作的雲計算環境。該系統為大型組織提供了一種逐步過渡到雲的絕佳方法，但是當他們難以跟蹤整個架構中的資產並監視眾多混合雲連接的活動時，它給安全性帶來了挑戰。實際上，Firemon先前發佈的一份報告顯示，80％的組織都在挑戰混合安全監控和管理工具的侷限性和複雜性。
5.暗數據
就像電信行業的暗光纖一樣，暗數據也適用於企業和商業。這裡有大量未開發的、大多是不受監管的數據，它們只是存在而已，什麼也沒做。
不幸的是，儘管暗光纖明確代表了僅點亮即可增加功率和帶寬的優點，即使被識別和忽略，暗數據也可能存在安全風險，無論它們在用戶手中出現錯誤還是落在用戶的範圍之外。
有關暗數據的大多數爭論都傾向於集中於組織的潛在價值和有用性。實際上，對於願意花費資本（資金、設備和時間）來創建和利用暗數據中鎖定的知識和興趣的組織，這些前景無疑是有利可圖的。 這也說明了為什麼許多公司儘管不打算代表他們工作，卻拒絕在短期內或在計劃過程中進一步交換黑暗的細節。
就像許多潛在的富有吸引力的信息資源一樣，企業還必須意識到，暗數據或者關於暗數據及其客戶和他們的雲運營的暗數據，可能會給他們持續的健康和福祉帶來風險，超出了他們的直接控制和管理範圍。根據最近的研究，有40％的組織仍處於有關容器環境的安全策略的規劃或基本階段。
6.容器與容器編排
如果你使用容器在表面上開發應用程序或將現有的單源（單片）應用程序帶入容器化的生態系統，則必須理解容器環境會帶來奇怪的安全威脅。從第一天開始，你就應該準備好應對這些威脅。開始構建自己的容器，該容器將在生產行業中安裝和運行。
以下是最常見的容器安全風險：
- 特權標誌：即使是那些對容器有深入瞭解的人也可以知道特權容器的含義。使用特權標誌的容器幾乎可以執行服務器可以執行的任何操作，執行並獲得對客戶端資源的訪問。這意味著，如果入侵者進入一組受保護的標誌箱，則它們可能會被破壞。
- 無限制的交互：為了實現其目標，容器必須彼此交互。但是，容器和微服務的數量以及容器的短暫設計通常意味著，要執行符合最低權限概念的聯網或防火牆法規可能會很困難。但是，你的目標應該是使容器只能在減少攻擊面所必需的容器中進行交互。
- 缺乏隔離：容器安全是一把雙刃劍。除了使用壽命短和功能受限外，它們的不變性質還提供了各種安全優勢。但是容器也可以用來攻擊主機。我們之前討論過，這種危險存在於帶有特權標誌的容器中。基礎主機可能會受到許多其他錯誤配置的威脅。
確保全面安全
為了接近雲原生的安全性，最好不要使用傳統的手動安全技術。此外，為了建立成功的DevSecOps，IT部門應將重點放在自動化和安全人員融入DevOps團隊中。由於其在容器基礎結構中的微服務體系結構軟件包，因此基於雲的應用程序可以比傳統應用程序更快地擴展。以上意味著手動安全方法太慢而無法保留，並且自動化是強制性的。將安全團隊歸入DevOps組可確保安全性包含在應用程序代碼中，而不是一旦發現問題便進行修改。這也可以加快並澄清對問題的響應。
讓我們談談五個DevSecOps支柱，這些支柱在確保全面網絡安全方面具有重大潛力：
- 安全合規的部署管道：分析工具、集成管道以及如何將合規性和審核融入到DevSecOps和Cloud-Native Development的管道中。
- 安全且合規的雲平臺：身份和訪問管理評估、檢測控制、基礎結構保護、數據保護和響應事件。
- 代碼一致性：在軟件開發過程中，合規性被視為代碼框架，以確保管理、合規性和任何風險緩解問題。
- 機密信息管理：在混合雲業務模型中管理基於雲的敏感信息、密鑰和證書。
- 容器隱私：容器如何適應安全策略，如何鏈接容器安全威脅以及如何審查容器操作模型和檢查。
所有這些支柱都是側重點領域，因此，始終地、完全地應用了業務安全，並且需要進一步進行審查。為了提供每個實施支柱的跨部門願景，對所有支柱進行橫向治理。這些治理模型適用於每個支柱，並確保支柱以互惠互利的方式運作。
- 受保護的交付：確保支持的應用程序平臺和雲基礎架構穩定、合規且安全。
- 安全模式 ：開發安全位置和威脅模型以支持客戶的多樣化接受。
- 信息保護：確保內部和外部員工不受客戶數據的保護。
- 風險評估：包括當前體系結構、容器策略和雲基礎架構，並對應用程序進行差距分析。
- 技術變更日誌：創建有序的戰術執行積壓，通過交付工程結果來推動3-6個月的路線圖和戰略實施計劃。
對新安全原型的需求
統計數據顯示，到2021年，將有92％的公司成為雲原生公司。
話雖如此，通常使組織陷入困境的是為它構建一個5000美元的應用程序和一個5美元的安全系統。就雲安全性而言，安全性同等或是一個更重要的因素。因此，DevSecOps的概念需要儘早實施並認真對待。
DevSecOps在應用程序開發過程的所有階段均提供合規性，並負責設計和安裝應用程序。首先要評估團隊或實體的性質，並建立代表該團隊或實體的程序。
第一步是在團隊之間分配孤島，以確保每個人都對保護負責。由於開發團隊出於安全原因構建應用程序，因此Ops將更快地交付軟件，並且使你高枕無憂，因為他們理解開發人員知道穩定性和保護至關重要。
實際上，必須有可以立即進行安全檢查的過程。
服務器記錄表明誰進行了修改、進行了哪些更改以及何時進行了更改，這些都是在審核程序時要知道的所有重要事實。保持保護的最簡單方法是始終保證系統運行最新的軟件更新。安全修復程序無需花費數月的時間，並且應該是快速而自動的。同樣，在開發API和新功能時，應進行潛在的更新，以防止軟件承擔責任並阻止框架打補丁以防止崩潰。
創建雲原生應用程序時，仍然沒有單一的安全方法來保護你的軟件。為了保護雲中的服務器資源，你需要採取多方面的方法。為了保護你的容器，你需要採取幾種策略。歸根結底，要將安全放在適當的優先級列表中，你需要DevSecOps策略。
理想的雲原生安全框架會是什麼樣？
為了允許基於雲的轉換，公司需要在設計安全策略之前考慮以下進一步要求：
- 高標準的安全自動化：常規的基於預防措施的安全操作根本無法使基於雲的系統保持幾乎無限的動態性。根本不是手動工作流程的選擇。對雲原生安全性的需求是自動檢測和大規模靈敏性。
- 混沌設計：在微服務架構中，運行時組合在一起的許多軟件組件可以用於任何功能。從安全的角度來看，這意味著檢測和控制的邏輯不能依賴於對操作安全性的事先了解。雲原生安全性應該包含混沌工程的原理——高效、有效地運行測試等。
- 快速識別，涵蓋本地並立即追蹤：雲原生程序本質上是分配了計算應用程序。在這樣的生態系統中，隨後無法輕鬆執行全局安全性選擇。因此，你希望確定措施的優先級，使你能夠在系統範圍的惡意趨勢蔓延之前迅速識別，恢復並涵蓋本地影響。儘管你的安全決策並非100％準確，但是本地操作和快速恢復可以為你提供更兼容的現有系統。
隨後，你的雲解決方案應具有哪些原生安全性？簡而言之，讓我們關注編譯器功能。作者認為主要功能如下：
- 混合堆棧可見性和決策支持
在服務器、VM、數據庫、軟件和API服務中，即使分佈了應用程序，但短期內還是動態資源和容器，仍需要雲原生數據中心中的可見性和決策支持。在這些不同層上獲得的數據應該進入引擎，以便實時進行選擇過程。
- 快速反應和警告功能可限制爆炸半徑
萬一發生事故或襲擊，安全解決方案將減輕並控制影響。這種論點等同於迅速的決策和有見地的控制措施，可以在發生不可逆轉的破壞之前阻止惡意行為。在雲原生環境中，智能檢測系統可以完全識別入侵的出現並影響本地控制。
- 嚴密監控與調查
由於所有分佈式組件和API服務，雲本機工作負載安全調查可能會很複雜，因此監視和安全調查必須最大程度地降低性能影響和存儲要求。這包括一個集中的監視體系結構，沒有網絡瓶頸，並且工作負載可以擴展。
- 與自動化工具集成
容器工作負載可以在雲原生環境中由Kubernetes、Openshift、Amazon ECS或Google GKE管理。你可以（可選）使用Puppet、Ansible或Chef自動執行部署。安全工具可以與要保護的工作負載一起自動部署，雲環境必須是與此類組件的必備集成。
對於替換第一代物理服務器和虛擬機的事件驅動的容器和應用程序，安全性必須找到正確的切入點，以最大化可視性並降低風險，同時允許創造力和適應連續雲交付的複雜性。
結論
從整體環境遷移到雲原生環境確實聽起來很吸引人，但是一旦決定這樣做，請確保評估可能出現的所有安全問題，評估是否有足夠的資源和團隊來處理這些問題。而且最重要的是，如果要實現這種轉變，你的企業才能真正脫穎而出並發展壯大。
希望這篇文章對你有用，歡迎評論區和我們討論。
☞微信 QQ 小程序因違規被封；微軟大破全球最大殭屍網絡；VS Code 1.43 發佈 | 極客頭條
☞官宣！阿里進軍 5G，成立 XG 實驗室發力新基建
☞前沿技術探秘：知識圖譜構建流程及方法
☞留德武漢程序員在疫區：凌晨下載數據，網速影響工作
☞雲原生的漏洞與威脅有哪些？雲原生安全性如何？這裡有你想知道的一切！
☞編程小白模擬簡易比特幣系統，手把手帶你寫一波！（附代碼） | 博文精選
閱讀更多 CSDN 的文章
