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

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

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

容器自21世紀初期就出現了，并于2007年被構架到Linux中。因其占用空間小和便攜性，與虛擬器相比同樣的硬盤可以支持更多的容器，極大的減少了基礎設施成本，加快了更多應用程序的運行速度。

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

就像容器的卓越性一樣，它們也帶來了獨特的新風險。通常情況下，只有在新技術出現時才會發生此類事件，因此安全意識并未構建在容器內部。如果容器不在你的雷達上，那么現在是時候加速了，因為它們很有可能已經在你們公司內部的某個地方開始運行。我列出了在使用容器時會面臨的5個獨特的問題。

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

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

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

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

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

我們已將發現，由于企業沒有一個系統的容器漏洞評估體系，導致容器化措施施行受阻甚至擱淺。因此，一個不斷改進的漏洞評估和修復體系要作為完整的一部分被納入企業的IT風險和治理計劃中去。

2.減少容器的攻擊面

減少攻擊面是保障安全性的基本原則。防止代碼漏洞進入環境是減少一個關鍵攻擊面的完美示例，需要注意的是，容器化有特定結構和操作要素。主要是，除了要保障主機的安全性，更要保障容器中潛在的共享內核架構的安全性;這需要維護標準配置和容器配置文件。

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

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

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

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

3.加強用戶訪問控制

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

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

應用集中管理約束條例使用戶可以基于自己的角色做出更改或命令，而不是他們訪問根賬戶的能力，使企業能夠定義和執行標準流程。實現職責分離訪問和基于用戶角色的命令約束條例是確保通過軟件開發生命周期的基礎。

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

4.硬化主機

容器化最重要的好處之一就是它獨立于應用程序，可以在任何地方獨立運行而不依賴于任何自給系統。

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

嚴苛的細節確保了對照組和命名空間中配置的恰當性和一致性，并且保證了配置和安全政策相符。

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

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

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

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

由于安全團隊往往沒有意識到導致容器在生產中運行的過程，重要的是要涉及到他們工作流程的定義和促進知識的轉化。因此，他們可以給適當的控制和實踐提供指導原則以滿足其安全標準和審計要求。

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

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

DeVops規定在應用程序的整個生命周期中采用自動化和協作精神來加快靈活開發速度以實現目標。安全性 是目前為止在生產過程中最必不可少的 可以使用相同的方法來達到與其相左的結果。

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

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

歡迎來電咨詢0574 88168918,郵箱sales@cobinet.cn，網址www.54hr.com.cn