（一） IDC機房安全防護
成都創(chuàng)新互聯(lián)服務項目包括泌陽網(wǎng)站建設、泌陽網(wǎng)站制作、泌陽網(wǎng)頁制作以及泌陽網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，泌陽網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到泌陽省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！
IDC機房防火墻可預防所有常見的攻擊。我們在給客戶部署我們?nèi)萜髟飘a(chǎn)品時，會遞交一份產(chǎn)品網(wǎng)絡規(guī)劃說明。說明書上詳細說明的產(chǎn)品的網(wǎng)絡拓撲圖、使用的端口號等等。我們建議客戶只開啟說明書中提到的端口號。在我們的實踐中，對于需要外網(wǎng)訪問的用戶。我們只需要開啟80端口。
部署容器云產(chǎn)品的每臺物理機器會開啟防火墻。
1. 控制授信機器之間可以互相訪問。
2. 禁用icmp協(xié)議。
使用vpn遠程訪問容器服務平臺跳板機器。由跳板機器登錄容器服務平臺所在機器進行日常運維。
（二） Docker daemon 安全
Docker daemon的安全更多是出現(xiàn)在docker engine API的防護上。我們在docker daemon做如下配置
1. 配置tls方式訪問docker daemon
2. http remote api 綁定IP地址（只用戶內(nèi)網(wǎng)調(diào)度系統(tǒng)訪問）
3. 使用非root用戶運行docker daemon。例如：創(chuàng)建docker:docker 用戶與用戶組。
（三） 鏡像安全
我們的私有容器云服務鏡像來源于兩個地方：客戶自行構(gòu)建的鏡像與我們的公有云鏡像中心。
1. 客戶自行構(gòu)建的鏡像
客戶自行構(gòu)建的鏡像有兩種方式，一種是通過我們?nèi)萜髟破脚_定制的模板來構(gòu)建。這種方式下，基礎鏡像由平臺提供，安全最有保證。另外一種由用戶編寫Dockerfile自行構(gòu)建的鏡像。此類鏡像我們通過兩種手段來保障容器的安全：人工審核與在線安全掃描。我們會不定期通知用戶更新我們的鏡像安全掃描特征庫來保證鏡像的安全。
2. 我們的共有云鏡像中心
目前，公有云鏡像中心中的鏡像全部由我們研發(fā)團隊與安全管控團隊制作，幾乎不會存在安全問題的。公有云鏡像中心，主要是提供工具類相關(guān)的鏡像，譬如：緩存、redis、mongodb、微服務架構(gòu)等等。
（四） 容器安全
我們主要從以下幾個部分管控容器安全。
1. 網(wǎng)絡安全
不同用戶之間容器網(wǎng)絡隔離。默認，不同用戶的容器與容器之間不能互相訪問；同一用戶的所有容器可以互相訪問。
容器與宿主機網(wǎng)絡隔離。默認，容器是不能網(wǎng)絡內(nèi)網(wǎng)環(huán)境下任何一臺宿主機。
2. 數(shù)據(jù)安全
宿主機掛在目錄。用戶通過統(tǒng)一運維管理平臺，只能將固定目錄掛在到容器中。
不同容器之間文件共享。用戶通過統(tǒng)一運維管理平臺，可以將自己的數(shù)據(jù)分享給指定的容器（或者其他用戶）。
分布式文件系統(tǒng)。用戶通過統(tǒng)一運維管理平臺申請數(shù)據(jù)文件。通過apikey/secrekey訪問平臺提供的分布式文件存儲。
3. 進程安全
采用docker 默認隔離策略。
以Docker 容器的安全問題為例
(1) Docker 自身安全
Docker 作為一款容器引擎，本身也會存在一些安全漏洞，CVE 目前已經(jīng)記錄了多項與 Docker 相關(guān)的安全漏洞，主要有權(quán)限提升、信息泄露等幾類安全問題。
(2) 鏡像安全
由于Docker 容器是基于鏡像創(chuàng)建并啟動，因此鏡像的安全直接影響到容器的安全。具體影響鏡像安全的總結(jié)如下。
鏡像軟件存在安全漏洞：由于容器需要安裝基礎的軟件包，如果軟件包存在漏洞，則可能會被不法分子利用并且侵入容器，影響其他容器或主機安全。
倉庫漏洞：無論是Docker 官方的鏡像倉庫還是我們私有的鏡像倉庫，都有可能被攻擊，然后篡改鏡像，當我們使用鏡像時，就可能成為攻擊者的目標對象。
用戶程序漏洞：用戶自己構(gòu)建的軟件包可能存在漏洞或者被植入惡意腳本，這樣會導致運行時提權(quán)影響其他容器或主機安全。
(3) Linux 內(nèi)核隔離性不夠
盡管目前Namespace 已經(jīng)提供了非常多的資源隔離類型，但是仍有部分關(guān)鍵內(nèi)容沒有被完全隔離，其中包括一些系統(tǒng)的關(guān)鍵性目錄（如 /sys、/proc 等），這些關(guān)鍵性的目錄可能會泄露主機上一些關(guān)鍵性的信息，讓攻擊者利用這些信息對整個主機甚至云計算中心發(fā)起攻擊。
而且僅僅依靠Namespace 的隔離是遠遠不夠的，因為一旦內(nèi)核的 Namespace 被突破，使用者就有可能直接提權(quán)獲取到主機的超級權(quán)限，從而影響主機安全。
(4) 所有容器共享主機內(nèi)核
由于同一宿主機上所有容器共享主機內(nèi)核，所以攻擊者可以利用一些特殊手段導致內(nèi)核崩潰，進而導致主機宕機影響主機上其他服務。
既然容器有這么多安全上的問題，那么我們應該如何做才能夠既享受到容器的便利性同時也可以保障容器安全呢？下面我?guī)銇碇鸩搅私庀氯绾谓鉀Q容器的安全問題。
如何解決容器的安全問題？
(1) Docker 自身安全性改進
事實上，Docker 從 2013 年誕生到現(xiàn)在，在安全性上面已經(jīng)做了非常多的努力。目前 Docker 在默認配置和默認行為下是足夠安全的。
Docker 自身是基于 Linux 的多種 Namespace 實現(xiàn)的，其中有一個很重要的 Namespace 叫作 User Namespace，User Namespace 主要是用來做容器內(nèi)用戶和主機的用戶隔離的。在過去容器里的 root 用戶就是主機上的 root 用戶，如果容器受到攻擊，或者容器本身含有惡意程序，在容器內(nèi)就可以直接獲取到主機 root 權(quán)限。Docker 從 1.10 版本開始，使用 User Namespace 做用戶隔離，實現(xiàn)了容器中的 root 用戶映射到主機上的非 root 用戶，從而大大減輕了容器被突破的風險。
因此，我們盡可能地使用Docker 最新版本就可以得到更好的安全保障。
(2) 保障鏡像安全
為保障鏡像安全，我們可以在私有鏡像倉庫安裝鏡像安全掃描組件，對上傳的鏡像進行檢查，通過與CVE 數(shù)據(jù)庫對比，一旦發(fā)現(xiàn)有漏洞的鏡像及時通知用戶或阻止非安全鏡像繼續(xù)構(gòu)建和分發(fā)。同時為了確保我們使用的鏡像足夠安全，在拉取鏡像時，要確保只從受信任的鏡像倉庫拉取，并且與鏡像倉庫通信一定要使用 HTTPS 協(xié)議。
(3) 加強內(nèi)核安全和管理
由于僅僅依賴內(nèi)核的隔離可能會引發(fā)安全問題，因此我們對于內(nèi)核的安全應該更加重視?？梢詮囊韵聨讉€方面進行加強。
宿主機及時升級內(nèi)核漏洞
宿主機內(nèi)核應該盡量安裝最新補丁，因為更新的內(nèi)核補丁往往有著更好的安全性和穩(wěn)定性。
使用Capabilities 劃分權(quán)限
Capabilities 是 Linux 內(nèi)核的概念，Linux 將系統(tǒng)權(quán)限分為了多個 Capabilities，它們都可以單獨地開啟或關(guān)閉，Capabilities 實現(xiàn)了系統(tǒng)更細粒度的訪問控制。
容器和虛擬機在權(quán)限控制上還是有一些區(qū)別的，在虛擬機內(nèi)我們可以賦予用戶所有的權(quán)限，例如設置cron 定時任務、操作內(nèi)核模塊、配置網(wǎng)絡等權(quán)限。而容器則需要針對每一項 Capabilities 更細粒度的去控制權(quán)限，例如：
cron 定時任務可以在容器內(nèi)運行，設置定時任務的權(quán)限也僅限于容器內(nèi)部；
由于容器是共享主機內(nèi)核的，因此在容器內(nèi)部一般不允許直接操作主機內(nèi)核；
容器的網(wǎng)絡管理在容器外部，這就意味著一般情況下，我們在容器內(nèi)部是不需要執(zhí)行ifconfig、route等命令的 。
由于容器可以按照需求逐項添加Capabilities 權(quán)限，因此在大多數(shù)情況下，容器并不需要主機的 root 權(quán)限，Docker 默認情況下也是不開啟額外特權(quán)的。
最后，在執(zhí)行docker run命令啟動容器時，如非特殊可控情況，–privileged 參數(shù)不允許設置為 true，其他特殊權(quán)限可以使用 --cap-add 參數(shù)，根據(jù)使用場景適當添加相應的權(quán)限。
使用安全加固組件
Linux 的 SELinux、AppArmor、GRSecurity 組件都是 Docker 官方推薦的安全加固組件。下面我對這三個組件做簡單介紹。
SELinux (Secure Enhanced Linux): 是 Linux 的一個內(nèi)核安全模塊，提供了安全訪問的策略機制，通過設置 SELinux 策略可以實現(xiàn)某些進程允許訪問某些文件。
AppArmor: 類似于 SELinux，也是一個 Linux 的內(nèi)核安全模塊，普通的訪問控制僅能控制到用戶的訪問權(quán)限，而 AppArmor 可以控制到用戶程序的訪問權(quán)限。
GRSecurity: 是一個對內(nèi)核的安全擴展，可通過智能訪問控制，提供內(nèi)存破壞防御，文件系統(tǒng)增強等多種防御形式。
這三個組件可以限制一個容器對主機的內(nèi)核或其他資源的訪問控制。目前，容器報告的一些安全漏洞中，很多都是通過對內(nèi)核進行加強訪問和隔離來實現(xiàn)的。
資源限制
在生產(chǎn)環(huán)境中，建議每個容器都添加相應的資源限制。下面給出一些執(zhí)行docker run命令啟動容器時可以傳遞的資源限制參數(shù)：
1??--cpus ?????????????????????????限制 CPU 配額
2??-m, --memory ???????????????????限制內(nèi)存配額
3??--pids-limit ???????????????????限制容器的 PID 個數(shù)
例如我想要啟動一個1 核 2G 的容器，并且限制在容器內(nèi)最多只能創(chuàng)建 1000 個 PID，啟動命令如下：
1 ?$ docker run -it --cpus=1 -m=2048m --pids-limit=1000 busybox sh
推薦在生產(chǎn)環(huán)境中限制CPU、內(nèi)存、PID 等資源，這樣即便應用程序有漏洞，也不會導致主機的資源完全耗盡，最大限度降低安全風險。
(4) 使用安全容器
容器有著輕便快速啟動的優(yōu)點，虛擬機有著安全隔離的優(yōu)點，有沒有一種技術(shù)可以兼顧兩者的優(yōu)點，做到既輕量又安全呢？
答案是有，那就是安全容器。安全容器是相較于普通容器的，安全容器與普通容器的主要區(qū)別在于，安全容器中的每個容器都運行在一個單獨的微型虛擬機中，擁有獨立的操作系統(tǒng)和內(nèi)核，并且有虛擬化層的安全隔離。
安全容器目前推薦的技術(shù)方案是Kata Containers，Kata Container 并不包含一個完整的操作系統(tǒng)，只有一個精簡版的 Guest Kernel 運行著容器本身的應用，并且通過減少不必要的內(nèi)存，盡量共享可以共享的內(nèi)存來進一步減少內(nèi)存的開銷。另外，Kata Container 實現(xiàn)了 OCI 規(guī)范，可以直接使用 Docker 的鏡像啟動 Kata 容器，具有開銷更小、秒級啟動、安全隔離等許多優(yōu)點。
作者 | Drishti Shastri
譯者 | 天道酬勤 責編 | 徐威龍
封圖| CSDN 下載于視覺中國
在當今時代，企業(yè)網(wǎng)絡和數(shù)據(jù)安全風險從未像現(xiàn)在這樣具有里程碑意義。盡管如此，傳統(tǒng)方法（包括公有云運營商使用的方法）基本上是相同的。
云原生的漏洞與威脅有哪些？安全性如何？這里有你想知道的一切
云原生應用的興起及其安全威脅
云原生的漏洞與威脅有哪些？安全性如何？這里有你想知道的一切
在當今時代，企業(yè)網(wǎng)絡和數(shù)據(jù)安全風險從未像現(xiàn)在這樣具有里程碑意義。盡管如此，傳統(tǒng)方法（包括公有云運營商使用的方法）基本上是相同的。
轉(zhuǎn)向應對威脅攻擊而不是阻止威脅的反應措施。云原生應用程序日益受到重視，用各種可能的方式質(zhì)疑了傳統(tǒng)智慧。
從基礎架構(gòu)到應用程序的開發(fā)，堆棧在傳統(tǒng)方法與更現(xiàn)代的基于云的方法之間形成了鮮明的對比，其中大多數(shù)已對成功的模式和實踐達成了主流觀點：DevOps文化、持續(xù)交付和微服務架構(gòu) 。為什么我們還沒有重新構(gòu)想云原生的安全性呢？我們對此大膽的新想法在哪里呢？
可以肯定地說，在交付應用程序的過程中，云原生的安全性一直在被長期追蹤。傳統(tǒng)的IT安全團隊將自己視為中間人。他們必須正確地完成工作，否則將面臨代理機構(gòu)所面臨的更大風險。
它們在所有過程中都對安全性有很高的要求，但是要滿足這些級別需要花費時間、測試和修訂。因為這會延遲應用程序的開發(fā)并且通常不能確保全面的保護，所以開發(fā)團隊經(jīng)常會抱怨。
當組織希望提高和加快應用程序改進生命周期并調(diào)度云原生應用程序時，安全將成為更為突出的測試。大部分云原生應用程序都在新模型中運行，這些模型可提供非常規(guī)的生產(chǎn)力、適應性和成本優(yōu)勢。
使用dev-ops進行開發(fā)的云原生進一步將DevSecOps作為其安全組件。DevSecOps試圖將安全納入速度、敏捷性和連續(xù)交付流程中。但是，如果DevSecOps忽略了集成、業(yè)務流程功能和控制，并且對用戶的安全性較低，則可能很難在連續(xù)交付系統(tǒng)中提供安全性。
云原生的漏洞與威脅有哪些？安全性如何？這里有你想知道的一切
云原生的漏洞與威脅有哪些？安全性如何？這里有你想知道的一切
云原生漏洞
云原生肯定會發(fā)生漏洞。我們是人類，肯定會犯錯誤，尤其是在苛刻的期限和產(chǎn)品交付之后。盡管有全部的警告、標志和注意事項，我們也會做出一些錯誤的判斷。
在發(fā)出警告的過程中，人們繼續(xù)盲目地從Stack Exchange復制和粘貼，來掩蓋在GitHub上發(fā)現(xiàn)的應用程序，甚至隨機地將代碼從一個毫無頭緒的文件夾中隨機拉出，并且只能懷疑地認為該作者從未遇到過或甚至沒有與之交談過的第三方。
微服務應用程序的分布式性質(zhì)意味著，即使在內(nèi)部編寫所有代碼的情況下，通過消除第三方參與者的風險，不同的組件也可能由不同的團隊擁有。
團隊之間的溝通障礙會導致一系列問題，包括在測試、質(zhì)量保證甚至應用程序中的漏洞解決方面缺乏協(xié)調(diào)。
一個單獨的云原生應用程序可以包括分散在眾多基礎上的數(shù)千個剩余任務。在本地數(shù)據(jù)中心、眾多公有云和邊緣數(shù)據(jù)中心中可能會有奇異的微服務，最后，在組織領(lǐng)域中，我們目前似乎還無法發(fā)展。
每個開發(fā)人員和每個開發(fā)團隊都知道并了解如何解決不同的問題。他們所做的就是相應地培養(yǎng)他們的注意力和知識。在內(nèi)部代碼環(huán)境中，即使所有部門都以某種方式保護自己的更廣泛程序的一部分，微服務也必須與其他部門聯(lián)系，并且通信在這里是風險或脆弱性。
這些所有說法聽起來都令人生畏和令人恐懼，但云原生確實解決了一些非常復雜的現(xiàn)實問題，我們再也不能忽視它的存在。隨著我們不斷升級其安全性，云原生的漏洞正在不斷發(fā)展并一直存在。
云原生的漏洞與威脅有哪些？安全性如何？這里有你想知道的一切
云原生的漏洞與威脅有哪些？安全性如何？這里有你想知道的一切
對云原生應用程序的主要威脅
盡管公司開始體驗云原生應用程序的優(yōu)勢，但他們對處理和維護此類系統(tǒng)的實際方面卻知之甚少。與在云環(huán)境中相比，保護的后果是否與傳統(tǒng)系統(tǒng)相比有很大不同？防護措施和保障措施如何對其產(chǎn)生影響？
以下是基于云的環(huán)境的一些最高安全性問題：
1.云配置錯誤
IaaS和云數(shù)據(jù)存儲的配置錯誤是當今一些最具破壞性的云違規(guī)和數(shù)據(jù)泄露的主要原因。無論你要刪除結(jié)構(gòu)化的云安全設置、使用通用代碼、無限制地訪問某些資源還是其他任何原因，配置錯誤問題都會導致許多未知威脅，這些威脅僅在尷尬的遭遇后經(jīng)常在報紙上看到。最新的《 2019年云安全報告》稱，大約40％的組織認為錯誤配置云平臺是他們對網(wǎng)絡安全的主要關(guān)注點。
2.商業(yè)化管理的IT
不用擔心“影子IT”或“流氓IT”。毫不夸張地說， 幾家公司將基礎架構(gòu)的收購趨勢標記為，將獲得和運營云服務的業(yè)務橋梁客戶稱為“商業(yè)化管理的IT”，以及創(chuàng)造力和發(fā)展的引擎?！?Harvey Nash /畢馬威CIO 2019調(diào)查》報告稱，目前有超過三分之二的公司為企業(yè)推廣或允許IT管理。這是因為這樣做的公司擊敗行業(yè)競爭對手的能力提高了52％，提供更好的員工服務的可能性提高了38％。
令人擔憂的是，如果沒有信息和網(wǎng)絡安全專業(yè)人員的合作，這些云技術(shù)孤島可能成為組織的巨大安全障礙。這些公司的發(fā)展速度相當快，但調(diào)查顯示，冗余的安全隱患波長的可能性是后者的兩倍。
3.購買多云產(chǎn)品
《云保護聯(lián)盟報告》顯示，大多數(shù)公司都依賴各種各樣供應商的云環(huán)境來購買多云產(chǎn)品。大約66％的公司具有多云設置，其中大約36％取決于多云和混合系統(tǒng)的混合。
目前，由于云實際上是希望降低其運營處理成本的所有其他企業(yè)的首選工具，因此云計算向其云消費者提供一系列服務（SaaS、PaaS、IaaS）。云在其整個上下文中提供安全、迅速響應和服務質(zhì)量。但是，每次用戶無法從一個云遷移到另一個云時，它都會保持成本和QoS可伸縮性。為了克服這種多云計算框架，引入了基于云的系統(tǒng)之間的資源動態(tài)共享。在多云設備中，安全性甚至是一個更為復雜的問題。
云原生的漏洞與威脅有哪些？安全性如何？這里有你想知道的一切
4.混合架構(gòu)
根據(jù)著名的《云安全聯(lián)盟報告》，大約55％的組織擁有復雜的、混合操作的云計算環(huán)境。該系統(tǒng)為大型組織提供了一種逐步過渡到云的絕佳方法，但是當他們難以跟蹤整個架構(gòu)中的資產(chǎn)并監(jiān)視眾多混合云連接的活動時，它給安全性帶來了挑戰(zhàn)。實際上，F(xiàn)iremon先前發(fā)布的一份報告顯示，80％的組織都在挑戰(zhàn)混合安全監(jiān)控和管理工具的局限性和復雜性。
5.暗數(shù)據(jù)
就像電信行業(yè)的暗光纖一樣，暗數(shù)據(jù)也適用于企業(yè)和商業(yè)。這里有大量未開發(fā)的、大多是不受監(jiān)管的數(shù)據(jù)，它們只是存在而已，什么也沒做。
不幸的是，盡管暗光纖明確代表了僅點亮即可增加功率和帶寬的優(yōu)點，即使被識別和忽略，暗數(shù)據(jù)也可能存在安全風險，無論它們在用戶手中出現(xiàn)錯誤還是落在用戶的范圍之外。
有關(guān)暗數(shù)據(jù)的大多數(shù)爭論都傾向于集中于組織的潛在價值和有用性。實際上，對于愿意花費資本（資金、設備和時間）來創(chuàng)建和利用暗數(shù)據(jù)中鎖定的知識和興趣的組織，這些前景無疑是有利可圖的。這也說明了為什么許多公司盡管不打算代表他們工作，卻拒絕在短期內(nèi)或在計劃過程中進一步交換黑暗的細節(jié)。
就像許多潛在的富有吸引力的信息資源一樣，企業(yè)還必須意識到，暗數(shù)據(jù)或者關(guān)于暗數(shù)據(jù)及其客戶和他們的云運營的暗數(shù)據(jù)，可能會給他們持續(xù)的健康和福祉帶來風險，超出了他們的直接控制和管理范圍。根據(jù)最近的研究，有40％的組織仍處于有關(guān)容器環(huán)境的安全策略的規(guī)劃或基本階段。
6.容器與容器編排
如果你使用容器在表面上開發(fā)應用程序或?qū)F(xiàn)有的單源（單片）應用程序帶入容器化的生態(tài)系統(tǒng)，則必須理解容器環(huán)境會帶來奇怪的安全威脅。從第一天開始，你就應該準備好應對這些威脅。開始構(gòu)建自己的容器，該容器將在生產(chǎn)行業(yè)中安裝和運行。
以下是最常見的容器安全風險：
特權(quán)標志：即使是那些對容器有深入了解的人也可以知道特權(quán)容器的含義。使用特權(quán)標志的容器幾乎可以執(zhí)行服務器可以執(zhí)行的任何操作，執(zhí)行并獲得對客戶端資源的訪問。這意味著，如果入侵者進入一組受保護的標志箱，則它們可能會被破壞。
無限制的交互：為了實現(xiàn)其目標，容器必須彼此交互。但是，容器和微服務的數(shù)量以及容器的短暫設計通常意味著，要執(zhí)行符合最低權(quán)限概念的聯(lián)網(wǎng)或防火墻法規(guī)可能會很困難。但是，你的目標應該是使容器只能在減少攻擊面所必需的容器中進行交互。
缺乏隔離：容器安全是一把雙刃劍。除了使用壽命短和功能受限外，它們的不變性質(zhì)還提供了各種安全優(yōu)勢。但是容器也可以用來攻擊主機。我們之前討論過，這種危險存在于帶有特權(quán)標志的容器中?；A主機可能會受到許多其他錯誤配置的威脅。
云原生的漏洞與威脅有哪些？安全性如何？這里有你想知道的一切
確保全面安全
為了接近云原生的安全性，最好不要使用傳統(tǒng)的手動安全技術(shù)。此外，為了建立成功的DevSecOps，IT部門應將重點放在自動化和安全人員融入DevOps團隊中。由于其在容器基礎結(jié)構(gòu)中的微服務體系結(jié)構(gòu)軟件包，因此基于云的應用程序可以比傳統(tǒng)應用程序更快地擴展。以上意味著手動安全方法太慢而無法保留，并且自動化是強制性的。將安全團隊歸入DevOps組可確保安全性包含在應用程序代碼中，而不是一旦發(fā)現(xiàn)問題便進行修改。這也可以加快并澄清對問題的響應。
讓我們談談五個DevSecOps支柱，這些支柱在確保全面網(wǎng)絡安全方面具有重大潛力：
安全合規(guī)的部署管道：分析工具、集成管道以及如何將合規(guī)性和審核融入到DevSecOps和Cloud-Native Development的管道中。
安全且合規(guī)的云平臺：身份和訪問管理評估、檢測控制、基礎結(jié)構(gòu)保護、數(shù)據(jù)保護和響應事件。
代碼一致性：在軟件開發(fā)過程中，合規(guī)性被視為代碼框架，以確保管理、合規(guī)性和任何風險緩解問題。
機密信息管理：在混合云業(yè)務模型中管理基于云的敏感信息、密鑰和證書。
容器隱私：容器如何適應安全策略，如何鏈接容器安全威脅以及如何審查容器操作模型和檢查。
所有這些支柱都是側(cè)重點領(lǐng)域，因此，始終地、完全地應用了業(yè)務安全，并且需要進一步進行審查。為了提供每個實施支柱的跨部門愿景，對所有支柱進行橫向治理。這些治理模型適用于每個支柱，并確保支柱以互惠互利的方式運作。
受保護的交付：確保支持的應用程序平臺和云基礎架構(gòu)穩(wěn)定、合規(guī)且安全。
安全模式：開發(fā)安全位置和威脅模型以支持客戶的多樣化接受。
信息保護：確保內(nèi)部和外部員工不受客戶數(shù)據(jù)的保護。
風險評估：包括當前體系結(jié)構(gòu)、容器策略和云基礎架構(gòu)，并對應用程序進行差距分析。
技術(shù)變更日志：創(chuàng)建有序的戰(zhàn)術(shù)執(zhí)行積壓，通過交付工程結(jié)果來推動3-6個月的路線圖和戰(zhàn)略實施計劃。
云原生的漏洞與威脅有哪些？安全性如何？這里有你想知道的一切
云原生的漏洞與威脅有哪些？安全性如何？這里有你想知道的一切
對新安全原型的需求
統(tǒng)計數(shù)據(jù)顯示，到2021年，將有92％的公司成為云原生公司。
話雖如此，通常使組織陷入困境的是為它構(gòu)建一個5000美元的應用程序和一個5美元的安全系統(tǒng)。就云安全性而言，安全性同等或是一個更重要的因素。因此，DevSecOps的概念需要盡早實施并認真對待。
DevSecOps在應用程序開發(fā)過程的所有階段均提供合規(guī)性，并負責設計和安裝應用程序。首先要評估團隊或?qū)嶓w的性質(zhì)，并建立代表該團隊或?qū)嶓w的程序。
第一步是在團隊之間分配孤島，以確保每個人都對保護負責。由于開發(fā)團隊出于安全原因構(gòu)建應用程序，因此Ops將更快地交付軟件，并且使你高枕無憂，因為他們理解開發(fā)人員知道穩(wěn)定性和保護至關(guān)重要。
實際上，必須有可以立即進行安全檢查的過程。
服務器記錄表明誰進行了修改、進行了哪些更改以及何時進行了更改，這些都是在審核程序時要知道的所有重要事實。保持保護的最簡單方法是始終保證系統(tǒng)運行最新的軟件更新。安全修復程序無需花費數(shù)月的時間，并且應該是快速而自動的。同樣，在開發(fā)API和新功能時，應進行潛在的更新，以防止軟件承擔責任并阻止框架打補丁以防止崩潰。
創(chuàng)建云原生應用程序時，仍然沒有單一的安全方法來保護你的軟件。為了保護云中的服務器資源，你需要采取多方面的方法。為了保護你的容器，你需要采取幾種策略。歸根結(jié)底，要將安全放在適當?shù)膬?yōu)先級列表中，你需要DevSecOps策略。
云原生的漏洞與威脅有哪些？安全性如何？這里有你想知道的一切
云原生的漏洞與威脅有哪些？安全性如何？這里有你想知道的一切
理想的云原生安全框架會是什么樣？
為了允許基于云的轉(zhuǎn)換，公司需要在設計安全策略之前考慮以下進一步要求：
高標準的安全自動化：常規(guī)的基于預防措施的安全操作根本無法使基于云的系統(tǒng)保持幾乎無限的動態(tài)性。根本不是手動工作流程的選擇。對云原生安全性的需求是自動檢測和大規(guī)模靈敏性。
混沌設計：在微服務架構(gòu)中，運行時組合在一起的許多軟件組件可以用于任何功能。從安全的角度來看，這意味著檢測和控制的邏輯不能依賴于對操作安全性的事先了解。云原生安全性應該包含混沌工程的原理——高效、有效地運行測試等。
快速識別，涵蓋本地并立即追蹤：云原生程序本質(zhì)上是分配了計算應用程序。在這樣的生態(tài)系統(tǒng)中，隨后無法輕松執(zhí)行全局安全性選擇。因此，你希望確定措施的優(yōu)先級，使你能夠在系統(tǒng)范圍的惡意趨勢蔓延之前迅速識別，恢復并涵蓋本地影響。盡管你的安全決策并非100％準確，但是本地操作和快速恢復可以為你提供更兼容的現(xiàn)有系統(tǒng)。
隨后，你的云解決方案應具有哪些原生安全性？簡而言之，讓我們關(guān)注編譯器功能。作者認為主要功能如下：
混合堆棧可見性和決策支持
在服務器、VM、數(shù)據(jù)庫、軟件和API服務中，即使分布了應用程序，但短期內(nèi)還是動態(tài)資源和容器，仍需要云原生數(shù)據(jù)中心中的可見性和決策支持。在這些不同層上獲得的數(shù)據(jù)應該進入引擎，以便實時進行選擇過程。
快速反應和警告功能可限制爆炸半徑
萬一發(fā)生事故或襲擊，安全解決方案將減輕并控制影響。這種論點等同于迅速的決策和有見地的控制措施，可以在發(fā)生不可逆轉(zhuǎn)的破壞之前阻止惡意行為。在云原生環(huán)境中，智能檢測系統(tǒng)可以完全識別入侵的出現(xiàn)并影響本地控制。
嚴密監(jiān)控與調(diào)查
由于所有分布式組件和API服務，云本機工作負載安全調(diào)查可能會很復雜，因此監(jiān)視和安全調(diào)查必須最大程度地降低性能影響和存儲要求。這包括一個集中的監(jiān)視體系結(jié)構(gòu)，沒有網(wǎng)絡瓶頸，并且工作負載可以擴展。
與自動化工具集成
容器工作負載可以在云原生環(huán)境中由Kubernetes、Openshift、Amazon ECS或Google GKE管理。你可以（可選）使用Puppet、Ansible或Chef自動執(zhí)行部署。安全工具可以與要保護的工作負載一起自動部署，云環(huán)境必須是與此類組件的必備集成。
對于替換第一代物理服務器和虛擬機的事件驅(qū)動的容器和應用程序，安全性必須找到正確的切入點，以最大化可視性并降低風險，同時允許創(chuàng)造力和適應連續(xù)云交付的復雜性。
云原生的漏洞與威脅有哪些？安全性如何？這里有你想知道的一切
結(jié)論
從整體環(huán)境遷移到云原生環(huán)境確實聽起來很吸引人，但是一旦決定這樣做，請確保評估可能出現(xiàn)的所有安全問題，評估是否有足夠的資源和團隊來處理這些問題。而且最重要的是，如果要實現(xiàn)這種轉(zhuǎn)變，你的企業(yè)才能真正脫穎而出并發(fā)展壯大。
希望這篇文章對你有用，歡迎評論區(qū)和我們討論。
重慶分公司
重慶分公司
