容器是目前應(yīng)用系統(tǒng)運(yùn)行的常用環(huán)境，特別是對(duì)于復(fù)雜的應(yīng)用系統(tǒng)，開(kāi)發(fā)人員更喜歡使用基于容器的開(kāi)發(fā)架構(gòu)，因?yàn)槿萜魇禽p量級(jí)的、可移植的，并且易于維護(hù)和擴(kuò)展。由于這些特性，容器非常適用于現(xiàn)代開(kāi)發(fā)模式，如DevOps、無(wú)服務(wù)器和微服務(wù)等。

開(kāi)發(fā)人員可在容器中封裝了應(yīng)用程序的輕量級(jí)運(yùn)行時(shí)環(huán)境。因此，當(dāng)在容器中開(kāi)發(fā)微服務(wù)時(shí)，它繼承了容器化的優(yōu)點(diǎn)，如可移植性、可伸縮性和額外安全層等。同時(shí)，在單獨(dú)的容器中運(yùn)行微服務(wù)，用戶可以獨(dú)立地部署它們，消除了語(yǔ)言、庫(kù)和框架之間的兼容性風(fēng)險(xiǎn)。在服務(wù)監(jiān)測(cè)方面，容器化使微服務(wù)更容易定位和相互通信，因?yàn)樗鼈兌歼\(yùn)行在位于同一平臺(tái)上的容器中，開(kāi)發(fā)人員將更容易編排微服務(wù)。

微服務(wù)和容器應(yīng)用的安全挑戰(zhàn)

雖然基于容器的微服務(wù)開(kāi)發(fā)應(yīng)用方法有諸多好處，包括易于擴(kuò)展和管理，但它們也同樣存在一些的安全問(wèn)題。在服務(wù)開(kāi)發(fā)之前，企業(yè)應(yīng)該了解可能出現(xiàn)的網(wǎng)絡(luò)安全風(fēng)險(xiǎn)以及如何消除這些風(fēng)險(xiǎn)，將有助于創(chuàng)建可靠又安全的產(chǎn)品。

1. 可被利用的漏洞

一般來(lái)說(shuō)，與微服務(wù)和容器相關(guān)的安全問(wèn)題屬于應(yīng)用編排平臺(tái)的整體安全需求中。但是，并非所有的安全風(fēng)險(xiǎn)都可以在業(yè)務(wù)流程中處理。比如說(shuō)可能被利用的漏洞。

映像漏洞是基于微服務(wù)和容器的應(yīng)用程序內(nèi)最常見(jiàn)的安全威脅。它們通常來(lái)自不安全的庫(kù)或其他依賴項(xiàng)。當(dāng)容器基于不安全的映像時(shí)，就會(huì)將該漏洞威脅引入整個(gè)應(yīng)用環(huán)境；

應(yīng)用程序漏洞主要指應(yīng)用程序的源代碼缺陷。比如某個(gè)應(yīng)用程序中存在一個(gè)緩沖區(qū)溢出漏洞，攻擊者可能會(huì)利用它來(lái)執(zhí)行惡意代碼并接管容器；

網(wǎng)絡(luò)攻擊的漏洞。基于微服務(wù)的應(yīng)用程序比傳統(tǒng)應(yīng)用程序更復(fù)雜，因?yàn)樗鼈冇稍S多獨(dú)立部件組成。一個(gè)應(yīng)用程序可以包括部署在數(shù)千個(gè)容器中的數(shù)百個(gè)微服務(wù)，這使得基于微服務(wù)的應(yīng)用程序非常容易受到網(wǎng)絡(luò)攻擊，因?yàn)楹茈y同時(shí)確保這么多組件的整體安全性。

2. 惡意軟件風(fēng)險(xiǎn)

惡意軟件的危害在于，如果企業(yè)在啟動(dòng)容器之前沒(méi)有檢測(cè)到它，惡意軟件將感染此容器內(nèi)的微服務(wù)以及整個(gè)環(huán)境。惡意軟件攻擊帶來(lái)的安全風(fēng)險(xiǎn)主要包括：

黑客可以訪問(wèn)一個(gè)容器并向其中注入惡意代碼，通過(guò)惡意代碼可以攻擊該容器、其他容器或主機(jī)操作系統(tǒng)中的微服務(wù)；

惡意攻擊者會(huì)危害企業(yè)的CI/CD環(huán)境，并將惡意軟件注入用于構(gòu)建容器映像的源代碼存儲(chǔ)庫(kù)；

攻擊者會(huì)破壞容器注冊(cè)表并替換包含惡意軟件的圖像；

攻擊者欺騙開(kāi)發(fā)人員從外部來(lái)源下載惡意容器映像。

3. 與代碼訪問(wèn)相關(guān)的風(fēng)險(xiǎn)

訪問(wèn)和修改代碼的人越多，安全風(fēng)險(xiǎn)就越大，最常見(jiàn)的情況是：

訪問(wèn)權(quán)限過(guò)大。許多開(kāi)發(fā)公司選擇DevOps方法來(lái)使用微服務(wù)和容器構(gòu)建應(yīng)用程序，這可能導(dǎo)致訪問(wèn)權(quán)限過(guò)于寬泛，增加了在分布式工作環(huán)境中惡意修改代碼的風(fēng)險(xiǎn)。

機(jī)密管理薄弱。在安全實(shí)踐不佳或違反安全規(guī)則的情況下，很多人可以訪問(wèn)容器。例如，開(kāi)發(fā)人員可能將腳本中編碼的憑證放入容器中，或者將憑證存儲(chǔ)在配置不安全的密鑰管理系統(tǒng)中。

4. 容器間的通信不受限制

通常情況下，容器不能訪問(wèn)外部任何資源，這被稱為非特權(quán)模式。工程師應(yīng)該只允許保障應(yīng)用系統(tǒng)正常工作所必需的容器間通信。每當(dāng)容器的通信權(quán)限超過(guò)嚴(yán)格要求時(shí)，它可能會(huì)導(dǎo)致額外的安全風(fēng)險(xiǎn)。由于缺乏經(jīng)驗(yàn)或管理不當(dāng)而導(dǎo)致的錯(cuò)誤配置，會(huì)讓容器獲得過(guò)多的特權(quán)。

5. 不安全的數(shù)據(jù)管理

微服務(wù)體系的分布式框架使得數(shù)據(jù)安全管理更具挑戰(zhàn)性，因?yàn)楹茈y控制對(duì)單個(gè)服務(wù)的訪問(wèn)和安全授權(quán)。因此，工程師必須更加關(guān)注如何確保每個(gè)服務(wù)內(nèi)數(shù)據(jù)的機(jī)密性、隱私性和完整性。另一個(gè)問(wèn)題是，微服務(wù)中的數(shù)據(jù)不斷地移動(dòng)、更改，并在不同的服務(wù)中用于不同的目的，這為攻擊者創(chuàng)建了更多的數(shù)據(jù)竊取攻擊點(diǎn)。

6. 錯(cuò)誤配置工具

在開(kāi)發(fā)和維護(hù)微服務(wù)架構(gòu)時(shí)，DevOps團(tuán)隊(duì)需要使用大量工具，包括開(kāi)源和第三方工具。雖然這類工具幫助工程師實(shí)現(xiàn)DevOps管道所需的效率，但它們很難保證所需要的安全性。

如果不能準(zhǔn)確評(píng)估開(kāi)源工具的安全功能，企業(yè)就有可能在微服務(wù)和容器中創(chuàng)建漏洞。即使一個(gè)工具本身是安全，如果沒(méi)有正確設(shè)置，也會(huì)出現(xiàn)很多安全問(wèn)題。

微服務(wù)和容器安全防護(hù)最佳實(shí)踐

如何選擇適當(dāng)?shù)陌踩胧﹣?lái)應(yīng)對(duì)上面提到的風(fēng)險(xiǎn)可能是一個(gè)挑戰(zhàn)。究其原因，容器和微服務(wù)都是因?yàn)樗鼈儜?yīng)用的簡(jiǎn)潔性和快捷性而對(duì)開(kāi)發(fā)人員具有如此大的吸引力。如果安全措施使開(kāi)發(fā)流程變得緩慢和復(fù)雜，那么就很可能會(huì)被開(kāi)發(fā)人員所抵觸或故意忽視。為了幫助企業(yè)在安全的情況下高效利用容器和微服務(wù)進(jìn)行應(yīng)用系統(tǒng)開(kāi)發(fā)，本文收集整理了10種有用的最佳實(shí)踐。

1. 創(chuàng)建不可變?nèi)萜?/p>

開(kāi)發(fā)人員往往保留通過(guò)shell訪問(wèn)映像的途徑，以便修復(fù)生產(chǎn)環(huán)境中的映像。然而，攻擊者常利用這條途徑來(lái)注入惡意代碼。要避免這種情況，可以創(chuàng)建不可變?nèi)萜鳌２豢勺內(nèi)萜鳠o(wú)法被改動(dòng)。如果用戶需要更新應(yīng)用程序代碼、打補(bǔ)丁或更改配置，可以重新構(gòu)建映像并重新部署容器。如果用戶需要撤回更改，只需重新部署舊映像。需要注意的是，容器的不可變特性會(huì)影響到數(shù)據(jù)持久性。開(kāi)發(fā)人員應(yīng)該將數(shù)據(jù)存儲(chǔ)在容器外面，這樣容器被替換時(shí)，所有數(shù)據(jù)仍可供新版本使用。

2. 將自動(dòng)安全測(cè)試集成到CI/CD過(guò)程中

有各種工具可以在CI/CD過(guò)程中自動(dòng)測(cè)試容器。比如說(shuō)，HP Fortify和IBM AppScan提供動(dòng)態(tài)和靜態(tài)應(yīng)用程序安全測(cè)試。還可以使用JFrog Xray和Black Duck等掃描器實(shí)時(shí)檢查容器中已知的漏洞。一旦這類工具發(fā)現(xiàn)了漏洞，就會(huì)將檢測(cè)到有問(wèn)題的部分標(biāo)注出來(lái)，以便檢查和修復(fù)。

3. 避免使用特權(quán)容器

如果容器在特權(quán)模式下運(yùn)行，它就可以訪問(wèn)主機(jī)上的所有組件。如果這種容器被破壞，攻擊者可以全面訪問(wèn)服務(wù)器。因此，應(yīng)該考慮盡量避免使用特權(quán)容器。比如在Kubernetes中，可以使用策略控制器（Policy Controller）禁止特權(quán)容器。

如果出于某種原因需要使用特權(quán)容器，谷歌云架構(gòu)中心提供了幾個(gè)替代方案：

通過(guò)Kubernetes的securityContext選項(xiàng)為容器提供特定的功能

在sidecar容器或init容器中修改應(yīng)用程序設(shè)置

使用專用注釋修改Kubernetes中的sysctls接口

4. 建立可信映像庫(kù)

開(kāi)源社區(qū)會(huì)為開(kāi)發(fā)人員提供許多具有容器的開(kāi)源軟件包。但是出于安全目的，開(kāi)發(fā)者需要知道容器的來(lái)源、更新時(shí)間以及它們是否含有漏洞和惡意代碼。最好建立可信映像庫(kù)，只從這個(gè)可信源運(yùn)行映像。如果想使用其他來(lái)源的映像，建議首先使用掃描工具掃描映像。此外，在將容器部署到生產(chǎn)環(huán)境之前，開(kāi)發(fā)人員應(yīng)檢查腳本中的應(yīng)用程序簽名。如果在多個(gè)云環(huán)境中運(yùn)行容器，需要建立多個(gè)安全映像存儲(chǔ)庫(kù)。

5. 使用注冊(cè)中心管理映像

Docker Hub、Amazon EC2 Container Registry和Quay Container Registry等注冊(cè)中心可以幫助開(kāi)發(fā)人員存儲(chǔ)和管理已創(chuàng)建的映像。可以使用這些注冊(cè)中心執(zhí)行以下操作：

提供基于角色的訪問(wèn)控制

指定容器的可信源

創(chuàng)建和更新已知漏洞列表

標(biāo)注易受攻擊的映像

基于角色的訪問(wèn)控制非常重要，因?yàn)樾枰刂普l(shuí)可以改變?nèi)萜鳌Ｗ詈脤⒃L問(wèn)權(quán)限分開(kāi)到不同的管理帳戶：一個(gè)負(fù)責(zé)系統(tǒng)管理，另一個(gè)負(fù)責(zé)操作和編排容器。要記住的另一點(diǎn)是，應(yīng)該確保注冊(cè)中心驗(yàn)證每個(gè)容器的簽名，只接受來(lái)自可信源的容器。此外，需要充分利用幫助不斷檢查映像內(nèi)容查找已知漏洞，并報(bào)告安全問(wèn)題的功能。

6. 加固主機(jī)操作系統(tǒng)

保障微服務(wù)和容器的應(yīng)用安全，有必要確保主機(jī)操作系統(tǒng)的安全。

首先，建議企業(yè)使用針對(duì)特定容器的主機(jī)操作系統(tǒng)（明確旨在只運(yùn)行容器的簡(jiǎn)版主機(jī)操作系統(tǒng)），因?yàn)樗鼈儧](méi)有不必要的功能，因而攻擊面比通用主機(jī)系統(tǒng)小很多。

其次，CIS Docker Benchmark提供了加固系統(tǒng)的核對(duì)列表，主要的建議如下：

建立用戶身份驗(yàn)證

設(shè)置訪問(wèn)角色

指定二進(jìn)制文件訪問(wèn)權(quán)限

收集詳細(xì)的審計(jì)日志

為了避免數(shù)據(jù)泄露，應(yīng)該限制容器對(duì)底層操作系統(tǒng)資源的訪問(wèn)，并將容器彼此隔離。一個(gè)好的做法是在內(nèi)核模式下運(yùn)行容器引擎，同時(shí)在用戶模式下運(yùn)行容器。比如說(shuō)，Linux提供了Linux命名空間、seccomp、cgroups和SELinux等技術(shù)，從而安全地構(gòu)建和運(yùn)行容器。

7. 用縱深防御方法保護(hù)微服務(wù)

縱深防御可以結(jié)合多種安全機(jī)制和控制措施，比如殺毒軟件、防火墻和補(bǔ)丁管理，以保護(hù)網(wǎng)絡(luò)和數(shù)據(jù)的機(jī)密性、完整性和可用性。

縱深防御方法的三大層是：

物理控制——用于物理限制用戶訪問(wèn)IT系統(tǒng)，比如安保系統(tǒng)和閉路電視系統(tǒng)

技術(shù)控制——旨在保護(hù)系統(tǒng)和資源的軟硬件

管理控制——通過(guò)各種策略和程序，以確保組織關(guān)鍵基礎(chǔ)設(shè)施的網(wǎng)絡(luò)安全性

縱深防御方法是確保微服務(wù)安全的最重要原則之一，因?yàn)樗鼊?chuàng)建了多層安全以防止攻擊。它包括下列安全措施：過(guò)濾傳輸?shù)臄?shù)據(jù)流、驗(yàn)證和授權(quán)對(duì)微服務(wù)的訪問(wèn)以及使用加密技術(shù)等。要確保內(nèi)部環(huán)境不受任何外部連接的影響，因?yàn)檫@是安全防護(hù)的基礎(chǔ)。

8. 嚴(yán)格控制API訪問(wèn)

API是微服務(wù)應(yīng)用程序的關(guān)鍵，很多軟件都會(huì)有多個(gè)獨(dú)立的API服務(wù)。因此，確保安全身份驗(yàn)證和授權(quán)的API訪問(wèn)控制對(duì)于微服務(wù)安全至關(guān)重要。當(dāng)API服務(wù)訪問(wèn)敏感數(shù)據(jù)時(shí)，應(yīng)該需要提供驗(yàn)證令牌，令牌要經(jīng)過(guò)數(shù)字簽名或得到權(quán)威來(lái)源的驗(yàn)證。開(kāi)發(fā)人員和管理員可以使用OAuth/OAuth2服務(wù)器來(lái)獲取令牌，以便通過(guò)API訪問(wèn)應(yīng)用程序。出于安全考慮，還應(yīng)該使用傳輸層安全（TLS）加密來(lái)保護(hù)所有客戶機(jī)/服務(wù)器通信。

9. 原生化容器檢測(cè)工具

持續(xù)性監(jiān)測(cè)容器的運(yùn)行很有必要，因?yàn)樗梢詭椭脩簦?/p>

深入了解容器度量指標(biāo)和日志

了解集群、主機(jī)以及容器內(nèi)部正在發(fā)生的情況

做出更明智的安全運(yùn)營(yíng)決策

然而要確保有效的監(jiān)視，最好使用容器原生監(jiān)視工具。比如在使用Docker時(shí)，開(kāi)發(fā)人員通常使用Docker Security Scanner或其他專門(mén)設(shè)計(jì)的工具來(lái)檢測(cè)任何潛在威脅。監(jiān)視工具會(huì)先收集事件，然后對(duì)照設(shè)置好的安全策略加以對(duì)比分析和檢查。

10. 使用服務(wù)編排管理器

服務(wù)編排是個(gè)復(fù)雜的過(guò)程，可使微服務(wù)和容器的部署、管理、擴(kuò)展和連接實(shí)現(xiàn)自動(dòng)化。編排器負(fù)責(zé)從注冊(cè)中心提取映像，將這些映像部署到容器，并管理容器運(yùn)行。編排器提供的抽象讓用戶可以指定運(yùn)行某個(gè)映像所必需的容器數(shù)量，以及需要為它們分配哪些主機(jī)資源。

如果使用編排管理器，不僅可以自動(dòng)部署微服務(wù)，還可以確保一定級(jí)別的安全。比如說(shuō)，編排器便于管理容器集群、隔離工作負(fù)載、限制對(duì)元數(shù)據(jù)的訪問(wèn)以及收集日志。許多編排管理器還有內(nèi)置的機(jī)密數(shù)據(jù)管理工具，允許開(kāi)發(fā)人員安全地存儲(chǔ)和共享機(jī)密數(shù)據(jù)，比如API和SSL證書(shū)、加密密鑰、身份令牌和密碼。

更多信息可以來(lái)這里獲取==>>電子技術(shù)應(yīng)用-AET<<