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

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

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

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

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

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

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

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

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

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

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

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

2.減少容器的攻擊面

減少攻擊面是保障安全性的基本原則。防止代碼漏洞進(jìn)入環(huán)境是減少一個(gè)關(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)隊(duì)可以依靠驗(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(安全計(jì)算模式)配置文件的能力有了顯著提高，這些文件只在默認(rèn)情況下禁用52系統(tǒng)調(diào)用，出于X64計(jì)算機(jī)中的313可用性，仍留下了一些開放的260系統(tǒng)調(diào)用。

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

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

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

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

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

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

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

4.硬化主機(jī)

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

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

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

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

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

5.容器安全過程的自動(dòng)化

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

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

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

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

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

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

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

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