當(dāng)今，企業(yè)在加速應(yīng)用現(xiàn)代化的同時(shí)，往往將 Kubernetes 安全置于次要地位。盡管這樣的風(fēng)險(xiǎn)越來(lái)越高，但我們?nèi)孕柚?jǐn)慎對(duì)待那些能夠緩解容器化環(huán)境威脅的安全策略。

一方面，安全措施必須足夠精準(zhǔn)，才能滿足嚴(yán)格的合規(guī)要求，并通過(guò)審計(jì)這一關(guān)。組織必須遵守的各種法規(guī)包括 SOC 2、PCI DSS、GPDR、HIPAA 等等。與此同時(shí)，無(wú)論采用哪種安全流程，都要確保 DevOps 和開發(fā)人員的生產(chǎn)力不會(huì)受到影響。這是一種微妙的平衡法，容錯(cuò)率極低。

為了確保在容器化環(huán)境中持續(xù)合規(guī)，而不影響生產(chǎn)力，請(qǐng)遵循以下 6 個(gè)實(shí)踐。

1. 實(shí)現(xiàn)自動(dòng)化

市面上有許多出色的、完全開源的工具可供選擇，合適的工具能夠幫助企業(yè)實(shí)現(xiàn)實(shí)時(shí)威脅響應(yīng)和持續(xù)在線監(jiān)控，從而確保持續(xù)合規(guī)。例如，企業(yè)應(yīng)將自動(dòng)化漏洞掃描和安全策略即代碼(https://www.darkreading.com/cloud/security-as-code-gains-more-support-but-still-nascent)集成到流水線中。通過(guò)自動(dòng)化 Kubernetes 審計(jì)日志分析工具處理日志和事件。基于機(jī)器學(xué)習(xí)的 SIEM 技術(shù)能夠快速自動(dòng)識(shí)別攻擊模式。企業(yè)還應(yīng)利用 CIS 基準(zhǔn)和自定義合規(guī)核查來(lái)持續(xù)檢查 Kubernetes 配置。

2. 對(duì) Kubernetes 本身進(jìn)行保護(hù)

將 Kubernetes 本身視為攻擊面至關(guān)重要，因?yàn)楣粽咭欢〞?huì)這樣做。威脅越來(lái)越復(fù)雜，企業(yè)需要主動(dòng)保護(hù)容器環(huán)境背后的全棧，以實(shí)現(xiàn)持續(xù)合規(guī)。保護(hù)措施包括：?jiǎn)⒂米詣?dòng)監(jiān)控、強(qiáng)化反攻擊手段、執(zhí)行配置審計(jì)以及準(zhǔn)備自動(dòng)化緩解。除了 Kubernetes(https://www.darkreading.com/cloud/firms-struggle-to-secure-multicloud-misconfigurations)，企業(yè)對(duì)任何可能受到攻擊的服務(wù)網(wǎng)格、托管 VM、插件或其他目標(biāo)也應(yīng)采取相同措施。

3. 發(fā)現(xiàn)攻擊就能防止攻擊

攻擊殺傷的鏈條通常從啟動(dòng)無(wú)法識(shí)別的容器網(wǎng)絡(luò)連接或進(jìn)程開始，通過(guò)寫入或更改現(xiàn)有文件，或者利用未受到保護(hù)的入口點(diǎn)，來(lái)提升其訪問級(jí)別。然后，此類惡意手段會(huì)利用網(wǎng)絡(luò)流量，將捕獲到的數(shù)據(jù)發(fā)送到外部 IP 地址，造成數(shù)據(jù)泄露。殺傷鏈可能會(huì)以類似的方式將 Kubernetes API 服務(wù)作為中間人攻擊的目標(biāo)，通常會(huì)發(fā)起零日攻擊、內(nèi)部攻擊和加密貨幣挖礦攻擊。利用 Apache Log4j 進(jìn)行的攻擊也日益增多。

數(shù)據(jù)丟失防護(hù) (DLP) 和 Web 應(yīng)用程序防火墻 (WAF) 相結(jié)合的策略能夠提供檢測(cè)活躍殺傷鏈所需的可見性以及自動(dòng)響應(yīng)能力，在可疑的進(jìn)程和流量造成破壞之前將其終止。事實(shí)上，目前許多法規(guī)的合規(guī)框架都專門要求組織具備 DLP 和 WAF 能力，以保護(hù)其容器和 Kubernetes 環(huán)境，這些框架包括 PCI DSS、SOC 2 和 GDPR。(HIPAA 也強(qiáng)烈建議采用 DLP。)

4. 專注于零信任

通過(guò)實(shí)施零信任模型(https://www.darkreading.com/edge/get-started-on-continuous-compliance-ahead-of-pci-dss-v4-0)，企業(yè)不再被動(dòng)地處理在日志分析或基于簽名的檢測(cè)中發(fā)現(xiàn)的威脅。零信任策略只允許經(jīng)過(guò)批準(zhǔn)的進(jìn)程和流量在企業(yè)環(huán)境中活動(dòng)，從而阻止所有攻擊。整個(gè)云原生技術(shù)棧，以及 RBAC 等訪問控制，都必須采取這些零信任防護(hù)措施。這樣一來(lái)，企業(yè)就確保能夠?qū)崿F(xiàn)持續(xù)合規(guī)。

5. 利用Kubernetes 內(nèi)置安全措施

Kubernetes 內(nèi)置的安全功能包括日志審計(jì)、RBAC 以及由 Kubernetes API 服務(wù)器(https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/)集中進(jìn)行的系統(tǒng)日志收集。利用這些功能來(lái)收集并分析所有活動(dòng)日志，從而識(shí)別攻擊或錯(cuò)誤配置。然后，通過(guò)安全補(bǔ)丁或者基于策略的新防護(hù)措施，來(lái)解決各種事件或不合規(guī)的運(yùn)行時(shí)活動(dòng)。

在大多數(shù)情況下，企業(yè)會(huì)希望進(jìn)一步通過(guò)能夠?qū)崿F(xiàn)容器應(yīng)用程序安全和持續(xù)合規(guī)審計(jì)的工具來(lái)支持現(xiàn)有的 Kubernetes 安全措施。企業(yè)應(yīng)使用內(nèi)置的 Kubernetes 準(zhǔn)入控制器(https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)，緊密協(xié)調(diào) Kubernetes 與外部注冊(cè)請(qǐng)求和資源請(qǐng)求。這種方法可以更有效地防止應(yīng)用程序部署中的漏洞和未經(jīng)授權(quán)的行為。

6. 驗(yàn)證云主機(jī)的安全性

托管 Kubernetes 的云平臺(tái)能夠把控自己的系統(tǒng)，必須確保其持續(xù)合規(guī)。然而，如果不檢查這些云托管實(shí)踐是否真正得到了充分保護(hù)，是否履行了企業(yè)自身的合規(guī)責(zé)任，那風(fēng)險(xiǎn)就太高了。事實(shí)上，許多云提供商所提供的責(zé)任共擔(dān)模式(https://www.darkreading.com/cloud/companies-need-to-keep-watch-on-cloud-data)會(huì)將保護(hù)應(yīng)用程序訪問權(quán)限、網(wǎng)絡(luò)行為和云上其他資產(chǎn)的重任直接留給客戶。

實(shí)時(shí)環(huán)境中的持續(xù)合規(guī)

Kubernetes 和容器化環(huán)境極其活躍，容器創(chuàng)建和刪除的速度之快，讓手動(dòng)安全檢查無(wú)法對(duì)其進(jìn)行保護(hù)。此外，許多合規(guī)法規(guī)要求的傳統(tǒng)安全技術(shù)，例如，網(wǎng)絡(luò)分段和防火墻，在容器網(wǎng)絡(luò)中不起作用。

在構(gòu)建、遷移和在生產(chǎn)環(huán)境中運(yùn)行應(yīng)用程序時(shí)，現(xiàn)代的持續(xù)開發(fā)流程會(huì)定期引入新的代碼和容器。因此，法規(guī)要求組織采用自動(dòng)化實(shí)時(shí)安全防護(hù)和審計(jì)措施，以實(shí)現(xiàn)真正的持續(xù)合規(guī)。

原文鏈接：https://mp.weixin.qq.com/s/MQh16-PQYsjaGCjwyxIk_A