容器給將安全性融入發(fā)展和操作過程中提供了一個千載難逢的機(jī)會，讓我們把握住這個機(jī)會。

當(dāng)企業(yè)開發(fā)應(yīng)用程序時，安全性仍被看做是一個事后考慮項(xiàng)，在應(yīng)用發(fā)布之前才會涉及。軟件容器的迅猛發(fā)展，為把安全性納入上游開發(fā)過程(或在devops術(shù)語中稱為 左移 )提供了一個難得的機(jī)會，并成為早期綜合性和整個軟件交付的管道。然而，大多數(shù)安全團(tuán)隊不知道容器為何物，更不必說了解它們獨(dú)特的安全挑戰(zhàn)是什么了。

軟件容器可以被認(rèn)為是系統(tǒng)需求更為精簡的輕量級虛擬器。在運(yùn)行時，容器共享主機(jī)的操作系統(tǒng)內(nèi)核，大大減少了信息處理量(只有兆字節(jié))，加快了運(yùn)行速度。容器啟動一個虛擬器僅需幾秒而不是幾分鐘。

容器自21世紀(jì)初期就出現(xiàn)了，并于2007年被構(gòu)架到Linux中。因其占用空間小和便攜性，與虛擬器相比同樣的硬盤可以支持更多的容器，極大的減少了基礎(chǔ)設(shè)施成本，加快了更多應(yīng)用程序的運(yùn)行速度。

然而，由于可用性問題，容器并未流行，直到Docker加入后改善了其可用性和對企業(yè)的適用性。如今容器 和Docker 變得炙手可熱。今年早些時候，摩根大通和梅隆銀行公開表示，他們正在尋求一種基于容器的發(fā)展戰(zhàn)略，證明了容器對傳統(tǒng)企業(yè)的發(fā)展有巨大的推動力，就像云之于谷歌、優(yōu)步和Yelp。

就像容器的卓越性一樣，它們也帶來了獨(dú)特的新風(fēng)險。通常情況下，只有在新技術(shù)出現(xiàn)時才會發(fā)生此類事件，因此安全意識并未構(gòu)建在容器內(nèi)部。如果容器不在你的雷達(dá)上，那么現(xiàn)在是時候加速了，因?yàn)樗鼈兒苡锌赡芤呀?jīng)在你們公司內(nèi)部的某個地方開始運(yùn)行。我列出了在使用容器時會面臨的5個獨(dú)特的問題。

1.容器圖像中的漏洞管理

圖像是構(gòu)建容器的基石。開發(fā)人員可以輕易地創(chuàng)建自己的圖像，或者從Docker 樞紐和其他集中開源注冊中心下載公共圖像。使容器的使用達(dá)到高度自動化，過程靈活。

從安全性和管理方式的角度看，信任容器圖像是貫穿整個軟件開發(fā)生命周期的關(guān)鍵考量。確保圖像的簽署和來源于一個可信的注冊處是保障安全的最佳做法。不過，堅持這些做法并不足以應(yīng)對審批和驗(yàn)證代碼的核心挑戰(zhàn)。

在容器環(huán)境中，圖像被不斷地加入到企業(yè)的私人注冊處和樞紐，容器負(fù)責(zé)圖像的收入和輸出。即使列出了圖像的漏洞，基于對其公司安全事件和政策的考量，開發(fā)團(tuán)隊也很少能提出解決辦法。例如，開發(fā)人員從一個注冊處中選取了一個有1000處漏洞的圖像。這個數(shù)字本身的上下波動并沒有可操作性。有多少諸如此類的漏洞發(fā)生呢?為什么?

放大開放源圖像的問題相對容易，特別是有多個圖層的圖像尤其容易。為加速資源配置在圖像中創(chuàng)建越多的圖層，軟件組件就會面臨越大的風(fēng)險，包括開放源組件。風(fēng)險會在不被掃描、驗(yàn)證或修補(bǔ)的情況下產(chǎn)生。

我們已將發(fā)現(xiàn)，由于企業(yè)沒有一個系統(tǒng)的容器漏洞評估體系，導(dǎo)致容器化措施施行受阻甚至擱淺。因此，一個不斷改進(jìn)的漏洞評估和修復(fù)體系要作為完整的一部分被納入企業(yè)的IT風(fēng)險和治理計劃中去。

2.減少容器的攻擊面

減少攻擊面是保障安全性的基本原則。防止代碼漏洞進(jìn)入環(huán)境是減少一個關(guān)鍵攻擊面的完美示例，需要注意的是，容器化有特定結(jié)構(gòu)和操作要素。主要是，除了要保障主機(jī)的安全性，更要保障容器中潛在的共享內(nèi)核架構(gòu)的安全性;這需要維護(hù)標(biāo)準(zhǔn)配置和容器配置文件。

不像在虛擬化環(huán)境中，虛擬機(jī)管理程序作為其控制點(diǎn)，任何用戶或服務(wù)訪問內(nèi)核根賬戶能夠查看和訪問所有所有容器共享Linux內(nèi)核。安全團(tuán)隊可以依靠驗(yàn)證的方法來強(qiáng)化內(nèi)核和主機(jī)，但這離用成熟和可復(fù)驗(yàn)的方式來確保特定于容器環(huán)境中操作過程的安全還差得很遠(yuǎn)。

其中的很多過程是容器化中固有的。例如，容器本身依靠內(nèi)核以及一系列服務(wù)利用Docker防護(hù)程序通過系統(tǒng)調(diào)用。而Docker在調(diào)用開箱seccomp(安全計算模式)配置文件的能力有了顯著提高，這些文件只在默認(rèn)情況下禁用52系統(tǒng)調(diào)用，出于X64計算機(jī)中的313可用性，仍留下了一些開放的260系統(tǒng)調(diào)用。

另一個例子是把Docker防護(hù)程序綁定到Unix Docker訪問組或TCP端口從而允許容器互相交流，此外，也有提供給所用用戶根權(quán)限的作用。根開放可以減少運(yùn)營摩擦，但是可能會使安全部門對違反最小特權(quán)訪問原則表示不滿。

解決隔離和容器通訊、操作和開發(fā)之間的內(nèi)在張力意味著所采取的措施既要控制容器內(nèi)部相互影響的程度，也要限制通過插孔或開放的端口進(jìn)入到Docker 群組的容器的數(shù)量。

3.加強(qiáng)用戶訪問控制

直到最近，根在默認(rèn)情況下訪問Docker主機(jī)是一個非此即彼的命題，使安全專員對此十分焦慮。雖然限制訪問容器主機(jī)根賬戶花費(fèi)了他們大量的精力 并且推動了Docker在系統(tǒng)中刪除特權(quán)訪問這一新功能的投資 對安全更廣泛的關(guān)注是對特權(quán)賬戶的強(qiáng)制訪問控制和部署管道的操作運(yùn)行。顯而易見，擴(kuò)大創(chuàng)建實(shí)用有效的訪問控制規(guī)模很有益處：可以保證問責(zé)性和操作一致性。

問責(zé)需要一定的能力以便查明是什么改變了容器的設(shè)置或配置或下載圖像或在生產(chǎn)中創(chuàng)建了一個容器。擁有通用的根訪問權(quán)限之后，要確定是什么做出了改變幾乎是不可能的。即使根訪問可能是開發(fā)人員在工作過程中所需要的最簡單的一種訪問方式，這也意味著他們有太多的訪問權(quán)限。此外，得到訪問根賬戶權(quán)限的攻擊者就相當(dāng)于得到了任意訪問容器的權(quán)限，包括其數(shù)據(jù)和程序。

應(yīng)用集中管理約束條例使用戶可以基于自己的角色做出更改或命令，而不是他們訪問根賬戶的能力，使企業(yè)能夠定義和執(zhí)行標(biāo)準(zhǔn)流程。實(shí)現(xiàn)職責(zé)分離訪問和基于用戶角色的命令約束條例是確保通過軟件開發(fā)生命周期的基礎(chǔ)。

如果不采取集中的方式，很難確定每個容器中不同的用戶和其對應(yīng)的不同的特權(quán)是否合適，與其職能作用和最小訪問特權(quán)是否一致。

4.硬化主機(jī)

容器化最重要的好處之一就是它獨(dú)立于應(yīng)用程序，可以在任何地方獨(dú)立運(yùn)行而不依賴于任何自給系統(tǒng)。

一個重要的意義是有了專門的工具來限制哪些是自給系統(tǒng)可以訪問和使用的，哪些是不可以訪問和使用的。對照組和命名空間是關(guān)鍵容器的隔離元件。對照組決定一個容器可以使用多少共享內(nèi)核和系統(tǒng)資源。命名空間決定了一個容器可以 查看 或有效確定容器被授權(quán)訪問哪些資源。這些組件的設(shè)計目標(biāo)非常明確：無論你想在哪個服務(wù)器中運(yùn)行多種服務(wù)，這些服務(wù)彼此盡可能相互隔離，這是確保安全性和穩(wěn)定性至關(guān)重要的一點(diǎn)。

嚴(yán)苛的細(xì)節(jié)確保了對照組和命名空間中配置的恰當(dāng)性和一致性，并且保證了配置和安全政策相符。

盡管對照組和命名空間隔離可以用來限制對容器中內(nèi)核資源的訪問，但它并不能有效地隔離容器的執(zhí)行路徑。資源隔離對檢測和預(yù)防濫用特權(quán)或打破容器中的 箱 等擴(kuò)大化攻擊無效。

在運(yùn)行防御和容器分析過程中缺少分層法來保證對其的有效控制和可見性，由于配置錯誤或攻擊者采取明確的行動操控命名空間，容器的安全性很容易就被破壞了。例如，容器環(huán)境下拒絕服務(wù)攻擊與 流氓 容器消耗更多的內(nèi)核資源和擠占其他過程并無二致。

5.容器安全過程的自動化

在安全性領(lǐng)域，將安全的理念落實(shí)到實(shí)際操作中去 而且不僅僅是隨后在書面上描摹它 像是一個遙不可及的夢想。盡管在DeVops和安全團(tuán)隊中存在著一些領(lǐng)域或文化分歧，將安全滲透到容器的創(chuàng)建、傳送和運(yùn)行的過程中毫無疑問是企業(yè)最感興趣的。這不僅會使內(nèi)部應(yīng)用程序更加安全，也會調(diào)動DeVops和安全團(tuán)隊的積極性，培養(yǎng)更具協(xié)作性的文化。

由于安全團(tuán)隊往往沒有意識到導(dǎo)致容器在生產(chǎn)中運(yùn)行的過程，重要的是要涉及到他們工作流程的定義和促進(jìn)知識的轉(zhuǎn)化。因此，他們可以給適當(dāng)?shù)目刂坪蛯?shí)踐提供指導(dǎo)原則以滿足其安全標(biāo)準(zhǔn)和審計要求。

換句話說，DeVops應(yīng)該做它們最擅長的事情：自動化。基于容器的應(yīng)用程序開發(fā)過程已經(jīng)實(shí)現(xiàn)高度自動化。使用CI/CD和業(yè)務(wù)流程工具是在容器的整個生命周期中保障安全的最佳實(shí)踐，這使建立安全管理框架的過程變得透明和相對安全簡單。它將建立一個高度安全基線，減少了對后續(xù)安全工作的需要，也降低了安全成為部署障礙的可能性。

我們都知道當(dāng)安全不是優(yōu)先級時發(fā)生了什么，所以除了回滾以外還有什么其他的選擇嗎?容器為正確地解決這一問題提供了一個很好的機(jī)會，因?yàn)樗麄円呀?jīng)完全實(shí)現(xiàn)了自動化。將安全過程自動化到可操作的工作流程中可能是一個新的安全措施，但是這并不是第一次在容器中出現(xiàn)，其自動化已經(jīng)成為所有方面的業(yè)務(wù)(網(wǎng)絡(luò)、存儲等)的規(guī)范。安全僅僅成為另一種滿足自動化的要求。

DeVops規(guī)定在應(yīng)用程序的整個生命周期中采用自動化和協(xié)作精神來加快靈活開發(fā)速度以實(shí)現(xiàn)目標(biāo)。安全性 是目前為止在生產(chǎn)過程中最必不可少的 可以使用相同的方法來達(dá)到與其相左的結(jié)果。

安全專業(yè)人員面臨的最大挑戰(zhàn)：他們可能不清楚容器部署計劃，甚至在其實(shí)施過程中也不了解。安全團(tuán)隊的參與宜早不宜遲-DeVops操作過程 而不是等到用生產(chǎn)壓力和生產(chǎn)過程延遲取代提高效率。在此之前我們看到過那種場景;沒有人想看第二次。

文章編輯：CobiNet(寧波)  
本公司專注于電訊配件,銅纜綜合布線系列領(lǐng)域產(chǎn)品研發(fā)生產(chǎn)超五類，六類,七類屏蔽網(wǎng)線/屏蔽模塊及相關(guān)模塊配件, 我們是萬兆屏蔽模塊，10G屏蔽模塊，屏蔽線生產(chǎn)廠家。

歡迎來電咨詢0574 88168918,郵箱sales@cobinet.cn，網(wǎng)址www.idouxiong.cn