容器與微服務(wù)技術(shù)將給安全帶來怎樣的影響?(下)
譯文【51CTO.com快譯】云原生應(yīng)用程序與基礎(chǔ)設(shè)施需要配合不同于以往的安全方法。而以下最佳實踐無疑值得您關(guān)注。
在本系列文章的上半部分,我們探討了云原生軟件技術(shù)——特別是容器與微服務(wù)——所帶來的實際挑戰(zhàn),以及傳統(tǒng)安全工具無法滿足實際需求的相關(guān)理由。在今天的下半部分中,我們將繼續(xù)這一議題,聊聊兩大階段當(dāng)中的實際解決思路。
保護(hù)容器構(gòu)建與部署
構(gòu)建與部署階段的保護(hù)重點,在于將控制能力引入開發(fā)者工作流以及持續(xù)整合與部署管道,從而緩解容器啟動后可能出現(xiàn)的安全問題。相關(guān)指導(dǎo)原則與最佳實踐包括:
· 盡可能降低鏡像體積。 容器鏡像是一個輕量化可執(zhí)行文件,用于打包應(yīng)用程序代碼以及運行所必需的關(guān)聯(lián)面??s小鏡像體積能夠有效降低攻擊面。作為安全保護(hù)工作,我們應(yīng)從為系統(tǒng)基礎(chǔ)鏡像“瘦身”開始,例如Alpine Linux能夠有效降低鏡像體積并提升管理能力。
· 掃描鏡像以發(fā)現(xiàn)已知問題。 在進(jìn)行鏡像構(gòu)建時,確保其中不存在已知漏洞無疑非常重要。您可以掃描鏡像當(dāng)中的各個文件系統(tǒng)層,并將結(jié)果與CVE數(shù)據(jù)庫進(jìn)行比較。如此一來,開發(fā)與安全團(tuán)隊即可保證用于啟動容器的鏡像不致包含已經(jīng)被發(fā)現(xiàn)的漏洞。
· 數(shù)字簽名鏡像。 鏡像構(gòu)建完成后,其完整性應(yīng)在部署前接受驗證。我們可以利用惟一摘要標(biāo)識符對部分鏡像格式進(jìn)行檢測,從而把握其內(nèi)容何時曾發(fā)生變化。利用私鑰簽名鏡像實現(xiàn)加密保證,確保用于啟動容器的任何鏡像皆由可信方所創(chuàng)建。
· 加強(qiáng)并限制對主機(jī)操作系統(tǒng)的訪問。 由于運行在同一主機(jī)上的容器共享同一操作系統(tǒng),因此確保其僅接入與自身作用相關(guān)的功能集就非常重要。我們可以利用內(nèi)核安全功能與模塊(例如Seccomp、AppArmor以及SELinux)實現(xiàn)這一目標(biāo)。
· 特定應(yīng)用級細(xì)分策略。 微服務(wù)間的網(wǎng)絡(luò)流量可進(jìn)行細(xì)分,用以限制具體連接方式。但在實施層面,這要求我們根據(jù)標(biāo)簽及選擇器等應(yīng)用級屬性進(jìn)行配置,從而將IP地址等傳統(tǒng)網(wǎng)絡(luò)復(fù)雜性因素抽象出來。細(xì)分工作的難度在于必須預(yù)先定義通信限制策略,且保證其不會影響容器在環(huán)境內(nèi)/跨環(huán)境情況下的通信能力。
· 保護(hù)容器所使用的敏感信息。 微服務(wù)間經(jīng)常交換密碼、令牌及密鑰等敏感數(shù)據(jù)。如果將其存儲在鏡像或者環(huán)境變量中,則可能引發(fā)意外泄露風(fēng)險。因此,Docker與Kubernetes等平臺皆集成有敏感信息管理功能,確保其僅在必要時分配給正確的容器對象。
Docker、紅帽以及CoreOS等領(lǐng)先容器平臺與工具能夠提供部分乃至全部上述提到的功能。選擇這些方案能夠幫助您快速實現(xiàn)構(gòu)建與部署階段的安全保障目標(biāo)。
然而,構(gòu)建與部署階段的控制手段并不足以實現(xiàn)徹底安全。之所以無法在容器啟動前解決所有安全問題,原因有三:第一,漏洞無法被完全消除,新的漏洞終將出現(xiàn); 第二,聲明容器元數(shù)據(jù)與網(wǎng)絡(luò)細(xì)分策略并不能完全預(yù)測高度分布環(huán)境中的所有合法應(yīng)用活動; 第三,運行時控件的使用非常復(fù)雜,經(jīng)常出現(xiàn)配置錯誤,并導(dǎo)致應(yīng)用程序遭受威脅。
運行時內(nèi)容器保護(hù)
運行時階段的安全保障包括發(fā)現(xiàn)并在必要時停止容器運行所需要的所有功能——可見性、檢測、響應(yīng)以及預(yù)防等等。安全人員需要對安全事件的根源進(jìn)行調(diào)查、判斷與確定,從而作出充分補(bǔ)救。以下為實現(xiàn)這一目標(biāo)的幾大重要前提:
· 對整體環(huán)境進(jìn)行持續(xù)監(jiān)控。 能夠?qū)崟r追蹤全部運行中容器內(nèi)的活動以提供“真相來源”,從而及時發(fā)現(xiàn)攻擊及策略違規(guī)。我們可以選擇市場上的多種不同容器相關(guān)數(shù)據(jù)監(jiān)控框架,但請確保其符合您的容器規(guī)模與速度需求。
· 對分布式威脅指標(biāo)進(jìn)行關(guān)聯(lián)。 容器的一大特性在于根據(jù)資源可用性分布于計算基礎(chǔ)設(shè)施之上。由于應(yīng)用程序內(nèi)可能包含大量容器,因此違規(guī)指標(biāo)可能同樣分布于眾多主機(jī)當(dāng)中。因此,我們需要對其進(jìn)行規(guī)?;焖訇P(guān)聯(lián),從而將對應(yīng)指標(biāo)與特定攻擊聯(lián)系起來。
· 分析容器與微服務(wù)行為。 微服務(wù)與容器可將應(yīng)用程序拆分為執(zhí)行特定功能且不可變的眾多小型組件。如此一來,我們將能夠更輕松地理解預(yù)期的正常行為模式。而與正常基準(zhǔn)不符的行為則可能代表存在惡意活動。
· 利用機(jī)器學(xué)習(xí)強(qiáng)化威脅檢測。 容器環(huán)境下生成的數(shù)據(jù)規(guī)模及生成速度往往超出常規(guī)檢測技術(shù)的承載能力。自動化與機(jī)器學(xué)習(xí)類方案能夠更高效地實現(xiàn)行為建模、模式識別與分類,從而提高判斷準(zhǔn)確度并減少誤報狀況。但請不要使用那些僅利用機(jī)器學(xué)習(xí)生成靜態(tài)白名單的解決方案,其往往會帶來嚴(yán)重的誤報并令管理人員因疲勞而忽略掉真正的威脅。
· 攔截并阻止未授權(quán)容器引擎命令。指向容器引擎的命令用于創(chuàng)建、啟動并終止容器以及運行于容器內(nèi)的全部負(fù)載。這些命令的出現(xiàn)可能破壞容器環(huán)境,因此必須禁止一切未授權(quán)容器引擎命令。
· 自動響應(yīng)與取證。 容器因生命周期較短而很少留下可用于事件響應(yīng)及取證的信息。此外,云原生架構(gòu)通常會利用新系統(tǒng)替換存在問題的系統(tǒng),導(dǎo)致容器在取證調(diào)查時已然消失。自動化機(jī)制能夠確??焖俨蹲健⒎治霾⑸壭畔?,從而減輕攻擊與違規(guī)活動的影響。
基于容器與微服務(wù)技術(shù)的云原生體系正快速普及,并迫使安全人員重新考慮保護(hù)手段的實際成效。一套全面的云原生軟件安全程序應(yīng)面向整個應(yīng)用程序生命周期,包含容器的構(gòu)建、部署與運行階段。希望今天的文章能夠為大家在這方面帶來一點啟示。
【51CTO譯稿,合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】