云原生趨勢下，金融企業(yè)的安全新挑戰(zhàn)和防護難點解讀

隨著云計算的發(fā)展，以容器和微服務(wù)為代表的云原生技術(shù)受到人們的廣泛關(guān)注，其中Docker和Kubernetes（K8S）是企業(yè)容器運行時和容器編排的首要選擇。然而，在應(yīng)用容器和K8S過程中，大多數(shù)企業(yè)都遇到過不同程度的安全問題，如何保障容器安全，已成為企業(yè)最關(guān)心的問題。為能更好的解決大家在容器云安全方面的所遇到的難題，twt社區(qū)近期持續(xù)組織了多場同行交流和話題研討。現(xiàn)將干貨內(nèi)容整理如下，重點分析解讀金融企業(yè)面臨的安全新挑戰(zhàn)，以及容器云安全防護的典型問題及解決辦法，最后分享同行共識總結(jié)，希望能夠幫助更多金融企業(yè)做好容器云場景下的安全建設(shè)。

一、趨勢分析

（一）傳統(tǒng)信息安全面臨的新挑戰(zhàn)及與容器安全的聯(lián)系和區(qū)別尚峰某大型國有銀行資深云計算專家：傳統(tǒng)安全是基礎(chǔ)?？梢哉J為傳統(tǒng)的安全包裹著容器安全，容器安全不是獨立存在的。沒有一個體系能夠完全脫離傳統(tǒng)的安全完成容器云的安全。因此，先要做好傳統(tǒng)安全，然后再做容器安全。那么，針對容器安全能否使用一些傳統(tǒng)的安全方案？有一些領(lǐng)域確實是沒有辦法去適應(yīng)容器安全。在容器云中，如果是徹底的原生概念，基于容器的動態(tài)肯定會是短平快，即容器的變化會是非?？斓摹Ｈ萜魇且粋€不可變基礎(chǔ)設(shè)施，一般不會基于原有的技術(shù)、原有的東西去做變更，而是徹底摒棄掉老的，生成一個新的，對于這種情況，其安全體系需要能夠識別新和老的這種更替，必須能夠適應(yīng)這種新的場景。容器云要監(jiān)控的對象比傳統(tǒng)的全面監(jiān)控對象要多很多倍，這樣就會有很多的關(guān)系存在，這張網(wǎng)就會越來越復(fù)雜，這也是對容器云安全的的一大挑戰(zhàn)。此外，因為容器是標準化的，標準化就意味著要做的事情幾乎是一定的，在運行的過程中間，如果超出了這個范圍即是異常，所以這種情況也需要有機制能夠去識別，去監(jiān)測，并且有一定的機制能夠去進行阻擋，或是人為的干預(yù)等等。王洪濤

紅帽資深解決方案架構(gòu)師：傳統(tǒng)信息安全和容器安全，其實是兩個互補的部分，容器安全不能夠解決所有問題，傳統(tǒng)安全也不能捎帶著把容器安全解決了，因為它們各司其職，或者說各自的側(cè)重點是不一樣的。以一個比較形象的比喻來說：傳統(tǒng)的信息安全，就好像一個小區(qū)，小區(qū)門口設(shè)立一個保安；現(xiàn)在在容器云平臺上，這個小區(qū)太大了，光在門口做保安檢查是不夠的，需要在這個小區(qū)的每棟樓，甚至每戶門口都要有保安才能解決問題。這是容器的一些特點所決定的。而像日常的傳統(tǒng)信息安全的范疇，比如說操作系統(tǒng)殺毒，其實就不應(yīng)該放在容器的安全的成本內(nèi)去考慮。比如平臺上的網(wǎng)絡(luò)抓包分析，如果通過容器云平臺的安全機制去解決，其性能損耗其實是不值得的，肯定要借助于之前的傳統(tǒng)網(wǎng)絡(luò)解決方案，傳統(tǒng)的走路由器或者做F5。因此，傳統(tǒng)安全和容器安全是互補的關(guān)系，需要搞清楚它們各自的職責和角色分工，它們是缺一不可的。（二）容器云安全防護的需求在容器云使用過程中，會發(fā)現(xiàn)與傳統(tǒng)的安全有很大的區(qū)別。傳統(tǒng)的安全管控，主要是在網(wǎng)絡(luò)邊界或者主機層面使用防火墻進行限制。但是使用容器云之后，所有的容器都運行在集群的內(nèi)部，傳統(tǒng)的防火墻，對該類防護已經(jīng)無能為力了。需要從容器化基礎(chǔ)設(shè)施、容器編排平臺、云原生應(yīng)用以及無服務(wù)等方面分析云原生安全威脅、云原生安全漏洞風險、容器鏡像、容器運行時、容器網(wǎng)絡(luò)、云原生可觀測性、宿主機威脅檢測等方面綜合考慮，具體體現(xiàn)在如下幾點需求：1)同一個容器云集群中，不同namespace之間的網(wǎng)絡(luò)防護：默認情況下我們不希望不同的namespace可以直接互相訪問，這樣不利于安全控制，如果有一個pod失陷，攻擊者就可以進行橫向移動，造成危害。

2)怎樣對個別Pod進行網(wǎng)絡(luò)防護：在同一個Namespace中，默認情況下，Pod之間是可以互相訪問的，但是有時可能會有特殊需求，不希望該Pod被其他Pod訪問到或者只能訪問指定的端口。

3)出容器云集群后的流量識別：在傳統(tǒng)應(yīng)用部署上，應(yīng)用被部署在特定的幾臺機器上，出口流量也就是固定的幾個IP，但是在容器云上，出口的IP有可能是容器云集群中的任何一個Node，而且與其他在容器云上的應(yīng)用混雜在一起，那么在網(wǎng)絡(luò)的邊界，傳統(tǒng)的防火墻如何去識別這些流量，對不同的應(yīng)用去做不同的網(wǎng)絡(luò)策略。4)Pod之間的流量加密：這個需求在自建私有云上用到的比較少，但是如果是租用公有云的用戶，這種需求就可能存在了，畢竟底層的網(wǎng)絡(luò)流量不能在用戶自己的掌控下，被流量抓包和分析的可能性還是很大。

5)容器基礎(chǔ)鏡像的安全：基礎(chǔ)鏡像作為我們的應(yīng)用運行的底層，如果出現(xiàn)安全漏洞，所有以該鏡像所生成的應(yīng)用鏡像都受到影響，如何確保基礎(chǔ)鏡像的安全。

6)容器運行狀態(tài)下的安全檢測：當容器在鏡像倉庫中時，可以通過掃描鏡像倉庫發(fā)現(xiàn)一些可疑鏡像，但是如果鏡像已經(jīng)部署在容器云中，那么使用哪些手段可以快速發(fā)現(xiàn)可疑容器以及對應(yīng)的鏡像。二、容器云安全防護典型問題及解決辦法（一）上云之后安全的管理邊界和方式■

典型問題1：都強調(diào)編制規(guī)范、標準、基線很重要，那在研發(fā)中心和運維中心中，哪個中心組織編制這些資料會更好？還是會針對開發(fā)和運維分別編制？rechen某股份制銀行云計算架構(gòu)師：以我們行為例，整個規(guī)范是架構(gòu)辦，負責整個應(yīng)用的推廣，整個規(guī)范的制定過程或者審核過程其實是個虛擬工作組，會把數(shù)據(jù)中心的同事拉上來，最終會做K8S集群的運維。基本上我們是歸口在架構(gòu)管理團隊，發(fā)布、牽頭制定職能規(guī)范。我們?nèi)萜鬟@邊有一個團隊，主體是各個職能團隊，但是整個發(fā)布出來的話，是放在架構(gòu)的完善。尚峰

某大型國有銀行資深云計算專家：有一個這樣的做法：誰運維誰定規(guī)范。當然不是說其一家獨大或者一言堂，對于開發(fā)而言，需要參與制定過程，尤其是云上應(yīng)用的運行規(guī)范，基本上要運維方確定怎么運行更好，保證穩(wěn)定安全，這些是由運維方指定的。我們特殊在我們既是建設(shè)方又是運維方，所以我們的規(guī)范基本上包含了全流程。開發(fā)平臺的部門也要介入規(guī)范的制定，最終是由運維方來牽頭做這件事。我們的做法是這樣?！?/p>

典型問題2：好多容器安全都沒有七層防護，而紅帽有像WAF這種防護能力，WAF要是基于HTTPS，是怎么去做的？這個產(chǎn)品還有其他功能嗎？王洪濤

紅帽資深解決方案架構(gòu)師：WAF的功能界定，就看你要用到多深。畢竟有專門做WAF的這種Web應(yīng)用的防火墻的。紅帽的這個產(chǎn)品，還是把重心關(guān)注在容器層的，用來彌補傳統(tǒng)的WAF軟件的不足，比如：在復(fù)雜的容器環(huán)境下，網(wǎng)絡(luò)噪音和攻擊信號更難識別，容器安全產(chǎn)品以容器而不是以應(yīng)用為檢測對象，使攻擊信號更容易分辨;在受到危險的攻擊后，容器安全產(chǎn)品可采用積極主動的響應(yīng)手段，調(diào)動orchestrator重啟容器。除此之外，對于對于Web應(yīng)用的啟動防護。還可以利用容器安全產(chǎn)品的微隔離技術(shù)，實現(xiàn)聲明式網(wǎng)絡(luò)安全；利用容器平臺，比如OpenShift，有一個Router層的安全加固能力，實現(xiàn)HTTPS加密、防DDOS攻擊等這些層面的能力?！?/p>

典型問題3：微隔離如何實現(xiàn)？對于那種橫向的移動攻擊，可以主動發(fā)現(xiàn)或主動防護嗎？王洪濤紅帽資深解決方案架構(gòu)師：微隔離的實現(xiàn)，主要利用Kubernetes內(nèi)置的網(wǎng)絡(luò)執(zhí)行功能，確保一致、可移植和可擴展的分段；另外，微隔離還需要實現(xiàn)命名空間、部署和容器集之間的網(wǎng)絡(luò)流量可視化，包括允許流量、活動流量、集群內(nèi)外流量；以聲明式安全為準則，消除不必要的網(wǎng)絡(luò)連接許可，以最大化的減少對環(huán)境的運維風險。還應(yīng)該提供一種能力，比如自動提取當前網(wǎng)絡(luò)訪問的策略，然后給出網(wǎng)絡(luò)策略的最佳推薦（基于當前活動的網(wǎng)絡(luò)連接），還可以跟蹤和定位每一個網(wǎng)絡(luò)連接，便于安全人員進行判斷和處理。對于橫向的移動攻擊，有網(wǎng)絡(luò)基線的能力，服務(wù)運行一段時間后，安全平臺自動創(chuàng)建網(wǎng)絡(luò)基線，若網(wǎng)絡(luò)活動一旦違反基線，比如做左右平移的時候違反了基線，馬上就能發(fā)現(xiàn)，并出現(xiàn)異常告警。■

典型問題4：對于一個傳統(tǒng)的企業(yè)來講，隔離和安全可能有一個安全職能的部門來負責，上云的過程對運維和安全部門等組織架構(gòu)有什么影響？由哪個職能部門來牽頭或者具體執(zhí)行？張立

某銀行資深工程師：我們現(xiàn)在其實還是盡量沿用以前的邊界，但是比如微隔離，以及現(xiàn)在跟防火墻聯(lián)動等，這些還是以前的網(wǎng)絡(luò)安全部門有人去負責去控制，但是跟我們會有交互有聯(lián)動，我們會推送他們這些pod變化，然后他們?nèi)ラ_通相應(yīng)的策略，這些都是自動化的。但是整體策略的維護還是由他們來負責。然后像一些安全方面，比如說一些防護入侵檢測，包括防護這些介質(zhì)的安全，還是交給安全部門去負責，需要向容器部門的人提相應(yīng)的需求，包括一些平常部署管控的方式。比如說安全的人可能說，我希望部署哪些，那你就要評估這種方式是否合適，是不是可以換成那種方式可能會更好一些。但是整體上來說，我們盡量不打破原有的分工的體系，因為我認為這語言本身是一個大的體系，需要很多周邊部門的配合、合作，才能把它落地，才能把它做得好，如果什么東西都想伸一手，都自己去搞的話，其實不一定會搞得太好。把大家的邊界說清楚了，然后大家互相通力合作會更好一些。（二）基礎(chǔ)鏡像和鏡像倉庫的管理■

典型問題1：按銀行監(jiān)管方面要求，開發(fā)測試生產(chǎn)這些環(huán)境，正常來說都是要從最開始的進行物理隔離，這樣一來，我們這些版本、鏡像可能都沒法互相傳，或者說有些環(huán)境互相可以連通，但不可能一連串都連通。容器云是怎么樣很好的來支持DevOps、CICD的？

張立某銀行資深工程師：首先，這種情況就是不同環(huán)境之間介質(zhì)的流轉(zhuǎn)，特別是從開發(fā)測試往生產(chǎn)流轉(zhuǎn)的時候，以前是有一套類似門禁或者審批等等機制，其實現(xiàn)在也是有的，要走一個相當大的準入審批。另外，CICD的整個流程可能涉及到從開發(fā)端到整個部署，這是一個比較長的鏈條。我們開發(fā)端有一套相應(yīng)的工具體系，我們叫APaaS（ApplicationPaaS），這里面集成了前端后端的標準化的開發(fā)框架，還有標準的基于容器的流水線，我們現(xiàn)在針對容器的微服務(wù)架構(gòu)是前后端分離的。每個工程只能形成一個鏡像，還有微服務(wù)的方式去做這種流水線。改動都是自動化的，根據(jù)定義的生產(chǎn)部署模型自動去適配，然后去做相應(yīng)的一些替換。（三）容器運行時安全■

典型問題1：企業(yè)應(yīng)用的穩(wěn)定運行離不開運行時刻的安全防護手段。采用什么手段可以較好的進行實時監(jiān)控和告警諸如面向容器內(nèi)部入侵，容器逃逸，病毒和惡意程序，異常網(wǎng)絡(luò)連接等常見的運行時刻攻擊行為？同時針對告警事件的溯源和攻擊分析提供有效能力？Liyuanlong某銀行資深工程師：容器運行時目前有多種辦法：1、通過宿主機agent的形式來監(jiān)控容器行為，包括入侵，反彈shell等行為2、通過平行容器的方式來監(jiān)控容器，效果類似，與上一個的區(qū)別在于無法監(jiān)控宿主機的行為3、通過進程白名單的形式，建議采用這種形式。容器與主機不同，就在于其足夠單一，一個容器的進程通常不會太復(fù)雜，因此，可以通過白名單的形式來進行安全監(jiān)控，實現(xiàn)方式平行容器和宿主機agent都可4、流量監(jiān)測的形式發(fā)現(xiàn)異常行為，這種目前不太好做，因為容器內(nèi)部流量較大，尤其是集群內(nèi)東西向流量，因此流量監(jiān)測能做，但是不好做?，F(xiàn)在的建議是采用進程白名單的形式來做。王洪濤紅帽資深解決方案架構(gòu)師：RHACS是Kubernetes原生安全管理平臺，能夠提供異構(gòu)K8S下多集群的統(tǒng)一容器安全管理。包括進行實時監(jiān)控和告警諸如面向容器內(nèi)部入侵，容器逃逸，病毒和惡意程序，異常網(wǎng)絡(luò)連接等常見的運行時刻攻擊行為，同時針對告警事件的溯源和攻擊分析提供有效能力?！?/p>

典型問題2：容器在安全領(lǐng)域有沒有比較推薦的整治與加固措施？Steven某券商資深云架構(gòu)師：容器安全措施跟傳統(tǒng)的安全措施沒有本質(zhì)的區(qū)別，只不過需要根據(jù)容器自身的特點選擇合適的方法和機制。比如靜態(tài)安全測試、動態(tài)安全測試、入侵檢測、病毒防護、網(wǎng)絡(luò)流量監(jiān)控、漏洞檢測等。但容器自身的特點是輕量、彈性、無狀態(tài)、生命周期短等。采用容器通常容器的量是很大的，往往無法實現(xiàn)人工對每個容器管理，需要實現(xiàn)自動化。采用容器通常要盡可能安全左移，將安全風險消滅在部署之前。但運行時安全措施同樣一點不可少。采用容器，盡可能實現(xiàn)基礎(chǔ)設(shè)施自服務(wù)能力，安全能力也是一樣，比如發(fā)現(xiàn)漏洞后可能成百數(shù)千個容器都需要更新升級。而且不適合用傳統(tǒng)網(wǎng)絡(luò)防火墻的管理方式目前容器安全方案還在發(fā)展中，簡單的可以按照應(yīng)用生命周期分設(shè)計時和運行時進行安全檢測和防護。不過沒有100%安全，有時需要根據(jù)實際有所取舍。基本上需要考慮代碼的安全檢測、鏡像安全檢測、運行時防護、入侵檢測、病毒防護、節(jié)點安全、接口安全等?！?/p>

典型問題3：容器逃逸問題主要是dockerrunc等基礎(chǔ)軟件的漏洞引起，雖然發(fā)生概率低，但破壞性大，一旦逃逸，可能會使得黑客拿到宿主機權(quán)限，從而對基礎(chǔ)設(shè)施造成破壞性攻擊。直接影響到了承載容器的底層基礎(chǔ)設(shè)施的保密性、完整性和可用性。容器的逃逸問題如何解決？擊歌吟某保險集團資深工程師：在運行容器的時候，如果容器的使用不合理會造成容器逃逸等安全問題，所以啟動容器就要給容器賦予最小權(quán)限，可以從如下兩個方面考慮：一、賦予容器合理的capabilities；二、在容器中以非root用戶運行程序。首先：Linuxcapabilities是把root用戶的所有的特權(quán)做了分化，當我們啟動不同功能的進程就要給容器賦予不同的權(quán)限，例如進程運行iptables命令，就要給容器賦予CAP_NET_ADMIN這個capability。其次：是盡量不用特權(quán)用戶啟動容器，一般是用root用戶，系統(tǒng)默認會帶有15個capabilities,當發(fā)現(xiàn)容器進程權(quán)限不夠的時候，需要根據(jù)使用情況整理capabilities集合，而不是直接賦予privileged權(quán)限。另外當我們在K8s運行容器需要特權(quán)用戶權(quán)限掛載塊存儲并創(chuàng)建目錄時，盡量通過InitContainer賦予較高權(quán)限來完成該操作。三、容器云安全防護難點解決辦法共識總結(jié)相比于傳統(tǒng)應(yīng)用而言，容器天然是弱安全的