【51CTO.com快譯】云原生應(yīng)用程序與基礎(chǔ)設(shè)施需要配合不同于以往的安全方法。而以下最佳實(shí)踐無(wú)疑值得您關(guān)注。

[[208433]]

在本系列文章的上半部分，我們探討了云原生軟件技術(shù)——特別是容器與微服務(wù)——所帶來(lái)的實(shí)際挑戰(zhàn)，以及傳統(tǒng)安全工具無(wú)法滿足實(shí)際需求的相關(guān)理由。在今天的下半部分中，我們將繼續(xù)這一議題，聊聊兩大階段當(dāng)中的實(shí)際解決思路。

保護(hù)容器構(gòu)建與部署

構(gòu)建與部署階段的保護(hù)重點(diǎn)，在于將控制能力引入開發(fā)者工作流以及持續(xù)整合與部署管道，從而緩解容器啟動(dòng)后可能出現(xiàn)的安全問(wèn)題。相關(guān)指導(dǎo)原則與最佳實(shí)踐包括：

· 盡可能降低鏡像體積。 容器鏡像是一個(gè)輕量化可執(zhí)行文件，用于打包應(yīng)用程序代碼以及運(yùn)行所必需的關(guān)聯(lián)面。縮小鏡像體積能夠有效降低攻擊面。作為安全保護(hù)工作，我們應(yīng)從為系統(tǒng)基礎(chǔ)鏡像“瘦身”開始，例如Alpine Linux能夠有效降低鏡像體積并提升管理能力。

· 掃描鏡像以發(fā)現(xiàn)已知問(wèn)題。 在進(jìn)行鏡像構(gòu)建時(shí)，確保其中不存在已知漏洞無(wú)疑非常重要。您可以掃描鏡像當(dāng)中的各個(gè)文件系統(tǒng)層，并將結(jié)果與CVE數(shù)據(jù)庫(kù)進(jìn)行比較。如此一來(lái)，開發(fā)與安全團(tuán)隊(duì)即可保證用于啟動(dòng)容器的鏡像不致包含已經(jīng)被發(fā)現(xiàn)的漏洞。

· 數(shù)字簽名鏡像。 鏡像構(gòu)建完成后，其完整性應(yīng)在部署前接受驗(yàn)證。我們可以利用惟一摘要標(biāo)識(shí)符對(duì)部分鏡像格式進(jìn)行檢測(cè)，從而把握其內(nèi)容何時(shí)曾發(fā)生變化。利用私鑰簽名鏡像實(shí)現(xiàn)加密保證，確保用于啟動(dòng)容器的任何鏡像皆由可信方所創(chuàng)建。

· 加強(qiáng)并限制對(duì)主機(jī)操作系統(tǒng)的訪問(wèn)。 由于運(yùn)行在同一主機(jī)上的容器共享同一操作系統(tǒng)，因此確保其僅接入與自身作用相關(guān)的功能集就非常重要。我們可以利用內(nèi)核安全功能與模塊(例如Seccomp、AppArmor以及SELinux)實(shí)現(xiàn)這一目標(biāo)。

· 特定應(yīng)用級(jí)細(xì)分策略。 微服務(wù)間的網(wǎng)絡(luò)流量可進(jìn)行細(xì)分，用以限制具體連接方式。但在實(shí)施層面，這要求我們根據(jù)標(biāo)簽及選擇器等應(yīng)用級(jí)屬性進(jìn)行配置，從而將IP地址等傳統(tǒng)網(wǎng)絡(luò)復(fù)雜性因素抽象出來(lái)。細(xì)分工作的難度在于必須預(yù)先定義通信限制策略，且保證其不會(huì)影響容器在環(huán)境內(nèi)/跨環(huán)境情況下的通信能力。

· 保護(hù)容器所使用的敏感信息。 微服務(wù)間經(jīng)常交換密碼、令牌及密鑰等敏感數(shù)據(jù)。如果將其存儲(chǔ)在鏡像或者環(huán)境變量中，則可能引發(fā)意外泄露風(fēng)險(xiǎn)。因此，Docker與Kubernetes等平臺(tái)皆集成有敏感信息管理功能，確保其僅在必要時(shí)分配給正確的容器對(duì)象。

Docker、紅帽以及CoreOS等領(lǐng)先容器平臺(tái)與工具能夠提供部分乃至全部上述提到的功能。選擇這些方案能夠幫助您快速實(shí)現(xiàn)構(gòu)建與部署階段的安全保障目標(biāo)。

然而，構(gòu)建與部署階段的控制手段并不足以實(shí)現(xiàn)徹底安全。之所以無(wú)法在容器啟動(dòng)前解決所有安全問(wèn)題，原因有三：第一，漏洞無(wú)法被完全消除，新的漏洞終將出現(xiàn); 第二，聲明容器元數(shù)據(jù)與網(wǎng)絡(luò)細(xì)分策略并不能完全預(yù)測(cè)高度分布環(huán)境中的所有合法應(yīng)用活動(dòng); 第三，運(yùn)行時(shí)控件的使用非常復(fù)雜，經(jīng)常出現(xiàn)配置錯(cuò)誤，并導(dǎo)致應(yīng)用程序遭受威脅。

運(yùn)行時(shí)內(nèi)容器保護(hù)

運(yùn)行時(shí)階段的安全保障包括發(fā)現(xiàn)并在必要時(shí)停止容器運(yùn)行所需要的所有功能——可見性、檢測(cè)、響應(yīng)以及預(yù)防等等。安全人員需要對(duì)安全事件的根源進(jìn)行調(diào)查、判斷與確定，從而作出充分補(bǔ)救。以下為實(shí)現(xiàn)這一目標(biāo)的幾大重要前提：

· 對(duì)整體環(huán)境進(jìn)行持續(xù)監(jiān)控。 能夠?qū)崟r(shí)追蹤全部運(yùn)行中容器內(nèi)的活動(dòng)以提供“真相來(lái)源”，從而及時(shí)發(fā)現(xiàn)攻擊及策略違規(guī)。我們可以選擇市場(chǎng)上的多種不同容器相關(guān)數(shù)據(jù)監(jiān)控框架，但請(qǐng)確保其符合您的容器規(guī)模與速度需求。

· 對(duì)分布式威脅指標(biāo)進(jìn)行關(guān)聯(lián)。 容器的一大特性在于根據(jù)資源可用性分布于計(jì)算基礎(chǔ)設(shè)施之上。由于應(yīng)用程序內(nèi)可能包含大量容器，因此違規(guī)指標(biāo)可能同樣分布于眾多主機(jī)當(dāng)中。因此，我們需要對(duì)其進(jìn)行規(guī)模化快速關(guān)聯(lián)，從而將對(duì)應(yīng)指標(biāo)與特定攻擊聯(lián)系起來(lái)。

· 分析容器與微服務(wù)行為。 微服務(wù)與容器可將應(yīng)用程序拆分為執(zhí)行特定功能且不可變的眾多小型組件。如此一來(lái)，我們將能夠更輕松地理解預(yù)期的正常行為模式。而與正常基準(zhǔn)不符的行為則可能代表存在惡意活動(dòng)。

· 利用機(jī)器學(xué)習(xí)強(qiáng)化威脅檢測(cè)。 容器環(huán)境下生成的數(shù)據(jù)規(guī)模及生成速度往往超出常規(guī)檢測(cè)技術(shù)的承載能力。自動(dòng)化與機(jī)器學(xué)習(xí)類方案能夠更高效地實(shí)現(xiàn)行為建模、模式識(shí)別與分類，從而提高判斷準(zhǔn)確度并減少誤報(bào)狀況。但請(qǐng)不要使用那些僅利用機(jī)器學(xué)習(xí)生成靜態(tài)白名單的解決方案，其往往會(huì)帶來(lái)嚴(yán)重的誤報(bào)并令管理人員因疲勞而忽略掉真正的威脅。

· 攔截并阻止未授權(quán)容器引擎命令。指向容器引擎的命令用于創(chuàng)建、啟動(dòng)并終止容器以及運(yùn)行于容器內(nèi)的全部負(fù)載。這些命令的出現(xiàn)可能破壞容器環(huán)境，因此必須禁止一切未授權(quán)容器引擎命令。

· 自動(dòng)響應(yīng)與取證。 容器因生命周期較短而很少留下可用于事件響應(yīng)及取證的信息。此外，云原生架構(gòu)通常會(huì)利用新系統(tǒng)替換存在問(wèn)題的系統(tǒng)，導(dǎo)致容器在取證調(diào)查時(shí)已然消失。自動(dòng)化機(jī)制能夠確保快速捕捉、分析并升級(jí)信息，從而減輕攻擊與違規(guī)活動(dòng)的影響。

基于容器與微服務(wù)技術(shù)的云原生體系正快速普及，并迫使安全人員重新考慮保護(hù)手段的實(shí)際成效。一套全面的云原生軟件安全程序應(yīng)面向整個(gè)應(yīng)用程序生命周期，包含容器的構(gòu)建、部署與運(yùn)行階段。希望今天的文章能夠?yàn)榇蠹以谶@方面帶來(lái)一點(diǎn)啟示。

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】