金融行業輕量級虛擬化架構安全部署研究

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

一、引言

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

傳統金融行業在進行互聯網化轉型的嘗試中，越來越多地使用了基于虛擬化架構的彈性部署方案，云計算技術的應用成為了新常態。同時，隨著互聯網新興技術的快速迭代和演進，容器云模式也成為了金融行業云部署的一種新的可行選項和發展方向。

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

二、從傳統虛擬機到輕量級虛擬化

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

（一）傳統虛擬化技術

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

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

（二）容器技術

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

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

（三）安全性對比

傳統虛擬化技術與容器技術的架構對比如圖1所示[5]。

圖1 傳統虛擬化與輕量級虛擬化架構對比

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

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

三、容器安全風險分析

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

圖2 容器安全風險分類

（一）鏡像安全風險

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

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

1、Dockerfile 安全問題

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

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

2、鏡像漏洞

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

（1）CVE 漏洞

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

（2）惡意漏洞

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

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

3、鏡像倉庫安全

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

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

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

（二）隔離性安全風險

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

1、容器隔離問題

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

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

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

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

2、容器逃逸攻擊

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

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

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

3、拒絕服務攻擊

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

（1）計算型DoS 攻擊

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

（2）存儲型DoS 攻擊

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

（三）網絡安全風險

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

1、容器網絡攻擊

Docker 提供橋接網絡、MacVLAN[12]、覆蓋網絡[13]等多種組網模式，可分別實現同一宿主機內容器互聯、跨宿主機容器互聯、容器集群網絡等功能。

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

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

2、網絡DoS 攻擊

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

①內部威脅：DoS 攻擊可不通過物理網卡而在宿主機內部的容器之間進行，攻擊者通過某個容器向其他容器發起DoS 攻擊可能降低其他容器的網絡數據處理能力。

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

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

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

（一）容器隔離性安全

1、安全需求

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

2、安全機制與解決方案

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

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

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

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

（2）容器能力限制

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

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

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

因此，不當的容器能力配置會擴大攻擊面，在運行容器時可根據實際需求對容器的能力進行增刪。

（3）強制訪問控制

強制訪問控制（Mandatory Access Control,MAC）用于控制特定訪問主體對特定訪問客體的相關操作。在Docker容器應用環境下，可通過強制訪問控制機制限制容器的訪問資源。Linux 內核的強制訪問控制機制包括SELinux[15]（Security-Enhanced Linux，安全增強型Linux）、AppArmor（Application Armor，應用程序防護）等，可實現進程或可執行程序對文件目錄、網絡端口等資源的讀寫權限控制，使shocker.c 程序等容器逃逸攻擊失效。

（二)容器安全管理

1、安全需求

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

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

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

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

2、安全機制與解決方案

（1）鏡像安全掃描

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

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

（2）容器運行監控

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

（3）容器安全審計

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

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

（三）容器網絡安全

1、安全需求

在容器環境下的網絡安全需求是保障宿主機與宿主機之間、容器與宿主機之間、容器與容器之間的網絡訪問控制與安全防御。

2、安全機制與解決方案

（1）容器間流量限制

由于Docker 容器默認的網橋模式不會對網絡流量進行控制和限制，為了防止潛在的網絡DoS 攻擊風險，需要根據實際需求對網絡流量進行相應的配置。

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

（2）網橋模式下的網絡訪問控制

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

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

（3）集群模式下的網絡訪問控制

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

五、金融行業容器安全部署建議

（一）開發行業容器基礎應用軟件

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

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

（二）搭建行業容器可信鏡像倉庫

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

（三）制定行業容器合規檢查體系

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

（四）部署行業容器安全管理平臺

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

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

六、總結

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

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

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