引 言
当前网络空间安全已经成为各国的发展重点， 网络空间攻防博弈也已经从个人、团队等以盈利为 目的发展为政治斗争。为了提升网络攻防水平，美、英、日等国家纷纷建立网络安全实验平台开展 网络攻防理论研究、网络设备测试等，当前比较 著名的网络安全实验平台有美国的，National Cyber Range、Emulab,英国 BreakingPoint 和日本 Starbed 等。网络安全实验平台的建设必须具备网络拓 扑可重构、网络节点类型可定义、主机支持多配制 多系统、虚拟网络能够重现真实网络环境等4项要 求囹。虚拟化技术和仿真技术由于较大程度满足上 述要求，且具有较低的技术门槛和经费需求，使得 一般的科院院所也有能力构建中小型的网络安全实 验平台开展相关实验工作，因此被广泛用于网络安 全实验平台中。尤其在国内相关研究中，通过利 用OpenStack等开源软件构建基于虚拟化技术的网 络靶场、网络攻防实训平台成为众多高校科研院所 的选择。但基于OpenStack等虚拟化技术为网络 安全实验平台存在两点不足，一是当实验环境需要 部署大量业务时，通过基于虚拟机的业务部署存在部署慢、占用资源大的问题；另一个则是由于虚 拟机运行需要占用较大的硬件资源。
针对上述问题，陈一鸣提出一种基于Docker 的漏洞验证框架的设计，以及谢睿等提出基于 Docker的课程实验平台，这些方案通过将原来需 要基于虚拟机的业务部署方式改为基于Docker进 行部署，从而可以在单个虚拟机上动态部署多个业 务，大大加快了部署时间减少了硬件资源消耗。但 该方法在安全隔离方面，相比Kernel-based Virtual Machine(KVM)等虚拟化方案安全性较差，无法实现 与宿主系统的高安全隔离。因此，在实验平台中 包含Docker宿主节点安全，以及如何从Docker宿主节点建立安全通道采集业务状态信息等实验数据都成为现有基于Docker业务部署方案需要解决的问题。
本文在现有基于Docker的业务部署方案基础 上，针对其中的安全隔离、数据采集安全通道建立 等问题，利用Kubernetes的Docker管理平台提出一 种改进的网络安全实验平台构建方法。该方法基于 多域安全隔离的思路，将实验平台划分基础资源域、 实验数据域、业务管理域、实验场景域四个域，通 过虚拟化技术将基础实验设施、业务镜像等基础资 源与其他安全域进行逻辑，通过网络隔离保证基础 资源域安全性；针对实验数据域需要采集实验场景 中数据的取消，通过建立基于两级防火墙数据建立 单向数据采集流的安全采集通道实施保护；业务管 理域、实验场景域由于与安全实验联系紧密，具有 较多的数据通道，因此仅在实验开始前建立，并在 实验结束后删除，从而消除安全隐患。
01
基于Docker网络安全实验平台原理介绍
基于Docker网络安全实验平台利用OpenStack 等开源基础设施即服务(Infrastructure as a Service, laaS)平台提供基础设施调度，并在此基础上基于 Kubernetes等Docker管理平台实现业务部署，进一 步考虑业务部署中对场景隔离、监控评估等方面的需求，其系统构成如图1所示。
图1基于Docker网络安全实验平台系统构成
图1中包含了基于OpenStack的网络安全实验 基础设施、基于Kubernetes的容器管理、业务镜像 以及实验数据存储集群四个部分。
(1 ) OpenStack提供网络安全实验基础设施， 以及通过虚拟化手段实现实验场景级隔离。针对不 同的实验场景，通过加载不同Kubernetes主节点， 为各场景建立独立的业务部署系统。
(2 )Kubernetes为业务部署提供统一管理平 台，实现业务的下发、部署、状态监控等概功能；
(3)业务镜像用于存放业务镜像，不同的实 验平台景共享业务镜像；
(4)业务状态监控数据库用于存放各个业务 运行状态数据，为实验数据提供业务状态级数据。
02
改进的网络安全实验平台
2.1 安全域划分
借鉴网络空间安全靶场设计中域的概念，按 照安全等级将系统划分为基础资源域、实验数据域、 业务管理域、实验场景域四个不同的安全域，他们 之间的关系如图2所示。
图２ 实验平台安全域划分
(1) 基础资源域
其中基础资源具有最高的安全等级，为整个网 络安全实验平台提供虚拟机、Docker镜像等公共资 源。实验开始前，与业务管理域临时建立连接用于 分配业务资源，实验开始后与其他域完全隔离。
(2) 实验数据域
实验数据域用于采集存储实验数据，比如通过 部署业务状态信息存储数据库存放业务运行状态等 数据。该域中的数据用于支撑实验状态监控、实验 评估等，因此数据会进入分析、评估等实验系统， 其安全等级高于业务管理域和实验场景域；但其在 实验过程中与业务管理和实验场景域存在数据通 道，因此安全等级低于基础资源域。
(3) 业务管理域
业务管理域指由各实验平台景中Kubernetes主 节点构成的域，该节点负责从拉取业务镜像部署到 实验环境，同时在实验过程中采集各个node的业 务状态信息，供实验分析、评估使用。由于业务域 中的节点在实验开始后，要从实验场景中釆集数据, 因此存在较高的安全溢出风险，其安全等级仅高于 实验场景域，业务域中的Kubernetes各主节点之间 彼此隔离，在相应的实验平台景完成实验后，随实 验场景一起删除，消除安全隐患。
(4)实验场景域
实验场景域是网络安全实验开展的网络空间， 所有实验业务均被部署在该域中，各个业务的安全 漏洞等问题被充分暴露，因此具有最低的安全等级。任何安全实验结束后，所有业务节点均随着实验场 景一起删除。
2.2 各域之间的安全隔离关系
本节根据各个域的安全属性，对各个域之间的 安全隔离关系进行说明，如图3所示。
图3按区域隔离关系
在本方案中，基础资源域有最高的安全等级， 其仅在实验开始前与业务域有数据交互，实验开始 后与其他域网络逻辑隔离，具备最高等级安全保护；实验数据域与业务管理域之间通过防火墙进行隔 离，通过会话控制、IP限制、端口控制等方式进行 安全保护，安全防护低于基础资源域；业务管理域 与实验数据域之间同样通过防火墙进行会话、IP限 制、端口控制等方式进行安全保护。
2.3 基于多安全域的平台构建
在引入不同的安全域后，对本文给出一种如 图4的改进安全实验平台系统架构。
图４ 基于安全域的安全实验平台系统构成
在业务的具体部署中，每个业务基于场景进行 隔离，每个场景内有一个Kubernetes主节点(master ) 和若干个node节点，主节点从业务镜像拉取相应 的资源将业务部署到指定的虚拟机，具体过程如 图5所示。
图5业务部署过程
业务部署过程：
第一步：由实验平台发起业务部署请求，请求 首先传递到OpenStack管理服务器，由管理服务器 根据业务部署的场景，分配相应的虚拟机资源，首 先生成一个包含Kubernetes主节点和多个node节 点，业务部署基础环境，如图6所示。
图6生成业务部署基础环境
第二步：Kubernetes主节点根据需要部署的业 务，从业务镜像服务器获取相应的镜像资源，并将 相应的业务部署到相应的node节点上，如图7所示。由于单个node可以部署多个业务，显著降低了虚 拟的使用量，从而大大增加了资源利用率。
图7生成业务部署虚拟机
第三步：在Kubernetes主节点和业务状态监控 数据库之间建立数据连接，用于采集业务状态信息。同时，通过防火墙实施安全隔离，仅允许监控数据通 过防火墙，从而实现监控数据与实验平台的安全隔离。
03
安全性分析
3.1 基础资源域安全性
OpenStack通过创建虚拟机部署业务，各个 docker运行在虚拟机之上，因此相比将docker直接 部署到基础设施，由虚拟机提供了更高的安全隔离。同时，当实验结束后所有的虚拟机都会被删除，进 一步确保了基础设施的安全性。从而有效弥补了现 有docker环境安全性的不足。
对于基础资源域中的容器镜像资源，由于网络 安全实验平台并不是真实业务环境，通过控制镜像 服务器与Kubernetes主节点连接时间实现安全隔离。即将业务镜像拉取安排在实验开始前，一旦镜像下 载完成立即断开业务镜像与实验管理域的连接，从而确保了安全性。
3.2 实验数据域安全性
实验数据域中仅用于存储包括业务状态信息等 实验数据，其安全威胁主要来自数据釆集过程中， 由业务管理域渗透过来的安全威胁。因此实验数据 域和业务管理域之间通过增加防火墙进行安全隔 离，且实验数据域的安全等级高于业务管理域，阻 止任何从业务管理域发起的会话请求。
3.3 业务管理域安全性
业务管理域中负责对实验场景中的业务进行 部署和监控，因此和实验场景中存在大量的数据交 互。其安全威胁主要来自两个方面：实验过程中通 过业务管理和数据采集通道溢出的攻击；实验过程 中不同场景之间通过业务管理域跳转的跨场景攻击 溢出。
由于业务管理域必须直接与实验场景域交互， 因此通过增加防火墙的手段，阻断除业务管理和采 集数据通路以外的数据通道。
针对跨场景攻击溢出，通过为每个场景配置独 立的Kubemetes主节点，阻断场景间的连接通路， 从而可以消除安全风险。
3.4 安全性实验场景域
实验场景域中开展各类网络安全实验，也是对 实验平台造成安全威胁的源头。通过在实验开始前 创建新的实验场景，实验完成后删除实验场景的方 式进行管理。
3.5 数据采集通道安全性
数据采集通道横跨实验数据域、业务管理域和 实验场景域三个域，是域间安全威胁传递的唯一通 道。本文通过一种基于数据推拉的方式建立数据釆 集通道，其中实验数据域通过拉的方式从业务管理 域获取数据，实验场景域通过推的方式发送数据， 过程如图8所示。
图8业务状态数据采集推拉过程
在实验过程中，由于各个节点业务状态变化的 不一致，通过拉取方式难以实现获取效率与开销的 平衡，因此实验场景中的node节点通过推的方式将 业务运行状态发送给业务管理域中的Kubemetes主 节点；而实验数据域仅需要跟业务域中的Kubemetes 主节点进行通信，其开销远远小于Kubemetes主节 点与nodes之间的开销，因此采用拉的方式获取数据。
由于釆用不同数据获取方式，实验数据域采用 拉的方式从业务管理域获取数据，其防火墙策略设 置为阻止由业务管理域主动向实验数据域发起的 会话请求；业务管理域和实验场景域之间则可以 由实验管理域中的节点主动向业务管理域发起会 话请求。
