高崇明，李躍武，楊建鋒

（1.新疆量子通信技術(shù)有限公司，新疆 烏魯木齊 830001；2.新疆數(shù)字證書中心，新疆 烏魯木齊 830001）

0 引言

密碼是網(wǎng)絡(luò)安全的核心與關(guān)鍵。網(wǎng)絡(luò)系統(tǒng)中密碼措施的效能，愈發(fā)受到網(wǎng)絡(luò)安全領(lǐng)域的關(guān)注。受此理念影響，人們開始熱衷于在傳統(tǒng)網(wǎng)絡(luò)安全措施的基礎(chǔ)之上，通過密碼強化安全保障。但是，深入分析后，經(jīng)常會發(fā)現(xiàn)，大量網(wǎng)絡(luò)安全系統(tǒng)中，密碼措施的效能并不樂觀，時常也會事與愿違，并不能全部達到預(yù)期的效果。在傳統(tǒng)的網(wǎng)絡(luò)拓撲結(jié)構(gòu)中，由于實體和資產(chǎn)（如數(shù)據(jù)）的存在形式是明確的，只要正確分析業(yè)務(wù)流程，了解作業(yè)的邏輯過程，明確業(yè)務(wù)對實體真實性保障強度的需求程度、對行為真實性保障強度的需求程度、對數(shù)據(jù)存儲和傳輸?shù)乃矫苄耘c完整性保障強度的需求程度等基本問題（參考GB 17895—1999《計算機信息系統(tǒng)安全等級劃分準則》），在具備合理的密碼應(yīng)用技能基礎(chǔ)上，總能夠配置出合理的解決方案，或者對既有解決方案給出合理的評價與判斷。在理論研究和實際工作中都發(fā)現(xiàn)，云計算環(huán)境下的密碼保障已經(jīng)變得不再簡單。本文試圖通過對云架構(gòu)模型，數(shù)據(jù)中心，網(wǎng)絡(luò)、服務(wù)器和存儲設(shè)備的虛擬化，邊界及內(nèi)容分發(fā)網(wǎng)絡(luò)等云概念下的實體與資源的物理存在與邏輯存在的俯瞰，揭示云計算環(huán)境對商用密碼應(yīng)用規(guī)劃與設(shè)計方案的效能的挑戰(zhàn)。

1 物理存在與邏輯存在——云計算環(huán)境中的不同視域

云計算環(huán)境建立和分布在廣大的空間區(qū)域的大型物理設(shè)施之上，但對使用者所呈現(xiàn)的卻是邏輯上的網(wǎng)絡(luò)功能。對于維護者來講，電力、空調(diào)、線纜、機架、設(shè)備都是實實在在的物理存在；對于使用者（程序員或用戶側(cè)的維護者），感受到的卻是如云原生（Cloud Native）、Kubernetes（K8S）、Storage Plugin 和Network Pluginde，以及容器（虛擬化）、微服務(wù)、應(yīng)用程序接口（Application Programming Interface，API）服務(wù)器、基礎(chǔ)設(shè)施即服務(wù)（Infrastructure as a Service，IaaS）、平臺即服務(wù)（Platform as a Service，PaaS）、軟件即服務(wù)（Software as a Service，SaaS）等邏輯上的存在。這體現(xiàn)了不同角色在存在形式上針對云設(shè)施的視域差異性。

1.1 云的邏輯存在——租戶視域

大多數(shù)云租戶能感受到的是虛擬化的功能，比如云原生概念下的云應(yīng)用產(chǎn)品或服務(wù)，它們由應(yīng)用計算管理平臺K8S、存儲代理Storage Plugin 或者網(wǎng)絡(luò)代理Network Plugin 等支撐[1]。

如圖1所示K8S以一種master 和node的 方式，將其對云資源的劃分與管理功能呈現(xiàn)給用戶接口（User Interface，UI）和client。Master 由API Server、Controler、Scheduler 和etcd 構(gòu)成。

圖1 K8S 架構(gòu)的Master 和Node

具有復(fù)雜功能的用戶應(yīng)用，大多數(shù)會被分解為運行在容器中的微服務(wù)，最終再重組成完整的功能得以實現(xiàn)。這些運行微服務(wù)的容器，在K8S 中，由pod 承載。pod 之間不能直接聯(lián)系，要通過API Server 完成數(shù)據(jù)的交互。這一機制，顯然會使應(yīng)用中微服務(wù)之間的流量非常大。

pod 是Kubernetes的一個最小調(diào)度以及資源單元。用戶可以通過Kubernetes的pod API 生產(chǎn)一個pod，讓Kubernetes 對這個Pod 進行調(diào)度，也就是把它放在某一個Kubernetes 管理的節(jié)點上運行起來。一個pod 簡單來說是對一組容器的抽象，它里面會包含一個或多個容器。

按照國標GB 17895—1999的理念，每一個微服務(wù)都是一個主體，所有交互的數(shù)據(jù)都是客體，都是可管理的，也必定得到了管理系統(tǒng)的良好標識。運營者也可以跟蹤與查找到這些標識，否則，應(yīng)用也將會錯亂。

1.2 云的物理存在——云運營商視域

云計算是一種模型[2,3]。所有的IT 資源與服務(wù)都是從底層基礎(chǔ)設(shè)施中抽象出來的，在多租戶的環(huán)境下按照需求和規(guī)模提供服務(wù)。每一種云都是服務(wù)與配置的組合。不管云的類型如何，沒有網(wǎng)絡(luò)就沒有云。各種應(yīng)用與數(shù)據(jù)將不能在云上傳遞。在云平臺下，云服務(wù)商需要將位于全國各地，甚至全球各地的數(shù)據(jù)中心連接成一個有機整體。每一個數(shù)據(jù)中心的服務(wù)器數(shù)量可達幾萬臺甚至幾十萬臺。圖2 為一個典型的云平臺整體網(wǎng)絡(luò)架構(gòu)，其中重要的組成部分包括可用域（Availability Zone，AZ）、區(qū)域網(wǎng)絡(luò)（Region Network，RN）、核心網(wǎng)絡(luò)（Core Network，CN），以及邊緣內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network，CDN）部分。一個AZ 中包括了一個或者多個數(shù)據(jù)中心（Data Center，DC），一個Region 中又包含多個AZ；Edge/CDN 是與運營商直接相連的部分；整個網(wǎng)絡(luò)架構(gòu)中最核心的是CN，它通過連接設(shè)備將各個Region 和Edge/CDN 連接在一起，使整個網(wǎng)絡(luò)形成有機的整體。

圖2 典型的云平臺架構(gòu)

臉書、瞻博網(wǎng)絡(luò)、思科和谷歌等眾多公司都采用了Clos 架構(gòu)。應(yīng)用Clos 架構(gòu)的交換機的開關(guān)密度，與交換機端口數(shù)量N的關(guān)系是O(N)3/2，而傳統(tǒng)的交換架構(gòu)這個指標是O(N2)，所以在N較大時，Clos模型能降低交換機內(nèi)部的開關(guān)密度。以臉書為例，開關(guān)矩陣類似于一塊布的纖維，所以交換機內(nèi)的架構(gòu)被稱為Switch Fabric。Fabric 架構(gòu)中，骨干（Spine）交換機與多個Fabric 交換機連接，為數(shù)據(jù)中心的多個最小構(gòu)成單元（Point Of Delivery，POD）提供連通性。其基本網(wǎng)絡(luò)架構(gòu)如圖3 所示，圖中用3 種方式表示了同一種網(wǎng)絡(luò)架構(gòu)。最上層是Spine 交換機，中間是Fabric 交換機，最下面是柜上交換機（switch on Top Of Rack，TOR）。

Spine 交換機相當于核心交換機。Spine 和Leaf 交換機之間通過等價多路徑（Equal cost multipath，ECMP）動態(tài)選擇多條路徑，Leaf Switch 相當于傳統(tǒng)3 層架構(gòu)中的接入交換機，作為TOR 直接連接物理服務(wù)器。

在Fabric 架構(gòu)中，存在著兩個切面，左右切面是一個個POD，前后切面被稱為SP（Spine Plane）。SP的數(shù)量總共有4 個，每個也是一個3 級Clos 架構(gòu)。在SP中，Leaf是Fabric交換機，Spine就是Spine交換機。每個SP 中，由48 個Spine 交換機和N個Fabric 交換機相連組成，N的值相當于當前數(shù)據(jù)中心接入的POD 數(shù)。SP的三級Clos 架構(gòu)和POD的3 級Clos 架構(gòu)，共同構(gòu)成了數(shù)據(jù)中心的5 級Clos 架構(gòu)。因為在POD 內(nèi)，F(xiàn)abric 交換機通過48 個口與TOR 連接，所以在SP的Clos 架構(gòu)中，F(xiàn)abric 交換機的輸入輸出端口數(shù)量都是48個。根據(jù)Clos架構(gòu)的特性，在SP中，Spine 交換機的數(shù)量只要大于或等于48，不論N（POD數(shù)）等于多少，都可以保證網(wǎng)絡(luò)架構(gòu)無阻塞。當然實際中N還受限于Spine 交換機的端口密度。

由于每個POD 有4 個Fabric 交換機，所以總共有4 個SP，如圖3 所示。除了前面描述的POD和SP，圖3 中還有黃色的Edge Plane，這是為數(shù)據(jù)中心提供南北向流量的模塊。它們與Spine 交換機的連接方式，與二層的Spine/Leaf 架構(gòu)一樣。并且它們也是可以水平擴展的。

與傳統(tǒng)的三層網(wǎng)絡(luò)架構(gòu)采用的生成樹協(xié)議（SpanningTreepProtocol，STP），以及STP的改良版快速生成樹協(xié)議（Rapid Spanning Tree Protocol，RSTP）和多生成樹（Multiple Spanning Tree，MST），還有虛擬局域網(wǎng)（Virtual Local Area Network，VLAN）、內(nèi)部網(wǎng)關(guān)協(xié)議（Open Shortest Path First，OSPF）、加強型內(nèi)部網(wǎng)關(guān)路由協(xié)議（Enhanced Interior Gateway Routing Protocol，EIGRP）、內(nèi) 部邊界網(wǎng)關(guān)協(xié)議（Internal Border Gateway Protocol，IBGP）不同，Clos 是一個L2 和L3 混合的網(wǎng)絡(luò)，采用的是外部邊界網(wǎng)關(guān)協(xié)議（External Border Gateway Protocol，EBGP），采用4 字節(jié)抽象形式語法（Abstract Syntax Notation Dotone，ASN），對于10 萬個服務(wù)器，每機架40 個的情形，需要2 500 個ASN，超過2 字節(jié)ASN的1 023 個的國際標準。

在整個網(wǎng)絡(luò)中，AZ 由與圖3 類似的結(jié)構(gòu)連接而成。區(qū)域又由AZ 連接而成。兩者方式都是類似的，最終通過核心交換設(shè)備把所有區(qū)域連接起來。Fabric 正如其含義一樣，以非常龐大的數(shù)量，既連接了交換點，又連接著被交換設(shè)備。

圖3 一個典型Clos 網(wǎng)絡(luò)架構(gòu)實例

2 K8S的Pod 與Clos 網(wǎng)絡(luò)的Fabric

在K8S 云管理平臺上，作為所有資源重新劃分與功能組合的結(jié)果，pod 以最基本的容器形式出現(xiàn)，用以承載應(yīng)用分解為微服務(wù)后的計算邏輯單元。應(yīng)用服務(wù)的運行過程，最終體現(xiàn)為各pod 之間數(shù)據(jù)的交互，以及pod 對存儲和網(wǎng)絡(luò)資源的調(diào)用過程。按照我國GB/T 22239—2019《信息安全技術(shù) 網(wǎng)絡(luò)安全等級保護基本要求》和GB/T 22240—2020《信息安全技術(shù)網(wǎng)絡(luò)安全等級保護定級指南》等等級保護標準的基本理念，以及密碼應(yīng)用基本要求GM/T 0054—2018《信息系統(tǒng)密碼應(yīng)用基本要求》的基本理念，各個pod 理應(yīng)是安全考察的最基本邏輯單元。

2.1 可信計算

pod 容器應(yīng)為其所承載的微服務(wù)計算提供可信環(huán)境，同時承載各pod 本身的容器也應(yīng)當有可信計算的要求。然而，由于K8S 采用的Master-Node 結(jié)構(gòu)中，所有pod 對外是通過API 服務(wù)器中介的，這些API 服務(wù)器具有對外通信的職能。所以API 服務(wù)器的可信性就是極大的問題。

2.2 密碼服務(wù)及其調(diào)用主體

承載微服務(wù)的pod，有可能分布在不同的AZ，甚至云架構(gòu)的不同區(qū)域，也就是說，微服務(wù)的計算設(shè)備在物理空間位置上可能分布在全國，甚至全球。這就帶來了傳輸安全的需求。安全性如何保障，是一個不得不面對的現(xiàn)實問題。假如采用密碼技術(shù)，按照其應(yīng)用框架[4]，必定要有pod的對密碼資源的調(diào)用過程，以及密碼資源層的服務(wù)過程和密碼管理基礎(chǔ)設(shè)施的維護機制，但在實際過程中，諸如安全認證、真實性、完整性等功能的需求，對密碼資源的物理位置要求不明顯。事實上，無論傳輸，還是存儲的私密性需求，都對密碼資源的物理位置非常敏感。因為在云虛擬化環(huán)境中實際運行的是應(yīng)用的虛擬化實例，而Pod 最終在哪個物理CPU 等硬件資源上生成，實際上是不能預(yù)知的。這些物理CPU的位置，可能與邏輯上提供密碼服務(wù)的資源相距數(shù)千公里。為認識到這一點，以圖1 為例，假如在某時刻，平臺在組織用戶應(yīng)用的計算資源時，涉及的pod1 假設(shè)運行在區(qū)域1的AZ1的數(shù)據(jù)中心1 內(nèi)Fabric1 這根連線所連接的服務(wù)器上，而pod2 在區(qū)域2的AZ2的數(shù)據(jù)中心1 內(nèi)fabric2 所連接的服務(wù)器上。pod1 和pod2 在計算協(xié)同時，都通過API 服務(wù)器實現(xiàn)數(shù)據(jù)交互。按照網(wǎng)絡(luò)安全等級保護制度2.0（簡稱等保2.0）和密碼應(yīng)用基本要求，這里都要求引入私密性保障。于是，設(shè)計者必須面對一個現(xiàn)實的問題，即如圖4 所示密碼技術(shù)應(yīng)用模型中，密碼資源保障層的實體，部署在整個云架構(gòu)的哪個位置，才更有利？

圖4 密碼應(yīng)用技術(shù)框架

一個不假思索的想法可能是，由用戶應(yīng)用設(shè)計者決定?？杉毾胫戮蜁l(fā)現(xiàn)，應(yīng)用設(shè)計者并不知道podn在什么位置，實際上對podn的維護是由K8S 完成的。這樣看來，K8S 是有義務(wù)考慮，所生成的實體之間交互時，可能涉及虛擬通道的私密性問題。假如這里是pod1、API 服務(wù)器和pod2 之間的通信，那么不禁要問，K8S 有這個機能嗎？更普遍性的問題是，有任何一種云管理平臺在生成實體時，同時生成了這些實體之間的安全傳輸通道（比如VPN）了嗎？答案顯然是否定的。這是因為，如果答案是肯定的，那么在面對如此靈活的實體生成需要時，它們所涉及的密鑰管理問題怎么實現(xiàn)？尤其是實體的密鑰存儲在哪里？能適應(yīng)哪個安全等級的需要？因此，在進行平臺設(shè)計時，還應(yīng)考慮到的是，平臺并無法決定哪些實體之間不必要通信，只能默認所有實體均需要維護安全傳輸通道。這個數(shù)量將是O(N2)。這里N是整個云平臺中生成的類似于pod 樣的實體的總數(shù)目。對于一個有數(shù)十萬臺服務(wù)器的云平臺，如果每個服務(wù)器不承載百倍千倍的虛擬實體，虛擬化實際是沒有意義的。以100 000臺服務(wù)器，1 000 倍的實體數(shù)量估算，這個數(shù)量級是1016。這是所涉及的具有完整的密碼保障系統(tǒng)（如VPN）的數(shù)量級。這是任何云設(shè)施都無法保障其安全的。目前也沒有任何云平臺能做到這一點。

2.3 Fabric（纖維）

Fabric 是連接云中所有物理端口的物理連接線。云中的所有數(shù)據(jù)互動，最終都表現(xiàn)在某一組Fabric中的數(shù)據(jù)傳送。運行在容器（如Pod）中的微服務(wù)的任何一次活動，總對應(yīng)著一組特定的Fabrics 配合。于是，另一個自然的想法是，將容器里運行的服務(wù)所涉及的所有Fabrics 兩端都加裝安全設(shè)備。對于預(yù)設(shè)的系統(tǒng)，F(xiàn)abric的這種動作雖是確定的，卻不可預(yù)知。從這個意義上講，這是混沌現(xiàn)象的特征。而這種特征，使得無法預(yù)判為哪些Fabrics 準備的密碼設(shè)備，因此這個想法也是無法實現(xiàn)的。

3 結(jié)語

本文先從云的邏輯模型和物理模型營造了討論問題的語言工具，同時俯瞰了目前云環(huán)境的全貌和細節(jié)，從宏觀上概覽了云網(wǎng)絡(luò)架構(gòu)和K8S 管理平臺，從微觀上深入到Fabrics 和容器（如pod）的概念。此外，還結(jié)合GB17895、等保2.0 及GM/T0054 對安全保障能力的基本要求，分析了云計算環(huán)境下，安全問題對密碼應(yīng)用的迫切要求，最后概述了云的某些固有特性對密碼措施的效能的挑戰(zhàn)。