在當(dāng)今時(shí)代，企業(yè)網(wǎng)絡(luò)和數(shù)據(jù)安全風(fēng)險(xiǎn)從未像現(xiàn)在這樣具有里程碑意義。盡管如此，傳統(tǒng)方法（包括公有云運(yùn)營(yíng)商使用的方法）基本上是相同的。
云原生應(yīng)用的興起及其安全威脅
在當(dāng)今時(shí)代，企業(yè)網(wǎng)絡(luò)和數(shù)據(jù)安全風(fēng)險(xiǎn)從未像現(xiàn)在這樣具有里程碑意義。盡管如此，傳統(tǒng)方法（包括公有云運(yùn)營(yíng)商使用的方法）基本上是相同的。
轉(zhuǎn)向應(yīng)對(duì)威脅攻擊而不是阻止威脅的反應(yīng)措施。云原生應(yīng)用程序日益受到重視，用各種可能的方式質(zhì)疑了傳統(tǒng)智慧。
從基礎(chǔ)架構(gòu)到應(yīng)用程序的開(kāi)發(fā)，堆棧在傳統(tǒng)方法與更現(xiàn)代的基于云的方法之間形成了鮮明的對(duì)比，其中大多數(shù)已對(duì)成功的模式和實(shí)踐達(dá)成了主流觀(guān)點(diǎn)：DevOps文化、持續(xù)交付和微服務(wù)架構(gòu) 。為什么我們還沒(méi)有重新構(gòu)想云原生的安全性呢？我們對(duì)此大膽的新想法在哪里呢？
可以肯定地說(shuō)，在交付應(yīng)用程序的過(guò)程中，云原生的安全性一直在被長(zhǎng)期追蹤。傳統(tǒng)的IT安全團(tuán)隊(duì)將自己視為中間人。他們必須正確地完成工作，否則將面臨代理機(jī)構(gòu)所面臨的更大風(fēng)險(xiǎn)。
它們?cè)谒羞^(guò)程中都對(duì)安全性有很高的要求，但是要滿(mǎn)足這些級(jí)別需要花費(fèi)時(shí)間、測(cè)試和修訂。因?yàn)檫@會(huì)延遲應(yīng)用程序的開(kāi)發(fā)并且通常不能確保全面的保護(hù)，所以開(kāi)發(fā)團(tuán)隊(duì)經(jīng)常會(huì)抱怨。
當(dāng)組織希望提高和加快應(yīng)用程序改進(jìn)生命周期并調(diào)度云原生應(yīng)用程序時(shí)，安全將成為更為突出的測(cè)試。大部分云原生應(yīng)用程序都在新模型中運(yùn)行，這些模型可提供非常規(guī)的生產(chǎn)力、適應(yīng)性和成本優(yōu)勢(shì)。
使用dev-ops進(jìn)行開(kāi)發(fā)的云原生進(jìn)一步將DevSecOps作為其安全組件。DevSecOps試圖將安全納入速度、敏捷性和連續(xù)交付流程中。但是，如果DevSecOps忽略了集成、業(yè)務(wù)流程功能和控制，并且對(duì)用戶(hù)的安全性較低，則可能很難在連續(xù)交付系統(tǒng)中提供安全性。
云原生漏洞
云原生肯定會(huì)發(fā)生漏洞。我們是人類(lèi)，肯定會(huì)犯錯(cuò)誤，尤其是在苛刻的期限和產(chǎn)品交付之后。盡管有全部的警告、標(biāo)志和注意事項(xiàng)，我們也會(huì)做出一些錯(cuò)誤的判斷。
在發(fā)出警告的過(guò)程中，人們繼續(xù)盲目地從Stack Exchange復(fù)制和粘貼，來(lái)掩蓋在GitHub上發(fā)現(xiàn)的應(yīng)用程序，甚至隨機(jī)地將代碼從一個(gè)毫無(wú)頭緒的文件夾中隨機(jī)拉出，并且只能懷疑地認(rèn)為該作者從未遇到過(guò)或甚至沒(méi)有與之交談過(guò)的第三方。
微服務(wù)應(yīng)用程序的分布式性質(zhì)意味著，即使在內(nèi)部編寫(xiě)所有代碼的情況下，通過(guò)消除第三方參與者的風(fēng)險(xiǎn)，不同的組件也可能由不同的團(tuán)隊(duì)擁有。
團(tuán)隊(duì)之間的溝通障礙會(huì)導(dǎo)致一系列問(wèn)題，包括在測(cè)試、質(zhì)量保證甚至應(yīng)用程序中的漏洞解決方面缺乏協(xié)調(diào)。
一個(gè)單獨(dú)的云原生應(yīng)用程序可以包括分散在眾多基礎(chǔ)上的數(shù)千個(gè)剩余任務(wù)。在本地?cái)?shù)據(jù)中心、眾多公有云和邊緣數(shù)據(jù)中心中可能會(huì)有奇異的微服務(wù)，最后，在組織領(lǐng)域中，我們目前似乎還無(wú)法發(fā)展。
每個(gè)開(kāi)發(fā)人員和每個(gè)開(kāi)發(fā)團(tuán)隊(duì)都知道并了解如何解決不同的問(wèn)題。他們所做的就是相應(yīng)地培養(yǎng)他們的注意力和知識(shí)。在內(nèi)部代碼環(huán)境中，即使所有部門(mén)都以某種方式保護(hù)自己的更廣泛程序的一部分，微服務(wù)也必須與其他部門(mén)聯(lián)系，并且通信在這里是風(fēng)險(xiǎn)或脆弱性。
這些所有說(shuō)法聽(tīng)起來(lái)都令人生畏和令人恐懼，但云原生確實(shí)解決了一些非常復(fù)雜的現(xiàn)實(shí)問(wèn)題，我們?cè)僖膊荒芎鲆曀拇嬖?。隨著我們不斷升級(jí)其安全性，云原生的漏洞正在不斷發(fā)展并一直存在。
對(duì)云原生應(yīng)用程序的主要威脅
盡管公司開(kāi)始體驗(yàn)云原生應(yīng)用程序的優(yōu)勢(shì)，但他們對(duì)處理和維護(hù)此類(lèi)系統(tǒng)的實(shí)際方面卻知之甚少。與在云環(huán)境中相比，保護(hù)的后果是否與傳統(tǒng)系統(tǒng)相比有很大不同？防護(hù)措施和保障措施如何對(duì)其產(chǎn)生影響？
以下是基于云的環(huán)境的一些最高安全性問(wèn)題：
1.云配置錯(cuò)誤
IaaS和云數(shù)據(jù)存儲(chǔ)的配置錯(cuò)誤是當(dāng)今一些最具破壞性的云違規(guī)和數(shù)據(jù)泄露的主要原因。無(wú)論你要?jiǎng)h除結(jié)構(gòu)化的云安全設(shè)置、使用通用代碼、無(wú)限制地訪(fǎng)問(wèn)某些資源還是其他任何原因，配置錯(cuò)誤問(wèn)題都會(huì)導(dǎo)致許多未知威脅，這些威脅僅在尷尬的遭遇后經(jīng)常在報(bào)紙上看到。最新的《 2019年云安全報(bào)告》稱(chēng)，大約40％的組織認(rèn)為錯(cuò)誤配置云平臺(tái)是他們對(duì)網(wǎng)絡(luò)安全的主要關(guān)注點(diǎn)。
2.商業(yè)化管理的IT
不用擔(dān)心“影子IT”或“流氓IT”。毫不夸張地說(shuō)， 幾家公司將基礎(chǔ)架構(gòu)的收購(gòu)趨勢(shì)標(biāo)記為，將獲得和運(yùn)營(yíng)云服務(wù)的業(yè)務(wù)橋梁客戶(hù)稱(chēng)為“商業(yè)化管理的IT”，以及創(chuàng)造力和發(fā)展的引擎?！?Harvey Nash /畢馬威CIO 2019調(diào)查》報(bào)告稱(chēng)，目前有超過(guò)三分之二的公司為企業(yè)推廣或允許IT管理。這是因?yàn)檫@樣做的公司擊敗行業(yè)競(jìng)爭(zhēng)對(duì)手的能力提高了52％，提供更好的員工服務(wù)的可能性提高了38％。
令人擔(dān)憂(yōu)的是，如果沒(méi)有信息和網(wǎng)絡(luò)安全專(zhuān)業(yè)人員的合作，這些云技術(shù)孤島可能成為組織的巨大安全障礙。這些公司的發(fā)展速度相當(dāng)快，但調(diào)查顯示，冗余的安全隱患波長(zhǎng)的可能性是后者的兩倍。
3.購(gòu)買(mǎi)多云產(chǎn)品
《云保護(hù)聯(lián)盟報(bào)告》顯示，大多數(shù)公司都依賴(lài)各種各樣供應(yīng)商的云環(huán)境來(lái)購(gòu)買(mǎi)多云產(chǎn)品。大約66％的公司具有多云設(shè)置，其中大約36％取決于多云和混合系統(tǒng)的混合。
目前，由于云實(shí)際上是希望降低其運(yùn)營(yíng)處理成本的所有其他企業(yè)的首選工具，因此云計(jì)算向其云消費(fèi)者提供一系列服務(wù)（SaaS、PaaS、IaaS）。云在其整個(gè)上下文中提供安全、迅速響應(yīng)和服務(wù)質(zhì)量。但是，每次用戶(hù)無(wú)法從一個(gè)云遷移到另一個(gè)云時(shí)，它都會(huì)保持成本和QoS可伸縮性。為了克服這種多云計(jì)算框架，引入了基于云的系統(tǒng)之間的資源動(dòng)態(tài)共享。在多云設(shè)備中，安全性甚至是一個(gè)更為復(fù)雜的問(wèn)題。
4.混合架構(gòu)
根據(jù)著名的《云安全聯(lián)盟報(bào)告》，大約55％的組織擁有復(fù)雜的、混合操作的云計(jì)算環(huán)境。該系統(tǒng)為大型組織提供了一種逐步過(guò)渡到云的絕佳方法，但是當(dāng)他們難以跟蹤整個(gè)架構(gòu)中的資產(chǎn)并監(jiān)視眾多混合云連接的活動(dòng)時(shí)，它給安全性帶來(lái)了挑戰(zhàn)。實(shí)際上，F(xiàn)iremon先前發(fā)布的一份報(bào)告顯示，80％的組織都在挑戰(zhàn)混合安全監(jiān)控和管理工具的局限性和復(fù)雜性。
5.暗數(shù)據(jù)
就像電信行業(yè)的暗光纖一樣，暗數(shù)據(jù)也適用于企業(yè)和商業(yè)。這里有大量未開(kāi)發(fā)的、大多是不受監(jiān)管的數(shù)據(jù)，它們只是存在而已，什么也沒(méi)做。
不幸的是，盡管暗光纖明確代表了僅點(diǎn)亮即可增加功率和帶寬的優(yōu)點(diǎn)，即使被識(shí)別和忽略，暗數(shù)據(jù)也可能存在安全風(fēng)險(xiǎn)，無(wú)論它們?cè)谟脩?hù)手中出現(xiàn)錯(cuò)誤還是落在用戶(hù)的范圍之外。
有關(guān)暗數(shù)據(jù)的大多數(shù)爭(zhēng)論都傾向于集中于組織的潛在價(jià)值和有用性。實(shí)際上，對(duì)于愿意花費(fèi)資本（資金、設(shè)備和時(shí)間）來(lái)創(chuàng)建和利用暗數(shù)據(jù)中鎖定的知識(shí)和興趣的組織，這些前景無(wú)疑是有利可圖的。這也說(shuō)明了為什么許多公司盡管不打算代表他們工作，卻拒絕在短期內(nèi)或在計(jì)劃過(guò)程中進(jìn)一步交換黑暗的細(xì)節(jié)。
就像許多潛在的富有吸引力的信息資源一樣，企業(yè)還必須意識(shí)到，暗數(shù)據(jù)或者關(guān)于暗數(shù)據(jù)及其客戶(hù)和他們的云運(yùn)營(yíng)的暗數(shù)據(jù)，可能會(huì)給他們持續(xù)的健康和福祉帶來(lái)風(fēng)險(xiǎn)，超出了他們的直接控制和管理范圍。根據(jù)最近的研究，有40％的組織仍處于有關(guān)容器環(huán)境的安全策略的規(guī)劃或基本階段。
6.容器與容器編排
如果你使用容器在表面上開(kāi)發(fā)應(yīng)用程序或?qū)F(xiàn)有的單源（單片）應(yīng)用程序帶入容器化的生態(tài)系統(tǒng)，則必須理解容器環(huán)境會(huì)帶來(lái)奇怪的安全威脅。從第一天開(kāi)始，你就應(yīng)該準(zhǔn)備好應(yīng)對(duì)這些威脅。開(kāi)始構(gòu)建自己的容器，該容器將在生產(chǎn)行業(yè)中安裝和運(yùn)行。
以下是最常見(jiàn)的容器安全風(fēng)險(xiǎn)：
特權(quán)標(biāo)志：即使是那些對(duì)容器有深入了解的人也可以知道特權(quán)容器的含義。使用特權(quán)標(biāo)志的容器幾乎可以執(zhí)行服務(wù)器可以執(zhí)行的任何操作，執(zhí)行并獲得對(duì)客戶(hù)端資源的訪(fǎng)問(wèn)。這意味著，如果入侵者進(jìn)入一組受保護(hù)的標(biāo)志箱，則它們可能會(huì)被破壞。
無(wú)限制的交互：為了實(shí)現(xiàn)其目標(biāo)，容器必須彼此交互。但是，容器和微服務(wù)的數(shù)量以及容器的短暫設(shè)計(jì)通常意味著，要執(zhí)行符合最低權(quán)限概念的聯(lián)網(wǎng)或防火墻法規(guī)可能會(huì)很困難。但是，你的目標(biāo)應(yīng)該是使容器只能在減少攻擊面所必需的容器中進(jìn)行交互。
缺乏隔離：容器安全是一把雙刃劍。除了使用壽命短和功能受限外，它們的不變性質(zhì)還提供了各種安全優(yōu)勢(shì)。但是容器也可以用來(lái)攻擊主機(jī)。我們之前討論過(guò)，這種危險(xiǎn)存在于帶有特權(quán)標(biāo)志的容器中?；A(chǔ)主機(jī)可能會(huì)受到許多其他錯(cuò)誤配置的威脅。
確保全面安全
為了接近云原生的安全性，最好不要使用傳統(tǒng)的手動(dòng)安全技術(shù)。此外，為了建立成功的DevSecOps，IT部門(mén)應(yīng)將重點(diǎn)放在自動(dòng)化和安全人員融入DevOps團(tuán)隊(duì)中。由于其在容器基礎(chǔ)結(jié)構(gòu)中的微服務(wù)體系結(jié)構(gòu)軟件包，因此基于云的應(yīng)用程序可以比傳統(tǒng)應(yīng)用程序更快地?cái)U(kuò)展。以上意味著手動(dòng)安全方法太慢而無(wú)法保留，并且自動(dòng)化是強(qiáng)制性的。將安全團(tuán)隊(duì)歸入DevOps組可確保安全性包含在應(yīng)用程序代碼中，而不是一旦發(fā)現(xiàn)問(wèn)題便進(jìn)行修改。這也可以加快并澄清對(duì)問(wèn)題的響應(yīng)。
讓我們談?wù)勎鍌€(gè)DevSecOps支柱，這些支柱在確保全面網(wǎng)絡(luò)安全方面具有重大潛力：
安全合規(guī)的部署管道：分析工具、集成管道以及如何將合規(guī)性和審核融入到DevSecOps和Cloud-Native Development的管道中。
安全且合規(guī)的云平臺(tái)：身份和訪(fǎng)問(wèn)管理評(píng)估、檢測(cè)控制、基礎(chǔ)結(jié)構(gòu)保護(hù)、數(shù)據(jù)保護(hù)和響應(yīng)事件。
代碼一致性：在軟件開(kāi)發(fā)過(guò)程中，合規(guī)性被視為代碼框架，以確保管理、合規(guī)性和任何風(fēng)險(xiǎn)緩解問(wèn)題。
機(jī)密信息管理：在混合云業(yè)務(wù)模型中管理基于云的敏感信息、密鑰和證書(shū)。
容器隱私：容器如何適應(yīng)安全策略，如何鏈接容器安全威脅以及如何審查容器操作模型和檢查。
所有這些支柱都是側(cè)重點(diǎn)領(lǐng)域，因此，始終地、完全地應(yīng)用了業(yè)務(wù)安全，并且需要進(jìn)一步進(jìn)行審查。為了提供每個(gè)實(shí)施支柱的跨部門(mén)愿景，對(duì)所有支柱進(jìn)行橫向治理。這些治理模型適用于每個(gè)支柱，并確保支柱以互惠互利的方式運(yùn)作。
受保護(hù)的交付：確保支持的應(yīng)用程序平臺(tái)和云基礎(chǔ)架構(gòu)穩(wěn)定、合規(guī)且安全。
安全模式：開(kāi)發(fā)安全位置和威脅模型以支持客戶(hù)的多樣化接受。
信息保護(hù)：確保內(nèi)部和外部員工不受客戶(hù)數(shù)據(jù)的保護(hù)。
風(fēng)險(xiǎn)評(píng)估：包括當(dāng)前體系結(jié)構(gòu)、容器策略和云基礎(chǔ)架構(gòu)，并對(duì)應(yīng)用程序進(jìn)行差距分析。
技術(shù)變更日志：創(chuàng)建有序的戰(zhàn)術(shù)執(zhí)行積壓，通過(guò)交付工程結(jié)果來(lái)推動(dòng)3-6個(gè)月的路線(xiàn)圖和戰(zhàn)略實(shí)施計(jì)劃。
對(duì)新安全原型的需求
統(tǒng)計(jì)數(shù)據(jù)顯示，到2021年，將有92％的公司成為云原生公司。
話(huà)雖如此，通常使組織陷入困境的是為它構(gòu)建一個(gè)5000美元的應(yīng)用程序和一個(gè)5美元的安全系統(tǒng)。就云安全性而言，安全性同等或是一個(gè)更重要的因素。因此，DevSecOps的概念需要盡早實(shí)施并認(rèn)真對(duì)待。
DevSecOps在應(yīng)用程序開(kāi)發(fā)過(guò)程的所有階段均提供合規(guī)性，并負(fù)責(zé)設(shè)計(jì)和安裝應(yīng)用程序。首先要評(píng)估團(tuán)隊(duì)或?qū)嶓w的性質(zhì)，并建立代表該團(tuán)隊(duì)或?qū)嶓w的程序。
第一步是在團(tuán)隊(duì)之間分配孤島，以確保每個(gè)人都對(duì)保護(hù)負(fù)責(zé)。由于開(kāi)發(fā)團(tuán)隊(duì)出于安全原因構(gòu)建應(yīng)用程序，因此Ops將更快地交付軟件，并且使你高枕無(wú)憂(yōu)，因?yàn)樗麄兝斫忾_(kāi)發(fā)人員知道穩(wěn)定性和保護(hù)至關(guān)重要。
實(shí)際上，必須有可以立即進(jìn)行安全檢查的過(guò)程。
服務(wù)器記錄表明誰(shuí)進(jìn)行了修改、進(jìn)行了哪些更改以及何時(shí)進(jìn)行了更改，這些都是在審核程序時(shí)要知道的所有重要事實(shí)。保持保護(hù)的最簡(jiǎn)單方法是始終保證系統(tǒng)運(yùn)行最新的軟件更新。安全修復(fù)程序無(wú)需花費(fèi)數(shù)月的時(shí)間，并且應(yīng)該是快速而自動(dòng)的。同樣，在開(kāi)發(fā)API和新功能時(shí)，應(yīng)進(jìn)行潛在的更新，以防止軟件承擔(dān)責(zé)任并阻止框架打補(bǔ)丁以防止崩潰。
創(chuàng)建云原生應(yīng)用程序時(shí)，仍然沒(méi)有單一的安全方法來(lái)保護(hù)你的軟件。為了保護(hù)云中的服務(wù)器資源，你需要采取多方面的方法。為了保護(hù)你的容器，你需要采取幾種策略。歸根結(jié)底，要將安全放在適當(dāng)?shù)膬?yōu)先級(jí)列表中，你需要DevSecOps策略。
理想的云原生安全框架會(huì)是什么樣？
為了允許基于云的轉(zhuǎn)換，公司需要在設(shè)計(jì)安全策略之前考慮以下進(jìn)一步要求：
高標(biāo)準(zhǔn)的安全自動(dòng)化：常規(guī)的基于預(yù)防措施的安全操作根本無(wú)法使基于云的系統(tǒng)保持幾乎無(wú)限的動(dòng)態(tài)性。根本不是手動(dòng)工作流程的選擇。對(duì)云原生安全性的需求是自動(dòng)檢測(cè)和大規(guī)模靈敏性。
混沌設(shè)計(jì)：在微服務(wù)架構(gòu)中，運(yùn)行時(shí)組合在一起的許多軟件組件可以用于任何功能。從安全的角度來(lái)看，這意味著檢測(cè)和控制的邏輯不能依賴(lài)于對(duì)操作安全性的事先了解。云原生安全性應(yīng)該包含混沌工程的原理——高效、有效地運(yùn)行測(cè)試等。
快速識(shí)別，涵蓋本地并立即追蹤：云原生程序本質(zhì)上是分配了計(jì)算應(yīng)用程序。在這樣的生態(tài)系統(tǒng)中，隨后無(wú)法輕松執(zhí)行全局安全性選擇。因此，你希望確定措施的優(yōu)先級(jí)，使你能夠在系統(tǒng)范圍的惡意趨勢(shì)蔓延之前迅速識(shí)別，恢復(fù)并涵蓋本地影響。盡管你的安全決策并非100％準(zhǔn)確，但是本地操作和快速恢復(fù)可以為你提供更兼容的現(xiàn)有系統(tǒng)。
隨后，你的云解決方案應(yīng)具有哪些原生安全性？簡(jiǎn)而言之，讓我們關(guān)注編譯器功能。作者認(rèn)為主要功能如下：
混合堆?？梢?jiàn)性和決策支持
在服務(wù)器、VM、數(shù)據(jù)庫(kù)、軟件和API服務(wù)中，即使分布了應(yīng)用程序，但短期內(nèi)還是動(dòng)態(tài)資源和容器，仍需要云原生數(shù)據(jù)中心中的可見(jiàn)性和決策支持。在這些不同層上獲得的數(shù)據(jù)應(yīng)該進(jìn)入引擎，以便實(shí)時(shí)進(jìn)行選擇過(guò)程。
快速反應(yīng)和警告功能可限制爆炸半徑
萬(wàn)一發(fā)生事故或襲擊，安全解決方案將減輕并控制影響。這種論點(diǎn)等同于迅速的決策和有見(jiàn)地的控制措施，可以在發(fā)生不可逆轉(zhuǎn)的破壞之前阻止惡意行為。在云原生環(huán)境中，智能檢測(cè)系統(tǒng)可以完全識(shí)別入侵的出現(xiàn)并影響本地控制。
嚴(yán)密監(jiān)控與調(diào)查
由于所有分布式組件和API服務(wù)，云本機(jī)工作負(fù)載安全調(diào)查可能會(huì)很復(fù)雜，因此監(jiān)視和安全調(diào)查必須最大程度地降低性能影響和存儲(chǔ)要求。這包括一個(gè)集中的監(jiān)視體系結(jié)構(gòu)，沒(méi)有網(wǎng)絡(luò)瓶頸，并且工作負(fù)載可以擴(kuò)展。
與自動(dòng)化工具集成
容器工作負(fù)載可以在云原生環(huán)境中由Kubernetes、Openshift、Amazon ECS或Google GKE管理。你可以（可選）使用Puppet、Ansible或Chef自動(dòng)執(zhí)行部署。安全工具可以與要保護(hù)的工作負(fù)載一起自動(dòng)部署，云環(huán)境必須是與此類(lèi)組件的必備集成。
對(duì)于替換第一代物理服務(wù)器和虛擬機(jī)的事件驅(qū)動(dòng)的容器和應(yīng)用程序，安全性必須找到正確的切入點(diǎn)，以最大化可視性并降低風(fēng)險(xiǎn)，同時(shí)允許創(chuàng)造力和適應(yīng)連續(xù)云交付的復(fù)雜性。
結(jié)論
從整體環(huán)境遷移到云原生環(huán)境確實(shí)聽(tīng)起來(lái)很吸引人，但是一旦決定這樣做，請(qǐng)確保評(píng)估可能出現(xiàn)的所有安全問(wèn)題，評(píng)估是否有足夠的資源和團(tuán)隊(duì)來(lái)處理這些問(wèn)題。而且最重要的是，如果要實(shí)現(xiàn)這種轉(zhuǎn)變，你的企業(yè)才能真正脫穎而出并發(fā)展壯大。
