云原生環(huán)境下的安全風(fēng)險(xiǎn)及防護(hù)策略研究

【摘 要】 本文對(duì)企業(yè)云原生架構(gòu)特點(diǎn)和云原生環(huán)境下容器、容器編排平臺(tái)、網(wǎng)絡(luò)以及微服務(wù)應(yīng)用等方面面臨的安全風(fēng)險(xiǎn)進(jìn)行了分析說(shuō)明，給出了云原生環(huán)境下安全機(jī)制左移、容器運(yùn)行時(shí)行為的聚焦、最小權(quán)限原則和零信任架構(gòu)的防護(hù)思路，并針對(duì)云原生風(fēng)險(xiǎn)，結(jié)合云原生防護(hù)思路提出了云原生全生命周期的安全防護(hù)解決方案。

【關(guān)鍵詞】 云原生 云安全 容器

1 引言

云計(jì)算的快速發(fā)展和業(yè)務(wù)系統(tǒng)快速迭代部署、可移植性、可擴(kuò)展性等需求的不斷增長(zhǎng)，促使容器化、服務(wù)網(wǎng)格、微服務(wù)、無(wú)服務(wù)等云原生（Cloud Native）技術(shù)得到企業(yè)的廣泛關(guān)注和應(yīng)用。云原生應(yīng)用的敏捷、高效、彈性擴(kuò)展等特性在企業(yè)數(shù)字化轉(zhuǎn)型和降本增效、專注業(yè)務(wù)價(jià)值效率方面發(fā)揮著重大助力作用，但隨之而來(lái)的安全問(wèn)題也日益突出，構(gòu)建全方位的云原生環(huán)境安全體系是企業(yè)“上云”的必經(jīng)之路。

2 云原生環(huán)境及面臨的安全挑戰(zhàn)和風(fēng)險(xiǎn)

大型企業(yè)從傳統(tǒng)的IT系統(tǒng)轉(zhuǎn)型升級(jí)為云原生應(yīng)用系統(tǒng)往往按照不同的業(yè)務(wù)域，分類、分段、分層建設(shè)，應(yīng)用架構(gòu)體系則從基礎(chǔ)設(shè)施架構(gòu)和業(yè)務(wù)能力架構(gòu)兩方面不斷抽象發(fā)展融合。一方面，下沉應(yīng)用系統(tǒng)的全部基礎(chǔ)設(shè)施，將業(yè)務(wù)邏輯與基礎(chǔ)設(shè)施完全解耦，應(yīng)用端聚焦業(yè)務(wù)創(chuàng)新和邏輯功能實(shí)現(xiàn)，基礎(chǔ)設(shè)施提供物理服務(wù)器到應(yīng)用系統(tǒng)函數(shù)代碼之間的全部技術(shù)架構(gòu)和工具軟件，如容器、編排引擎、服務(wù)網(wǎng)格、無(wú)服務(wù)計(jì)算等。另一方面，開(kāi)展業(yè)務(wù)邏輯能力的抽象設(shè)計(jì)，提取共性下沉至可復(fù)用的賦能平臺(tái)，形成小而精的業(yè)務(wù)靈活創(chuàng)新前臺(tái)和厚而廣的共性能力賦能中臺(tái)。

在基于“大中臺(tái)、小前臺(tái)”的平臺(tái)賦能支撐下，云原生的數(shù)字化環(huán)境可以很好地滿足各業(yè)務(wù)領(lǐng)域的功能復(fù)用與快速迭代、數(shù)據(jù)共享與互通、需求敏捷開(kāi)發(fā)與高效交付、應(yīng)用流水線部署與滾動(dòng)升級(jí)、資源彈性擴(kuò)展與實(shí)時(shí)在線以及運(yùn)維自動(dòng)化和智能化的要求。

云原生技術(shù)作為企業(yè)數(shù)字業(yè)務(wù)應(yīng)用創(chuàng)新的原動(dòng)力，在進(jìn)入生產(chǎn)環(huán)境實(shí)現(xiàn)云原生應(yīng)用全生命周期管理，發(fā)揮數(shù)字業(yè)務(wù)快速交付與迭代的優(yōu)勢(shì)過(guò)程中，也帶來(lái)了新的安全風(fēng)險(xiǎn)和挑戰(zhàn)。

云原生安全并不獨(dú)特，傳統(tǒng)IT環(huán)境下的安全問(wèn)題在云環(huán)境下仍然存在，如DoS攻擊、內(nèi)部越權(quán)、漏洞攻擊、數(shù)據(jù)篡改、數(shù)據(jù)泄露等。同時(shí)，由云原生架構(gòu)的多租戶、虛擬化、快速?gòu)椥陨炜s等特點(diǎn)和業(yè)務(wù)應(yīng)用微服務(wù)化帶來(lái)的軟件架構(gòu)復(fù)雜度的大幅提升，內(nèi)部網(wǎng)絡(luò)流量、服務(wù)通信端口、容器等出現(xiàn)、消失的動(dòng)態(tài)變化，業(yè)務(wù)微服務(wù)化后大量服務(wù)認(rèn)證、訪問(wèn)授權(quán)控制機(jī)制的自動(dòng)配置管理，開(kāi)發(fā)測(cè)試和生產(chǎn)環(huán)境中持續(xù)集成和持續(xù)交付自動(dòng)化流水線的各環(huán)節(jié)的安全保護(hù)，以及未能及時(shí)跟上云原生技術(shù)快速發(fā)展而缺位的云原生安全策略和防護(hù)工具等問(wèn)題，都使運(yùn)行在云原生環(huán)境下的業(yè)務(wù)應(yīng)用和數(shù)據(jù)面臨潛在安全風(fēng)險(xiǎn)。

與傳統(tǒng)安全技術(shù)相比，云原生安全技術(shù)表現(xiàn)出了明顯的不同，技術(shù)架構(gòu)由下至上可分為容器、虛擬化、宿主機(jī)運(yùn)行時(shí)安全、編排平臺(tái)、服務(wù)網(wǎng)格安全、微服務(wù)、無(wú)服務(wù)安全，以及與開(kāi)發(fā)運(yùn)維過(guò)程相關(guān)的持續(xù)集成與持續(xù)部署（CI/CD）、開(kāi)發(fā)運(yùn)維一體化（DevOps）和運(yùn)行過(guò)程的監(jiān)控、追蹤和測(cè)量等安全技術(shù)。簡(jiǎn)而言之，傳統(tǒng)安全更重視邊界防護(hù)，而云原生安全更重視持續(xù)、動(dòng)態(tài)和整體的安全防護(hù)。

2.1 容器環(huán)境的風(fēng)險(xiǎn)

容器技術(shù)是云原生技術(shù)體系的基石，容器是宿主機(jī)上的進(jìn)程，其技術(shù)本質(zhì)是對(duì)宿主機(jī)操作系統(tǒng)的一層虛擬化，通過(guò)操作系統(tǒng)命名空間（Namespace）實(shí)現(xiàn)不同容器間主機(jī)名與域名、信號(hào)量/消息隊(duì)列和共享內(nèi)存、進(jìn)程編號(hào)、網(wǎng)絡(luò)設(shè)備、網(wǎng)絡(luò)棧、端口、文件掛載點(diǎn)、用戶和用戶組環(huán)境的隔離；通過(guò)控制組（Cgroup）將容器進(jìn)程或線程分隔到按資源劃分等級(jí)的不同組內(nèi)，實(shí)現(xiàn)對(duì)不同容器資源的使用限制。容器采用鏡像的方法創(chuàng)建，以虛擬化隔離和資源受限的方式運(yùn)行在宿主機(jī)上，通過(guò)容器運(yùn)行時(shí)接口（CRI）接受外部管理和調(diào)度。鏡像具有分層構(gòu)建、寫時(shí)復(fù)制、內(nèi)容尋址、聯(lián)合掛載等特征。

容器直接運(yùn)行于宿主機(jī)操作系統(tǒng)之上，與以硬件層支持實(shí)現(xiàn)的虛擬化技術(shù)比較，更容易出現(xiàn)逃逸風(fēng)險(xiǎn)。攻擊者往往首先通過(guò)劫持容器內(nèi)部業(yè)務(wù)邏輯或直接控制等方式（如遠(yuǎn)程攻擊、惡意容器、惡意租用），獲得容器內(nèi)某種權(quán)限下的命令執(zhí)行能力，之后借助技術(shù)手段進(jìn)一步獲得該容器所在宿主機(jī)上某些權(quán)限的命令執(zhí)行能力并獲取相應(yīng)資源。

例如，通過(guò)配置特權(quán)模式可使容器獲得與宿主機(jī)相同根權(quán)限（root）；通過(guò)掛載宿主機(jī)上運(yùn)行的通信文件/var/run/docker.sock，在容器中安裝Docker客戶端可操作宿主機(jī)建立新容器；通過(guò)Docker程序漏洞（CVE-2019-5736）可在宿主機(jī)內(nèi)執(zhí)行攻擊載荷（payload）代碼；通過(guò)操作系統(tǒng)內(nèi)核漏洞（CVE-2016-5195）可進(jìn)入宿主機(jī)root環(huán)境等。

因此，容器運(yùn)行時(shí)的風(fēng)險(xiǎn)主要源于與宿主機(jī)操作系統(tǒng)共享了內(nèi)核和硬件資源，共享內(nèi)核相對(duì)于虛擬機(jī)（VM）而言具有更大的攻擊面。如果系統(tǒng)內(nèi)核存在漏洞或者使用者對(duì)容器有意無(wú)意地不當(dāng)配置，其上運(yùn)行的容器就存在被攻擊和隔離性被破壞的風(fēng)險(xiǎn)。一旦隔離性被打破，隨之而來(lái)的就是容器逃逸。

容器鏡像的風(fēng)險(xiǎn)同樣不容忽視，容器鏡像通過(guò)鏡像倉(cāng)庫(kù)的自動(dòng)化、層級(jí)化管理大大降低了容器使用的難度，開(kāi)發(fā)者在方便使用的同時(shí)也要重視可能發(fā)生的安全問(wèn)題。鏡像的風(fēng)險(xiǎn)一般來(lái)自于不可靠的鏡像來(lái)源，鏡像構(gòu)建時(shí)引入的不安全第三方組件，及包括官方鏡像在內(nèi)的鏡像自身存在的漏洞等。通常軟件項(xiàng)目中會(huì)使用大量開(kāi)源軟件，按照以往的經(jīng)驗(yàn)，官方提供下載的軟件一般是最新且安全可靠的。但2015年一份研究報(bào)告顯示，Docker公共倉(cāng)庫(kù)（Docker Hub）中超過(guò)30%的官方鏡像包含高危漏洞，而2021年全年公開(kāi)的通用漏洞披露（CVE）漏洞數(shù)為20139個(gè)，其中高危漏洞數(shù)高達(dá)4064個(gè)。漏洞鏡像主要集中在種類繁多的應(yīng)用程序中間件的鏡像中。鏡像的風(fēng)險(xiǎn)必然導(dǎo)致容器運(yùn)行的風(fēng)險(xiǎn)。

2.2 容器編排平臺(tái)的風(fēng)險(xiǎn)

云原生的焦點(diǎn)是業(yè)務(wù)服務(wù)，業(yè)務(wù)服務(wù)核心是對(duì)服務(wù)的管理和控制，如服務(wù)暴露、負(fù)載均衡、流量感知、應(yīng)用擴(kuò)容、灰度發(fā)布、應(yīng)用更新等。服務(wù)編排提供了分布式的計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)資源的管理功能，實(shí)現(xiàn)了按需、彈性地控制服務(wù)的位置、容量、版本，監(jiān)控并保證業(yè)務(wù)的可訪問(wèn)性。

事實(shí)上，編排系統(tǒng)與容器之間并非完全獨(dú)立。以當(dāng)前最流行的云原生管理與編排系統(tǒng)Kubernetes（K8s）為例，K8s集群本身的API服務(wù)管理器（API Server）、控制器（Controller Manager）、調(diào)度器（Scheduler）、基本域名解析服務(wù)器（CoreDNS）等服務(wù)端組件和K8s網(wǎng)絡(luò)代理（Kube-proxy）、K8s節(jié)點(diǎn)代理服務(wù)（Kubelet）等客戶端組件均以宿主機(jī)的一個(gè)或多個(gè)進(jìn)程形式運(yùn)行，而集群使用YAML語(yǔ)言以聲明形式創(chuàng)建的K8s最小部署單元（Pod）實(shí)際是同一網(wǎng)絡(luò)命名空間下的多個(gè)容器組成的邏輯組，因此K8s并不能降低由其管理的容器環(huán)境本身已存在的安全風(fēng)險(xiǎn)。另外，多節(jié)點(diǎn)組成的K8s集群使用第三方網(wǎng)絡(luò)插件提供節(jié)點(diǎn)間通信的機(jī)制，也使集群網(wǎng)絡(luò)的風(fēng)險(xiǎn)比單宿主機(jī)運(yùn)行容器的網(wǎng)絡(luò)風(fēng)險(xiǎn)更大。

除此之外，K8s內(nèi)部核心組件如API Server設(shè)置了便于測(cè)試環(huán)境或者集群初啟動(dòng)時(shí)使用的未加密端口8080，Kubelet和分布式鍵值對(duì)存儲(chǔ)系統(tǒng)（Etcd）可以通過(guò)改變啟動(dòng)參數(shù)配置使用匿名訪問(wèn)功能，以及用于集群訪問(wèn)控制的認(rèn)證、授權(quán)和準(zhǔn)入機(jī)制設(shè)置過(guò)于寬松，高權(quán)限賬號(hào)濫用等配置、操作、管理性問(wèn)題同樣威脅著云原生環(huán)境的安全，不安全的配置暴露于網(wǎng)絡(luò)中將給云安全帶來(lái)嚴(yán)重的風(fēng)險(xiǎn)。

2.3 云原生網(wǎng)絡(luò)的風(fēng)險(xiǎn)

不同于網(wǎng)絡(luò)位置有明確劃分、具有單一網(wǎng)絡(luò)連接關(guān)系的傳統(tǒng)IT應(yīng)用，云原生應(yīng)用采用網(wǎng)絡(luò)虛擬化的部署方式，實(shí)際上是對(duì)網(wǎng)絡(luò)邊界進(jìn)行了重新定義。例如，Docker容器在網(wǎng)絡(luò)命名空間隔離下，一般通過(guò)虛擬以太網(wǎng)（Veth）設(shè)備對(duì)、網(wǎng)橋等虛擬設(shè)備采用動(dòng)態(tài)地址映射方式與外界通信；K8s則以Pod為單位，Pod內(nèi)部的所有容器共享一個(gè)網(wǎng)絡(luò)堆棧，不同Pod之間以非網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）的方式互相通信，即“每個(gè)Pod分配一個(gè)IP（IP-per-Pod）”模型。從宏觀上看，集群中的網(wǎng)絡(luò)空間、包過(guò)濾防火墻（Iptables）和路由隨著容器的產(chǎn)生、消亡不斷動(dòng)態(tài)變化，分布式容器集群網(wǎng)絡(luò)的復(fù)雜度大大提升，這必然會(huì)引入新的網(wǎng)絡(luò)風(fēng)險(xiǎn)。

每個(gè)容器雖然與宿主機(jī)之間存在隔離，但一般情況下同一宿主機(jī)上的容器位于同一局域網(wǎng)，網(wǎng)絡(luò)互通。如果攻擊者非法獲取局域網(wǎng)內(nèi)一個(gè)容器的權(quán)限，就有可能與其他容器非法通信，發(fā)生容器間的網(wǎng)絡(luò)攻擊（東西向攻擊）。

K8s實(shí)現(xiàn)了容器的分布式集群部署，集群Pod間可互相通信。在沒(méi)有其他網(wǎng)絡(luò)隔離策略和Pod安全策略的情況下，可能存在網(wǎng)絡(luò)探測(cè)、拒絕服務(wù)和中間人攻擊等網(wǎng)絡(luò)攻擊（南北向攻擊）。

2.4 云原生應(yīng)用的風(fēng)險(xiǎn)

云原生應(yīng)用采用微服務(wù)架構(gòu)、前后端分離的模式設(shè)計(jì)，交互方式從傳統(tǒng)的Web請(qǐng)求/響應(yīng)轉(zhuǎn)向?yàn)楦黝怉PI請(qǐng)求/響應(yīng)，使用方式逐漸由“人-機(jī)交互”轉(zhuǎn)變?yōu)椤皺C(jī)-機(jī)交互”，通過(guò)表述性狀態(tài)轉(zhuǎn)移風(fēng)格的超文本傳輸協(xié)議（RESTful/Http）、二進(jìn)制/跨語(yǔ)言的遠(yuǎn)程過(guò)程調(diào)用（gRPC）等方式進(jìn)行通信，App服務(wù)的數(shù)量和API請(qǐng)求量大大增加。新模式在帶來(lái)高彈性、可擴(kuò)展、可移植性優(yōu)勢(shì)的同時(shí)，也在安全方面有了新變化。

傳統(tǒng)的以Web為主的應(yīng)用風(fēng)險(xiǎn)依然存在，如注入、跨站腳本、敏感數(shù)據(jù)泄露、使用有漏洞的第三方組件等。當(dāng)傳統(tǒng)的單體應(yīng)用拆分為多個(gè)服務(wù)后，前端的單一請(qǐng)求在后端可能有數(shù)以千計(jì)的服務(wù)調(diào)用關(guān)系，復(fù)雜的調(diào)用鏈和分布式問(wèn)題更容易在外部訪問(wèn)急劇增加時(shí)，大量占用甚至耗盡CPU資源，從而造成拒絕服務(wù)風(fēng)險(xiǎn)。

相較于作為一個(gè)整體對(duì)用戶進(jìn)行授權(quán)、訪問(wèn)單一的傳統(tǒng)IT應(yīng)用，微服務(wù)應(yīng)用的所有服務(wù)間需互相認(rèn)證授權(quán)，請(qǐng)求來(lái)源除了用戶側(cè)外，還有大量?jī)?nèi)部或其他服務(wù)API調(diào)用，其認(rèn)證授權(quán)更為復(fù)雜。若某些API或微服務(wù)之間的鑒權(quán)或訪問(wèn)權(quán)限配置錯(cuò)誤，就有可能造成數(shù)據(jù)非法訪問(wèn)、非法操作等問(wèn)題。同時(shí)，應(yīng)用的配置數(shù)量與服務(wù)數(shù)量成正比，微服務(wù)數(shù)量的增加導(dǎo)致各種服務(wù)、證書、數(shù)據(jù)訪問(wèn)、環(huán)境變量等配置增加，且生產(chǎn)環(huán)境中要求實(shí)現(xiàn)的動(dòng)態(tài)調(diào)整對(duì)服務(wù)的配置管理、密鑰管理也提出更高的要求。復(fù)雜度和管理難度的上升，增加了數(shù)據(jù)泄露風(fēng)險(xiǎn)。

3 云原生環(huán)境安全防護(hù)思路

3.1 安全機(jī)制左移

容器的生存時(shí)間（Time To Live，TTL）對(duì)安全技術(shù)有顯著的影響。據(jù)統(tǒng)計(jì)，46%的容器生存時(shí)間小于1小時(shí)，11%的容器小于1分鐘，對(duì)容器的攻擊和防護(hù)有可能跟不上容器自身的變化。因此，對(duì)于攻擊者而言，在其攻擊鏈條中會(huì)傾向于尋找更持久化的資源，如代碼、第三方庫(kù)、鏡像、倉(cāng)庫(kù)、編排系統(tǒng)、控制面、宿主機(jī)等；而對(duì)于安全防護(hù)而言，將實(shí)時(shí)殺毒、入侵檢測(cè)等防護(hù)工具安裝在輕量級(jí)的容器當(dāng)中變得不可行，需轉(zhuǎn)變思路將安全控制向開(kāi)發(fā)側(cè)轉(zhuǎn)移，在DevOps中加入更多安全控制，包括開(kāi)發(fā)/測(cè)試/驗(yàn)證安全、軟件供應(yīng)鏈安全、鏡像倉(cāng)庫(kù)安全、監(jiān)控與分析以及配置和暴露面的核查。例如，使用代碼檢查工具進(jìn)行代碼靜態(tài)分析、使用鏡像漏洞掃描工具對(duì)鏡像倉(cāng)庫(kù)進(jìn)行掃描、核查用戶憑證、密鑰配置等。開(kāi)發(fā)及安全運(yùn)維一體化（DevSecOps）框架如圖1所示。

3.2 容器運(yùn)行時(shí)行為的聚焦

容器具有體量小、平均生命周期短、變化較快的特點(diǎn)，因其源于鏡像，在運(yùn)行時(shí)來(lái)自同一鏡像的容器行為具有相似性，如容器的用戶、進(jìn)程及數(shù)量、文件路徑、CPU/內(nèi)存資源使用等。通過(guò)對(duì)容器的行為畫像、分析和規(guī)格匹配，若出現(xiàn)異常的新用戶、新路徑、CPU偏高等情況，可以獲取高置信度的告警信息。

3.3 最小權(quán)限原則

在宿主機(jī)、容器、編排集群、DevOps以及微服務(wù)管理中，多種訪問(wèn)關(guān)系錯(cuò)綜復(fù)雜，用戶和服務(wù)認(rèn)證授權(quán)方面錯(cuò)誤配置和漏洞非常容易被利用。因此，要盡量明確組件間邊界和劃分，控制權(quán)限的細(xì)粒度，合理限制組件的權(quán)限，確保組件只執(zhí)行它被授權(quán)的行為，限制容器對(duì)基礎(chǔ)設(shè)施和同存的其他容器的干擾和影響，保證容器與其所在宿主機(jī)的隔離，避免攻擊者惡意越權(quán)訪問(wèn)，使數(shù)據(jù)或功能遭到惡意破環(huán)。

3.4 零信任架構(gòu)

云原生環(huán)境下云計(jì)算、容器集群架構(gòu)復(fù)雜，訪問(wèn)類型多樣，尤其在涉及多租戶，云的運(yùn)營(yíng)方、使用方、應(yīng)用開(kāi)發(fā)方均為獨(dú)立實(shí)體的情況下，客觀上要求能夠隨時(shí)在云原生環(huán)境的任何位置進(jìn)行風(fēng)險(xiǎn)的控制、分析和防范，也就是零信任（默認(rèn)不信任）架構(gòu)的理念需要貫穿在安全防護(hù)中。

4 云原生環(huán)境安全體系構(gòu)建方案

針對(duì)云原生環(huán)境下容器基礎(chǔ)設(shè)施、編排平臺(tái)、網(wǎng)絡(luò)、云原生應(yīng)用層面存在的風(fēng)險(xiǎn)，結(jié)合云安全防護(hù)思路，在對(duì)應(yīng)層面建立安全防護(hù)機(jī)制，形成全生命周期的安全防護(hù)體系，如圖2所示。

4.1 容器基礎(chǔ)設(shè)施的安全

在鏡像構(gòu)建時(shí)，驗(yàn)證依賴鏡像的來(lái)源，最小化安裝減小風(fēng)險(xiǎn)引入，構(gòu)建完成立即進(jìn)行漏洞掃描；在鏡像倉(cāng)庫(kù)中，從公共倉(cāng)庫(kù)選擇官方鏡像最新版本，下載后進(jìn)行漏洞檢測(cè)并保證及時(shí)更新，私有倉(cāng)庫(kù)配置安全證書，并對(duì)用戶訪問(wèn)進(jìn)行權(quán)限控制；在鏡像分發(fā)時(shí)，利用數(shù)字簽名對(duì)鏡像進(jìn)行驗(yàn)證，防止被惡意篡改。

從容器宿主機(jī)的角度，通過(guò)最小化安裝、最小權(quán)限授權(quán)、容器存儲(chǔ)單獨(dú)分區(qū)、Docker守護(hù)進(jìn)程及相關(guān)文件目錄審計(jì)，Docker軟件及時(shí)更新等方式對(duì)容器環(huán)境進(jìn)行加固。

充分利用Linux自身內(nèi)核安全機(jī)制來(lái)實(shí)現(xiàn)容器資源的隔離和權(quán)限的管控，如利用SELinux實(shí)現(xiàn)進(jìn)程訪問(wèn)文件的強(qiáng)制控制訪問(wèn)，保證進(jìn)程只能訪問(wèn)它的任務(wù)中所需的文件。

監(jiān)測(cè)運(yùn)行時(shí)容器異常行為，正常的容器進(jìn)程行為雖然是動(dòng)態(tài)的，但其行為應(yīng)該在一定基線內(nèi)變化，可以認(rèn)為大幅偏離此基線的行為存在風(fēng)險(xiǎn)。這種監(jiān)測(cè)基線既可以通過(guò)已知威脅的規(guī)則庫(kù)建立，也可以通過(guò)大量容器行為和屬性集合進(jìn)行分類、聚合、自學(xué)習(xí)等方式來(lái)自動(dòng)構(gòu)建。

4.2 編排系統(tǒng)的安全

利用K8s自身提供的安全機(jī)制，從認(rèn)證授權(quán)、準(zhǔn)入控制、密鑰管理以及Pod自身提供的安全策略和網(wǎng)絡(luò)策略確保編排系統(tǒng)的組件和配置都是符合安全要求的。

利用X.509證書開(kāi)啟K8s的集群訪問(wèn)認(rèn)證，要求客戶端必須通過(guò)證書驗(yàn)證后才能進(jìn)一步授權(quán)；啟動(dòng)服務(wù)賬號(hào)令牌認(rèn)證機(jī)制，通過(guò)令牌控制集群內(nèi)進(jìn)程能否與API Server進(jìn)行通信；使用Secret對(duì)象保存敏感信息，如密碼、令牌和SSH密鑰；通過(guò)基于角色的訪問(wèn)控制（RBAC）為Pod安全策略授權(quán)實(shí)現(xiàn)準(zhǔn)入控制，以及通過(guò)網(wǎng)絡(luò)策略實(shí)現(xiàn)Pod間的可靠通信等。

4.3 網(wǎng)絡(luò)安全

針對(duì)云原生網(wǎng)絡(luò)架構(gòu)虛擬化、連接情況復(fù)雜、網(wǎng)絡(luò)邊界動(dòng)態(tài)變化的特點(diǎn)，需要在更細(xì)粒度上實(shí)現(xiàn)網(wǎng)絡(luò)隔離，減少不同容器間網(wǎng)絡(luò)橫向攻擊的風(fēng)險(xiǎn)。同時(shí)，需要引入零信任安全理念。

目前比較先進(jìn)的3層以上可進(jìn)行網(wǎng)絡(luò)隔離的技術(shù)是微服務(wù)管理框架服務(wù)網(wǎng)格（Istio）下的邊車（Sidecar）模式，如圖3所示。Sidecar代理如邊緣/服務(wù)代理（Envoy）通過(guò)流量劫持接受控制面的調(diào)度，協(xié)調(diào)與其連接的服務(wù)實(shí)例的出入站通信，實(shí)現(xiàn)了更細(xì)粒度調(diào)整和控制端口、協(xié)議的功能，所有網(wǎng)格內(nèi)的Sidecar代理實(shí)例由控制平面的服務(wù)發(fā)現(xiàn)和流量管理組件（Pilot）管理和配置，流量控制較為容易且無(wú)需修改應(yīng)用。

4.4 應(yīng)用安全

在開(kāi)發(fā)側(cè)引入安全機(jī)制，對(duì)軟件依賴的第三方庫(kù)進(jìn)行安全性分析和漏洞掃描，及時(shí)告警，保證軟件供應(yīng)鏈安全；在開(kāi)發(fā)中加強(qiáng)安全檢查、漏洞測(cè)試和代碼審計(jì)，提升開(kāi)發(fā)人員的安全意識(shí)和安全技術(shù)能力，減少早期漏洞引入。

引入云原生API網(wǎng)關(guān)，對(duì)所有的外部訪問(wèn)進(jìn)行流量接入、認(rèn)證授權(quán)、監(jiān)控審計(jì)、傳輸層安全（TLS）加密等細(xì)粒度的控制。

引入服務(wù)網(wǎng)格治理，以Istio為主的安全機(jī)制，對(duì)微服務(wù)間的互訪采用開(kāi)放的JWT標(biāo)準(zhǔn)認(rèn)證、Istio授權(quán)、TLS雙向傳輸加密等方法進(jìn)行安全防護(hù)。

針對(duì)無(wú)服務(wù)計(jì)算（FaaS）可能存在的風(fēng)險(xiǎn)，采用加強(qiáng)服務(wù)平臺(tái)自身的隔離和安全防護(hù)機(jī)制，開(kāi)發(fā)的函數(shù)遵從安全規(guī)范，對(duì)無(wú)服務(wù)（Serverless）實(shí)例進(jìn)行監(jiān)控審計(jì)，定期清理非必要Serverless來(lái)減小攻擊面等方法進(jìn)行防護(hù)。

5 結(jié)語(yǔ)

隨著云計(jì)算技術(shù)的發(fā)展，云原生已是大勢(shì)所趨，新技術(shù)的不斷發(fā)展也必然會(huì)持續(xù)引入新的風(fēng)險(xiǎn)。云原生安全不僅僅是對(duì)已知安全問(wèn)題的防護(hù)，更是對(duì)云原生環(huán)境中的所有安全風(fēng)險(xiǎn)的快速發(fā)現(xiàn)和響應(yīng)。未來(lái)的云原生安全必然會(huì)發(fā)展出更多新的手段和工具，必然也會(huì)具備云原生的特點(diǎn)，如微服務(wù)、彈性擴(kuò)展和自動(dòng)化編排等。企業(yè)的“上云”之路必須轉(zhuǎn)變傳統(tǒng)應(yīng)用安全的防護(hù)思路，重視云原生安全。

（原載于《保密科學(xué)技術(shù)》雜志2022年7月刊）