云環境固有特性及其對密碼效能的挑戰

密碼是網絡安全的核心與關鍵。網絡系統中密碼措施的效能，愈發受到網絡安全領域的關注。受此理念影響，人們開始熱衷于在傳統網絡安全措施的基礎之上，通過密碼強化安全保障。但是，深入分析后，經常會發現，大量網絡安全系統中，密碼措施的效能并不樂觀，時常也會事與愿違，并不能全部達到預期的效果。在傳統的網絡拓撲結構中，由于實體和資產（如數據）的存在形式是明確的，只要正確分析業務流程，了解作業的邏輯過程，明確業務對實體真實性保障強度的需求程度、對行為真實性保障強度的需求程度、對數據存儲和傳輸的私密性與完整性保障強度的需求程度等基本問題（參考 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.