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

一、引言

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

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

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

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

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

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

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

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

（二）容器技術(shù)

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

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

（三）安全性對(duì)比

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

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

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

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

三、容器安全風(fēng)險(xiǎn)分析

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

圖2 容器安全風(fēng)險(xiǎn)分類

（一）鏡像安全風(fēng)險(xiǎn)

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

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

1、Dockerfile 安全問(wèn)題

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

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

2、鏡像漏洞

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

（1）CVE 漏洞

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

（2）惡意漏洞

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

綜上所述，鏡像在獲取來(lái)源上的安全風(fēng)險(xiǎn)是Docker 容器在應(yīng)用中的最主要風(fēng)險(xiǎn)來(lái)源之一。

3、鏡像倉(cāng)庫(kù)安全

鏡像倉(cāng)庫(kù)的安全風(fēng)險(xiǎn)主要包括倉(cāng)庫(kù)本身的安全風(fēng)險(xiǎn)和鏡像拉取過(guò)程中的傳輸安全風(fēng)險(xiǎn)。

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

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

（二）隔離性安全風(fēng)險(xiǎn)

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

1、容器隔離問(wèn)題

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

針對(duì)容器隔離安全風(fēng)險(xiǎn)問(wèn)題，主要存在以下兩種隔離失效的情況：

①攻擊者可能通過(guò)對(duì)宿主機(jī)內(nèi)核進(jìn)行攻擊達(dá)到攻擊其中某個(gè)容器的目的。

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

2、容器逃逸攻擊

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

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

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

3、拒絕服務(wù)攻擊

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

（1）計(jì)算型DoS 攻擊

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

（2）存儲(chǔ)型DoS 攻擊

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

（三）網(wǎng)絡(luò)安全風(fēng)險(xiǎn)

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

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

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

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

因此，如果在同一臺(tái)宿主機(jī)上部署的多個(gè)容器沒(méi)有進(jìn)行合理的網(wǎng)絡(luò)配置進(jìn)行訪問(wèn)控制邊界隔離，將可能產(chǎn)生容器間的網(wǎng)絡(luò)安全風(fēng)險(xiǎn)。

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

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

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

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

四、容器安全需求與相關(guān)機(jī)制

基于上述安全風(fēng)險(xiǎn)，需要進(jìn)一步加強(qiáng)對(duì)容器的安全控制能力，采用相應(yīng)的容器安全機(jī)制，以滿足用戶對(duì)容器的應(yīng)用需要和安全訴求。

（一）容器隔離性安全

1、安全需求

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

2、安全機(jī)制與解決方案

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

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

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

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

（2）容器能力限制

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

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

②外部因素：不必要的內(nèi)核功能可能導(dǎo)致攻擊者通過(guò)容器實(shí)現(xiàn)對(duì)宿主機(jī)內(nèi)核的攻擊。

因此，不當(dāng)?shù)娜萜髂芰ε渲脮?huì)擴(kuò)大攻擊面，在運(yùn)行容器時(shí)可根據(jù)實(shí)際需求對(duì)容器的能力進(jìn)行增刪。

（3）強(qiáng)制訪問(wèn)控制

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

（二)容器安全管理

1、安全需求

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

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

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

③容器安全審計(jì)需求要求對(duì)容器業(yè)務(wù)的安全風(fēng)險(xiǎn)進(jìn)行審計(jì)。

2、安全機(jī)制與解決方案

（1）鏡像安全掃描

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

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

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

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

（3）容器安全審計(jì)

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

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

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

1、安全需求

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

2、安全機(jī)制與解決方案

（1）容器間流量限制

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

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

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

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

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

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

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

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

（一）開(kāi)發(fā)行業(yè)容器基礎(chǔ)應(yīng)用軟件

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

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

（二）搭建行業(yè)容器可信鏡像倉(cāng)庫(kù)

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

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

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

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

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

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

六、總結(jié)

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

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

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