◎電子商務與電子支付國家工程實驗室（上海）、中國銀聯(lián)股份有限公司（上海）吳金壇 邱震堯 楊陽

一、引言

作為云計算技術的基石，虛擬化技術是解決大規(guī)?；A設施資源管理問題的關鍵所在[1]。隨著DevOps（開發(fā)運維一體化）需求的興起，一種輕量級虛擬化架構(gòu)——容器技術應運而生，成為了傳統(tǒng)虛擬化技術的一種輕量化補充形式。目前，以Docker 為代表的容器技術已廣泛應用于互聯(lián)網(wǎng)等行業(yè)各大機構(gòu)的云計算相關基礎平臺，可實現(xiàn)開發(fā)、測試和運維流程的敏捷化。

傳統(tǒng)金融行業(yè)在進行互聯(lián)網(wǎng)化轉(zhuǎn)型的嘗試中，越來越多地使用了基于虛擬化架構(gòu)的彈性部署方案，云計算技術的應用成為了新常態(tài)。同時，隨著互聯(lián)網(wǎng)新興技術的快速迭代和演進，容器云模式也成為了金融行業(yè)云部署的一種新的可行選項和發(fā)展方向。

值得注意的是，對于金融行業(yè)而言，應用系統(tǒng)的安全穩(wěn)定運行具有十分重要的意義。然而，業(yè)界在應用容器技術時更多考慮的是容器化給應用部署帶來的便利性，而較少考慮其引入的安全風險。因此，為了積極向輕量級虛擬化架構(gòu)平穩(wěn)過渡，同時保證系統(tǒng)運行的穩(wěn)定性，防范金融應用系統(tǒng)運行風險的發(fā)生，金融行業(yè)在應用容器技術時應充分考慮其特有安全問題與安全機制。

二、從傳統(tǒng)虛擬機到輕量級虛擬化

目前，金融行業(yè)的云平臺架構(gòu)以傳統(tǒng)虛擬機為主要部署模式。面對更進一步的資源利用率壓力和高性能彈性需求，傳統(tǒng)金融云的基礎架構(gòu)正向著輕量化、敏捷化的方向演進。

（一）傳統(tǒng)虛擬化技術

虛擬化技術是實現(xiàn)硬件基礎設施資源的充分利用、合理分配和有效調(diào)度的重要技術手段[2]。例如，在典型的IaaS（Infrastructure as a Service，基礎設施即服務）服務中，云服務提供商可通過搭建硬件設備集群的方式建立資源池，并將服務器、存儲和網(wǎng)絡等底層資源進行彈性虛擬化提供給租戶。

傳統(tǒng)虛擬化技術基于Hypervisor 虛擬機監(jiān)視器實現(xiàn)，可在主機或主機操作系統(tǒng)上運行完整的虛擬機環(huán)境，共享主機的硬件資源[3]。傳統(tǒng)虛擬化技術以虛擬機為管理單元，各虛擬機擁有獨立的操作系統(tǒng)內(nèi)核，不共用宿主機的軟件系統(tǒng)資源，因此具有良好的隔離性，適用于云計算環(huán)境中的多租戶場景。

（二）容器技術

容器技術是一種輕量級的虛擬化方式，將應用與必要的執(zhí)行環(huán)境打包成容器鏡像，使得應用程序可以直接在宿主機（物理機或虛擬機）中相對獨立地運行。相比于傳統(tǒng)的應用部署，容器的部署無需預先考慮應用的運行環(huán)境兼容性問題；相比于傳統(tǒng)虛擬機，容器無需獨立的操作系統(tǒng)內(nèi)核就可在宿主機中運行，實現(xiàn)了更高的運行效率與資源利用率。

Docker 是目前最具代表性的容器平臺之一，它模糊了傳統(tǒng)的IaaS 和PaaS（Platform as a Service，平臺即服務）的邊界，具有持續(xù)部署與測試、跨云平臺支持等優(yōu)點。與基于Hypervisor 的傳統(tǒng)虛擬化技術不同，Docker 容器技術以宿主機中的容器為管理單元，但各容器共用宿主機內(nèi)核資源，分別通過Linux 系統(tǒng)的Namespaces（命名空間）和CGroups（控制組）機制實現(xiàn)資源的隔離與限制[4]。

（三）安全性對比

傳統(tǒng)虛擬化技術與容器技術的架構(gòu)對比如圖1所示[5]。

圖1 傳統(tǒng)虛擬化與輕量級虛擬化架構(gòu)對比

傳統(tǒng)虛擬化技術與Docker 容器技術在運行時的安全性差異主要體現(xiàn)在隔離性方面。由于傳統(tǒng)虛擬化為每個虛擬機生成獨立的操作系統(tǒng)內(nèi)核，虛擬機間不存在進程、文件系統(tǒng)等方面的共享。而傳統(tǒng)虛擬機管理軟件Hypervisor 在虛擬機生成時就分配了固定的硬盤空間、CPU、內(nèi)存等資源，虛擬機間的資源使用也不會存在明顯的相互影響。

而在Docker 容器環(huán)境中，由于各容器共享操作系統(tǒng)內(nèi)核，而容器僅為運行在宿主機上的若干進程，其安全性特別是隔離性與傳統(tǒng)虛擬機相比在理論上與實際上都存在一定的差距。

三、容器安全風險分析

根據(jù)Docker 容器的主要特點及其在安全應用中的實際問題，我們將Docker 容器技術應用中可能存在的技術性安全風險分為鏡像安全風險、隔離性安全風險、網(wǎng)絡安全風險等類型進行具體分析，如圖2所示。

圖2 容器安全風險分類

（一）鏡像安全風險

Docker 容器鏡像是Docker 容器的靜態(tài)表示形式，鏡像不安全意味著容器的運行已經(jīng)偏離原來的軌道[6]。

公共鏡像倉庫中的Docker 容器鏡像數(shù)量豐富、版本多樣，但質(zhì)量參差不齊，甚至存在包含惡意漏洞的惡意鏡像，因而可能存在較大的安全風險[7]。進一步而言，Docker 鏡像的安全風險分布在創(chuàng)建過程、獲取來源、獲取途徑等方方面面。

1、Dockerfile 安全問題

Dockerfile 文件是容器鏡像的初始化形式，其內(nèi)容在一定程度上決定了Docker 鏡像的安全性。例如，如果Dockerfile 存在漏洞或被插入惡意腳本，那么通過其生成的容器也可能產(chǎn)生漏洞或被惡意利用。此外，如果在Dockerfile文件中存儲了固定密碼等敏感信息并對外進行發(fā)布，則可能導致數(shù)據(jù)泄露的風險。

因此，作為容器鏡像的基本構(gòu)建方式，Dockerfile 文件編寫不當可能造成各種類型的潛在安全風險，需要對Dockerfile 的編寫制定標準化規(guī)則與檢查措施。

2、鏡像漏洞

除了通過編寫Dockerfile文件進行容器鏡像構(gòu)建之外，還可通過獲取一系列基礎鏡像進行容器應用的部署和進一步開發(fā)，因此，基礎鏡像的安全漏洞可能引入容器應用環(huán)境中。

（1）CVE 漏洞

由于鏡像通常由基礎操作系統(tǒng)與各類應用軟件構(gòu)成，因此，含有CVE（Common Vulnerabilities & Exposures，公共漏洞和暴露）漏洞的應用軟件同樣也會向Docker 鏡像中引入CVE 漏洞。根據(jù)Shu 等人[8]對Docker 官方鏡像倉庫Docker Hub 中鏡像安全漏洞的研究，無論是社區(qū)鏡像還是官方鏡像，其平均漏洞數(shù)量均接近200 個。

（2）惡意漏洞

惡意用戶可能將含有后門、病毒等惡意漏洞的鏡像上傳至官方鏡像庫。目前，由于Docker 應用在世界范圍內(nèi)具有廣泛性，全網(wǎng)針對Docker 容器的攻擊很多都被用于進行虛擬貨幣挖礦，為攻擊者帶來實際經(jīng)濟利益，損害容器應用的正常使用。

綜上所述，鏡像在獲取來源上的安全風險是Docker 容器在應用中的最主要風險來源之一。

3、鏡像倉庫安全

鏡像倉庫的安全風險主要包括倉庫本身的安全風險和鏡像拉取過程中的傳輸安全風險。

（1）倉庫自身安全：如果鏡像倉庫特別是私有鏡像倉庫被惡意攻擊者所控制，那么其中所有鏡像的安全性將無法得到保證。

（2）鏡像拉取安全：由于用戶以明文形式拉取鏡像，如果用戶在與鏡像倉庫交互傳輸?shù)倪^程中遭遇了中間人攻擊，可能會造成鏡像倉庫和用戶雙方的安全風險。

（二）隔離性安全風險

Docker 容器不擁有獨立的資源配置，且沒有做到操作系統(tǒng)內(nèi)核層面的隔離，因此可能存在資源隔離不徹底與資源限制不到位所導致的安全風險。

1、容器隔離問題

雖然Docker 容器通過Namespaces機制進行了文件系統(tǒng)資源的基本隔離，但仍有一些重要系統(tǒng)文件目錄和命名空間信息沒實現(xiàn)隔離，而是與宿主機共享相關資源，因此存在容器與宿主機之間、容器與容器之間隔離方面的安全風險。

針對容器隔離安全風險問題，主要存在以下兩種隔離失效的情況：

①攻擊者可能通過對宿主機內(nèi)核進行攻擊達到攻擊其中某個容器的目的。

②由于容器所在宿主機文件系統(tǒng)存在聯(lián)合掛載的情況，惡意用戶控制的容器可能通過共同掛載的文件目錄獲取其他容器的信息，造成數(shù)據(jù)安全問題。

2、容器逃逸攻擊

容器逃逸攻擊指的是容器利用系統(tǒng)漏洞，“逃逸”出了其自身所擁有的權限，實現(xiàn)了對宿主機和宿主機上其他容器的訪問[9]。

在容器逃逸案例中，最為著名的是shocker.c 程序，其通過系統(tǒng)函數(shù)調(diào)用對宿主機文件系統(tǒng)進行暴力掃描，以獲取宿主機的目標文件內(nèi)容。所幸的是，Docker 在后續(xù)版本中對容器能力采用白名單管理，避免了默認創(chuàng)建的容器通過shocker.c 案例實現(xiàn)容器逃逸的情況。

由于Docker 容器與宿主機共享操作系統(tǒng)內(nèi)核，因此容器逃逸問題是容器技術所面臨的重大安全風險之一。

3、拒絕服務攻擊

由于Docker 本身對容器使用的資源并沒有默認限制，如果單個容器耗盡宿主機的計算資源或存儲資源（例如進程數(shù)量、存儲空間等），可能導致宿主機或其他容器的拒絕服務[10][11]（Denial of Service,DoS）。

（1）計算型DoS 攻擊

由于宿主機操作系統(tǒng)內(nèi)核支持的進程總數(shù)有限，如果某個容器遭到了進程攻擊，那么就有可能存在由于短時間內(nèi)在該容器內(nèi)創(chuàng)建過多進程而耗盡宿主機進程資源的情況，宿主機及其他容器就無法再創(chuàng)建新的進程。

（2）存儲型DoS 攻擊

如果宿主機上的容器向文件系統(tǒng)中不斷進行寫文件操作，則可能會導致宿主機存儲設備空間不足，無法再滿足其自身及其他容器的數(shù)據(jù)存儲需求。

（三）網(wǎng)絡安全風險

網(wǎng)絡安全風險是互聯(lián)網(wǎng)中所有信息系統(tǒng)所面臨的重要風險，而在輕量級虛擬化的容器網(wǎng)絡環(huán)境中，其網(wǎng)絡安全風險較傳統(tǒng)網(wǎng)絡而言更為復雜嚴峻。

1、容器網(wǎng)絡攻擊

Docker 提供橋接網(wǎng)絡、MacVLAN[12]、覆蓋網(wǎng)絡[13]等多種組網(wǎng)模式，可分別實現(xiàn)同一宿主機內(nèi)容器互聯(lián)、跨宿主機容器互聯(lián)、容器集群網(wǎng)絡等功能。

無論采用何種網(wǎng)絡連接模式，都存在同一宿主機內(nèi)各容器之間的網(wǎng)絡攻擊風險，攻擊者可通過某個容器對宿主機內(nèi)的其他容器進行ARP（Address Resolution Protocol，地址解析協(xié)議）欺騙、嗅探、廣播風暴等攻擊，導致信息泄露、影響網(wǎng)絡正常運行等安全后果。

因此，如果在同一臺宿主機上部署的多個容器沒有進行合理的網(wǎng)絡配置進行訪問控制邊界隔離，將可能產(chǎn)生容器間的網(wǎng)絡安全風險。

2、網(wǎng)絡DoS 攻擊

由于網(wǎng)絡虛擬化的存在，容器網(wǎng)絡面臨著與傳統(tǒng)網(wǎng)絡不同的DoS 攻擊安全風險。Docker 容器網(wǎng)絡的DoS 攻擊分為內(nèi)部威脅和外部威脅兩種主要形式。

①內(nèi)部威脅：DoS 攻擊可不通過物理網(wǎng)卡而在宿主機內(nèi)部的容器之間進行，攻擊者通過某個容器向其他容器發(fā)起DoS 攻擊可能降低其他容器的網(wǎng)絡數(shù)據(jù)處理能力。

②外部威脅：由于同一臺宿主機上的所有容器共享宿主機的物理網(wǎng)卡資源，若外部攻擊者向某一個目標容器發(fā)起DoS 攻擊，將可能占滿宿主機的網(wǎng)絡帶寬資源，造成宿主機和其他容器的拒絕服務。

四、容器安全需求與相關機制

基于上述安全風險，需要進一步加強對容器的安全控制能力，采用相應的容器安全機制，以滿足用戶對容器的應用需要和安全訴求。

（一）容器隔離性安全

1、安全需求

由于在容器云環(huán)境中各容器共用宿主機資源，因此，容器隔離性安全需求包含容器間計算、網(wǎng)絡、存儲等性能的適度隔離（防止拒絕服務攻擊），容器間文件系統(tǒng)與數(shù)據(jù)的基本隔離，以及對容器行為能力實現(xiàn)監(jiān)管控制。

2、安全機制與解決方案

容器架構(gòu)不含有Hypervisor 層，因此需要依靠內(nèi)核層面的相關機制對容器進行安全的資源管理[14]。

（1）容器資源隔離與限制

在資源隔離方面，Docker 通過Linux 內(nèi)核的Namespace 機制實現(xiàn)容器與宿主機之間、容器與容器之間資源的相對獨立。通過為各運行容器創(chuàng)建獨立的命名空間，保證了容器中進程的運行不會直接影響到其他容器或宿主機中的進程。

在資源限制方面，Docker 通過CGroups 機制實現(xiàn)宿主機中不同容器的資源限制與審計，包括對CPU、內(nèi)存、I/O 等物理資源進行均衡化配置，防止單個容器耗盡所有資源造成其他容器或宿主機的拒絕服務，保證所有容器的正常運行。

（2）容器能力限制

Linux 內(nèi)核能力表示進程所擁有的系統(tǒng)調(diào)用權限，決定了程序的系統(tǒng)調(diào)用能力。如果對容器默認能力不加以適當限制，可能會存在以下安全隱患：

①內(nèi)部因素：在運行Docker容器時，如果采用默認的內(nèi)核功能配置可能會產(chǎn)生容器的隔離性安全問題。

②外部因素：不必要的內(nèi)核功能可能導致攻擊者通過容器實現(xiàn)對宿主機內(nèi)核的攻擊。

因此，不當?shù)娜萜髂芰ε渲脮U大攻擊面，在運行容器時可根據(jù)實際需求對容器的能力進行增刪。

（3）強制訪問控制

強制訪問控制（Mandatory Access Control,MAC）用于控制特定訪問主體對特定訪問客體的相關操作。在Docker容器應用環(huán)境下，可通過強制訪問控制機制限制容器的訪問資源。Linux 內(nèi)核的強制訪問控制機制包括SELinux[15]（Security-Enhanced Linux，安全增強型Linux）、AppArmor（Application Armor，應用程序防護）等，可實現(xiàn)進程或可執(zhí)行程序?qū)ξ募夸?、網(wǎng)絡端口等資源的讀寫權限控制，使shocker.c 程序等容器逃逸攻擊失效。

（二)容器安全管理

1、安全需求

容器安全管理方面的安全需求主要包括鏡像安全保障需求、容器全周期監(jiān)控需求、容器安全審計需求。

①鏡像安全保障需求要求確保容器鏡像的完整性和可靠性。

②容器全周期監(jiān)控需求要求對容器運行生命周期進行全程監(jiān)控和管理，確保容器始終處于可控狀態(tài)，保障服務的可用性。

③容器安全審計需求要求對容器業(yè)務的安全風險進行審計。

2、安全機制與解決方案

（1）鏡像安全掃描

為了保證容器運行的安全性，在從公共鏡像倉庫獲取鏡像時需要對鏡像進行安全檢查，防止存在安全隱患甚至惡意漏洞的鏡像運行，從源頭端預防安全事故的發(fā)生。

針對Docker 鏡像的漏洞掃描，目前已經(jīng)有許多相關工具與解決方案，包括Docker 官方的Docker Security Scanning 服務、Clair 開源工具等等，均可實現(xiàn)針對容器鏡像的CVE 漏洞掃描。

（2）容器運行監(jiān)控

為了在系統(tǒng)運維層面保證容器運行的安全性，實現(xiàn)安全風險的即時告警與應急響應，需要對Docker 容器運行時的各項性能指標進行實時監(jiān)控。常見的Docker 容器監(jiān)控工具有原生的docker stats 命令和開源的cAdvisor 可視化工具。

（3）容器安全審計

在安全審計方面，對于運行Docker容器的宿主機而言，除需對主機Linux文件系統(tǒng)等進行審計外，還需對Docker守護進程的活動進行審計。由于系統(tǒng)默認不會對Docker 守護進程進行審計，需要通過主動添加審計規(guī)則或修改規(guī)則文件進行。

除Docker 守護進程之外，還需對與Docker 的運行相關的文件和目錄進行審計，同樣需要通過命令行添加審計規(guī)則或修改規(guī)則配置文件。

（三）容器網(wǎng)絡安全

1、安全需求

在容器環(huán)境下的網(wǎng)絡安全需求是保障宿主機與宿主機之間、容器與宿主機之間、容器與容器之間的網(wǎng)絡訪問控制與安全防御。

2、安全機制與解決方案

（1）容器間流量限制

由于Docker 容器默認的網(wǎng)橋模式不會對網(wǎng)絡流量進行控制和限制，為了防止?jié)撛诘木W(wǎng)絡DoS 攻擊風險，需要根據(jù)實際需求對網(wǎng)絡流量進行相應的配置。

在特定的應用場景中，如果宿主機中的所有容器無需在三層或四層進行網(wǎng)絡通信交互，可直接禁止容器與容器間的通信。為了保證容器之間的正常通信，同時避免異常流量造成網(wǎng)絡DoS 攻擊等后果，需要對容器之間的通信流量進行一定的限制。因此，可采用Linux 的流量控制器（Traffic Control,TC）對容器網(wǎng)絡進行流量限制，在一定程度上減輕容器間的網(wǎng)絡DoS 攻擊危害。

（2）網(wǎng)橋模式下的網(wǎng)絡訪問控制

在默認的網(wǎng)橋連接模式中，連接在同一個網(wǎng)橋的兩個容器可以進行直接相互訪問。因此，為了實現(xiàn)網(wǎng)絡訪問控制，可按需配置網(wǎng)絡訪問控制機制和策略。

為了實現(xiàn)容器間的網(wǎng)絡隔離，可將容器放在不同的橋接網(wǎng)絡中。當在Docker 中創(chuàng)建新的橋接網(wǎng)絡時，會在iptables 中新增丟棄規(guī)則，阻斷與其他網(wǎng)絡之間的通信流量，實現(xiàn)容器網(wǎng)絡之間隔離的目的。進而可采用白名單策略實現(xiàn)網(wǎng)絡訪問控制，即根據(jù)實際需要在iptables 中添加訪問控制策略，以最小化策略減小攻擊面。

（3）集群模式下的網(wǎng)絡訪問控制

在由基于覆蓋網(wǎng)絡的容器集群構(gòu)成的大型容器云環(huán)境中，由于存在頻繁的微服務動態(tài)變化更新，難以通過手動的方式進行訪問控制策略配置。因此，可通過微分段（Micro-Segmentation）實現(xiàn)面向容器云環(huán)境中的容器防火墻。微分段是一種細粒度的網(wǎng)絡分段隔離機制，與傳統(tǒng)的以網(wǎng)絡地址為基本單位的網(wǎng)絡分段機制不同，微分段可以以單個容器、同網(wǎng)段容器集合、容器應用為粒度實現(xiàn)分段隔離，并通過容器防火墻對實現(xiàn)微分段間的網(wǎng)絡訪問控制。

五、金融行業(yè)容器安全部署建議

（一）開發(fā)行業(yè)容器基礎應用軟件

隨著云計算體系向輕量級的容器化部署的方向快速演進，Docker 容器技術在包括金融在內(nèi)各行各業(yè)的技術平臺架構(gòu)中越來越具有舉足輕重的地位。

為了適應金融對科技能力的更高要求，提升關鍵技術組件的自主可控能力，國內(nèi)金融行業(yè)應主動深耕容器技術前沿，產(chǎn)出平臺化技術成果，例如基于Docker、Kubernetes 等開源軟件進行定制化二次開發(fā)，實現(xiàn)基礎應用軟件的自主化。此外，金融行業(yè)在進行容器技術自主化嘗試中還可考慮引入業(yè)界先進的開源產(chǎn)品，以豐富與拓展容器技術的多場景安全應用。例如，Kata Containers、gVisor 等輕量級容器虛擬機開源產(chǎn)品支持為每個容器創(chuàng)建獨立內(nèi)核環(huán)境，可用于加強容器的隔離性安全。

（二）搭建行業(yè)容器可信鏡像倉庫

為了滿足容器化應用普及后對大量鏡像的安全存儲與傳輸需求，保證鏡像從構(gòu)建來源、打包發(fā)布、獲取途徑、運行使用等全生命周期的安全性，同時便于做好各類公共與自研鏡像的版本控制，有條件的金融機構(gòu)應建立自己的安全鏡像倉庫，或聯(lián)合建立金融行業(yè)共享的安全鏡像倉庫，用于發(fā)布和存儲安全可控的常用公共鏡像與自主開發(fā)鏡像版本，并建立可信身份認證交互機制保證鏡像的傳輸安全性。此外，可信鏡像倉庫應結(jié)合鏡像漏洞掃描工具與人工審計的方式嚴格管控鏡像的上傳發(fā)布流程，保證鏡像的源頭安全性。

（三）制定行業(yè)容器合規(guī)檢查體系

為了應對容器應用部署的快速擴張及其引入的安全風險，保證自有容器云平臺的安全穩(wěn)定運行，各金融機構(gòu)應積極制定符合金融行業(yè)自身業(yè)務需求與技術實際的容器安全規(guī)范，最終形成容器安全合規(guī)檢查體系與相應平臺。同時，各金融機構(gòu)還應積極推動容器安全在國內(nèi)特別是金融行業(yè)的標準化工作。

（四）部署行業(yè)容器安全管理平臺

對于日益龐大的集群化、分布式容器云環(huán)境而言，系統(tǒng)化的安全風險需要通過系統(tǒng)化的管理機制進行應對和化解。因此，系統(tǒng)化安全管理平臺的構(gòu)建對于容器環(huán)境而言具有十分重要的意義和必要性。

金融行業(yè)應加快建立對設備資源、容器資源、鏡像資源、鏡像倉庫等進行有效管理的安全監(jiān)控平臺與相關體系化機制，并同步研發(fā)相關安全工具庫，將鏡像漏洞掃描、安全合規(guī)檢查等功能進行整合嵌入，搭建包含資產(chǎn)管理、漏洞檢測、合規(guī)檢查、入侵檢測等安全功能的統(tǒng)一化管理入口，實現(xiàn)與基礎應用軟件、可信鏡像倉庫、合規(guī)檢查體系等其他自主化工作的相互配合、相互推進。

六、總結(jié)

安全是金融科技創(chuàng)新中不可逾越的紅線。本文就輕量級虛擬化架構(gòu)——容器技術及其存在的安全風險、安全需求、安全機制等進行了分析，并面向金融行業(yè)云的輕量化建設的給出了一系列安全建議。

與傳統(tǒng)虛擬化技術相比，容器技術具有敏捷化、輕量化等特點。與此同時，容器技術對于高效性的追求也犧牲了隔離性等安全要求，在安全性方面與傳統(tǒng)虛擬化技術相比還存在較大差距，且所涉及的面較廣，涉及到容器的鏡像安全、內(nèi)核安全、網(wǎng)絡安全、隔離性安全、運行時安全等各個層面。

因此，金融行業(yè)相關機構(gòu)在應用容器技術進行輕量級虛擬化應用部署時，應充分評估安全風險，根據(jù)不同場景制定相應安全需求，并整合相關安全解決方案，形成容器安全應用最佳實踐。同時，面對復雜嚴峻的國際網(wǎng)絡空間安全形勢，需根據(jù)金融業(yè)務場景，批判性地使用業(yè)界相關開源軟件進行定制開發(fā)，進而實現(xiàn)金融基礎設施與金融信息系統(tǒng)的自主可控安全。