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

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

云计算环境建立和分布在广大的空间区域的大型物理设施之上，但对使用者所呈现的却是逻辑上的网络功能。对于维护者来讲，电力、空调、线缆、机架、设备都是实实在在的物理存在；对于使用者（程序员或用户侧的维护者），感受到的却是如 云 原 生（Cloud Native）、Kubernetes（K8S）、Storage Plugin 和 Network Pluginde， 以 及 容 器（ 虚拟 化 ）、 微 服 务、 应 用 程 序 接 口（ApplicationProgramming 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所示 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 云的物理存在——云运营商视域

云计算是一种模型 。所有的 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(N 2)，所以在 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 架构一样。并且它们也是可以水平扩展的。

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

与传统的三层网络架构采用的生成树协议（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 正如其含义一样，以非常庞大的数量，既连接了交换点，又连接着被交换设备。

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

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

图 4 密码应用技术框架

2.3 Fabric（纤维）

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

３结　语

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

引用本文：高崇明 , 李跃武 , 杨建锋．云环境固有特性及其对密码效能的挑战 [J]. 通信技术 ,2022(3):375-379.