玩轉(zhuǎn)Docker要遵守的8條安全準則

無論大家是否知情，相信已經(jīng)有相當(dāng)數(shù)量的軟件（或者虛擬）容器運行在您的企業(yè)當(dāng)中，甚至開始在生產(chǎn)環(huán)境中發(fā)揮作用。遺憾的是，多數(shù)安全團隊仍不了解容器技術(shù)的安全含義，甚至不清楚自家環(huán)境中是否存在容器因素。

總體來講，Docker與CoreOS Rkt等容器技術(shù)能夠?qū)?yīng)用進行虛擬化——而非完整服務(wù)器。容器具備出色的輕量化優(yōu)勢，且無需復(fù)制訪客操作系統(tǒng)。其靈活、可擴展且易于使用，同時能夠在單一物理基礎(chǔ)設(shè)施內(nèi)納入更多應(yīng)用。由于使用共享式操作系統(tǒng)而非單一系統(tǒng)，因此容器往往能夠在瞬間完成引導(dǎo)（虛擬機則普遍需要數(shù)秒乃至數(shù)分鐘）。

考慮到開發(fā)者與DevOps團隊已經(jīng)廣泛接納容器技術(shù)，我們必須直面由此帶來的負面影響——即容器帶來了新型安全挑戰(zhàn)。

1． 引入存在漏洞的源代碼： 由于容器技術(shù)多為開源項目，因此開發(fā)者創(chuàng)建的鏡像需要經(jīng)常更新，以備必要時使用。這意味著可能帶來代碼受控性薄弱、存在漏洞或者引發(fā)意外狀況等問題。

2． 增大攻擊面：在指定環(huán)境中，容器的數(shù)量往往要多于應(yīng)用、虛擬機、數(shù)據(jù)庫乃至其它需要保護的對象。容器的數(shù)量越多，對其進行追蹤就越是困難，而檢測異常狀況自然也更難以實現(xiàn)。

3． 缺乏可觀察性： 容器由容器引擎負責(zé)運行，例如Docker或Rkt，同時與Linux內(nèi)核相對接。由此帶來的全新抽象層將導(dǎo)致我們很難發(fā)現(xiàn)特定容器中的活動或者特定用戶在其中執(zhí)行的操作。

4． Devops速度： 容器的生命周期平均只相當(dāng)于虛擬機的四分之一。容器能夠立即執(zhí)行，運行幾分鐘，而后被停止并刪除。這意味著惡意人士能夠借此發(fā)動閃電打擊，而后馬上消失無蹤。

5． 容器間干擾： 容器可彼此協(xié)作以用于建立DoS攻擊。例如，反復(fù)開啟嵌套會快速導(dǎo)致整體主機設(shè)備陷入卡頓并最終宕機。

6． 容器突破主機： 容器可作為root用戶運行，這使其能夠利用高權(quán)限以突破“圍堵”及訪問主機操作系統(tǒng)。

7． 橫向網(wǎng)絡(luò)攻擊： 單一容器的破壞可能導(dǎo)致其所在整體網(wǎng)絡(luò)遭遇入侵，特別是在對外網(wǎng)絡(luò)連接且原始嵌套運行未作適當(dāng)限制的情況下。

考慮到以上幾點，我整理出了這份最佳實踐列表，希望能夠為大家的容器安全保障工作帶來啟示。

1． 采用綜合性漏洞管理方案。安全漏洞管理工作絕不僅限于掃描鏡像，還需要貫穿整個容器開發(fā)周期進行訪問控制并配合其它策略，否則很可能導(dǎo)致應(yīng)用崩潰或者運行時入侵。嚴格的漏洞管理方案應(yīng)該利用主動性多項檢查完成“從搖籃到墳?zāi)?rdquo;的全面監(jiān)控，同時利用自動觸發(fā)機制控制開發(fā)、測試、分段與生產(chǎn)環(huán)境。

2． 確保僅在環(huán)境中運行獲準鏡像。在開發(fā)環(huán)境中控制所引入之容器鏡像能夠有效縮小攻擊面并預(yù)防開發(fā)者造成致命安全錯誤。這意味著僅使用獲準注冊鏡像及對應(yīng)版本。舉例來說，大家可以將單一Linux發(fā)行版指定為基礎(chǔ)鏡像，并借此最大程度控制潛在攻擊面。

3． 實施貫穿整個生命周期的主動完整性檢查。作為容器生命周期安全管理中的重要組成部分，我們需要確保注冊表中的容器鏡像具備理想的完整性，同時在鏡像進行變更或者凙時執(zhí)行進一步控制。鏡像簽名或指紋可提供一套保管鏈，幫助大家輕松驗證容器完整性。

4． 在運行時強制執(zhí)行最低權(quán)限原則。作為一項基礎(chǔ)性安全最佳實踐，其同樣適用于容器技術(shù)。在攻擊者利用漏洞時，其通常能夠獲取已入侵應(yīng)用或進程的訪問及其它操作權(quán)限。確保容器始終僅具備最低權(quán)限能夠顯著降低入侵后引發(fā)的暴露風(fēng)險。

5． 為容器允許訪問或運行的文件及可執(zhí)行文件設(shè)置白名單。白名單能夠幫助大家控制并管理文件與可執(zhí)行文件，同時確保其僅在需要特定功能時得以使用。如此一來，我們的環(huán)境將更加穩(wěn)定可靠。建立預(yù)核準或者白名單機制能夠顯著縮小攻擊面，同時作為基準參考防止容器干擾及容器入侵等問題。

6． 在運行中的容器上進行網(wǎng)絡(luò)隔離。 維持網(wǎng)絡(luò)隔離性以按照應(yīng)用或者工作負載進行容器集群或者容器區(qū)劃分。這一舉措除了屬于高效最佳實踐外，還屬于受PCI DSS管理的必備容器應(yīng)用原則，同時亦可預(yù)防橫向攻擊活動。

7． 主動監(jiān)控容器活動及用戶訪問。 與其它IT環(huán)境一樣，大家同樣需要對容器生態(tài)系統(tǒng)進行活動與用戶訪問監(jiān)控，從而快速發(fā)現(xiàn)異?；蛘邜阂饣顒?。

8． 記錄全部管理用戶訪問活動以進行審計。雖然強大的用戶訪問控制機制能夠限制大多數(shù)人－容器交互操作，但管理員無疑不在受控范圍之內(nèi)。因此，我們必須設(shè)置日志管理以記錄各類管理性操作，從而在必要時提供取證信息以及明確的審計線索。

盡管相較于其它早期解決方案，容器技術(shù)的安全性水平天然更高。然而由于其誕生時間還不長且已經(jīng)得到廣泛普及，因此我們必須將主動檢測與響應(yīng)方案納入管理體系以保障容器安全。另外，雖然容器安全相關(guān)知識已經(jīng)得到高度重視，但大量容器特定漏洞已經(jīng)開始出現(xiàn)，且這種不利趨勢在未來還將繼續(xù)持續(xù)下去。

好消息是，容器技術(shù)在發(fā)展之初就能夠?qū)姶蟮陌踩詣踊刂颇芰Y(jié)合至容器環(huán)境內(nèi)。但壞消息是，安全團隊需要針對這一新型技術(shù)做好準備，同時加強學(xué)習(xí)以及早意識到潛在的安全改進空間。不過發(fā)現(xiàn)問題正是解決問題的必要前提，因此意識到其重要性的朋友們已經(jīng)在保障容器安全方面邁出了重要一步。