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

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

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

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

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

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

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

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

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

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

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

考慮到以上幾點(diǎn)，我整理出了這份最佳實(shí)踐列表，希望能夠?yàn)榇蠹业娜萜靼踩Ｕ瞎ぷ鲙韱⑹尽?/p>

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

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

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

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

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

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

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

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

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

好消息是，容器技術(shù)在發(fā)展之初就能夠?qū)?qiáng)大的安全自動(dòng)化控制能力結(jié)合至容器環(huán)境內(nèi)。但壞消息是，安全團(tuán)隊(duì)需要針對(duì)這一新型技術(shù)做好準(zhǔn)備，同時(shí)加強(qiáng)學(xué)習(xí)以及早意識(shí)到潛在的安全改進(jìn)空間。不過發(fā)現(xiàn)問題正是解決問題的必要前提，因此意識(shí)到其重要性的朋友們已經(jīng)在保障容器安全方面邁出了重要一步。