云环境固有特性及其对密码效能的挑战*

高崇明，李跃武，杨建锋

（1.新疆量子通信技术有限公司，新疆 乌鲁木齐 830001；2.新疆数字证书中心，新疆 乌鲁木齐 830001）

0 引言

密码是网络安全的核心与关键。网络系统中密码措施的效能，愈发受到网络安全领域的关注。受此理念影响，人们开始热衷于在传统网络安全措施的基础之上，通过密码强化安全保障。但是，深入分析后，经常会发现，大量网络安全系统中，密码措施的效能并不乐观，时常也会事与愿违，并不能全部达到预期的效果。在传统的网络拓扑结构中，由于实体和资产（如数据）的存在形式是明确的，只要正确分析业务流程，了解作业的逻辑过程，明确业务对实体真实性保障强度的需求程度、对行为真实性保障强度的需求程度、对数据存储和传输的私密性与完整性保障强度的需求程度等基本问题（参考GB 17895—1999《计算机信息系统安全等级划分准则》），在具备合理的密码应用技能基础上，总能够配置出合理的解决方案，或者对既有解决方案给出合理的评价与判断。在理论研究和实际工作中都发现，云计算环境下的密码保障已经变得不再简单。本文试图通过对云架构模型，数据中心，网络、服务器和存储设备的虚拟化，边界及内容分发网络等云概念下的实体与资源的物理存在与逻辑存在的俯瞰，揭示云计算环境对商用密码应用规划与设计方案的效能的挑战。

1 物理存在与逻辑存在——云计算环境中的不同视域

云计算环境建立和分布在广大的空间区域的大型物理设施之上，但对使用者所呈现的却是逻辑上的网络功能。对于维护者来讲，电力、空调、线缆、机架、设备都是实实在在的物理存在；对于使用者（程序员或用户侧的维护者），感受到的却是如云原生（Cloud Native）、Kubernetes（K8S）、Storage Plugin 和Network Pluginde，以及容器（虚拟化）、微服务、应用程序接口（Application Programming Interface，API）服务器、基础设施即服务（Infrastructure as a Service，IaaS）、平台即服务（Platform as a Service，PaaS）、软件即服务（Software as a Service，SaaS）等逻辑上的存在。这体现了不同角色在存在形式上针对云设施的视域差异性。

1.1 云的逻辑存在——租户视域

大多数云租户能感受到的是虚拟化的功能，比如云原生概念下的云应用产品或服务，它们由应用计算管理平台K8S、存储代理Storage Plugin 或者网络代理Network Plugin 等支撑[1]。

如图1所示K8S以一种master 和node的 方式，将其对云资源的划分与管理功能呈现给用户接口（User Interface，UI）和client。Master 由API Server、Controler、Scheduler 和etcd 构成。

图1 K8S 架构的Master 和Node

具有复杂功能的用户应用，大多数会被分解为运行在容器中的微服务，最终再重组成完整的功能得以实现。这些运行微服务的容器，在K8S 中，由pod 承载。pod 之间不能直接联系，要通过API Server 完成数据的交互。这一机制，显然会使应用中微服务之间的流量非常大。

pod 是Kubernetes的一个最小调度以及资源单元。用户可以通过Kubernetes的pod API 生产一个pod，让Kubernetes 对这个Pod 进行调度，也就是把它放在某一个Kubernetes 管理的节点上运行起来。一个pod 简单来说是对一组容器的抽象，它里面会包含一个或多个容器。

按照国标GB 17895—1999的理念，每一个微服务都是一个主体，所有交互的数据都是客体，都是可管理的，也必定得到了管理系统的良好标识。运营者也可以跟踪与查找到这些标识，否则，应用也将会错乱。

1.2 云的物理存在——云运营商视域

云计算是一种模型[2,3]。所有的IT 资源与服务都是从底层基础设施中抽象出来的，在多租户的环境下按照需求和规模提供服务。每一种云都是服务与配置的组合。不管云的类型如何，没有网络就没有云。各种应用与数据将不能在云上传递。在云平台下，云服务商需要将位于全国各地，甚至全球各地的数据中心连接成一个有机整体。每一个数据中心的服务器数量可达几万台甚至几十万台。图2 为一个典型的云平台整体网络架构，其中重要的组成部分包括可用域（Availability Zone，AZ）、区域网络（Region Network，RN）、核心网络（Core Network，CN），以及边缘内容分发网络（Content Delivery Network，CDN）部分。一个AZ 中包括了一个或者多个数据中心（Data Center，DC），一个Region 中又包含多个AZ；Edge/CDN 是与运营商直接相连的部分；整个网络架构中最核心的是CN，它通过连接设备将各个Region 和Edge/CDN 连接在一起，使整个网络形成有机的整体。

图2 典型的云平台架构

脸书、瞻博网络、思科和谷歌等众多公司都采用了Clos 架构。应用Clos 架构的交换机的开关密度，与交换机端口数量N的关系是O(N)3/2，而传统的交换架构这个指标是O(N2)，所以在N较大时，Clos模型能降低交换机内部的开关密度。以脸书为例，开关矩阵类似于一块布的纤维，所以交换机内的架构被称为Switch Fabric。Fabric 架构中，骨干（Spine）交换机与多个Fabric 交换机连接，为数据中心的多个最小构成单元（Point Of Delivery，POD）提供连通性。其基本网络架构如图3 所示，图中用3 种方式表示了同一种网络架构。最上层是Spine 交换机，中间是Fabric 交换机，最下面是柜上交换机（switch on Top Of Rack，TOR）。

Spine 交换机相当于核心交换机。Spine 和Leaf 交换机之间通过等价多路径（Equal cost multipath，ECMP）动态选择多条路径，Leaf Switch 相当于传统3 层架构中的接入交换机，作为TOR 直接连接物理服务器。

在Fabric 架构中，存在着两个切面，左右切面是一个个POD，前后切面被称为SP（Spine Plane）。SP的数量总共有4 个，每个也是一个3 级Clos 架构。在SP中，Leaf是Fabric交换机，Spine就是Spine交换机。每个SP 中，由48 个Spine 交换机和N个Fabric 交换机相连组成，N的值相当于当前数据中心接入的POD 数。SP的三级Clos 架构和POD的3 级Clos 架构，共同构成了数据中心的5 级Clos 架构。因为在POD 内，Fabric 交换机通过48 个口与TOR 连接，所以在SP的Clos 架构中，Fabric 交换机的输入输出端口数量都是48个。根据Clos架构的特性，在SP中，Spine 交换机的数量只要大于或等于48，不论N（POD数）等于多少，都可以保证网络架构无阻塞。当然实际中N还受限于Spine 交换机的端口密度。

由于每个POD 有4 个Fabric 交换机，所以总共有4 个SP，如图3 所示。除了前面描述的POD和SP，图3 中还有黄色的Edge Plane，这是为数据中心提供南北向流量的模块。它们与Spine 交换机的连接方式，与二层的Spine/Leaf 架构一样。并且它们也是可以水平扩展的。

与传统的三层网络架构采用的生成树协议（SpanningTreepProtocol，STP），以及STP的改良版快速生成树协议（Rapid Spanning Tree Protocol，RSTP）和多生成树（Multiple Spanning Tree，MST），还有虚拟局域网（Virtual Local Area Network，VLAN）、内部网关协议（Open Shortest Path First，OSPF）、加强型内部网关路由协议（Enhanced Interior Gateway Routing Protocol，EIGRP）、内 部边界网关协议（Internal Border Gateway Protocol，IBGP）不同，Clos 是一个L2 和L3 混合的网络，采用的是外部边界网关协议（External Border Gateway Protocol，EBGP），采用4 字节抽象形式语法（Abstract Syntax Notation Dotone，ASN），对于10 万个服务器，每机架40 个的情形，需要2 500 个ASN，超过2 字节ASN的1 023 个的国际标准。

在整个网络中，AZ 由与图3 类似的结构连接而成。区域又由AZ 连接而成。两者方式都是类似的，最终通过核心交换设备把所有区域连接起来。Fabric 正如其含义一样，以非常庞大的数量，既连接了交换点，又连接着被交换设备。

图3 一个典型Clos 网络架构实例

2 K8S的Pod 与Clos 网络的Fabric

在K8S 云管理平台上，作为所有资源重新划分与功能组合的结果，pod 以最基本的容器形式出现，用以承载应用分解为微服务后的计算逻辑单元。应用服务的运行过程，最终体现为各pod 之间数据的交互，以及pod 对存储和网络资源的调用过程。按照我国GB/T 22239—2019《信息安全技术 网络安全等级保护基本要求》和GB/T 22240—2020《信息安全技术网络安全等级保护定级指南》等等级保护标准的基本理念，以及密码应用基本要求GM/T 0054—2018《信息系统密码应用基本要求》的基本理念，各个pod 理应是安全考察的最基本逻辑单元。

2.1 可信计算

pod 容器应为其所承载的微服务计算提供可信环境，同时承载各pod 本身的容器也应当有可信计算的要求。然而，由于K8S 采用的Master-Node 结构中，所有pod 对外是通过API 服务器中介的，这些API 服务器具有对外通信的职能。所以API 服务器的可信性就是极大的问题。

2.2 密码服务及其调用主体

承载微服务的pod，有可能分布在不同的AZ，甚至云架构的不同区域，也就是说，微服务的计算设备在物理空间位置上可能分布在全国，甚至全球。这就带来了传输安全的需求。安全性如何保障，是一个不得不面对的现实问题。假如采用密码技术，按照其应用框架[4]，必定要有pod的对密码资源的调用过程，以及密码资源层的服务过程和密码管理基础设施的维护机制，但在实际过程中，诸如安全认证、真实性、完整性等功能的需求，对密码资源的物理位置要求不明显。事实上，无论传输，还是存储的私密性需求，都对密码资源的物理位置非常敏感。因为在云虚拟化环境中实际运行的是应用的虚拟化实例，而Pod 最终在哪个物理CPU 等硬件资源上生成，实际上是不能预知的。这些物理CPU的位置，可能与逻辑上提供密码服务的资源相距数千公里。为认识到这一点，以图1 为例，假如在某时刻，平台在组织用户应用的计算资源时，涉及的pod1 假设运行在区域1的AZ1的数据中心1 内Fabric1 这根连线所连接的服务器上，而pod2 在区域2的AZ2的数据中心1 内fabric2 所连接的服务器上。pod1 和pod2 在计算协同时，都通过API 服务器实现数据交互。按照网络安全等级保护制度2.0（简称等保2.0）和密码应用基本要求，这里都要求引入私密性保障。于是，设计者必须面对一个现实的问题，即如图4 所示密码技术应用模型中，密码资源保障层的实体，部署在整个云架构的哪个位置，才更有利？

图4 密码应用技术框架

一个不假思索的想法可能是，由用户应用设计者决定。可细想之下就会发现，应用设计者并不知道podn在什么位置，实际上对podn的维护是由K8S 完成的。这样看来，K8S 是有义务考虑，所生成的实体之间交互时，可能涉及虚拟通道的私密性问题。假如这里是pod1、API 服务器和pod2 之间的通信，那么不禁要问，K8S 有这个机能吗？更普遍性的问题是，有任何一种云管理平台在生成实体时，同时生成了这些实体之间的安全传输通道（比如VPN）了吗？答案显然是否定的。这是因为，如果答案是肯定的，那么在面对如此灵活的实体生成需要时，它们所涉及的密钥管理问题怎么实现？尤其是实体的密钥存储在哪里？能适应哪个安全等级的需要？因此，在进行平台设计时，还应考虑到的是，平台并无法决定哪些实体之间不必要通信，只能默认所有实体均需要维护安全传输通道。这个数量将是O(N2)。这里N是整个云平台中生成的类似于pod 样的实体的总数目。对于一个有数十万台服务器的云平台，如果每个服务器不承载百倍千倍的虚拟实体，虚拟化实际是没有意义的。以100 000台服务器，1 000 倍的实体数量估算，这个数量级是1016。这是所涉及的具有完整的密码保障系统（如VPN）的数量级。这是任何云设施都无法保障其安全的。目前也没有任何云平台能做到这一点。

2.3 Fabric（纤维）

Fabric 是连接云中所有物理端口的物理连接线。云中的所有数据互动，最终都表现在某一组Fabric中的数据传送。运行在容器（如Pod）中的微服务的任何一次活动，总对应着一组特定的Fabrics 配合。于是，另一个自然的想法是，将容器里运行的服务所涉及的所有Fabrics 两端都加装安全设备。对于预设的系统，Fabric的这种动作虽是确定的，却不可预知。从这个意义上讲，这是混沌现象的特征。而这种特征，使得无法预判为哪些Fabrics 准备的密码设备，因此这个想法也是无法实现的。

3 结语

本文先从云的逻辑模型和物理模型营造了讨论问题的语言工具，同时俯瞰了目前云环境的全貌和细节，从宏观上概览了云网络架构和K8S 管理平台，从微观上深入到Fabrics 和容器（如pod）的概念。此外，还结合GB17895、等保2.0 及GM/T0054 对安全保障能力的基本要求，分析了云计算环境下，安全问题对密码应用的迫切要求，最后概述了云的某些固有特性对密码措施的效能的挑战。