隨著越來越多的組織將數(shù)據(jù)和工作負載轉(zhuǎn)移到了云上，許多組織都開始依賴于容器來封裝代碼及其依賴的軟件單元，以便在從一個計算環(huán)境遷移到另一個計算環(huán)境時，應(yīng)用程序能夠可靠地運行。克萊姆森大學(xué)遺傳與生物化學(xué)系的云架構(gòu)師Cole McKnight表示，容器化被譽為是一種以安全方式部署應(yīng)用程序和服務(wù)的強大技術(shù)。
Docker和Singularity等容器引擎提供了一種方法來實現(xiàn)和分發(fā)給定應(yīng)用程序的最佳實踐安全策略，而不是依賴于單個的用戶來配置安全安裝，McKnight說。“容器編排平臺，如Kubernetes、Mesos或Docker Swarm，都具有集成的安全機制來專門用于部署和執(zhí)行容器，”McKnight說。“結(jié)果是可以得到一個易于配置的可用于開發(fā)和部署容器的生態(tài)系統(tǒng)。”
雖然這些技術(shù)抽象了交付安全應(yīng)用程序和服務(wù)的傳統(tǒng)復(fù)雜性，但一些開發(fā)團隊將這種安全性的可能性也解釋為了一種保證，McKnight說。問題是，容器實現(xiàn)不是萬無一失的，團隊在使用它們時所犯的錯誤依然可能會產(chǎn)生而不是解決安全問題。
1. 過分關(guān)注容器本身
“在實現(xiàn)安全容器時，最常見的錯誤是只關(guān)注容器本身，”McKnight說。維護映像安全性的最佳實踐非常重要，他說，但開發(fā)人員通常只會將重點放在映像的安全性上，而不考慮執(zhí)行環(huán)境。
“容器內(nèi)的任何安全措施都無法保護它免受宿主的攻擊，”McKnight說。“承載容器引擎的每臺計算機必須在每一層上都受到保護，以防出現(xiàn)任何傳統(tǒng)上可利用的漏洞。”
必須將容器引擎和容器編制平臺(如果適用的話)配置為正確使用集成的容器安全機制，McKnight說。“因此，容器安全需要從主機的操作系統(tǒng)和網(wǎng)絡(luò)開始，”他說。
2. 假設(shè)代碼庫是安全的
獨立網(wǎng)絡(luò)安全顧問Tony Asher表示，在部署容器時，一些組織會錯誤地將代碼庫包括進來，并認為它們是安全的。“這包括了開發(fā)套件中的庫，”Asher說。“更重要的是，第三方庫也經(jīng)常會被直接引入以加速開發(fā)。”
安全性問題指的是這些應(yīng)用程序代碼庫中可能存在漏洞，Asher說。“編譯應(yīng)用程序并將它們發(fā)布到生產(chǎn)容器中，可能會通過漏洞利用而引入嚴重的風險。”
為了解決這個問題，Asher建議公司在考慮導(dǎo)入第三方庫時，將庫限制在滿足應(yīng)用程序容器成功標準所需的范圍內(nèi)，掃描代碼尋找漏洞，并應(yīng)用安全審查流程。
組織還需要開發(fā)一個正式的安全體系結(jié)構(gòu)審查流程。“這個流程應(yīng)該包括檢查符合風險標準的容器，由一組人來檢查，”Asher說。這提供了問責制，有助于確保風險得到考慮。
3. 給予容器不必要的特權(quán)
風險投資公司ClearSky的管理合伙人Jay Leek說，給容器過多的特權(quán)是很常見的，而攻擊者可以濫用這些特權(quán)來利用容器本不應(yīng)該訪問但確實可以訪問的資源。“在這里應(yīng)該應(yīng)用最小特權(quán)原則，并且執(zhí)行運行時行為監(jiān)視，以便能夠確保檢測到任何非必要的應(yīng)用程序特權(quán)的濫用。”Leek說。
一種常見的做法是在執(zhí)行環(huán)境中使用特權(quán)來運行容器，McKnight說。“取決于主機的軟件堆棧，這可能意味著不同的東西，”他說。“但是在宿主環(huán)境中給容器不必要的特權(quán)會導(dǎo)致問題的升級，不僅會導(dǎo)致容器被破壞，也可能會導(dǎo)致主機被破壞。”
正如容器內(nèi)部的安全性無法保護它不受其主機的攻擊一樣，主機內(nèi)部的安全性也無法保護其免受特權(quán)容器的利用。“容器的設(shè)計應(yīng)該確保其運行方式不會在主機環(huán)境中為其提供不必要的特權(quán)。”McKnight說。
當需要特權(quán)時，應(yīng)該以精細的粒度謹慎地給予特權(quán)，McKnight說。“最佳實踐是避免在宿主環(huán)境中提供具有清除權(quán)限的容器。”
4. 過度暴露容器
同樣，需要在執(zhí)行時公開給公共網(wǎng)絡(luò)的容器也需要以同樣的心態(tài)進行設(shè)計。“應(yīng)該只打開絕對必要的通道，而不是設(shè)計一個讓容器暴露于潛在攻擊的全面開放的策略。”McKnight說。
在實現(xiàn)容器本身時需要考慮很多問題。“容器是通過一系列命令構(gòu)建的，這些命令會在映像規(guī)范中被定義，并在映像構(gòu)建時以root權(quán)限運行，”McKnight說。“開發(fā)人員通常會在部署和執(zhí)行容器時錯誤地保留這些權(quán)限。”
如果在運行時使用root權(quán)限運行容器內(nèi)的進程，則該容器內(nèi)的數(shù)據(jù)和軟件將受到危害。為了解決這個問題，要在容器中運行的命令應(yīng)該是由非root用戶在沒有權(quán)限的情況下運行的(如果可能的話)，以避免容器中的任何權(quán)限提升。
在網(wǎng)絡(luò)方面，也需要仔細考慮容器的數(shù)據(jù)和進程暴露給其他實體的方式。“容器的安全需要再一次從傳統(tǒng)的操作系統(tǒng)和網(wǎng)絡(luò)安全開始，”McKnight說。“必須檢查容器與外部卷、網(wǎng)絡(luò)和進程之間的任何交互。”
5. 未能正確地審查映像
在部署容器時，組織通常忽略的另一個因素是它們所基于的映像。“團隊通常會犯這樣的錯誤:在將另一方開發(fā)的映像集成到他們的解決方案之前，沒有對其進行適當?shù)膶彶椤?rdquo;McKnight說。
在從公共注冊中心部署容器或?qū)⑵溆米骰A(chǔ)映像之前，請對其進行掃描，以查找惡意軟件和漏洞。此外，組織也應(yīng)該讓有經(jīng)驗的開發(fā)人員徹底檢查映像，找出漏洞，McKnight說。
“假定推送到公共注冊中心的映像是安全的，這是非常危險的，特別是在從這些映像構(gòu)建額外的映像時。”McKnight說。
6. 不尊重不可變映像的原則
不可變的映像是不可以改變的，Asher指出。“這是Docker、Kubernetes和其它容器解決方案的原則，”他表示。“在internet上部署系統(tǒng)和數(shù)據(jù)時(internet是不受信任的媒體)，需要創(chuàng)建一個能夠確保完整性的流程。”
不可變的映像提供了一些好處，例如可預(yù)測、可銷售以及提供了自動恢復(fù)能力。他們還提供了完整性，Asher說，這是安全的核心目的之一。
“當生產(chǎn)容器不遵循不可變的原則時，應(yīng)用程序?qū)⒖梢赃B接到它們并進行更改，”Asher說。“這種行為引發(fā)了多重安全隱患。具體來說，它會破壞容器的完整性。”
最令人擔憂的風險之一是惡意參與者會修改容器以包含惡意代碼。這可能會對公司造成重大影響，Asher說。監(jiān)視容器的完整性可以極大地降低這種風險。
“你需要改進和糾正部署管道，以防止生產(chǎn)容器發(fā)生變化，”Asher說。“確保在擁有質(zhì)量保證的測試環(huán)境中進行更改，確保這些更改能夠得到批準，然后部署新的不可變映像來替代舊的映像。”
