金融行业轻量级虚拟化架构安全部署研究

◎电子商务与电子支付国家工程实验室（上海）、中国银联股份有限公司（上海）吴金坛 邱震尧 杨阳

一、引言

作为云计算技术的基石，虚拟化技术是解决大规模基础设施资源管理问题的关键所在[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 等轻量级容器虚拟机开源产品支持为每个容器创建独立内核环境，可用于加强容器的隔离性安全。

（二）搭建行业容器可信镜像仓库

为了满足容器化应用普及后对大量镜像的安全存储与传输需求，保证镜像从构建来源、打包发布、获取途径、运行使用等全生命周期的安全性，同时便于做好各类公共与自研镜像的版本控制，有条件的金融机构应建立自己的安全镜像仓库，或联合建立金融行业共享的安全镜像仓库，用于发布和存储安全可控的常用公共镜像与自主开发镜像版本，并建立可信身份认证交互机制保证镜像的传输安全性。此外，可信镜像仓库应结合镜像漏洞扫描工具与人工审计的方式严格管控镜像的上传发布流程，保证镜像的源头安全性。

（三）制定行业容器合规检查体系

为了应对容器应用部署的快速扩张及其引入的安全风险，保证自有容器云平台的安全稳定运行，各金融机构应积极制定符合金融行业自身业务需求与技术实际的容器安全规范，最终形成容器安全合规检查体系与相应平台。同时，各金融机构还应积极推动容器安全在国内特别是金融行业的标准化工作。

（四）部署行业容器安全管理平台

对于日益庞大的集群化、分布式容器云环境而言，系统化的安全风险需要通过系统化的管理机制进行应对和化解。因此，系统化安全管理平台的构建对于容器环境而言具有十分重要的意义和必要性。

金融行业应加快建立对设备资源、容器资源、镜像资源、镜像仓库等进行有效管理的安全监控平台与相关体系化机制，并同步研发相关安全工具库，将镜像漏洞扫描、安全合规检查等功能进行整合嵌入，搭建包含资产管理、漏洞检测、合规检查、入侵检测等安全功能的统一化管理入口，实现与基础应用软件、可信镜像仓库、合规检查体系等其他自主化工作的相互配合、相互推进。

六、总结

安全是金融科技创新中不可逾越的红线。本文就轻量级虚拟化架构——容器技术及其存在的安全风险、安全需求、安全机制等进行了分析，并面向金融行业云的轻量化建设的给出了一系列安全建议。

与传统虚拟化技术相比，容器技术具有敏捷化、轻量化等特点。与此同时，容器技术对于高效性的追求也牺牲了隔离性等安全要求，在安全性方面与传统虚拟化技术相比还存在较大差距，且所涉及的面较广，涉及到容器的镜像安全、内核安全、网络安全、隔离性安全、运行时安全等各个层面。

因此，金融行业相关机构在应用容器技术进行轻量级虚拟化应用部署时，应充分评估安全风险，根据不同场景制定相应安全需求，并整合相关安全解决方案，形成容器安全应用最佳实践。同时，面对复杂严峻的国际网络空间安全形势，需根据金融业务场景，批判性地使用业界相关开源软件进行定制开发，进而实现金融基础设施与金融信息系统的自主可控安全。